SDK Spoofing и Click Injection: как ломают attribution в мобильном фроде

SDK Spoofing и Click Injection: как ломают attribution в мобильном фроде

Давайте поднимем логи и посмотрим правде в глаза. В mobile fraud чаще всего работают две схемы: подмена SDK-цепочки и внедрение фиктивного клика перед установкой. Первая бьёт по телеметрии, вторая — по attribution window. Обе маскируются под «нормальный» user flow, и именно поэтому бюджет утекает тихо.

SDK Spoofing — это когда фродер имитирует события, которые обычно генерирует приложение: install, session, purchase, level_up. В логах это выглядит как идеальная воронка без естественной паузы между touchpoint и событием, с одинаковыми payload-паттернами, повторяющимися device_id и подозрительно ровными таймстампами. Если событие приходит без предшествующей сетевой активности приложения, это уже не пользователь, а скрипт в спортивном костюме.

Click Injection работает проще и циничнее. Малварь на устройстве слушает установочный процесс и, поймав момент перед first open, отправляет «последний» клик, который перехватывает атрибуцию. В сырых логах это видно по микрозадержкам: клик живёт секунды, а затем почти сразу прилетает install, при этом path-to-install аномально короткий, а реального engagement до инсталла нет.

Защита строится не на одном сигнале, а на связке:
— сверяйте timing: click-to-install, click-to-event, event-to-event;
— ищите дубли по device fingerprint, IP, ASN, user agent и session entropy;
— режьте события без устойчивой сетевой истории и без нормального распределения задержек;
— помечайте installs, где SDK события выглядят слишком «чисто» и однотипно.

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