Трекер врет не сам по себе — ему подсовывают поддельные postback, cookie и IP

Трекер врет не сам по себе — ему подсовывают поддельные postback, cookie и IP

Давайте поднимем логи и посмотрим правде в глаза. Подмена данных в трекере почти всегда начинается не с «взлома», а с дырки в доверии: открытый postback без подписи, слабый clickid, отсутствие сверки user-agent и IP-пула. Ботнеты эволюционируют, но паттерны их поведения остаются прежними: массовые клики с одинаковым TTL, одинаковым JA3, одинаковыми таймингами до конверсии.

Что ломают чаще всего:
• clickid, который можно угадать или переиспользовать;
• postback, принимающий запрос без HMAC-подписи;
• редиректы, где не проверяется цепочка referrer → landing → action;
• антифрод, который смотрит только на одну метрику и игнорирует аномалии по сессии.

Защита строится не на одном фильтре, а на связке:
— подписывайте каждый server-to-server callback;
— привязывайте событие к IP, UA, времени жизни и fingerprint;
— режьте повторные конверсии по одному clickid;
— сравнивайте распределение задержек, а не только факт события;
— ставьте пороги на подозрительные ASN, датацентры и нестабильные цепочки редиректов.

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

Сначала закрывайте канал доверия, потом уже стройте отчеты. Иначе вы оптимизируете не трафик, а аккуратно упакованный фрод.