Вы открываете дашборды, чтобы оценить ключевые метрики. Ждете загрузки, завариваете кофе. Метрики опять не менялись и вы идете далее заниматься другими делами. И этот ритуал повторяется каждое утро. Знакомая ситуация?
А что если ваша BI система сама пришлет сообщение в телеграм, если ключевые метрики изменятся? И заодно объяснит причины этих изменений в короткой сводке – это и есть триггерная аналитика.
А что если ваша BI система сама пришлет сообщение в телеграм, если ключевые метрики изменятся? И заодно объяснит причины этих изменений в короткой сводке – это и есть триггерная аналитика.
Триггерная аналитика – это
Триггерная аналитика – это формат аналитики при котором НЕ пользователь изучает изменения в данных, а система сама уведомляет пользователей в случае, если метрики изменились аномально. А заодно автоматически ищет и объясняет причины этих изменений.
Примеры таких сообщений:
Все сообщения строятся по единой схеме:
Примеры таких сообщений:
- «аномальный прирост числа новых лидов из-за канала Youtube: Bloggers»;
- «сокращение выручки на 37% в категории "Электроника" про продажам Иванова А.»;
- «стат.значимое падение качества видео из-за prflx прокси в регионе "Ru".
Все сообщения строятся по единой схеме:
- Что произошло с целевой метрикой {упала/выросла}?
- Каким сегментом, кластером, подгруппой можно объяснить изменение метрики?
Преимущества триггерного подхода
Экономия времени на еженедельном просмотре дашбордов в поисках изменений.
Сокращение ошибок при интерпретации данных. Часто пользователи допускают ошибки и чтении данных: в случайных флуктуациях ошибочно видят тенденцию или путают падение/рост метрики с сезонными колебаниями. Статистические критерии так не ошибаются. К тому же чаще всего метрики не меняются, у пользователей «замыливается глаз» из-за чего сложнее заметить изменения, когда они действительно произойдут.
Отсутствие необходимости подключать аналитиков. Триггерная аналитика сообщает не только об изменении метрики, но и о наиболее вероятных причинах. При этом перебирая комбинации подгрупп. К классическом BI подходе ручной перебор подгрупп в поисках сегмента, который объяснит – это скрупулезная работа, требующая участия аналитиков.
Сокращение ошибок при интерпретации данных. Часто пользователи допускают ошибки и чтении данных: в случайных флуктуациях ошибочно видят тенденцию или путают падение/рост метрики с сезонными колебаниями. Статистические критерии так не ошибаются. К тому же чаще всего метрики не меняются, у пользователей «замыливается глаз» из-за чего сложнее заметить изменения, когда они действительно произойдут.
Отсутствие необходимости подключать аналитиков. Триггерная аналитика сообщает не только об изменении метрики, но и о наиболее вероятных причинах. При этом перебирая комбинации подгрупп. К классическом BI подходе ручной перебор подгрупп в поисках сегмента, который объяснит – это скрупулезная работа, требующая участия аналитиков.
Недостатки
- Не заменит BI, но дополняет.
- Так как данные обрабатываются автоматически, то возможны ошибки. Например в оценке сезонности / цикличности.
- «Ползучее изменение метрик» недетектируемое для статистических критериев. Это когда ваша выручка каждый день сокращается по "копеечке". В таких изменениях нет ничего аномального, но со временем, если вовремя не среагировать метрика может «уползти» слишком глубоко.
Признаки, при проявлении которых процесс считается вышедшим из-под контроля согласно правилу анализа закономерностей, следующие:
Где:
Зона C - в пределах 1 сигмы (68% "нормальных" значений)
Зона B - в пределах 1-2 сигм (27% "нормальных" значений)
Зона А - в пределах 2-3 сигм (4% самых аномальных значений)
Сигма - стандартное отклонение от среднего значения. Подробнее >
- Любое значение попадает вне зоны A (дальше от осевой линии).
- 9 последовательных значений попадают в зону C или кнаружи от неё по одну сторону от осевой линии.
- 6 последовательных значений уклоняются в одном направлении, то есть параметр постоянно увеличивается или уменьшается.
- 14 последовательных значений «скачут» попеременно то вверх, то вниз.
- 2 из 3 последовательных значений попадают в зону A или кнаружи от нее с одной и той же стороны от осевой линии.
- 4 из 5 последовательных значений попадают в зону B или кнаружи от нее по одну сторону от осевой линии.
- 15 значений подряд попадают в зону C.
- 11 последовательных значений попадают в зону B или кнаружи от нее.
Где:
Зона C - в пределах 1 сигмы (68% "нормальных" значений)
Зона B - в пределах 1-2 сигм (27% "нормальных" значений)
Зона А - в пределах 2-3 сигм (4% самых аномальных значений)
Сигма - стандартное отклонение от среднего значения. Подробнее >
Как это работает под капотом?
Моделька принимает ряд данных. Необходимый минимум: не менее 50 наблюдений изучаемой метрики. Лучше, есть есть метка дат и эта же метрика, выраженная в подгруппах (тогда алгоритм не только определит аномалии, но и выявит в каких сегментах кроется причина). Обрабатываются пропущенные значения, укрупняются мелкочастотные сегменты, удаляется последняя запись, если она не полная.
Далее ряд декомпозируется, чтобы исключить шум, сезонность и тренды:
Далее ряд декомпозируется, чтобы исключить шум, сезонность и тренды:
Иллюстрация декомпозиции ряда
К очищенному ряду применяются техники определения. Если совсем коротко, то это работает так:
1. Для каждого наблюдения определяем отклонение от среднего значения
2.Рассчитываем статистикуRi, которая измеряет, насколько данный элемент является аномальным путем деления п.1 на стандартное отклонение. Т.е. по сути выполняем Z-score нормализацию.
3. Для каждого Ri вычисляется критическое значение, основанное на t-распределении.
После чего аномальные значения, если они существуют изучаются в подгруппах, чтобы найти сегмент, который " объяснит" изменение.
4. Если R превышает это критическое значение, то элемент считается аномальным.
5. Исключаем аномалию и проводим расчет заново.
2.Рассчитываем статистикуRi, которая измеряет, насколько данный элемент является аномальным путем деления п.1 на стандартное отклонение. Т.е. по сути выполняем Z-score нормализацию.
3. Для каждого Ri вычисляется критическое значение, основанное на t-распределении.
После чего аномальные значения, если они существуют изучаются в подгруппах, чтобы найти сегмент, который " объяснит" изменение.
4. Если R превышает это критическое значение, то элемент считается аномальным.
5. Исключаем аномалию и проводим расчет заново.
Если аномалии найдены , то исследуемая метрика анализируется в подгруппах, чтобы найти сегмент, который «виновен» в изменении метрики. После чего уведомление отправляется заказчику.
А если я не хочу делиться чувствительными данными?
Если вы не хотите делиться с внешним подрядчиком чувствительными данными (о выручке, конверсии, ретеншене) и не доверяете NDA, то действенный метод – нормализация.
Просто перед отправкой данных разделите все значения на некое известное только вам число. Это может быть максимально значение или любое другое. Абсолютные значения при этом изменятся, но это не помещается критериям замечать закономерности в данных относительно друг друга.
А при интерпретации отчета вам будет достаточно умножить полученные от подрядчика значения на то самое известное только вам число.
Просто перед отправкой данных разделите все значения на некое известное только вам число. Это может быть максимально значение или любое другое. Абсолютные значения при этом изменятся, но это не помещается критериям замечать закономерности в данных относительно друг друга.
А при интерпретации отчета вам будет достаточно умножить полученные от подрядчика значения на то самое известное только вам число.
Хотите попробовать?
Я как раз работаю над такой системой.
Если вам любопытно поискать аномалии в собственных данных, то машите в Telegram > ✋
Если вам любопытно поискать аномалии в собственных данных, то машите в Telegram > ✋
Понравилась статья?
Поделиться: