Аномалии рекламной кампании без фиксированных порогов: как построить живой baseline

Редакция mevrica

Аналитика7 мин чтения

Обновлено 2 августа 2026 г.

Фиксированное правило вроде «CTR ниже двух процентов — тревога» удобно записать, но оно не понимает день недели, новый GEO, масштаб, задержку конверсии и изменение медиамикса. В результате мониторинг молчит во время медленного дрейфа и кричит при каждом штатном всплеске. Живой baseline описывает ожидаемое поведение кампании в сопоставимых условиях, а аномалия становится отклонением от этого ожидания, а не нарушением вечной универсальной цифры.

Главный принцип

Система должна объяснять, почему значение неожиданно сейчас, для этого сегмента и при таком объёме. Само расстояние от среднего без контекста редко достаточно.

1. Сначала определите операционное решение

Алерт нужен не ради красной точки на графике. До модели укажите, кто реагирует, какие проверки выполняет и какое действие допустимо. Если на сигнал никто не может ответить или он не меняет решение, это диагностический отчёт, а не алерт.

2. Разделите качество данных и бизнес-показатель

Падение конверсии может быть реальным, но сначала нужно проверить доставку событий, задержку, схему и полноту. Контрольные суммы воронки и heartbeat источников должны работать отдельно. Иначе алгоритм будет обучаться на сбоях трекинга и объявлять их новой нормой.

3. Выберите правильную гранулярность

Минутные данные дают быструю реакцию, но мало событий и много случайности. Суточные устойчивее, но могут обнаружить проблему слишком поздно. Гранулярность зависит от стоимости задержки и типичного объёма; иногда полезны два контура — быстрый технический и медленный экономический.

4. Не смешивайте несопоставимые кампании

Среднее по брендовому поиску, push и social не является baseline ни для одного источника. Сегментация нужна по механизмам, влияющим на распределение: источник, GEO, устройство, модель оплаты, версия лендинга и стадия кампании. Слишком мелкие сегменты, однако, теряют статистическую силу.

5. Определите минимальный объём наблюдения

CTR после десяти показов и после десяти тысяч имеет разную неопределённость. Алерт по доле должен учитывать знаменатель. При малом объёме система может отложить оценку, объединить несколько интервалов или использовать подходящее распределение, но не выдавать случайный скачок за уверенный сигнал.

6. Очистите историю от известных инцидентов

Периоды отключённого постбэка, ошибочной разметки и ручной остановки не должны формировать норму. Их не обязательно удалять физически: достаточно пометить и исключить из обучения конкретной модели. Журнал исключений сохраняет воспроизводимость baseline.

7. Сохраняйте запланированные изменения

Запуск креатива, новая ставка, перенос лендинга и изменение cap закономерно меняют процесс. Если модель не знает о релизе, она либо поднимет лишнюю тревогу, либо быстро примет деградацию за норму. Change events должны быть частью временного ряда.

8. Учитывайте недельную сезонность

Понедельник корректнее сравнивать с предыдущими понедельниками, если поведение стабильно зависит от дня недели. Аналогично важны час, праздники и расчётные периоды. Сезонность включают только после подтверждения историей: слишком сложный календарь способен объяснить любую ошибку постфактум.

9. Учитывайте тренд отдельно от всплеска

Кампания может постепенно выгорать, и каждое дневное значение останется близким к вчерашнему. Baseline с бесконтрольным адаптивным средним последует за деградацией и не подаст сигнал. Для дрейфа нужны более длинное ожидание, сравнение уровней и отдельный detector изменения режима.

10. Выберите устойчивую центральную линию

Среднее чувствительно к большим выбросам. Медиана или усечённая оценка иногда лучше описывает типичный уровень, особенно для тяжёлых распределений выручки. Выбор зависит от метрики: редкая крупная ценность может быть реальной частью экономики и не должна исчезнуть только ради гладкого графика.

11. Моделируйте разброс, а не одну норму

Ожидаемое значение без диапазона не позволяет оценить неожиданность. NIST описывает control chart как временной ряд с центральной линией и верхней и нижней контрольными границами для процесса в контроле. Эти границы отражают естественную вариативность, а не бизнес-целевой план.

12. Не называйте контрольную границу целью

Процесс может быть статистически стабилен и при этом экономически неприемлем. И наоборот, прибыльный всплеск может выйти за контрольную границу и потребовать проверки устойчивости. Нужны два слоя: отклонение от собственного процесса и соответствие бизнес-ограничению.

13. Используйте асимметричные ожидания

Для расхода внезапный рост и падение имеют разную цену. Для approve rate верхнее отклонение тоже может указывать на смену правил или задержку отказов. Верхняя и нижняя стороны могут иметь разные чувствительность, владельца и сценарий реакции.

14. Работайте с задержанными метриками

Revenue и approval дозревают. Сравнение свежего дня со зрелой историей гарантированно создаёт ложное падение. Baseline строят на одинаковом возрасте когорты или прогнозируют дозревание с интервалом. Система должна показывать, какая часть сигнала ещё способна измениться.

15. Разделите уровень и структуру

Общий CPA может остаться прежним, пока доля дорогого GEO растёт, а эффективность внутри сегментов ухудшается. Мониторинг проверяет агрегат и состав. Изменение mix иногда полностью объясняет общий показатель; иногда маскирует локальную проблему.

16. Проверяйте связанные метрики вместе

Падение кликов при стабильных показах указывает на один класс причин, падение и показов, и расхода — на другой. Мультисигнальная диагностика уменьшает число гипотез. Но единый сложный score не должен скрывать исходные ряды и вклад каждого признака.

17. Учитывайте зависимость между показателями

CPC, CTR, CPM и spend математически связаны. Четыре одновременных алерта могут описывать одно событие. Система группирует их в инцидент по времени, кампании и причинной близости, чтобы дежурный не расследовал один сбой четыре раза.

18. Настройте чувствительность по стоимости ошибки

Ложная тревога тратит внимание и приучает игнорировать систему. Пропуск инцидента тратит бюджет. Для большого spend и необратимого риска порог реакции ниже; для малой тестовой кампании допустимо ждать больше данных. Это решение бизнеса, а не универсальный параметр модели.

19. Используйте несколько уровней сигнала

Предупреждение сообщает о необычном наблюдении, критический алерт — о подтверждённом сочетании масштаба, длительности и риска. Между ними может быть состояние наблюдения. Такая эскалация позволяет не выключать кампанию по одному шумному интервалу.

20. Требуйте длительность или повтор

Один выброс может быть случайностью; несколько последовательных умеренных отклонений — дрейфом. Правила run length и накопительные методы реагируют на форму изменения. NIST отмечает, что EWMA использует экспоненциально убывающий вес прошлых измерений и полезен для обнаружения небольших сдвигов.

21. Не адаптируйте baseline слишком быстро

Если ожидание обновляется каждым новым значением, длительный инцидент становится нормой. Введите задержку обучения, защитный период после алерта и ручную маркировку подтверждённых изменений режима. Baseline должен учиться на нормальной работе, а не на всём подряд.

22. Не замораживайте baseline навсегда

С другой стороны, старая норма теряет смысл после устойчивого масштабирования или смены аукциона. Переобучение выполняют по расписанию и событиям, сравнивают старую и новую модель на holdout-периоде и сохраняют версию. Резкий скачок ожидания требует объяснения.

23. Проверяйте модель на исторических инцидентах

Backtest отвечает, подала бы система сигнал до того, как проблему заметил человек, и сколько ложных тревог создала бы в обычные дни. Исторический набор должен включать разные типы сбоев и спокойные периоды. Оптимизация только под известные инциденты переобучает правила.

24. Проводите теневой запуск

Новая модель сначала генерирует сигналы без автоматических действий. Команда оценивает понятность, задержку, дубли и пропуски. Только после этого критические сценарии могут запускать ограниченную автоматическую защиту, например снижение бюджета, но не необратимые изменения.

25. Делайте алерт объяснимым

Сообщение должно содержать текущее значение, ожидаемый диапазон, масштаб, длительность, затронутые сегменты, недавние изменения и ссылки на исходные графики. Фраза «anomaly score 0.93» не помогает принять решение, если неизвестно, что именно произошло.

26. Начинайте расследование с развилки

Сначала проверяется качество данных, затем изменение состава, исполнение платформы, продуктовый маршрут и внешняя среда. Порядок сокращает время: бессмысленно обсуждать креатив, пока половина postback не доставлена. Результат расследования возвращается в журнал как подтверждённая причина или неизвестное.

27. Измеряйте качество самого мониторинга

Считайте время до обнаружения, время до подтверждения, долю ложных тревог, повторные алерты одного инцидента, пропуски и стоимость предотвращённого ущерба с осторожной методикой. Количество алертов не является успехом: хорошая система может отправлять их меньше, но раньше и точнее.

28. Оставляйте место для неизвестного

Не всякое отклонение удаётся объяснить. Категория unknown лучше выдуманной причины. Она сохраняет честность и формирует очередь улучшений: добавить технический сигнал, событие релиза или новый разрез, если неизвестные случаи повторяются.

Аномалия не является автоматическим приговором кампании

Она сообщает, что наблюдение плохо согласуется с ожиданием. Остановка, снижение бюджета или продолжение зависят от качества данных, масштаба риска и заранее согласованного runbook.

Официальные источники

NIST/SEMATECH о контрольных картах: https://www.itl.nist.gov/div898/handbook/pmc/section3/pmc31.htm; раздел мониторинга процессов и временных рядов: https://itl.nist.gov/div898/handbook/pmc/pmc.htm; замечание об EWMA для малых сдвигов: https://www.itl.nist.gov/div898/handbook/mpc/section2/mpc22.htm

Вывод

Живой baseline учитывает время, объём, состав, зрелость и известные изменения кампании. Он не отменяет фиксированные бизнес-ограничения, а решает другую задачу — замечает неожиданное поведение процесса. Качественный мониторинг отделяет сбой данных от бизнеса, объединяет связанные сигналы, объясняет тревогу и учится только после подтверждения новой нормы.