Аномалии в потоке трекинга ловятся не по ROI, а по ритму событий

Аномалии в потоке трекинга ловятся не по ROI, а по ритму событий

Если смотреть только на итоговую CR, мусор в данных всплывает поздно. Нужен контроль формы потока: распределение кликов по часам, доля unique/repeat, лаг между click и postback, всплески по одному UA или GEO.

Базовый набор сигналов:
— резкий сдвиг click→conversion lag без изменения источника;
— одинаковые IP/ASN у разных связок;
— конверты приходят пачкой после длинной тишины;
— CTR и CR расходятся с исторической связкой у того же оффера;
— postback'и идут, а downstream-событий нет.

Дальше работай не по абсолютам, а по окнам. Сравни текущий поток с медианой за похожие часы и дни недели, плюс отдельно держи baseline по каждому источнику, сабайди, прокси-сегменту и device class. Если аномалия живёт только в одном кластере, режь его точечно, а не весь трафик.

Для триажа достаточно трёх уровней: soft alert, quarantine, kill switch. Soft alert — когда отклонение устойчиво, но ещё не ломает экономику. Quarantine — когда источник продолжает слать, но уходит в отдельную проверку. Kill switch — когда аномалия касается атрибуции, postback'ов или явного фрода.

Главное: anomaly detection в трекинге — это не ML-магия, а дисциплина метрик. Чем раньше ты видишь сдвиг в форме потока, тем меньше шансов кормить систему грязными конверсиями.