La détection de VPN n’est pas une validation de clic : comparez les signaux

Dans la plupart des discussions sur la fraude au clic, deux questions se confondent, et c’est de cette confusion que viennent les mauvaises décisions. La première est d’où vient une requête, à quoi une classification réseau peut répondre approximativement. La seconde est de savoir si l’événement doit compter, ce qui dépend des règles d’éligibilité, du comportement et du résultat. Une étiquette VPN est une preuve pour la première question et, à elle seule, ne dit rien de la seconde.

Deux questions qui n’en font qu’une en apparence

La première question est descriptive : cette requête est-elle arrivée via un hébergeur, un VPN de confidentialité ou une connexion résidentielle ? La seconde est normative : cet événement satisfait-il la définition convenue par votre activité ? Les réponses descriptives sont bon marché et statistiques. Les réponses normatives exigent une définition et un responsable.

Les confondre produit un détecteur sûr de lui et faux. Vous pouvez classer correctement chaque requête et compter malgré tout des événements invalides, parce que la classification n’a jamais demandé ce qu’est un événement éligible.

Ce qu’une étiquette réseau peut étayer

La classe d’adresse est une affirmation sur une population, pas sur un individu. Une seule IP peut être devant un NAT d’opérateur avec des milliers d’abonnés, une sortie d’entreprise pour tout un bureau ou un VPN de confidentialité avec des utilisateurs sans lien. Qualifier cette adresse de suspecte attribue le comportement de quelques-uns à tous ceux qui sont derrière.

Les consignes de Google sur le trafic invalide sont un exemple concret utile du problème de définition. Elles couvrent aussi bien la fraude intentionnelle que les clics accidentels, ce qui signifie que le modèle de la plateforme traite l’événement et son contexte comme sujet, pas seulement le réseau d’acheminement.

Une chaîne d’agent utilisateur n’y remédie pas. Elle est déclarée par le client lui-même, se change trivialement et n’est pas une identité authentifiée. Traitez-la comme un indice corrélé à une famille d’appareils, jamais comme une déclaration d’intention.

Ce qu’apporte un examen au niveau de l’événement

L’examen au niveau de l’événement pose d’autres questions : ce crédit a-t-il été compté plus d’une fois pour une seule interaction, le flux semblait-il automatisé, la session a-t-elle duré assez longtemps pour avoir lu ce qui a été cliqué, et le résultat en aval correspondait-il à l’intérêt déclaré ? On peut y répondre avec des données first-party que vous conservez déjà.

Notez qu’aucune d’elles n’exige un seuil universel. Une bouffée d’activité est une raison d’examiner une fenêtre, pas une preuve de ferme à clics, et une session isolée qui paraît étrange n’est pas une preuve de coordination. Le seuil que vous inventerez sera faux pour quelque flux de travail légitime, alors énoncez-le comme un déclencheur d’examen plutôt qu’un verdict.

Où chaque approche échoue

Placez les trois signaux côte à côte et les angles morts deviennent évidents.

Le tableau, c’est toute la comparaison. Chaque ligne est un signal réel avec un angle mort réel, et aucun n’est une définition de la fraude.

Mesurez le détecteur, pas seulement le trafic

Gardez trois ensembles : les événements que vous savez légitimes, les événements confirmés invalides et les cas que vous n’avez pas pu résoudre. Évaluez le détecteur sur les trois. Une règle qui rejette chaque sortie partagée paraît tranchante sur l’ensemble des confirmés invalides et nuit en silence aux utilisateurs ordinaires, et c’est exactement l’arbitrage que personne ne mesure.

Enregistrez les faux positifs comme une métrique de premier ordre, aux côtés de l’information manquante. Si le seau non résolu continue de grossir, le détecteur ne s’améliore pas ; il devient plus silencieux.

Donnez un responsable à la décision

Coordonnez-vous avec la plateforme de mesure ou de publicité et le responsable du service avant de changer une règle. Utilisez le processus de signalement et de correction pris en charge par la plateforme plutôt que de tester des annonces monétisées en direct avec des clics artificiels, ce qui crée précisément le trafic invalide que vous cherchez à éviter.

Limitez la collecte au but que vous pouvez justifier. Le désir de classer la fraude ne fait pas de la prise d’empreinte indéfinie une obligation, et les Consignes d’AdSense sur le trafic invalide sont une référence raisonnable pour la façon dont une plateforme encadre les catégories.

Commencez par écrire l’événement éligible en une phrase. Si la phrase porte sur l’origine réseau, vous avez une métrique indirecte, pas une définition.