Интеграция антифрода ломается не в API, а в точке склейки трафика и логики

Интеграция антифрода ломается не в API, а в точке склейки трафика и логики

Антифрод-сервис сам по себе ничего не «решает». Он получает поток событий: IP, fingerprint, user-agent, referer, cookie, поведенческие признаки, а дальше уже ваша backend-логика решает, кого пустить, кого завернуть, а кого отправить на доп.проверку. Анализ логов показывает: проблемы начинаются, когда один слой видит одно, а второй — совсем другое.

Разберем техническую составляющую реализации. Перед подключением проверьте:
— совпадение IP/Geo с источником трафика;
— стабильность fingerprint между кликами и конверсией;
— передачу event_id, чтобы не было дублей;
— корректный referer и цепочку редиректов;
— таймауты и retry, чтобы сервис не резал запросы по ошибке 5xx.

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

Проверка цепочки прохождения запроса обязательна: от креатива до postback. Сверяйте статус-коды, логи по session_id и расхождения между кликом, лидом и финальным скором. Конфиг готов, можно деплоить только тогда, когда каждый переход в цепочке воспроизводится вручную и совпадает в логах.