Trafic de robots et qualité des clics : ce que votre compteur compte vraiment

Tout service de redirection sait vous dire combien de requêtes il a servies. Presque aucun ne sait vous dire combien de ces requêtes étaient des personnes, alors que c’est le chiffre que chaque rapport est tacitement censé contenir. Les liens vivent sur le web ouvert : ils sont indexés, prévisualisés, scannés, supervisés et scrapés, et l’essentiel se produit dans les secondes qui suivent la mise en ligne, avant qu’un seul humain ait vu la publication.

Cet article traite de la couche située entre le compteur brut et un chiffre que vous pouvez défendre en réunion client : quelle automatisation vous voulez laisser passer, pourquoi identifier un robot par son nom n’est pas une identification, ce que prouve un type de réseau, et comment transformer tout cela en règles puis en rapport honnête.

Le compteur brut est un compteur de requêtes

Un moteur de redirection compte ce qui arrive. C’est sa vertu — il fonctionne pour des destinations que vous ne contrôlez pas, il survit aux bloqueurs, et il compte le scan d’un QR code sur une affiche, sans session ni référent, comme l’explique notre guide sur le suivi des clics. C’est aussi pourquoi ce chiffre a besoin d’être qualifié.

Le trafic automatisé qui atteint un lien court se range dans des groupes reconnaissables :

• Les scanners de liens. Les fournisseurs de courrier électronique, les plateformes de messagerie et les passerelles de sécurité récupèrent les liens à la livraison pour vérifier où ils mènent — d’où les clics qu’un lien accumule dans la minute qui suit un envoi, avant même que la livraison soit terminée.
• Les robots d’aperçu. Les réseaux sociaux et les applications de discussion récupèrent le lien pour construire la carte avec le titre et l’image. Un redirecteur bien élevé leur répond par des métadonnées au lieu de les router et de les compter.
• Les robots de recherche et de SEO. Les indexeurs des moteurs de recherche, plus les outils SEO commerciaux qui explorent tout ce qu’ils trouvent.
• Les sondes de supervision. Les contrôles de disponibilité, y compris les vôtres. C’est pour cette raison que les requêtes HEAD sont servies sans compter de clic.
• Les scrapers et les sondeurs. Les collecteurs de prix, les moissonneurs et les scanners en quête de liens qu’ils pourraient faire pointer ailleurs.

Deux de ces groupes sont du trafic que vous avez sollicité, un est une infrastructure neutre, un n’est pas le bienvenu. « Bloquer les robots » les traite tous de la même façon.

Les bons robots, et la seule chose qui les identifie

Un agent utilisateur est une affirmation

L’agent utilisateur est un en-tête écrit par l’émetteur. N’importe quoi peut y placer n’importe quel texte : une requête qui se dit Googlebot ne prouve rien, et un scraper qui se dit Chrome est plus courant qu’un scraper qui avoue ce qu’il est. La correspondance sur l’agent utilisateur garde malgré tout sa place — elle attrape l’automatisation qui s’identifie honnêtement et corrobore les autres signaux — mais dans le classificateur, c’est explicitement un signal faible : il confirme, il ne décide pas.

La vérification porte sur ce que l’émetteur ne contrôle pas

L’adresse depuis laquelle une requête arrive n’est pas choisie par l’émetteur, en tout cas pas d’une manière qui lui serve, et c’est ce qui en fait le bon objet de contrôle. Il y a deux façons de procéder.

Certains opérateurs publient les plages qu’utilisent leurs robots. Google, Bing et Apple le font tous, et ces fichiers sont chargés une fois par jour dans une structure de recherche rapide : une requête venue d’une plage listée est donc confirmée sans le moindre appel réseau au moment de la requête.

Pour les robots sans liste publiée — Yandex, DuckDuckGo, Baidu, Petal — la vérification est un contrôle de nom en deux étapes, et les deux étapes sont obligatoires :

Claim: "Googlebot" in the user agent

Step 1  reverse lookup of the address
        <address>  ->  crawl-<address>.googlebot.com   ends in the crawler's domain
Step 2  forward lookup of that name
        crawl-<address>.googlebot.com  ->  <address>    matches the original address
        verdict: verified crawler

Same claim, different address

Step 1  203.0.113.9  ->  host9.example-hosting.net     not the crawler's domain
        verdict: not verified, the claim is rejected

L’étape directe n’est pas facultative. Celui qui contrôle un bloc d’adresses peut en général donner à son enregistrement inverse la valeur qu’il veut : un nom inverse pris seul peut donc être fabriqué. C’est la résolution de ce nom vers l’adresse de départ qui boucle la boucle.

Le CDN placé devant le redirecteur effectue lui aussi sa propre catégorisation des robots vérifiés, un verdict que l’émetteur ne peut pas falsifier et qui ne coûte rien à lire. La confirmation est donc prise par ordre d’autorité décroissante : liste publiée, vérification du CDN, contrôle de nom inverse puis direct, enfin appartenance à une plage de robot connue dans la base d’adresses.

Pourquoi le contrôle de nom ne tourne jamais pendant qu’un visiteur attend

Une résolution inverse est un appel réseau à la latence imprévisible, et la redirection est le seul endroit où les millisecondes sont visibles par un être humain : elle ne tourne donc jamais de façon synchrone. Si une règle demande si un robot est vérifié et que la réponse n’est pas en cache, la règle le considère comme non vérifié, la résolution part en tâche de fond, et la réponse est en cache pour le clic suivant venu de cette adresse. Se tromper du côté de « non vérifié » coûte une classification correcte ; se tromper du côté d’une résolution synchrone coûte à une personne réelle un délai sur chaque requête.

Le type de réseau est un contexte, pas un verdict

Indépendamment de ce qu’un visiteur prétend être, la plage d’adresses dont il vient a un caractère connu. La base d’adresses commerciale qui alimente tout ceci classe les plages en un petit nombre de types :

| Type | Ce qu’est la plage | Part des plages IPv4 dans la base | | --- | --- | --- | | Non répertoriée | Adresses ordinaires, en majorité grand public et entreprise | 72,1 % | | Centre de données, hébergement, cloud | Serveurs, instances cloud, navigateurs hébergés | 15,3 % | | Proxy public ouvert | Relais ouverts par lesquels n’importe qui peut passer | 9,2 % | | VPN commercial | Services VPN grand public et professionnels | 3,2 % | | Robot de moteur de recherche | Plages connues pour appartenir à des robots | 0,17 % | | Nœud de sortie TOR | Points de sortie du réseau TOR | 0,005 % | | Anonymiseur web | Pages proxy utilisables depuis un navigateur | 0,005 % |

Lisez ce tableau attentivement, car il se prête au contresens. Ce sont des parts de plages d’adresses dans une base de référence, et non des parts du trafic de qui que ce soit. Une seule plage de fournisseur d’accès grand public dessert un nombre énorme de personnes ; une plage d’hébergement peut n’en desservir aucune. Le tableau dit quelles sont les catégories et avec quelle finesse l’espace d’adressage se répartit entre elles, et rien du tout sur ce qu’a reçu votre campagne.

Le point d’interprétation compte plus que les chiffres. Une adresse de centre de données ne veut pas dire robot. Les réseaux d’entreprise routent leurs salariés par des infrastructures cloud, les particuliers soucieux de leur vie privée utilisent des VPN commerciaux pour tout, y compris leurs achats, et les navigateurs hébergés sont une façon ordinaire de lire le web. Supprimez tous les clics de centres de données et vous supprimerez de vrais clients. Le type de réseau déplace la confiance ; pris isolément, c’est un fait de routage, rien de plus.

Le score de qualité et ce à quoi il sert

Le classificateur produit deux sorties : un type de visiteur — humain, robot de recherche, bibliothèque, centre de données, VPN, TOR ou inconnu — et un score de qualité de 1 à 100 accompagné des motifs qui l’expliquent. Les entrées sont celles décrites plus haut, plus des signaux comportementaux : à quelle fréquence la même adresse frappe le même lien en une minute, si la requête porte seulement une préférence de langue, et si l’ensemble des en-têtes correspond à la plateforme que revendique l’agent utilisateur.

Le score n’est délibérément pas un interrupteur. Rien n’est bloqué parce que le score est bas : le score explique un verdict et alimente les rapports, tandis que le blocage se configure explicitement. Le coût d’un faux positif est asymétrique — un robot compté comme humain fausse un pourcentage, tandis qu’un client bloqué comme robot n’atteint jamais la page et ne vous le dira jamais.

Le type, le score et les motifs apparaissent dans les répartitions géographie et qualité du trafic, où le tableau des réseaux est celui que les acheteurs média consultent en premier : numéro de système autonome, nom du fournisseur, type de plage, clics totaux et clics humains en colonnes séparées. L’écart entre ces deux dernières, fournisseur par fournisseur, raconte en général toute l’histoire d’un achat de trafic. L’ensemble est documenté dans l’analyse géographique.

Transformer un verdict en décision

Un verdict n’est utile que si quelque chose peut s’en servir. Les règles de filtrage du trafic attachent à un lien une liste ordonnée de conditions, évaluées sur le edge avant le choix de la destination, la première correspondance décidant de l’issue. Un lien sans aucune règle n’effectue pas le moindre travail supplémentaire.

Les conditions qui nous intéressent ici sont le type de visiteur, le statut de robot vérifié, le type de réseau et un seuil de score de qualité, aux côtés de la géographie, du système autonome, des listes d’adresses, de l’appareil, de la langue, du référent, du motif d’agent utilisateur, des balises de campagne, de l’heure locale et de la distinction première visite ou retour. Les issues : laisser passer, bloquer en 404, bloquer en 410, rediriger ailleurs, afficher une page de substitution à votre marque, ou laisser passer en marquant la visite comme suspecte.

Trois détails de conception décident si tout cela peut tourner sans danger en production.

Les conditions sont trivaluées. Remplie, non remplie, ou sans réponse possible parce que la donnée manque — et « sans réponse » ne compte jamais comme une correspondance. Si la base d’adresses est indisponible, une règle conditionnée au type de réseau ne se déclenche pas et le visiteur atteint la destination normale. Le filtrage échoue en laissant passer, jamais en fermant.

L’inversion ne retourne que les réponses certaines. Une règle écrite « tout le monde sauf l’Allemagne » ne se déclenche pas en douce sur les visiteurs dont le pays n’a pas pu être déterminé. C’est de loin la façon la plus courante dont une règle géographique bien intentionnée se transforme en panne.

Le laisser-passer existe pour que les filtres soient auditables. Une règle qui laisse le trafic passer tout en enregistrant qu’elle a correspondu, c’est ainsi que l’on teste un filtre avant de le laisser bloquer quoi que ce soit : lancez-le en mode laisser-passer, lisez la répartition « Filtré », confirmez qu’il attrape bien ce que vous attendiez, puis changez l’action.

Placez la politique générale dans le jeu de règles de l’espace de travail, puisqu’une politique sur les centres de données ne concerne presque jamais un seul lien, puis servez-vous des règles propres à un lien — évaluées en premier — pour porter les exceptions au-dessus de l’interdiction générale. C’est ainsi que votre sonde de disponibilité continue de fonctionner sur l’unique lien qu’elle surveille. Les plafonds de règles et de listes d’adresses figurent dans la documentation des règles de trafic.

Un détail avant d’écrire une règle sur la première visite : distinguer une première visite d’un retour exige un petit cookie sur votre domaine de redirection, déposé uniquement quand une règle pose réellement la question. Cela a des conséquences en matière de vie privée, et c’est pourquoi le mécanisme lui-même ne s’active que sur demande, jamais par défaut.

Ce qui change dans le rapport client

C’est là que le travail se rembourse, et l’essentiel tient au choix des chiffres qui figurent sur la page.

| Ligne du rapport | Sans couche de qualité | Avec | | --- | --- | --- | | Chiffre principal | Clics | Clics humains, avec le total des clics à côté | | Composition | Absente | Humain, robot vérifié, centre de données, VPN, TOR, inconnu | | Tableau des fournisseurs | Clics par réseau | Clics et clics humains par réseau | | Trafic filtré | Invisible | Volume par règle, avec l’action appliquée par chacune | | Explication d’un pic | « Il s’est passé quelque chose mardi » | Le type et le réseau d’où venait le pic |

Deux habitudes rendent ce rapport honnête plutôt que simplement détaillé. Affichez toujours les deux chiffres : un nombre de clics humains sans total à côté invite à soupçonner que le total gênait. Et rapportez ce que vous avez filtré et pourquoi — l’identifiant de la règle et l’action stockés sur chaque événement correspondant font que la répartition « Filtré » reste lisible même pour des règles que vous avez depuis modifiées ou supprimées.

Pour les agences, le tableau des fournisseurs est aussi un instrument commercial : un réseau qui envoie du volume avec presque aucun clic humain, c’est une conversation à avoir avec un fournisseur, et cette conversation se mène plus facilement avec une répartition par fournisseur qu’avec un agrégat. Nos pages solutions pour agences et solutions pour l’affiliation expliquent comment cela s’intègre au reporting client et aux reversements.

Une chose à dire franchement, ce que les fournisseurs de cette catégorie évitent en général : la classification est probabiliste. Un scraper déterminé qui pilote un vrai navigateur depuis une adresse résidentielle sera classé comme humain, et aucun produit du marché ne vous dira le contraire. Cette couche retire la grande majorité facile et franche de l’automatisation, et vous donne de quoi enquêter sur le reste. Un rapport qui laisse entendre une certitude finira par se tromper devant un client.

Une séquence qui fonctionne

1. Laissez le filtrage des robots actif par défaut dans les statistiques, et considérez comme de l’automatisation tout pic qui commence avant qu’un humain ait pu voir le lien, jusqu’à preuve du contraire.
2. Lisez la répartition par composition avant le chiffre principal. Une part automatisée inhabituelle pour le canal est en soi le résultat de l’analyse.
3. Parcourez le tableau des réseaux à la recherche des fournisseurs dont les clics totaux et les clics humains divergent nettement.
4. Écrivez la première règle en mode laisser-passer, observez la répartition « Filtré » pendant une semaine, et ne la faites passer en action bloquante qu’une fois que le volume qu’elle attrape ressemble à ce que vous visiez.
5. Continuez de laisser passer les robots vérifiés, et exemptez vos propres sondes par une règle au niveau du lien, placée au-dessus de la politique de l’espace de travail.
6. Rapportez ensemble les clics humains et les clics totaux, en affichant le volume filtré plutôt qu’en le soustrayant en silence.

L’idée de fond est simple : un clic est une requête, une requête a une provenance, et la provenance se mesure. Ce qui rend l’exercice payant, c’est l’effet de second ordre. Les taux de conversion calculés sur les clics humains sont stables, les répartitions géographiques débarrassées des plages d’hébergement décrivent des marchés plutôt que des infrastructures, et un client à qui l’on a montré une fois la composition de son trafic cesse de demander si les chiffres sont réels.