Откриването на VPN не е валидиране на кликове: сравнете сигналите
Мрежовият етикет отговаря откъде идва трафикът. Валидността на клика е за събитието, неговата допустимост и резултата. Ето как се сравняват двата сигнала.
В повечето дискусии за клик измами се сливат два въпроса и точно от това сливане идват лошите решения. Първият е откъде е дошла заявката, на което мрежовата класификация може да отговори приблизително. Вторият е дали събитието трябва да се брои, което зависи от правилата за допустимост, поведението и резултата. Етикетът VPN е доказателство за първия въпрос и сам по себе си не казва нищо за втория.
Два въпроса, които изглеждат като един
Първият въпрос е описателен: пристигна ли тази заявка през хостинг доставчик, VPN за поверителност или домашна връзка? Вторият е нормативен: отговаря ли това събитие на определението, за което се е съгласил вашият бизнес? Описателните отговори са евтини и статистически. Нормативните отговори изискват определение и собственик.
Объркването им създава детектор, който е уверен и грешен. Можете да класифицирате всяка заявка правилно и пак да броите невалидни събития, защото класификацията никога не е питала какво е допустимо събитие.
Какво може да подкрепи мрежовият етикет
Класът на адреса е твърдение за популация, а не за индивид. Един IP може да стои пред carrier-grade 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 за невалиден трафик са разумна отправна точка за това как платформата очертава категориите.
Започнете, като напишете допустимото събитие в едно изречение. Ако изречението е за мрежовия произход, имате прокси метрика, а не определение.