Привет! Меня зовут Дима Дынников, я руководитель команды продуктовой аналитики в Профи. Расскажу, как мы ищем поведенческие аномалии в продукте и зачем это вообще нужно делать.
Что такое аномалии
Покажу на примере. На скрине ниже — карточка заказа в приложении Профи для специалиста. Можно нажать на карту и посмотреть, где именно специалисту нужно выполнить заказ.
![Карточка заказа в приложении для специалистов Карточка заказа в приложении для специалистов](https://habrastorage.org/getpro/habr/upload_files/ef5/bc2/c72/ef5bc2c72254ac8536c4ada8712dc9d9.png)
Каждый раз, когда специалист нажимает на карту, мы видим это в аналитике. Он нажимает сначала на заказ, потом на карту — это базовый сценарий.
Но как-то мы увидели, что в одном и том же заказе специалист за короткий промежуток времени много раз нажимает на карту и выходит. А потом заходит в другой заказ и тоже много раз нажимает на карту. И так делает большинство специалистов.
Мы видим поведение, которое отличается от привычного, — это аномалия.
![Количество кликов на карту в заказе по дням Количество кликов на карту в заказе по дням](https://habrastorage.org/getpro/habr/upload_files/9de/a8d/102/9dea8d10275d6c979442b15d335c8763.png)
Оказалось, что в этот день мы сломали карту. Она не открывалась, и специалисты нажимали на неё много раз.
Другой пример — в один из дней мы сломали аналитику на экране авторизации. К нам просто перестало приходить одно событие. Но мы смогли быстро это заметить и починить.
![Количество событий авторизации по днями Количество событий авторизации по днями](https://habrastorage.org/getpro/habr/upload_files/fdc/74e/833/fdc74e833eeea44039bdc88d8009fcd8.png)
Чтобы улучшать продукт и оперативно фиксить баги, мы стали искать эти аномалии. Но сначала не очень понимали, как это делать.
А технические мониторинги для кого?
Аномалии не всегда вызваны техническими ошибками. Например, на графике ниже видно, что мы резко перестали показывать баннер с просьбой оценить наше приложение. Алгоритм, который выбирал, в какой момент нужно показать этот баннер, опирался на логику подсчёта откликов. А мы случайно изменили эту логику, поэтому баннер стал показываться реже. Пользователи практически его не видели.
Здесь не было технической ошибки, но нам всё равно важно мониторить подобные продуктовые баги.
![Количество событий показа баннера (картинка от бота) Количество событий показа баннера (картинка от бота)](https://habrastorage.org/getpro/habr/upload_files/0bd/111/c12/0bd111c12fee1f7ec1ec5cb092f7e5b4.jpg)
Почему искать аномалии на графиках событий – плохая идея
На Профи зарегистрировано более 2,5 миллионов специалистов. За прошедший октябрь мы записали более 400 миллионов событий от 382 тысяч уникальных пользователей, а уникальных событий было 284. Следить за графиком каждого события вручную — нереально. Нужен был детектор аномалий.
![Количество событий поведенческой аналитики по дням Количество событий поведенческой аналитики по дням](https://habrastorage.org/getpro/habr/upload_files/792/1a9/238/7921a9238ba2c1410d4a160f205c89de.png)
Что за детектор аномалий
Это бот в Slack, который каждый день анализирует миллионы событий и подробно показывает, что у нас происходит с продуктом. Если он видит, что каких-то событий стало слишком много или слишком мало, то выводит картинки в чат. После этого можно пойти посмотреть, что именно произошло.
![Пример ежедневного отчёта бота в Slack Пример ежедневного отчёта бота в Slack](https://habrastorage.org/getpro/habr/upload_files/1c4/3a0/391/1c43a039110b803225a88749fef72e5c.png)
Но бота было мало...
Даже с ботом приходилось делать много рутинной работы: смотреть, где возникла аномалия, из-за чего это произошло, выяснять, было ли это запланировано или появился баг.
Чтобы эту рутину не делать каждый раз, я сделал дашборд по аномалиям. В нём можно выбрать нужное событие и посмотреть, в какой момент они появляются. Можно сделать это в разрезе вертикалей или новых релизов.
![Главная страница дашборда по аномалиям в Metabase Главная страница дашборда по аномалиям в Metabase](https://habrastorage.org/getpro/habr/upload_files/2d9/054/c15/2d9054c15dfdd22f03c5138c57f55100.jpeg)
Технические подробности реализации
Каждый день в 6 утра запускается скрипт на питоне, который выгружает из ClickHouse все события за последние 6 недель, предварительно агрегируя их по часам в разрезе платформы, события и уникальных для этого события параметров (их список есть в виде словаря внутри самого скрипта).
Данные предобрабатываются и анализируются на предмет аномалий с помощью библиотеки ADTK.
Если видим, что за прошедшие сутки наблюдаются аномалии, — отрисовываем почасовой график этого события за последние 6 недель.
Все аномальные события отправляются в специальный чат в Slack — отдельно «негативные» аномалии, отдельно «позитивные».
Все аномальные события «проливаем» в отдельную витрину, на которой строим дашборд по аномалиям. Это нужно для того, чтобы выводить на дашборд только аномальные данные (сам Кликхаус ничего не знает про аномалии, т.к. они считаются в питоне).
Всё, что пролили, выводим во всевозможных разрезах, чтобы быстро узнать точное время возникновения аномалии, масштаб, какие версии приложения затрагивает, на каких вертикалях наблюдается и т.д.
В большинстве случаев бот в связке с дашбордом позволяет достаточно оперативно выявить аномалию и понять её первопричину минут за 10.
Что получается ловить
К сожалению, а может и к счастью, детектор аномалий срабатывает достаточно часто. В большинстве случаев это штатные и запланированные явления, но иногда это что-то критичное, что очень больно пропустить.
Вот типы проблем, которые мы ловим детектором аномалий:
Технические баги. Да, чаще всего к моменту отчета об аномалии (6 утра) о баге уже известно из технических мониторингов или жалоб пользователей. Но однажды технический мониторинг промолчал, а баг был критичный (хоть и затрагивал небольшое число пользователей). О нём тогда узнали от бота.
Продуктовые баги. Это когда технически всё работает штатно, но пользовательское поведение сильно поменялось и так не планировалось. Так было в случае с показом баннера "Оцените приложение".
Баги в аналитике. Т.к. речь о фронтовой аналитике, она отправляется напрямую с клиента и почти никак не синхронизируется с бизнес-логикой. Поэтому иногда разработчики неумышленно ломают аналитику там, где она уже была, и мы это видим.
Изменения в продукте. Это самая распространённая причина возникновения аномалий – переделали флоу, выпилили фичу, раскатили вариант АБ-теста на 100% – всё это влияет на количество отдельных событий, и мы об этих изменениях узнаём даже если о них забыли уведомить :)
Итого
Больше контроля, меньше рутины, продуктовые аналитики занимаются аналитикой, а не выяснением что не так с данными :)
Комментарии (7)
Mike-M
13.12.2022 23:00+2Напрашивается сходство с телеметрией )
Только в отличие от последней, у анализа аномалий поведения пользователей есть огромное преимущество — вся информация находится на сервере, не требуется ничего выкачивать на стороне клиента.
Хорошая практика, как мне показалось. Если, конечно, есть кому регулярно разгребать false positive/negative )
Не исключаю, что подобный подход со временем станет стандартом де факто, или как мы айтишники выражаемся — must have )dynnikovda Автор
14.12.2022 13:49+1Если, конечно, есть кому регулярно разгребать false positive/negative
Мой рабочий день обычно и начинается с того, что я открываю чатик с аномалиями, смотрю на картинки от бота и разгребаю их)
На самом деле занимает это прям мало времени - по части событий сразу видно, что false-positive (событий мало, разброс исторически большой, событие минорное). Если понятно, что что-то сильно поменялось - чаще я всё-таки в курсе предстоящих изменений, поэтому не сложно сопоставить изменения в продукте с аномалиями в событиях аналитики. Ну а если уж сходу не становится понятно, что произошло - идём в дашборд, локализуем проблему, быстро чекаем релизы, призываем разработчиков нужной команды (по названию ивента понятно, в какой части продукта он находится и какая команда за него отвечает).
Но и это не всегда приходится делать, т.к. разработчикам детектор аномалий тоже нравится и многие из них сами заглядывают в чатик с аномалиями и смотрят, что же там происходит :) Часто к тому моменту, как я захожу посмотреть аномалии, уже кто-то успевает отписаться в треде и скинуть ссылку на задачку, в которой вносили изменения
BogdanPetrov
Спасибо, что поделились опытом. По-моему описан очень естественный процесс от понимания, что какую-то проблему можно было бы обнаружить более оперативно, если бы был реализован мониторинг соответствующего показателя, до реализации мониторинга на всем множестве метрик.
Если не секрет, сколько срезов (метрик / временных рядов) таким образом анализируется? Хотя бы порядок: 1к, 10к?
dynnikovda Автор
Спасибо, рад, что оказалось полезно)
Вообще не секрет - где-то в районе тысячи
3 платформы * ~300 событий * N дополнительных параметров (например, события доски анализируются также в разрезе параметра board_type). Но некоторые из этих 300 событий приходят очень редко (меньше 100 в сутки), поэтому их отфильтровываем, чтоб не шуметь всякими ложно-положительными срабатываниями