Il rilevamento VPN non è la validazione dei clic: confrontate i segnali
Un’etichetta di rete risponde da dove è arrivato il traffico. La validità del clic riguarda l’evento, la sua ammissibilità e il suo esito. Ecco come si confrontano i due segnali.
Nella maggior parte delle discussioni sulle frodi sui clic due domande vengono fuse, ed è da questa fusione che nascono le decisioni sbagliate. La prima è da dove è arrivata una richiesta, a cui una classificazione di rete può rispondere in modo approssimativo. La seconda è se l’evento debba contare, il che dipende dalle regole di ammissibilità, dal comportamento e dall’esito. Un’etichetta VPN è una prova per la prima domanda e, da sola, non dice nulla sulla seconda.
Due domande che sembrano una
La prima domanda è descrittiva: questa richiesta è arrivata tramite un provider di hosting, una VPN per la privacy o una connessione residenziale? La seconda è normativa: questo evento soddisfa la definizione concordata dalla vostra attività? Le risposte descrittive sono economiche e statistiche. Le risposte normative richiedono una definizione e un responsabile.
Confonderle produce un rilevatore sicuro di sé e sbagliato. Potete classificare correttamente ogni richiesta e comunque contare eventi non validi, perché la classificazione non ha mai chiesto che cos’è un evento ammissibile.
Che cosa può sostenere un’etichetta di rete
La classe dell’indirizzo è un’affermazione su una popolazione, non su un individuo. Un solo IP può stare davanti a un NAT di operatore con migliaia di abbonati, a un’uscita aziendale per un intero ufficio o a una VPN per la privacy con utenti non correlati. Definire sospetto quell’indirizzo attribuisce il comportamento di pochi a tutti quelli che stanno dietro.
Le linee guida di Google sul traffico non valido sono un esempio concreto utile del problema della definizione. Coprono sia la frode intenzionale sia i clic accidentali, il che significa che il modello della piattaforma stessa tratta l’evento e il suo contesto come soggetto, non solo la rete di consegna.
Una stringa di user agent non risolve la questione. La dichiara il client stesso, si cambia banalmente e non è un’identità autenticata. Trattatela come un indizio correlato a una famiglia di dispositivi, mai come una dichiarazione di intenti.
Che cosa aggiunge una revisione a livello di evento
La revisione a livello di evento pone altre domande: questo credito è stato contato più di una volta per una sola interazione, il flusso sembrava automatizzato, la sessione è durata abbastanza per aver letto ciò che è stato cliccato, e l’esito a valle corrispondeva all’interesse dichiarato? A tutto questo si risponde con dati di prima parte che già conservate.
Notate che nessuna di esse richiede una soglia universale. Un picco di attività è un motivo per rivedere una finestra, non una prova di una fattoria di clic, e una singola sessione che sembra strana non è una prova di coordinamento. La soglia che inventerete sarà sbagliata per qualche flusso di lavoro legittimo, quindi esprimetela come un innesco di revisione e non come un verdetto.
Dove fallisce ogni approccio
Mettete i tre segnali uno accanto all’altro e i punti ciechi diventano evidenti.
| 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 |
La tabella è l’intero confronto. Ogni riga è un segnale reale con un punto cieco reale, e nessuno di essi è una definizione di frode.
Misurate il rilevatore, non solo il traffico
Tenete tre insiemi: eventi che sapete legittimi, eventi confermati non validi e casi che non siete riusciti a risolvere. Valutate il rilevatore su tutti e tre. Una regola che rifiuta ogni uscita condivisa sembra netta sull’insieme dei confermati non validi e danneggia in silenzio gli utenti comuni, ed è esattamente il compromesso che nessuno misura.
Registrate i falsi positivi come metrica di primo livello, accanto alle informazioni mancanti. Se il secchio irrisolto continua a crescere, il rilevatore non migliora; diventa più silenzioso.
Date un responsabile alla decisione
Coordinarvi con la piattaforma di misurazione o pubblicitaria e con il responsabile del servizio prima di cambiare una regola. Usate il processo di segnalazione e correzione supportato dalla piattaforma invece di testare annunci monetizzati live con clic artificiali, che crea proprio il traffico non valido che cercate di prevenire.
Limitate la raccolta allo scopo che potete giustificare. Il desiderio di classificare la frode non rende obbligatoria la raccolta indefinita di impronte, e le Linee guida di AdSense sul traffico non valido sono un riferimento ragionevole per come una piattaforma inquadra le categorie.
Iniziate scrivendo l’evento ammissibile in una frase. Se la frase riguarda l’origine di rete, avete una metrica indiretta, non una definizione.