Кейс 4: Нужно защититься от фрода при атрибуции, когда события отправляются напрямую с нашего сервера на сервер AppsFlyer.

Условие

Кейс 4: Нужно защититься от фрода при атрибуции, когда события отправляются напрямую с нашего сервера на сервер AppsFlyer. Контекст: приложение подвергается атакам эмуляторов, фроду установок, фейковому заполнению анкет. Базовый антифрод AppsFlyer (Protect360) отсекает часть трафика, но бизнес требует внедрения внутренней кастомной валидации перед отправкой финальных целевых событий в рекламные каналы. Рекламные каналы передают click_id, по которому нужно отбивать события — платим только за выдачу кредита. Нужно разработать схему API-взаимодействия и бизнес-правил для безопасной передачи конверсии: при каких условиях событие маркируется как валидное и отправляется партнёру, а когда оно невалидное, и как оно обрабатывается в каждом случае.

Ответ

Финальную конверсию отправляют только по подтверждённому серверному факту выдачи и проверенной связи с допустимым click_id. Клиентский запрос или статус анкеты не должны сами подтверждать оплату партнёру.

Поток: сохранить атрибуционный контекст → принять заявку → провести внутренние проверки → подтвердить выдачу в учётной системе → создать outbox-событие → отправить S2S. Уникальность задают по выдаче и типу конверсии; повторная доставка не должна приводить к повторной оплате. Правила валидности включают допустимое окно, отсутствие дубля и подтверждение бизнес-результата. Подозрительные случаи идут на проверку, невалидные сохраняются с причиной без отправки. Отсутствие ответа провайдера означает необходимость сверки, а не создания новой конверсии. Секреты остаются на сервере, лишние персональные данные не передаются.