Как улучшить алерты по данным, и причём тут аналитики😐
Сегодня я хочу поделиться двумя статьями с Хабра, в которых затрагивается интересный кейс, близкий к предметной области, с которой я работаю в Авито — определение аномалий в продуктовых метриках для алертов по ним📈
📱 Чтобы не терять деньги: оповещения о падениях продуктовых метрик — VK, декабрь 2022
🏦 Как сэкономить силы и время аналитиков: наш алгоритм выявления аномалии данных — Купер, сентябрь 2023
➡️ Что здесь происходит?
Базово это очередная вариация на классическую задачу продуктового аналитика — поиск аномалий в данных.
Представим себе временной ряд покупок на сайте, допустим, в минуту. Понятно, что ночью и днём ожидаемые значения разные, а ещё есть более «крупная» сезонность (например, еду домой чаще заказывают на выходных), и даже общий растущий тренд этой продуктовой метрики (мы же делаем крутой сервис, у которого становится всё больше пользователей и их заказов).
Так что с такими метриками определение границ нормальных значений перестаёт быть тривиальным, иначе бы дежурные каждую ночь просыпались от алертов, что юзеров мало😄
➡️ Почему это вообще задача для аналитика, а не DevOps?
Абсолютно резонный вопрос. DevOps занимаются технической реализацией всех этих мониторингов (настраивают Grafana для сервиса, подключают отправку уведомлений в чаты дежурных, интегрируют прочие процессы). Для этого у метрики должен быть известен диапазон нормальных значений. Например, количество ошибок должно быть достаточно близко к нулю.
С продуктовыми метриками уже не всё так просто, и логично, что алгоритмы определения аномальных значений делают аналитики, или даже DS, если выбрать ML-модель для этого.
➡️ Почему я считаю, что вам стоит это прочитать?
Во-первых, мне кажется, что это хорошие статьи для насмотренности продуктового аналитика. Лично я раньше тоже сталкивалась с задачей «как нам определить, что данных не достаточно и надо кидать алерт» в Озоне, но там было достаточно простого варианта, так как речь шла о состоянии наших витрин, а не мониторинге сервиса в режиме онлайн.
Во-вторых, вы уже не раз спрашивали, чем вообще можно заниматься в технической платформе👍 На этот вопрос я пока что сама пытаюсь осознать ответ, но у меня уже есть в работе задача, где я участвую во внедрении алгоритма выявления таких аномалий от моего предшественника — тестирую его на различных метриках и скоро буду работать над его качеством.
Что думаете? Сталкивались с подобными кейсами?😎
#хардов_пост
@analytess 👩
Сегодня я хочу поделиться двумя статьями с Хабра, в которых затрагивается интересный кейс, близкий к предметной области, с которой я работаю в Авито — определение аномалий в продуктовых метриках для алертов по ним📈
📱 Чтобы не терять деньги: оповещения о падениях продуктовых метрик — VK, декабрь 2022
🏦 Как сэкономить силы и время аналитиков: наш алгоритм выявления аномалии данных — Купер, сентябрь 2023
➡️ Что здесь происходит?
Базово это очередная вариация на классическую задачу продуктового аналитика — поиск аномалий в данных.
Представим себе временной ряд покупок на сайте, допустим, в минуту. Понятно, что ночью и днём ожидаемые значения разные, а ещё есть более «крупная» сезонность (например, еду домой чаще заказывают на выходных), и даже общий растущий тренд этой продуктовой метрики (мы же делаем крутой сервис, у которого становится всё больше пользователей и их заказов).
Так что с такими метриками определение границ нормальных значений перестаёт быть тривиальным, иначе бы дежурные каждую ночь просыпались от алертов, что юзеров мало😄
➡️ Почему это вообще задача для аналитика, а не DevOps?
Абсолютно резонный вопрос. DevOps занимаются технической реализацией всех этих мониторингов (настраивают Grafana для сервиса, подключают отправку уведомлений в чаты дежурных, интегрируют прочие процессы). Для этого у метрики должен быть известен диапазон нормальных значений. Например, количество ошибок должно быть достаточно близко к нулю.
С продуктовыми метриками уже не всё так просто, и логично, что алгоритмы определения аномальных значений делают аналитики, или даже DS, если выбрать ML-модель для этого.
➡️ Почему я считаю, что вам стоит это прочитать?
Во-первых, мне кажется, что это хорошие статьи для насмотренности продуктового аналитика. Лично я раньше тоже сталкивалась с задачей «как нам определить, что данных не достаточно и надо кидать алерт» в Озоне, но там было достаточно простого варианта, так как речь шла о состоянии наших витрин, а не мониторинге сервиса в режиме онлайн.
Во-вторых, вы уже не раз спрашивали, чем вообще можно заниматься в технической платформе👍 На этот вопрос я пока что сама пытаюсь осознать ответ, но у меня уже есть в работе задача, где я участвую во внедрении алгоритма выявления таких аномалий от моего предшественника — тестирую его на различных метриках и скоро буду работать над его качеством.
Что думаете? Сталкивались с подобными кейсами?😎
#хардов_пост
@analytess 👩