Привет! Меня зовут Дима Дынников, я руководитель команды продуктовой аналитики в Профи. Расскажу, как мы ищем поведенческие аномалии в продукте и зачем это вообще нужно делать.

Что такое аномалии

Покажу на примере. На скрине ниже — карточка заказа в приложении Профи для специалиста. Можно нажать на карту и посмотреть, где именно специалисту нужно выполнить заказ.

Карточка заказа в приложении для специалистов
Карточка заказа в приложении для специалистов

Каждый раз, когда специалист нажимает на карту, мы видим это в аналитике. Он нажимает сначала на заказ, потом на карту — это базовый сценарий.

Но как-то мы увидели, что в одном и том же заказе специалист за короткий промежуток времени много раз нажимает на карту и выходит. А потом заходит в другой заказ и тоже много раз нажимает на карту. И так делает большинство специалистов.

Мы видим поведение, которое отличается от привычного, — это аномалия.

Количество кликов на карту в заказе по дням
Количество кликов на карту в заказе по дням

Оказалось, что в этот день мы сломали карту. Она не открывалась, и специалисты нажимали на неё много раз.

Другой пример — в один из дней мы сломали аналитику на экране авторизации. К нам просто перестало приходить одно событие. Но мы смогли быстро это заметить и починить.

Количество событий авторизации по днями
Количество событий авторизации по днями

Чтобы улучшать продукт и оперативно фиксить баги, мы стали искать эти аномалии. Но сначала не очень понимали, как это делать.

А технические мониторинги для кого?

Аномалии не всегда вызваны техническими ошибками. Например, на графике ниже видно, что мы резко перестали показывать баннер с просьбой оценить наше приложение. Алгоритм, который выбирал, в какой момент нужно показать этот баннер, опирался на логику подсчёта откликов. А мы случайно изменили эту логику, поэтому баннер стал показываться реже. Пользователи практически его не видели.

Здесь не было технической ошибки, но нам всё равно важно мониторить подобные продуктовые баги.

Количество событий показа баннера (картинка от бота)
Количество событий показа баннера (картинка от бота)

Почему искать аномалии на графиках событий – плохая идея

На Профи зарегистрировано более 2,5 миллионов специалистов. За прошедший октябрь мы записали более 400 миллионов событий от 382 тысяч уникальных пользователей, а уникальных событий было 284. Следить за графиком каждого события вручную — нереально. Нужен был детектор аномалий.

Количество событий поведенческой аналитики по дням
Количество событий поведенческой аналитики по дням

Что за детектор аномалий

Это бот в Slack, который каждый день анализирует миллионы событий и подробно показывает, что у нас происходит с продуктом. Если он видит, что каких-то событий стало слишком много или слишком мало, то выводит картинки в чат. После этого можно пойти посмотреть, что именно произошло.

Пример ежедневного отчёта бота в Slack
Пример ежедневного отчёта бота в Slack

Но бота было мало...

Даже с ботом приходилось делать много рутинной работы: смотреть, где возникла аномалия, из-за чего это произошло, выяснять, было ли это запланировано или появился баг.

Чтобы эту рутину не делать каждый раз, я сделал дашборд по аномалиям. В нём можно выбрать нужное событие и посмотреть, в какой момент они появляются. Можно сделать это в разрезе вертикалей или новых релизов.

Главная страница дашборда по аномалиям в Metabase
Главная страница дашборда по аномалиям в Metabase

Технические подробности реализации

  • Каждый день в 6 утра запускается скрипт на питоне, который выгружает из ClickHouse все события за последние 6 недель, предварительно агрегируя их по часам в разрезе платформы, события и уникальных для этого события параметров (их список есть в виде словаря внутри самого скрипта).

  • Данные предобрабатываются и анализируются на предмет аномалий с помощью библиотеки ADTK.

  • Если видим, что за прошедшие сутки наблюдаются аномалии, — отрисовываем почасовой график этого события за последние 6 недель.

  • Все аномальные события отправляются в специальный чат в Slack — отдельно «негативные» аномалии, отдельно «позитивные».

  • Все аномальные события «проливаем» в отдельную витрину, на которой строим дашборд по аномалиям. Это нужно для того, чтобы выводить на дашборд только аномальные данные (сам Кликхаус ничего не знает про аномалии, т.к. они считаются в питоне).

  • Всё, что пролили, выводим во всевозможных разрезах, чтобы быстро узнать точное время возникновения аномалии, масштаб, какие версии приложения затрагивает, на каких вертикалях наблюдается и т.д.

В большинстве случаев бот в связке с дашбордом позволяет достаточно оперативно выявить аномалию и понять её первопричину минут за 10.

Что получается ловить

К сожалению, а может и к счастью, детектор аномалий срабатывает достаточно часто. В большинстве случаев это штатные и запланированные явления, но иногда это что-то критичное, что очень больно пропустить.

Вот типы проблем, которые мы ловим детектором аномалий:

  • Технические баги. Да, чаще всего к моменту отчета об аномалии (6 утра) о баге уже известно из технических мониторингов или жалоб пользователей. Но однажды технический мониторинг промолчал, а баг был критичный (хоть и затрагивал небольшое число пользователей). О нём тогда узнали от бота.

  • Продуктовые баги. Это когда технически всё работает штатно, но пользовательское поведение сильно поменялось и так не планировалось. Так было в случае с показом баннера "Оцените приложение".

  • Баги в аналитике. Т.к. речь о фронтовой аналитике, она отправляется напрямую с клиента и почти никак не синхронизируется с бизнес-логикой. Поэтому иногда разработчики неумышленно ломают аналитику там, где она уже была, и мы это видим.

  • Изменения в продукте. Это самая распространённая причина возникновения аномалий – переделали флоу, выпилили фичу, раскатили вариант АБ-теста на 100% – всё это влияет на количество отдельных событий, и мы об этих изменениях узнаём даже если о них забыли уведомить :)

Итого

Больше контроля, меньше рутины, продуктовые аналитики занимаются аналитикой, а не выяснением что не так с данными :)

Комментарии (7)


  1. BogdanPetrov
    12.12.2022 17:28
    +1

    Спасибо, что поделились опытом. По-моему описан очень естественный процесс от понимания, что какую-то проблему можно было бы обнаружить более оперативно, если бы был реализован мониторинг соответствующего показателя, до реализации мониторинга на всем множестве метрик.

    Каждый день в 6 утра запускается скрипт на питоне, который выгружает из ClickHouse все события за последние 6 недель, предварительно агрегируя их по часам в разрезе платформы, события и уникальных для этого события параметров

    Если не секрет, сколько срезов (метрик / временных рядов) таким образом анализируется? Хотя бы порядок: 1к, 10к?


    1. dynnikovda Автор
      12.12.2022 17:50
      +1

      Спасибо, рад, что оказалось полезно)

      Если не секрет, сколько срезов (метрик / временных рядов) таким образом анализируется?

      Вообще не секрет - где-то в районе тысячи

      3 платформы * ~300 событий * N дополнительных параметров (например, события доски анализируются также в разрезе параметра board_type). Но некоторые из этих 300 событий приходят очень редко (меньше 100 в сутки), поэтому их отфильтровываем, чтоб не шуметь всякими ложно-положительными срабатываниями


  1. margaritatxt
    13.12.2022 14:14
    +1

    Очень круто, спасибо!


  1. Orioko
    13.12.2022 14:58

    Очень крутая статья! Было интересно увидеть как это происходит.


  1. Mike-M
    13.12.2022 23:00
    +2

    Напрашивается сходство с телеметрией )
    Только в отличие от последней, у анализа аномалий поведения пользователей есть огромное преимущество — вся информация находится на сервере, не требуется ничего выкачивать на стороне клиента.

    Хорошая практика, как мне показалось. Если, конечно, есть кому регулярно разгребать false positive/negative )

    Не исключаю, что подобный подход со временем станет стандартом де факто, или как мы айтишники выражаемся — must have )


    1. dynnikovda Автор
      14.12.2022 13:49
      +1

      Если, конечно, есть кому регулярно разгребать false positive/negative

      Мой рабочий день обычно и начинается с того, что я открываю чатик с аномалиями, смотрю на картинки от бота и разгребаю их)

      На самом деле занимает это прям мало времени - по части событий сразу видно, что false-positive (событий мало, разброс исторически большой, событие минорное). Если понятно, что что-то сильно поменялось - чаще я всё-таки в курсе предстоящих изменений, поэтому не сложно сопоставить изменения в продукте с аномалиями в событиях аналитики. Ну а если уж сходу не становится понятно, что произошло - идём в дашборд, локализуем проблему, быстро чекаем релизы, призываем разработчиков нужной команды (по названию ивента понятно, в какой части продукта он находится и какая команда за него отвечает).

      Но и это не всегда приходится делать, т.к. разработчикам детектор аномалий тоже нравится и многие из них сами заглядывают в чатик с аномалиями и смотрят, что же там происходит :) Часто к тому моменту, как я захожу посмотреть аномалии, уже кто-то успевает отписаться в треде и скинуть ссылку на задачку, в которой вносили изменения


  1. k_kro
    14.12.2022 15:33

    Спасибо, очень круто!