Привет! Меня зовут Дима Дынников, я руководитель команды продуктовой аналитики в Профи. Расскажу, как мы ищем поведенческие аномалии в продукте и зачем это вообще нужно делать.
Что такое аномалии
Покажу на примере. На скрине ниже — карточка заказа в приложении Профи для специалиста. Можно нажать на карту и посмотреть, где именно специалисту нужно выполнить заказ.
Каждый раз, когда специалист нажимает на карту, мы видим это в аналитике. Он нажимает сначала на заказ, потом на карту — это базовый сценарий.
Но как-то мы увидели, что в одном и том же заказе специалист за короткий промежуток времени много раз нажимает на карту и выходит. А потом заходит в другой заказ и тоже много раз нажимает на карту. И так делает большинство специалистов.
Мы видим поведение, которое отличается от привычного, — это аномалия.
Оказалось, что в этот день мы сломали карту. Она не открывалась, и специалисты нажимали на неё много раз.
Другой пример — в один из дней мы сломали аналитику на экране авторизации. К нам просто перестало приходить одно событие. Но мы смогли быстро это заметить и починить.
Чтобы улучшать продукт и оперативно фиксить баги, мы стали искать эти аномалии. Но сначала не очень понимали, как это делать.
А технические мониторинги для кого?
Аномалии не всегда вызваны техническими ошибками. Например, на графике ниже видно, что мы резко перестали показывать баннер с просьбой оценить наше приложение. Алгоритм, который выбирал, в какой момент нужно показать этот баннер, опирался на логику подсчёта откликов. А мы случайно изменили эту логику, поэтому баннер стал показываться реже. Пользователи практически его не видели.
Здесь не было технической ошибки, но нам всё равно важно мониторить подобные продуктовые баги.
Почему искать аномалии на графиках событий – плохая идея
На Профи зарегистрировано более 2,5 миллионов специалистов. За прошедший октябрь мы записали более 400 миллионов событий от 382 тысяч уникальных пользователей, а уникальных событий было 284. Следить за графиком каждого события вручную — нереально. Нужен был детектор аномалий.
Что за детектор аномалий
Это бот в Slack, который каждый день анализирует миллионы событий и подробно показывает, что у нас происходит с продуктом. Если он видит, что каких-то событий стало слишком много или слишком мало, то выводит картинки в чат. После этого можно пойти посмотреть, что именно произошло.
Но бота было мало...
Даже с ботом приходилось делать много рутинной работы: смотреть, где возникла аномалия, из-за чего это произошло, выяснять, было ли это запланировано или появился баг.
Чтобы эту рутину не делать каждый раз, я сделал дашборд по аномалиям. В нём можно выбрать нужное событие и посмотреть, в какой момент они появляются. Можно сделать это в разрезе вертикалей или новых релизов.
Технические подробности реализации
Каждый день в 6 утра запускается скрипт на питоне, который выгружает из ClickHouse все события за последние 6 недель, предварительно агрегируя их по часам в разрезе платформы, события и уникальных для этого события параметров (их список есть в виде словаря внутри самого скрипта).
Данные предобрабатываются и анализируются на предмет аномалий с помощью библиотеки ADTK.
Если видим, что за прошедшие сутки наблюдаются аномалии, — отрисовываем почасовой график этого события за последние 6 недель.
Все аномальные события отправляются в специальный чат в Slack — отдельно «негативные» аномалии, отдельно «позитивные».
Все аномальные события «проливаем» в отдельную витрину, на которой строим дашборд по аномалиям. Это нужно для того, чтобы выводить на дашборд только аномальные данные (сам Кликхаус ничего не знает про аномалии, т.к. они считаются в питоне).
Всё, что пролили, выводим во всевозможных разрезах, чтобы быстро узнать точное время возникновения аномалии, масштаб, какие версии приложения затрагивает, на каких вертикалях наблюдается и т.д.
В большинстве случаев бот в связке с дашбордом позволяет достаточно оперативно выявить аномалию и понять её первопричину минут за 10.
Что получается ловить
К сожалению, а может и к счастью, детектор аномалий срабатывает достаточно часто. В большинстве случаев это штатные и запланированные явления, но иногда это что-то критичное, что очень больно пропустить.
Вот типы проблем, которые мы ловим детектором аномалий:
Технические баги. Да, чаще всего к моменту отчета об аномалии (6 утра) о баге уже известно из технических мониторингов или жалоб пользователей. Но однажды технический мониторинг промолчал, а баг был критичный (хоть и затрагивал небольшое число пользователей). О нём тогда узнали от бота.
Продуктовые баги. Это когда технически всё работает штатно, но пользовательское поведение сильно поменялось и так не планировалось. Так было в случае с показом баннера "Оцените приложение".
Баги в аналитике. Т.к. речь о фронтовой аналитике, она отправляется напрямую с клиента и почти никак не синхронизируется с бизнес-логикой. Поэтому иногда разработчики неумышленно ломают аналитику там, где она уже была, и мы это видим.
Изменения в продукте. Это самая распространённая причина возникновения аномалий – переделали флоу, выпилили фичу, раскатили вариант АБ-теста на 100% – всё это влияет на количество отдельных событий, и мы об этих изменениях узнаём даже если о них забыли уведомить :)
Итого
Больше контроля, меньше рутины, продуктовые аналитики занимаются аналитикой, а не выяснением что не так с данными :)
