A detección de VPN non é a validación de clics: compare os sinais
Unha etiqueta de rede responde de onde veu o tráfico. A validez do clic ten que ver co evento, a súa elixibilidade e o seu resultado. Velaquí como se comparan os dous sinais.
Na maioría dos debates sobre fraude de clics mestúranse dúas preguntas, e desa mestura veñen as malas decisións. A primeira é de onde chegou unha solicitude, algo que unha clasificación de rede pode responder de forma aproximada. A segunda é se o evento debe contarse, o que depende das regras de elixibilidade, do comportamento e do resultado. Unha etiqueta de VPN é evidencia para a primeira pregunta e, por si soa, non di nada sobre a segunda.
Dúas preguntas que parecen unha
A primeira pregunta é descritiva: chegou esta solicitude a través dun provedor de aloxamento, dunha VPN de privacidade ou dunha conexión residencial? A segunda é normativa: cumpre este evento a definición que acordou o seu negocio? As respostas descritivas son baratas e estatísticas. As respostas normativas esixen unha definición e un responsable.
Confundilas produce un detector seguro e equivocado. Pode clasificar correctamente cada solicitude e aínda así contar eventos non válidos, porque a clasificación nunca preguntou que é un evento elixible.
Que pode soster unha etiqueta de rede
A clase de enderezo é unha afirmación sobre unha poboación, non sobre un individuo. Unha soa IP pode estar diante dun NAT de operador con milleiros de subscritores, dunha saída corporativa de toda unha oficina ou dunha VPN de privacidade con usuarios sen relación. Chamar sospeitoso a ese enderezo atribúe o comportamento de poucos a todos os que están detrás.
As directrices de Google sobre tráfico non válido son un exemplo concreto útil do problema da definición. Cobren tanto a fraude intencionada coma os clics accidentais, o que significa que o modelo da propia plataforma trata o evento e o seu contexto como suxeito, non só a rede de entrega.
Unha cadea de axente de usuario non o salva. Decláraa o propio cliente, cámbiase con trivialidade e non é unha identidade autenticada. Trátea como unha pista que correlaciona cunha familia de dispositivos, nunca como unha declaración de intención.
Que engade unha revisión a nivel de evento
A revisión a nivel de evento fai outras preguntas: contouse este crédito máis dunha vez para unha soa interacción, o fluxo parecía automatizado, a sesión foi o bastante longa como para ter lido o que clicou, e o resultado posterior coincidiu co interese declarado? Todo iso se responde con datos de primeira parte que xa conserva.
Observe que ningunha delas esixe un limiar universal. Unha ráfaga de actividade é motivo para revisar unha xanela, non proba dunha granxa de clics, e unha soa sesión que parece estraña non é evidencia de coordinación. O limiar que invente será incorrecto para algún fluxo de traballo lexítimo, así que exprésao como un disparador de revisión e non como un veredicto.
Onde falla cada enfoque
Pon os tres sinais un xunto a outro e os puntos cegos fanse obvios.
| 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 |
A táboa é toda a comparación. Cada fila é un sinal real cun punto cego real, e ningunha delas é unha definición de fraude.
Mida o detector, non só o tráfico
Manteña tres conxuntos: eventos que sabe lexítimos, eventos confirmados como non válidos e casos que non puido resolver. Avalíe o detector contra os tres. Unha regra que rexeita cada saída compartida parece contundente no conxunto de confirmados non válidos e prexudica en silencio os usuarios correntes, que é xusto o equilibrio que ninguén mide.
Rexistre os falsos positivos como unha métrica de primeira clase, xunto á información faltante. Se o cesto sen resolver segue crecendo, o detector non mellora; vólvese máis silencioso.
Dea un responsable á decisión
Coordine coa plataforma de medición ou publicidade e co responsable do servizo antes de cambiar unha regra. Use o proceso de notificación e corrección que admite a plataforma en lugar de probar anuncios monetizados en vivo con clics artificiais, o que crea xusto o tráfico non válido que intenta evitar.
Limite a recollida á finalidade que pode xustificar. O desexo de clasificar a fraude non converte a toma indefinida de pegadas nun requisito, e as Directrices de AdSense sobre tráfico non válido son unha referencia razoable de como unha plataforma enmarca as categorías.
Comece escribindo o evento elixible nunha frase. Se a frase trata da orixe de rede, ten unha métrica indirecta, non unha definición.