La majeure partie de notre trafic de recherche n’a jamais été humaine
Par Oleg Sidorkin, CTO de Cinevva
Notre trafic de recherche organique augmente, et ce depuis le début de l’année. Cette partie est réelle. Mais début juillet, la courbe a bondi d’une manière qui ne correspondait à aucune de nos mises en production, et un bond sans cause apparente mérite qu’on lui consacre un après-midi.
Nous avons enquêté et découvert une flotte de Chrome headless arrivant avec un référent Google.
La forme compte davantage que le pic
Au printemps, la part de faux trafic a oscillé entre un tiers et deux tiers des sessions. C’est à peu près le bruit de fond auquel tout site web public doit s’attendre.
Fin juin, elle s’est mise à grimper et n’a pas cessé. Depuis la première semaine d’avril, les sessions réelles avaient été multipliées par environ 5,5 à la mi-juillet. Les sessions automatisées, par environ 18,6.
Pourquoi c’était difficile à voir
Nous surveillons ces chiffres de près, et tout mouvement inexpliqué déclenche une requête d’analyse. Si celui-ci a demandé une véritable investigation, c’est parce que nos lignes de session ne permettaient réellement pas de distinguer les deux populations.
L’engagement était déduit de l’horodatage last_activity_at de chaque session. Lors d’une visite sur une seule page, ce champ ne change jamais après sa première écriture.
Un bot qui charge une page puis repart produit donc la même ligne qu’une personne qui arrive sur un guide et le lit pendant cinq minutes. Taux de rebond, temps passé sur le site, engagement : tout était calculé à partir d’un champ qui ne contient aucune information pour les sessions d’une seule page. Ce n’est pas inhabituel. C’est le comportement par défaut de la plupart des systèmes d’analytics développés en interne, et c’est la première chose que je vérifierais dans le vôtre.
La solution a consisté à ne plus faire de déductions à partir de la ligne de session, mais à lire la balise de sortie, qui transmet depuis le client le temps réellement passé sur la page et la profondeur de défilement. Dès que nous avons remplacé les déductions par des données concrètes, les deux groupes se sont immédiatement séparés.
| Signalés | Tous les autres | |
|---|---|---|
| Ont fait défiler la page | 1,8 % | 56,5 % |
| Appartiennent à un compte connecté | 0,05 % | 29 % |
Cet écart prouve que le classificateur décrit un phénomène réel, plutôt que de qualifier de robots les visiteurs peu actifs.
Ce qui trahit réellement une flotte
L’agent utilisateur est le pire endroit où chercher, car c’est l’élément le moins coûteux à modifier. Le meilleur signal s’est révélé être la carte graphique.
Les navigateurs headless d’un centre de données n’ont pas de GPU. Ils se rabattent donc sur le rendu logiciel, et WebGL fournit sans hésiter la chaîne identifiant le moteur de rendu. SwiftShader, llvmpipe, Mesa OffScreen. Les vrais visiteurs ont de vrais GPU.
| Signal | Ce qu’il détecte | Part de nos éléments probants |
|---|---|---|
| Moteur de rendu GPU logiciel | Aucune carte graphique physique | 90,5 % |
| ASN de centre de données ou de proxy | Origine réseau louée | 58 % |
navigator.webdriver | Indicateur d’automatisation resté activé | 10,4 % |
L’origine réseau nous a moins aidés qu’on pourrait le penser. Environ quatre sessions sur dix sortent par de véritables FAI grand public. Les proxys résidentiels ne coûtent plus cher, et toute règle supposant que les bots viennent d’AWS en manquera près de la moitié.
Les autres indices venaient d’impossibilités physiques dans les informations déclarées par le client. L’agent utilisateur de Chromium se termine toujours par un jeton Safari correspondant à son jeton AppleWebKit, figé à 537.36 depuis 2013, mais cette flotte produisait des fautes : Safari/537.35 et .38. Un agent utilisateur de téléphone revendiquait un écran de 1600x1200. Une autre variante déclarait un carré parfait de 1600x1600. Une autre encore indiquait 1200x3000, soit un écran d’ordinateur en mode portrait au format 2,5:1 que personne ne fabrique.
Chacune de ces configurations vient de l’émulateur de quelqu’un, et aucune n’apparaît si vous ne la cherchez pas.
La flotte s’est adaptée chaque fois que nous l’avons signalée
Le premier profil utilisait Chrome sous Linux, un référent Google, America/New_York et une résolution de 1920x1080. Nous avons écrit une règle.
Une variante est revenue en 800x600 sur UTC. Nous avons élargi la règle.
Puis une cohorte chinoise est apparue, utilisant des adresses résidentielles de China Mobile et Unicom avec des versions de navigateur figées, dont Chrome 99 de mars 2022 et la configuration d’émulation d’appareil par défaut de Chrome DevTools : un Nexus 5 de 2015 exécutant la version 2018 de WeChat. Ces sessions sortent par des FAI grand public, si bien que toutes nos règles réseau étaient inutiles contre elles.
Puis une variante américaine est apparue sur Cox et Comcast, avec un agent utilisateur Chrome 146 actuel et parfaitement plausible, en 1920x1080. Rien dans cette empreinte n’est incorrect et, prise individuellement, chaque session est impossible à distinguer de celle d’un vrai visiteur.
Notre dernier détecteur n’examine donc pas les sessions individuellement. Il regroupe les 48 heures précédentes par pays, agent utilisateur, taille d’écran et source de trafic, puis recherche des groupes d’au moins 20 sessions anonymes dont 95 % ou plus n’ont jamais lu pendant trois secondes ni fait défiler la page d’un seul pixel.
Les vrais visiteurs ne forment pas des groupes aussi homogènes. Vingt inconnus utilisant un navigateur et une résolution identiques, qui repartent tous sans rien lire, sont une seule machine dotée de vingt adresses. Toute personne du groupe qui a lu ou fait défiler la page reste considérée comme humaine, et les sessions associées à un vrai compte ne sont jamais signalées.
L’audit a aussi révélé l’erreur inverse
En retirant les faux visiteurs de nos chiffres, nous avons découvert de vrais visiteurs que nous avions écartés.
Une fois les temps de lecture réels obtenus, il s’est avéré que 34,2 % de ce que nous avions compté comme des rebonds humains correspondait à des personnes ayant lu pendant au moins 30 secondes ou fait défiler plus de la moitié de la page. Un tiers de ces « échecs » signifiait en réalité que le contenu fonctionnait. Des lecteurs chinois arrivant depuis Bing passaient cinq minutes sur un seul guide et étaient enregistrés comme des rebonds.
Les chiffres étaient faussés simultanément dans les deux sens, et les deux erreurs conduisaient à la même conclusion erronée. Ensemble, elles donnent l’impression que votre trafic est important et superficiel, alors qu’il est en réalité plus faible et plus engagé.
Le canal que nous avons payé était le plus fiable
30 derniers jours. Le trafic organique Google représentait 63,7 % de toutes les sessions pendant cette période.
Tous les réflexes liés à la croissance vont dans l’autre sens. On suppose que le trafic payant est celui où l’on se fait escroquer, et que le trafic organique est celui que l’on a mérité. Chez nous, c’était l’inverse.
Si nous avions réaffecté notre budget en fonction des chiffres de juillet, nous aurions retiré de l’argent au canal qui nous apportait réellement des humains pour produire davantage de contenu destiné à un scraper.
Pourquoi cela mérite un après-midi
Le chiffre lui-même n’est qu’un chiffre. Mais en aval, il détermine les prochaines pages que nous écrivons, les langues dans lesquelles nous investissons, la survie d’une campagne lors de son évaluation et si le trimestre paraît suffisamment bon pour continuer de la même manière. Tout cela peut être influencé par un inconnu disposant d’un parc de proxys bon marché.
Si vous gérez un petit site, examinez les chaînes identifiant vos moteurs de rendu GPU et vos balises de sortie avant de vous fier à votre propre courbe de croissance.
Et considérez nos chiffres comme un plancher plutôt que comme un verdict. Ici, « humain » signifie seulement « pas encore détecté » ; les règles ont été écrites à partir des empreintes que nous avons eu l’occasion d’observer, et nous ignorons toujours qui exploite cette flotte ou ce qu’elle cherche sur un site de création de jeux.
À lire également :
- Le piège des coûts fixes — un autre chiffre derrière lequel il s’est avéré qu’il n’y avait aucun amortisseur
- Pourquoi nous avons créé notre propre moteur WebGPU — le même argument en faveur de la maîtrise de la couche dont vous dépendez
- Guides — le contenu que cet audit était censé mesurer