Откривање VPN-а није валидација кликова: упоредите сигнале

У већини расправа о клик преварама спајају се два питања, а лоше одлуке долазе управо из тог спајања. Прво је одакле је захтев дошао, на шта мрежна класификација може одговорити приближно. Друго је треба ли догађај уопште рачунати, што зависи од правила подобности, понашања и исхода. Ознака VPN-а доказ је за прво питање и сама по себи не говори ништа о другом.

Два питања која изгледају као једно

Прво питање је описно: је ли овај захтев стигао преко хостинг провајдера, VPN-а за приватност или кућне везе? Друго је нормативно: задовољава ли овај догађај дефиницију око које се ваше пословање договорило? Описни одговори су јефтини и статистички. Нормативни одговори траже дефиницију и власника.

Њихово мешање даје детектор који је самоуверен и погрешан. Можете исправно класификовати сваки захтев и ипак бројати неважеће догађаје, јер класификација никада није питала шта је подобан догађај.

Шта мрежна ознака може да подржи

Класа адресе је изјава о популацији, а не о појединцу. Једна IP адреса може стајати испред carrier-grade NAT-а са хиљадама претплатника, корпоративног излаза за целу канцеларију или VPN-а за приватност са неповезаним корисницима. Назвати ту адресу сумњивом значи приписати понашање неколицине свима иза ње.

Google-ове смернице о неважећем саобраћају користан су конкретан пример проблема дефиниције. Покривају и намерну превару и случајне кликове, што значи да властити модел платформе као предмет узима догађај и његов контекст, а не само мрежу доставе.

Низ корисничког агента то не спасава. Њега сам пријављује клијент, лако се мења и није аутентификовани идентитет. Третирајте га као наговештај који корелира с породицом уређаја, никада као изјаву о намери.

Шта додаје преглед на нивоу догађаја

Преглед на нивоу догађаја поставља друга питања: је ли овај кредит урачунат више пута за једну интеракцију, је ли ток изгледао аутоматизовано, је ли сесија била довољно дуга да прочита оно на шта је кликнула, и је ли каснији исход одговарао тврђеном интересу? На то се може одговорити подацима прве стране које већ чувате.

Приметите да ниједно од њих не тражи универзални праг. Прасак активности разлог је за преглед прозора, а не доказ клик фарме, и једна сесија која изгледа чудно није доказ координације. Праг који измислите биће погрешан за неки легитиман ток рада, зато га наведите као окидач за преглед, а не као пресуду.

Где сваки приступ пада

Ставите три сигнала један уз други и слепе тачке постају очигледне.

Табела је цело поређење. Сваки ред је стварни сигнал са стварном слепом тачком, и ниједан од њих није дефиниција преваре.

Мерите детектор, а не само саобраћај

Држите три скупа: догађаје за које знате да су легитимни, догађаје потврђено неважеће и случајеве које нисте могли да решите. Процењујте детектор према сва три. Правило које одбија сваки заједнички излаз изгледа одлучно на скупу потврђено неважећих и тихо штети обичним корисницима, а то је управо компромис који нико не мери.

Бележите лажне позитиве као метрику првог реда, уз недостајуће информације. Ако нерешена корпа настави да расте, детектор не постаје бољи; постаје тиши.

Дајте одлуци власника

Усагласите с платформом за мерење или оглашавање и власником услуге пре него што промените правило. Користите процес пријављивања и исправке који платформа подржава, уместо тестирања живих монетизованих огласа вештачким кликовима, што ствара управо онај неважећи саобраћај који покушавате да спречите.

Ограничите прикупљање на сврху коју можете да оправдате. Жеља да класификујете превару не чини неограничено узимање отисака обавезом, а AdSense-ове смернице о неважећем саобраћају разуман су ослонац за то како платформа уоквирује категорије.

Почните тако што ћете подобан догађај написати у једној реченици. Ако реченица говори о мрежном пореклу, имате proxy метрику, а не дефиницију.