SDK Spoofing и Click Injection: как мобильный фрод подменяет атрибуцию

SDK Spoofing и Click Injection: как мобильный фрод подменяет атрибуцию

Давайте поднимем логи и посмотрим правде в глаза. В mobile attribution мошеннику не нужно «ломать» приложение — достаточно подделать сигнал, который SDK считает валидным. Ботнеты эволюционируют, но паттерны их поведения остаются прежними: ложный клик, затем фейковый install, а в трекинге — идеальная цепочка, которой в реальности не было.

SDK Spoofing работает на уровне имитации ответов и событий: подставляется device_id, timestamp, referrer, иногда целиком лепится набор полей из типового install payload. Если у вас нет строгой валидации связки click_id ↔ device ↔ session, трекер принимает мусор за конверсию. Сырые логи обычно выдают это по аномалиям: слишком ровные интервалы, одинаковые UA-паттерны, повторяющиеся значения параметров, нулевой предиктивный след в post-install поведении.

Click Injection проще и наглее: вредоносное приложение слушает системные события и в момент легитимной установки отправляет свой клик раньше честного источника. Результат — last click wins, а бюджет уезжает в карман «партнера». Дальше смотрите на тайминг: подозрительно короткий click-to-install, массовые конверсии с одного app bundle, всплески install без соответствующей вовлеченности. 🎯

Защита не в одном флажке, а в связке: серверная атрибуция, защита от повторной отправки событий, allowlist на источники, корреляция времени жизни сессии и install window, проверка аномалий по устройству и сети. Если SDK можно заставить поверить в любой payload, значит ему нельзя доверять без независимой серверной сверки.

Финальный критерий простой: если конверсия не бьется с поведением после install, это не аудитория — это подмена сигнала.