Виявлення VPN — це не валідація кліків: порівняйте сигнали

У більшості обговорень клікфроду два питання зливаються, і саме з цього злиття народжуються погані рішення. Перше — звідки прийшов запит, на що мережева класифікація може відповісти приблизно. Друге — чи слід рахувати подію, що залежить від правил допустимості, поведінки та результату. Мітка VPN — це доказ для першого питання, і сама по собі вона нічого не говорить про друге.

Два питання, які виглядають як одне

Перше питання описове: чи прийшов цей запит через хостинг-провайдера, VPN для приватності або домашнє підключення? Друге нормативне: чи відповідає ця подія визначенню, про яке домовився ваш бізнес? Описові відповіді дешеві й статистичні. Нормативні відповіді вимагають визначення та власника.

Їх змішування дає детектор, який самовпевнений і помилковий. Можна правильно класифікувати кожен запит і все одно рахувати недопустимі події, бо класифікація жодного разу не запитала, що таке допустима подія.

Що може обґрунтувати мережева мітка

Клас адреси — це твердження про популяцію, а не про окрему людину. Один IP може стояти перед NAT операторського рівня з тисячами абонентів, корпоративним виходом на весь офіс або VPN для приватності з незв’язаними користувачами. Називати цю адресу підозрілою — означає приписувати поведінку небагатьох усім, хто за нею.

Рекомендації Google щодо недійсного трафіку — корисний конкретний приклад проблеми визначення. Вони охоплюють і навмисне шахрайство, і випадкові кліки, а отже, модель самої платформи розглядає як предмет подію та її контекст, а не лише мережу доставки.

Рядок user agent цього не рятує. Його повідомляє сам клієнт, його легко змінити, і він не є автентифікованою особою. Сприймайте його як підказку, що корелює з родиною пристроїв, і ніколи — як заяву про намір.

Що додає перевірка на рівні події

Перевірка на рівні події ставить інші питання: чи було цей кредит зараховано більше ніж один раз за одну взаємодію, чи виглядав потік автоматизованим, чи сесія була достатньо довгою, щоб прочитати те, по чому клікнули, і чи відповідав подальший результат заявленому інтересу? На все це можна відповісти даними першої сторони, які ви вже зберігаєте.

Зверніть увагу, що жодне з них не вимагає універсального порогу. Сплеск активності — це привід переглянути вікно, а не доказ клік-ферми, і одна дивна сесія не є доказом координації. Поріг, який ви вигадаєте, буде хибним для якогось законного робочого процесу, тому формулюйте його як тригер перевірки, а не як вирок.

Де зазнає невдачі кожен підхід

Поставте три сигнали поряд, і сліпі зони стануть очевидними.

Таблиця — це все порівняння. Кожен рядок — реальний сигнал із реальною сліпою зоною, і жоден із них не є визначенням шахрайства.

Вимірюйте детектор, а не лише трафік

Тримайте три набори: події, які ви знаєте як законні, підтверджено недопустимі події та випадки, які ви не змогли розв’язати. Оцінюйте детектор за всіма трьома. Правило, що відкидає кожен спільний вихід, виглядає рішуче на наборі підтверджено недопустимих і тихо шкодить звичайним користувачам, і саме цей компроміс ніхто не вимірює.

Записуйте хибні спрацювання як метрику першого класу, поряд із відсутньою інформацією. Якщо невирішена корзина продовжує зростати, детектор не стає кращим; він стає тихішим.

Дайте рішенню власника

Узгодьте з платформою вимірювань або реклами та власником сервісу, перш ніж змінювати правило. Використовуйте підтримуваний платформою процес звітності та виправлення замість тестування живих монетизованих оголошень штучними кліками, що створює саме той недійсний трафік, який ви намагаєтеся запобігти.

Обмежте збирання тією метою, яку можете обґрунтувати. Бажання класифікувати шахрайство не робить безстроковий збір відбитків вимогою, а Рекомендації AdSense щодо недійсного трафіку — це розумне посилання на те, як платформа окреслює категорії.

Почніть із того, що опишете допустиму подію одним реченням. Якщо речення про мережеве походження, у вас проксі-метрика, а не визначення.