Трекер врёт не “иногда”, а ровно там, где вы не валидируете входные данные

Трекер врёт не “иногда”, а ровно там, где вы не валидируете входные данные

Давайте поднимем логи и посмотрим правде в глаза. Уязвимость трекера почти всегда начинается с доверия к GET-параметрам и postback без жёсткой привязки к сессии. Если click_id можно подменить, а сервер принимает конверсию без сверки IP, user-agent, referer и времени жизни клика — бюджет уже течёт в чужой карман.

Типовые дыры одинаковы:
— open redirect в редирект-цепочке: подмена destination и кража атрибуции
— слабая дедупликация: один и тот же event проходит дважды
— отсутствие HMAC на click_id/pixel payload: фальшивый postback выглядит легитимно
— доверие к рефереру и кукам без проверки связности цепочки запросов

Защита строится не на “антиботе”, а на жёсткой корреляции сигналов. Сверяйте TTL клика, ASN, geo, fingerprint браузера и тайминг между click и conversion. Любой event, пришедший вне окна или с разрывом по сетевому профилю, уходит в quarantine. Отдельно режьте аномалии: одинаковые user-agent string, массовые одинаковые referrer, скачки в частоте событий с одного /24. Ботнеты эволюционируют, но паттерны их поведения остаются прежними.

И главное: логируйте сырьё, а не “статистику”. Храните request headers, raw query string, IP reputation, и весь redirect-chain. Тогда подмена данных перестаёт быть магией — она становится просто невалидным пакетом, который сервер обязан отклонить.