<b>Как трекер подменяют на входе и почему защита ломается в логах, а не в рекламе</b>

<b>Как трекер подменяют на входе и почему защита ломается в логах, а не в рекламе</b>

Давайте поднимем логи и посмотрим правде в глаза. Большинство подмен начинается не с «магии», а с банального доверия к параметрам запроса: click_id, subid, fbclid, utm и рефереру. Если трекер принимает их без проверки связности, атакующий легко рисует фальшивую атрибуцию: клик есть, сессия есть, а реального пользователя нет.

Типовые дыры выглядят одинаково:
— нет HMAC/подписи на click_id и postback;
— слабо валидируется IP/ASN/гео-переход между кликом и конверсией;
— отсутствует защита от replay, и один postback можно протащить повторно;
— трекер верит User-Agent и Accept-Language без корреляции с TLS/HTTP-профилем.

Ботнеты эволюционируют, но паттерны их поведения остаются прежними: одинаковые интервалы между кликами, однотипные заголовки, короткие цепочки редиректов, нулевая глубина скролла, странные расхождения между click time и conversion time. Сырые логи это показывают лучше любого «антибота» на витрине.

Защита строится не на одном фильтре, а на цепочке: подписывайте параметры, храните nonce с TTL, сверяйте IP-кластер и ASN, режьте повторные postback по idempotency key, добавляйте поведенческий скоринг и отдельный blacklist для прокси/дата-центров. Вот технический разбор того, как именно уплывает ваш рекламный бюджет: сначала подменяют идентификатор, потом легализуют событие, а затем трекер сам же записывает фрод в «успешные».

Финал простой: если в вашей схеме можно подставить любой click_id и получить засчитанную конверсию, у вас не трекер, а касса самообслуживания для ботов.