Привет! Меня зовут Юлия Зиновьева, я старший продуктовый аналитик в СберМаркете. В этой статье расскажу о простом и эффективном методе выявления аномалии данных, который разработала наша команда. Мы автоматизировали мониторинг событий в кликстриме и настроили алерты для аналитиков о возникающих аномалиях. Такой способ значительно сэкономит время и силы команды, а также будет понятен даже тем, у кого базовый уровень знания статистики.
Для удобства я собрала лайфхаки. Они помогут уточнить алгоритм поиска проблем в событиях и преодолеть психологический страх перед мониторингом. Поверьте, это вовсе не такая необъятная задача, как может показаться.
Думаю, наш опыт будет полезен тем, кто работает с бизнес-данными, занимается их анализом и хранением – словом, всем, кто активно вовлечен в проект или может на него влиять, принимая важные решения в опоре на данные. Поехали!
Как мы поняли, что нуждаемся в системе алертинга
Как устроен ETL в этом процессе
Как искали метод для выявления аномалий
Как построили процесс алертинга в компании
Количество данных растет
Современные аналитические системы в большинстве своем работают на основе событий. Смена адреса, поиск товара, заход в категорию каталога или просмотр баннеров — любое действие оставляет след. Эти данные аналитики используют для продуктовых ресечей, выявления узких мест в воронке, для создания дашбордов, составления отчетов и, конечно, для подсчета метрик в А/В тестах.
С кликстримом можно увидеть продукт глазами потребителей и адаптировать свои предложения под их запросы.
Каждый день аналитики имеют дело с большим объемом обрабатываемых данных. Например, в СберМаркете свыше 30 тысяч магазинов в 160 городах и более 200 млн товарных позиций. Только представьте, сколько «следов» пользователей мы должны ежедневно проверять.
С усложнением продукта данных становится все больше. У нас, например, количество событий за год выросло практически вдвое. Аномалии в одном событии становятся головной болью не только для команды, которая его создала, но и для других коллег. Как результат цена ошибки сильно растет.
Статистика показала, что 75% продактов откладывали запуск или подведение A/B-тестов из-за некорректных событий. Криты ставили релизы на стоп до устранения поломки на несколько дней.
Без права на ошибку
Аномалии в данных могут появиться на любом отрезке пути:
событие может сломаться на разработке
не отправиться к аналитикам,
не записаться в базу
или исчезнуть из неё.
При этом данные — это «глаза» бизнеса. Из-за ошибок может быть отложено принятие важных решений, а искаженные данные могут стоить бизнесу финансовых потерь. Поэтому для всех (и аналитиков, и разработчиков, и тестировщиков) важно оперативно узнавать о проблемных ситуациях и своевременно на них реагировать. Но выловить баги не так-то просто.
Типичная ситуация: показатели выросли или упали. В чем причина? Мы начинаем анализировать, что вызвало изменение метрик. Проверяя свою гипотезу, неожиданно сталкиваемся с проблемой нехватки данных. Как оказалось, нужное событие сломалось несколько релизов назад.
Вот еще пример. Допустим, мы запустили тест и в течение двух недель не заглядывали в метрики. А когда он завершился, обнаружили там странности. Аналитики выяснили причины аномалии: событие некорректно работает в какой-то из версий, а тестировщики не всегда могут отловить их с помощью автотестов. Из-за ошибки в событиях приходится перезапускать эксперимент. Работа над ошибками затягивает принятие решений по фиче.
Время, потраченное на поиск багов, можно использовать куда более продуктивно. Тогда мы решили найти свой способ справиться с ошибками.
Чем проще, тем лучше
Мы задумались, нельзя ли автоматизировать и упростить проверку данных с помощью системы мониторинга. Он позволяет видеть ошибки автоматически, причем на нескольких сотнях графиков (а у нас их именно столько) каждый день.
Когда мы думали над методологией, рассматривали использование готовых решений, таких как библиотека prophet или моделирование, но в конечном счете решили остановиться на простых статистических методах. Такое решение было самым быстрым и простым в реализации для MVP, легко масштабируемым на сотни метрик и его мог легко тюнить и поддерживать любой аналитик из команды со знанием статистики.
После реализации MVP, мы убедились, что оно дало нам достаточно хорошую точность при определении аномалий в данных, и решили остановиться на нем. А вот наши коллеги из VK реализовали подобную систему с помощью prophet, ловите крутую статью об этом.
Наш алгоритм выявления аномалий достаточно прост и состоит из трех основных шагов.
Шаг 1 – сделать прогноз числа строк в каждом событии кликстрим на базе исторических данных.
Шаг 2 – отложить вправо и влево от прогноза некоторый доверительный интервал, в пределах которого колебание метрики нормально.
Шаг 3 – сравнить фактическое значение данных, которое мы получили в день проверки, с нашим интервалом. Если оно попадает в него, то все в порядке, если нет, мы считаем это аномалией и говорим об этом ответственному аналитику.
Храните данные в ETL
Рассмотрим, как устроен ETL в этом процессе. Для автоматизации наши аналитики пользуются стандартными инструментами:
Кликстрим хранится в базе данных (в нашем случае это ClickHouse), трансформации и расчеты происходят частично в SQL, частично в Python.
Код расчетов и документация по всем нашим событиям хранится на GitLab’е. Раньше роль сейфа для документации исполняли Google-файлы и Confluence, но GitLab более удобен как разработчикам, так и аналитикам. У GitLab’а есть отличная API, она позволяет автоматически подключаться и собирать статистику по событиям, их описание, актуальные параметры. Мы ориентируем аналитика, который отвечает за конкретное событие, кому отправлять оповещение о поломке.
GitLab синхронизирован у нас с Airflow. Ежедневно там делается расчет по расписанию, формируется саммари с кратким описанием «странных» событий. Сводка отправляется в наш рабочий мессенджер, где есть ссылка на графики, различные разрезы, по которым аналитик может легко понять, что и где сломалось.
Много шума… и ничего
Верный путь искали методом проб и ошибок. Сначала прогнозировали число строк по каждому событию кликстрима.
Вот пример: на графике красным отмечена точка, которая находится значительно ниже от основной массы других точек — это явный провал в данных.
Первоначально для прогноза ожидаемого значения мы использовали самый простой baseline – сравнение числа строк с прошедшим периодом. По графику видно, что данные сезонные, у них есть еженедельные колебания, пики и провалы. Мы ожидали, что каждая неделя будет похожа на предыдущую. Как оказалось, ошибались.
Выстроили график с количеством строк в событии, отметили на нем предполагаемые аномалии данных. Поверх наложили тот же график только со сдвигом на неделю и нашли между ними разницу. И тут нас ждало и разочарование: простое сравнение с прошлым периодом дало много лишнего шума, который мешает разглядеть аномалию. Есть как минимум 7-8 дополнительных точек, которые кажутся аномальными относительно прошлой недели.
Сгладить помехи попробовали при помощи простого скользящего среднего. Наша идея заключалась в том, чтобы для каждой точки усреднить значения за три предыдущих дня. Таким образом мы получили сглаженный аппроксимированный график, с которым мы можем сравнивать наши фактические значения.
Ситуация стала намного лучше, вместо 7-8 точек выделились всего три аномальные. Точка, которую мы ищем, теперь лежит на графике чуть дальше от остальных. Однако шум не ушел, к тому же исказилась сезонность. Регулярные пики и падения чуть-чуть сместились и находятся не совсем там, где были на изначальном графике. Значит, продолжаем искать верный путь.
Нужно все взвесить
Как можно улучшить этот алгоритм? Как избавиться от шума? Мы задали себе эти вопросы и решили перейти от простого скользящего среднего к взвешенному. Разница в том, что при первом подходе все точки вносят равный вклад, а во втором — последняя точка имеет наибольший вес.
Веса — это очень гибкий инструмент, их существует много разных видов. Самые распространенные — линейные либо экспоненциальные, где последняя точка имеет больший вес по сравнению с предыдущими.
А ещё с весами можно экспериментировать. Можно сделать их кастомными и даже «штрафовать» аномальные точки, когда накопится лок наблюдений с разметкой нормальных и аномальных данных.
На графике взвешенного скользящего среднего аномальная точка больше удалена от остальных наблюдений, ошибка прогноза наших наблюдений уменьшилась.
На этом мы могли бы остановиться, но мы решили еще улучшить нашу систему мониторинга:
Сначала мы посчитали взвешенное скользящее среднее, используя это как прогноз, с которым мы сравниваем фактический график.
То же самое попробовали сделать не по абсолютной, а по коррелирующей метрике, которая объясняет большую часть изменчивости. Например, это может быть аудитория или число заказов.
Чтобы избавиться от изменчивости данных, связанной с колебаниями независимой переменной, мы попытались снизить дисперсию метрики при помощи нормирования.
В своих разработках мы оттолкнулись от следующей идеи: кликстрим наших пользователей не существует в вакууме. Они сами его генерируют, так как существуют в привязке к другим метрикам сервиса, например, к числу заказов или оформленных подписок. Все это вносит колебания в независимую метрику.
Если избавиться от части волатильности в числе строк в кликстриме, связанных с изменением зависящей метрики, то удастся изолировать изменчивость.
Объясню пошагово
Первым шагом мы попробовали подобрать коррелирующую метрику, к которой можно привязать число строк в кликстриме. Для нашего мониторинга взяли число заказов, но это может быть аудитория или конверсия, или другая метрика, например, число подписок.
Главное — убедиться, что данные кликстрима с этой метрикой взаимосвязаны, а она не подвержена проблемам, влияющим на ваши данные. Иными словами, она должна собираться независимо. Если получится подобрать такую метрику, это может существенно уточнить ваш прогноз.
Итак, метрика найдена. В нашем случае это количество строк на один заказ. Можно переходить от работы с абсолютной метрикой (число строк) к работе с относительной (число строк на единицу коррелирующей метрики).
Затем ищем взвешенное скользящее среднее по числу строк на один заказ. Получаем тот же прогноз, но в единицах этого отношения.
В завершение переводим прогноз снова в строки, умножая на число заказов в проверяемый день.
Таким образом, мы получаем уточненный прогноз, который не только взвешен, но еще и нормирован на зависимую метрику, что позволяет значительно снизить среднюю ошибку.
Даже невооруженным глазом видно: на графике аномальная точка лежит очень далеко от остальных, и мы можем визуально довольно легко ее идентифицировать.
Две составляющие — взвешивание и нормирование — помогли снизить среднюю ошибку прогноза по сравнению с базовой линией в 4 раза!
Можно немного усложнить
Удача воодушевила нас на дальнейшие усовершенствования и мы добавили доверительный интервал. Вариантов здесь два.
Фиксированный интервал. Оповещаем при отклонении, например, на 10% от ожидаемого значения. Это простой в расчете и понятный интуитивно вариант, однако он не подойдёт, если имеется множество мелких событий, для которых характерна существенная волатильность и большие колебания.
Доверительный интервал. Он учитывает изменчивость каждого отдельного события. Единственное ограничение, о котором нужно знать, — разница между вашим прогнозом и фактом должна быть распределена нормально. Бывают ситуации, когда она распределена ненормально, но эти варианты более сложные и трудоемкие.
Почитать подробнее про доверительный интервал для нормально и ненормально распределенных остатков: https://towardsdatascience.com/time-series-forecasting-prediction-intervals-360b1bf4b085
Строим процессы
После того, как мы прошли два из трех шагов определения аномалии: построение прогноза и построение доверительного интервала осталось лишь... сравнить факт с прогнозом и написать об этом аналитикам:
Мы сравниваем факт с прогнозом и формируем список обнаруженных за день аномалий.
Далее размещаем в продуктовом чате краткое саммари и делаем ссылку на более подробный отчет. В нем выведено количество строк с помеченными аномалиями и даны основные разрезы, позволяющие быстро сузить проблему до определенной версии приложения или до определенного экрана.
После этих несложных действий можно сообщать об аномалии в канал для алертов.
Плюсы и минусы подхода
За несколько дней работы алертинга мы выявили пять-шесть дней с техническими потерями данных, а за первую неделю было обнаружено две поломки фичей на проде.
Не скрою, для того чтобы система появилась, потребовалось время на ресерч данных и написание алгоритма, который в будущем ещё придется тюнить для лучших результатов. Конечно, наша методология не станет универсальной панацеей для решения любых задач. Но все же её плюсы очевидны:
Быстрее выявляются проблемы в данных, сокращается цикл принятия решений в продукте, логи поломок хранятся и легко поднимаются.
Отпадает необходимость регулярного мониторинга, который больше не нужно делать вручную, он ведется автоматически.
И, главное, у аналитиков остается больше времени на решение важных задач, а огромный объем данных теперь не выглядит пугающе.
С другой стороны, есть опасность того что алертов будет очень много и они превратятся в некий «фоновый шум» для получателя. Мы уже столкнулись с тем, что алертинг добавляет работы аналитикам, т.к. всплывает много аномалий которые раньше просто пропускались. Каждый день нужно смотреть отчеты, а с ростом количества событий, растёт и число графиков.
Здесь важно находиться в контакте с получателями алертов, собирать от них обратную связь и идти на некоторые трейд-оффы: например, балансировать чувствительность алертов. Писать день в день только о крупных отклонениях, а мелкие агрегировать в более редкие рассылки.
Вы не раз скажете себе спасибо, если вложитесь в систему мониторинга до того, как произойдет серьезная ошибка, которая будет стоить вашему бизнесу некорректных данных и финансовых потерь. Система мониторинга не обязательно должна быть суперсложной и продвинутой и точно не нужно ждать момента, когда серьезные сбои дадут знать о себе.
Спасибо, что дочитали до конца! Буду рада ответить на вопросы в комментариях.
Product&data команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.
