Трекер врёт не в отчёте — он врёт уже на входе: где ломают атрибуцию

Трекер врёт не в отчёте — он врёт уже на входе: где ломают атрибуцию

Давайте поднимем логи и посмотрим правде в глаза. Подмена данных в трекере почти всегда идёт по трём каналам: client-side параметры, server-to-server постбэки и cookie/localStorage. Если в цепочке нет жёсткой валидации click_id, source_ip, user-agent и времени жизни события, любой фрод-скрипт подставит «чистую» конверсию в уже оплаченный клик.

Типовые дыры:
• click_id не привязан к одному источнику и живёт дольше окна сессии
• postback принимает событие без HMAC-подписи или nonce
• редиректы не проверяют несоответствие IP/UA между кликом и конверсией
• трекер доверяет referrer и UTM, хотя их правят на уровне браузера и прокси

Защита начинается не с «антибота», а с нормальной схемы доверия. На каждый клик нужен серверный токен с подписью, коротким TTL и привязкой к fingerprint сетевого уровня: ASN, /24, UA, Accept-Language, часовой пояс, последовательность redirect hop. Если конверсия приходит с другого профиля — режьте её в quarantine, а не в отчёт «accepted». Ботнеты эволюционируют, но паттерны их поведения остаются прежними.

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