Как собрать доказательства ботового трафика и прижать подрядчика логами, а не эмоциями

Как собрать доказательства ботового трафика и прижать подрядчика логами, а не эмоциями

Давайте поднимем логи и посмотрим правде в глаза. Некачественный трафик доказывается не «ощущением просадки», а набором повторяемых артефактов: одинаковые user-agent, нулевой scroll depth, клики с интервалом в миллисекунды, одинаковые referrer chain и подозрительно ровные сессии без пауз. Ботнеты эволюционируют, но паттерны их поведения остаются прежними.

Собирайте не только конверсии, а сырые данные: IP, ASN, user-agent, accept-language, timestamps, session_id, device fingerprint, click_id, postback. Ищите:
— аномально высокий % трафика с одного ASN или подсети;
— повторяющиеся fingerprint на разных IP;
— одинаковые цепочки событий: click → landing → bounce за 1–3 секунды;
— нулевую глубину просмотра при формально «живых» сессиях.

Дальше строите сравнение по кластерам. У нормального потока распределение времени до первого действия, глубины скролла и времени на странице имеет хвост. У мусорного — пики на одинаковых значениях и почти идеальная синхронизация. Если подрядчик спорит, просите выгрузку по clickstream и сверяйте с вашими server-side логами: расхождения в user-agent, IP-географии и последовательности запросов обычно вскрывают ручной «креатив» фродера без лишней магии.

Фиксируйте доказательства так, чтобы их нельзя было списать на «особенности аудитории»: выгрузка по дням, хэш-срезы fingerprint, таблица повторов по IP/UA, скриншоты сырых логов, а не красивые дашборды. Если метрика не воспроизводится на другом окне атрибуции, это уже не спор о качестве, а проблема в поставке трафика.

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