Обнаружение VPN — не валидация кликов: сравните сигналы
Сетевой ярлык отвечает, откуда пришёл трафик. Достоверность клика касается события, его допустимости и результата. Вот как сопоставляются два сигнала.
В большинстве обсуждений кликфрода два вопроса сливаются, и именно из этого слияния рождаются плохие решения. Первый — откуда пришёл запрос, на что сетевая классификация может ответить приблизительно. Второй — нужно ли учитывать событие, что зависит от правил допустимости, поведения и результата. Метка VPN — это доказательство для первого вопроса, и сама по себе она ничего не говорит о втором.
Два вопроса, которые выглядят как один
Первый вопрос описательный: пришёл ли этот запрос через хостинг-провайдера, VPN для приватности или домашнее подключение? Второй нормативный: соответствует ли это событие определению, о котором договорился ваш бизнес? Описательные ответы дешёвы и статистичны. Нормативные ответы требуют определения и владельца.
Их смешение даёт детектор, который самоуверен и ошибочен. Можно правильно классифицировать каждый запрос и всё равно считать недопустимые события, потому что классификация ни разу не спросила, что такое допустимое событие.
Что может обосновать сетевой ярлык
Класс адреса — это утверждение о популяции, а не об отдельном человеке. Один IP может стоять перед NAT операторского уровня с тысячами абонентов, корпоративным выходом на весь офис или VPN для приватности с несвязанными пользователями. Называть этот адрес подозрительным — значит приписывать поведение немногих всем, кто за ним.
Рекомендации Google по недействительному трафику — полезный конкретный пример проблемы определения. Они охватывают и умышленное мошенничество, и случайные клики, а значит, модель самой платформы рассматривает в качестве предмета событие и его контекст, а не только сеть доставки.
Строка user agent этого не спасает. Её сообщает сам клиент, её легко изменить, и она не является аутентифицированной личностью. Считайте её подсказкой, коррелирующей с семейством устройств, и никогда — заявлением о намерении.
Что добавляет проверка на уровне события
Проверка на уровне события задаёт другие вопросы: был ли этот кредит посчитан более одного раза за одно взаимодействие, выглядел ли поток автоматизированным, была ли сессия достаточно долгой, чтобы прочитать то, по чему кликнули, и соответствовал ли последующий результат заявленному интересу? На всё это можно ответить данными первой стороны, которые вы уже храните.
Обратите внимание, что ни один из них не требует универсального порога. Всплеск активности — это повод просмотреть окно, а не доказательство клик-фермы, и одна странная сессия не является доказательством координации. Придуманный вами порог окажется неверным для какого-то законного рабочего процесса, поэтому формулируйте его как триггер проверки, а не как приговор.
Где терпит неудачу каждый подход
Поставьте три сигнала рядом, и слепые зоны станут очевидны.
| Signal | Question it answers | Characteristic failure |
|---|---|---|
| Address classification | Where did this arrive from | Rejects shared exits and privacy-conscious users |
| Automation signals | Does this look scripted | Misses paid human interaction entirely |
| Event and outcome review | Should this count | Needs a definition and an owner to be meaningful |
Таблица — это всё сравнение. Каждая строка — реальный сигнал с реальной слепой зоной, и ни один из них не является определением мошенничества.
Измеряйте детектор, а не только трафик
Держите три набора: события, которые вы знаете как законные, подтверждённо недопустимые события и случаи, которые вы не смогли разрешить. Оценивайте детектор по всем трём. Правило, отвергающее каждый общий выход, выглядит решительно на наборе подтверждённо недопустимых и тихо вредит обычным пользователям, и именно этот компромисс никто не измеряет.
Записывайте ложные срабатывания как метрику первого класса, наряду с недостающей информацией. Если нерешённая корзина продолжает расти, детектор не становится лучше; он становится тише.
Дайте решению владельца
Согласуйте с платформой измерений или рекламы и с владельцем сервиса, прежде чем менять правило. Используйте поддерживаемый платформой процесс отчётности и исправления вместо тестирования живых монетизированных объявлений искусственными кликами, что создаёт именно тот недопустимый трафик, который вы пытаетесь предотвратить.
Ограничьте сбор той целью, которую можете обосновать. Желание классифицировать мошенничество не делает бессрочный сбор отпечатков требованием, а Рекомендации AdSense по недействительному трафику — разумная отправная точка для того, как платформа задаёт рамки категорий.
Начните с того, что опишите допустимое событие одним предложением. Если предложение об источнике в сети, у вас прокси-метрика, а не определение.