Как настроить алерт на аномалии в отчётности (например, резкий скачок расходов), не создавая при этом лишнего шума из ложных срабатываний?

Короткий ответ

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

Как это работает подробнее

Например, алерт срабатывает, если расход за день превышает среднее за последние 7 дней более чем на X% и абсолютный расход выше минимального порога, что исключает шум на кампаниях с маленьким бюджетом, где колебания в процентах естественно велики. Стоит также предусмотреть отдельные пороги для разных по размеру кампаний или каналов, так как один и тот же процент отклонения может быть нормальным для крупного канала и критичным для совсем нового.

Пример кода

daily_spend_anomaly.sqlКопировать

WITH baselines AS (
  SELECT report_date, channel, spend,
         AVG(spend) OVER (
           PARTITION BY channel ORDER BY report_date
           ROWS BETWEEN 7 PRECEDING AND 1 PRECEDING
         ) AS avg_7d
  FROM daily_spend
)
SELECT report_date, channel, spend, avg_7d
FROM baselines
WHERE avg_7d IS NOT NULL AND spend > 1.5 * avg_7d AND spend > 5000;

Что использовать на практике

• Практика. На практике важно протестировать пороги алерта на исторических данных перед включением в продуктив, чтобы оценить, сколько ложных срабатываний он бы дал за последние несколько месяцев, и скорректировать чувствительность. Полезно разделять алерты по уровню критичности (например, предупреждение и срочный алерт), чтобы команда реагировала быстрее на действительно серьёзные отклонения и не терялась в потоке одинаковых по важности уведомлений.
• Пример. Например, алерт срабатывает при суточном расходе выше 150% среднего за предыдущие семь дней и выше абсолютного порога; проверьте частоту ложных тревог на истории за три месяца.

Подводные камни

• Риск. Частая ошибка — ставить фиксированный процентный порог без учёта объёма, например «алерт при росте расхода на 20%», из-за чего мелкие кампании с естественной волатильностью постоянно генерируют ложные алерты, и команда начинает их игнорировать.