Скликивание в поиске видно не в отчёте, а в серверных логах

Скликивание в поиске видно не в отчёте, а в серверных логах

Давайте поднимем логи и посмотрим правде в глаза. В поисковой рекламе фрод почти всегда оставляет след на уровне HTTP: одинаковые User-Agent, повторяющиеся IP/подсети, нулевая глубина сессии, короткий интервал между кликом и отказом. Когда у вас есть сырой access.log, можно ловить не «подозрительный CTR», а конкретную механику атаки.

Смотрите на связку полей: IP, UA, referer, cookie, timestamp, path. Для живого трафика характерна вариативность: разные окна, разные задержки, естественные последовательности запросов. Для скликивания — пачки кликов с одного ASN, синхронные тайм-слоты, пустой или однотипный referer, отсутствие последующих хитов на сайте. Ботнеты эволюционируют, но паттерны их поведения остаются прежними.

Что искать в логах:
• burst-rate по IP/подсети: несколько кликов за короткое окно
• UA-коллизии: один и тот же fingerprint на десятках кликов
• click-to-pageview gap: клик есть, а загрузки целевой страницы нет
• cookie mismatch: новый клик без устойчивой сессии
• подозрительные referrer chains: редиректы, обрывы, пустые цепочки

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

Нормальная защита начинается с парсера логов, правил агрегации и порогов на уровне IP/UA/cookie. Без этого вы защищаете не трафик, а иллюзию трафика.