VPN-identifiering är inte klickvalidering: jämför signalerna

I de flesta diskussioner om klickbedrägeri slås två frågor ihop, och det är just den sammanslagningen som skapar de dåliga besluten. Den första är var en begäran kom ifrån, vilket en nätverksklassificering kan svara på ungefärligt. Den andra är om händelsen ska räknas, vilket beror på behörighetsregler, beteende och utfall. En VPN-etikett är bevis för den första frågan och säger i sig ingenting om den andra.

Två frågor som ser ut som en

Den första frågan är beskrivande: kom den här begäran via en hostingleverantör, en integritets-VPN eller en bostadsanslutning? Den andra är normativ: uppfyller den här händelsen den definition som din verksamhet kom överens om? Beskrivande svar är billiga och statistiska. Normativa svar kräver en definition och en ägare.

Att blanda dem ger en detektor som är självsäker och fel. Du kan klassificera varje begäran korrekt och ändå räkna ogiltiga händelser, eftersom klassificeringen aldrig frågade vad en behörig händelse är.

Vad en nätverksetikett kan stödja

Adressklass är ett påstående om en population, inte om en individ. En enda IP kan stå framför en carrier-grade NAT med tusentals abonnenter, en företagsutgång för ett helt kontor eller en integritets-VPN med orelaterade användare. Att kalla den adressen misstänkt tillskriver fåtalets beteende alla bakom den.

Googles vägledning om ogiltig trafik är ett användbart konkret exempel på definitionsproblemet. Den täcker både avsiktligt bedrägeri och oavsiktliga klick, vilket innebär att plattformens egen modell behandlar händelsen och dess sammanhang som subjekt, inte bara leveransnätverket.

En user agent-sträng räddar inte detta. Den rapporteras av klienten själv, kan lätt ändras och är inte en autentiserad identitet. Behandla den som en ledtråd som korrelerar med en enhetsfamilj, aldrig som ett uttalande om avsikt.

Vad en granskning på händelsenivå tillför

Granskning på händelsenivå ställer andra frågor: räknades den här krediten mer än en gång för en enda interaktion, såg flödet automatiserat ut, var sessionen tillräckligt lång för att ha läst det som klickades, och matchade det efterföljande utfallet det påstådda intresset? Allt detta kan besvaras med förstapartsdata som du redan sparar.

Lägg märke till att ingen av dem kräver en universell tröskel. En aktivitetsvåg är ett skäl att granska ett fönster, inte ett bevis på en klickfarm, och en enda märklig session är inte bevis på samordning. Tröskeln du hittar på kommer att vara fel för något legitimt arbetsflöde, så ange den som en granskningsutlösare och inte som en dom.

Var varje metod brister

Ställ de tre signalerna sida vid sida och de blinda fläckarna blir tydliga.

Tabellen är hela jämförelsen. Varje rad är en verklig signal med en verklig blind fläck, och ingen av dem är en definition av bedrägeri.

Mät detektorn, inte bara trafiken

Håll tre mängder: händelser du vet är legitima, händelser bekräftat ogiltiga och fall du inte kunde lösa. Utvärdera detektorn mot alla tre. En regel som avvisar varje delad utgång ser bestämd ut på mängden bekräftat ogiltiga och skadar tyst vanliga användare, och det är precis den avvägning ingen mäter.

Registrera falska positiva som ett förstklassigt mått, tillsammans med saknad information. Om den olösta hinken fortsätter att växa blir detektorn inte bättre; den blir tystare.

Ge beslutet en ägare

Samordna med mät- eller annonsplattformen och tjänstens ägare innan du ändrar en regel. Använd plattformens stödda rapporterings- och korrigeringsprocess i stället för att testa live-monetiserade annonser med konstgjorda klick, vilket skapar just den ogiltiga trafik du försöker förhindra.

Begränsa insamlingen till det syfte du kan motivera. Önskan att klassificera bedrägeri gör inte obegränsat fingeravtryck till ett krav, och AdSense vägledning om ogiltig trafik är en rimlig referens för hur en plattform ramar in kategorierna.

Börja med att skriva den behöriga händelsen i en mening. Om meningen handlar om nätverksursprung har du ett proxymått, inte en definition.