<b>Fraud detection ломается там, где команды смотрят только на клики и конверсии</b>

<b>Fraud detection ломается там, где команды смотрят только на клики и конверсии</b>

Fraud detection почти всегда деградирует не из-за «плохой модели», а из-за узкого набора сигналов. Если у вас в решении нет связки между поведением, устройством и источником трафика, то обход начинается с простого: меняется IP, чистится профиль, а паттерн остаётся прежним.

Что полезно проверять в любой воронке:
— скорость действий: слишком ровные интервалы между событиями
— повторяемость браузерного отпечатка на разных аккаунтах
— несостыковки между гео, языком, часовым поясом и поведением
— одинаковые сценарии клика и скролла у разных пользователей
— аномалии в postback: всплески, кластеры, дубли, «слишком чистые» лиды

Слабое место многих антифрод-систем — поздняя реакция. Если триггер срабатывает только на подтверждённой конверсии, арбитраж уже успевает прогнать объём. Поэтому полезнее строить не один блокирующий фильтр, а цепочку: pre-click, on-click, post-click, postback. Каждый слой ловит свой тип мусора.

Отдельно смотрите на «честный шум»: реальные пользователи редко выглядят одинаково. Слишком аккуратные сессии, одинаковая глубина просмотра и повторяемые маршруты часто вреднее, чем отдельные подозрительные IP.

Если упростить: fraud detection должен искать не факт подмены, а несоответствие между слоями сигнала. Чем раньше вы это ловите, тем меньше шансов у обхода.