Comment savoir si Astrina détecte correctement le trafic des bots
Vous n’avez pas besoin d’un audit d’envergure pour répondre à une seule question : comment savoir si Astrina détecte les bots dans cette propriété, sur cette campagne, à cet instant précis, les visites de type bot comme vous l’attendez ? C’est un test bien plus ciblé que d’évaluer la qualité du trafic sur l’ensemble du compte, et cela fait gagner du temps. Commencez par là.
La méthode la plus simple consiste à choisir une propriété, une page d’atterrissage et une courte fenêtre de temps. Dix minutes peuvent suffire. Vous vérifiez la logique de suivi, pas la santé de tout votre mix d’acquisition.
1. Définissez précisément le scénario de vérification des bots
Notez le scénario avant d’ouvrir le tableau de bord. Indiquez la propriété, la campagne, le chemin de la page et le comportement attendu. Si un crawler visite /pricing trois fois en 90 secondes, c’est un cas précis. Si un outil de QA charge la même page avec le même user agent depuis une seule IP, c’en est un autre.
C’est important, car le trafic bot peut désigner des choses différentes selon le contexte. Une campagne newsletter peut attirer des scanners de liens. Une page de documentation publique peut attirer des scrapers. Une landing page publicitaire peut recevoir des bots d’aperçu venant des plateformes d’annonces. Ne mélangez pas ces cas dans un seul jeu de tests. Un test, une cible.
Si vous validez une configuration après un changement, notez précisément lequel. Quelqu’un a-t-il ajouté un filtre ? L’agent a-t-il été installé sur un second sous-domaine ? Une nouvelle règle d’alerte a-t-elle été activée ? Ces détails déterminent s’il s’agit d’un problème produit ou d’un problème de configuration. Pour vérifier la détection des bots dans Astrina, il faut pouvoir relier chaque résultat à un changement précis.
2. Choisissez une petite fenêtre de test avec des signaux bot connus
Choisissez une courte période pendant laquelle vous vous attendez à voir une activité de type bot. Une tranche de 30 minutes fonctionne mieux qu’une semaine entière lorsque vous cherchez à confirmer la classification. Si vous connaissez déjà une source, utilisez-la. Si vous connaissez une page d’atterrissage, partez de celle-ci. Si vous savez qu’une heure est très sollicitée par des crawlers, c’est encore mieux.
Recherchez une base de référence que vous pouvez expliquer en une phrase. Par exemple : « Cette page a été partagée dans un forum très fréquenté par des bots à 14 h », ou « Cette campagne a été touchée par un contrôle de monitoring toutes les 5 minutes ». Plus la base est claire, plus il est facile de voir si Astrina étiquette correctement les visites.
Un geste pratique : comparez la fenêtre de test à une fenêtre calme de même durée. Si les signaux bot n’apparaissent que dans la fenêtre attendue, et qu’Astrina les traite différemment de la fenêtre calme, vous avez un point de départ utile. Si les deux fenêtres se ressemblent, faites une pause. Quelque chose dans la configuration masque peut-être le signal.
3. Reproduisez le schéma de visite que vous voulez tester
Utilisez un schéma reproductible. Ouvrez le même chemin depuis le même profil de navigateur, ou depuis le même hôte de test, ou avec la même chaîne user agent. Faites-le dans le même ordre à chaque fois. Trois visites espacées d’une minute sont plus faciles à relire qu’une rafale confuse de clics aléatoires.
Un schéma simple peut ressembler à ceci : page A, puis page B, puis à nouveau page A. Ou page d’accueil, puis page produit, puis page de paiement sans pause. Certains bots font exactement cela. Certains humains aussi, ce qui explique pourquoi le nombre de répétitions compte. Deux hits sont une preuve faible. Cinq ou plus racontent une histoire plus claire.
Gardez le test ciblé. N’inondez pas la propriété avec des centaines de requêtes, sauf si vous testez le comportement à grande échelle, et c’est alors un autre exercice. Un petit ensemble de visites connues suffit dans la plupart des vérifications. Vous voulez des traces lisibles, pas du bruit. En pratique, cela aide à identifier le trafic bot Astrina sans brouiller les autres signaux.
Si vous avez besoin d’une installation propre, la page de configuration de l’agent est ici : * et la taille de texte visible normalisée. Installez une fois, vérifiez que la propriété reçoit bien des données, puis lancez le test bot. Un test raté ne signifie rien si le tracker n’a jamais été actif.
4. Vérifiez si Astrina enregistre la chaîne d’événements de façon cohérente
Ouvrez la vue individuelle de la visite ou de la session et inspectez la séquence. Les pages vues doivent apparaître dans l’ordre que vous avez généré. Les référents doivent correspondre à la source utilisée. Les horodatages doivent tomber sur les bonnes minutes, sans dériver vers une autre heure. Un test bot doit être ennuyeux à ce stade.
Surveillez les écarts. Un bot peut déclencher des événements de page vue sans démarrage de session correspondant. Une boucle de rechargement peut créer des hits en double avec le même chemin. Un crawler peut arriver sans référent, puis rebondir sur deux pages internes. Ces schémas ne suffisent pas à eux seuls pour prouver quoi que ce soit, mais ils indiquent si Astrina voit la chaîne comme une séquence unique de type bot ou comme du trafic sans lien.
Une vérification utile consiste à regarder l’intervalle entre les hits. Si vous avez déclenché des requêtes toutes les 20 secondes, les écarts enregistrés devraient rester proches de ce rythme. S’ils sont écrasés, étirés ou réordonnés, le problème peut venir de la gestion des horodatages plutôt que de la classification bot.
Ce petit détail compte. Une étiquette bot placée sur la mauvaise visite est une mauvaise étiquette. C’en est une aussi si une bonne étiquette est associée au mauvais chemin. Vérifiez d’abord la chaîne, puis l’étiquette.
5. Comparez les résultats de classification entre filtres et vues
Ne faites pas confiance à une seule tuile du tableau de bord. Vérifiez le même jeu de tests dans la vue principale, dans tout segment enregistré, dans tout export et dans tout filtre au niveau de la propriété sur lequel vous comptez. Le résultat doit rester cohérent. Si une visite est étiquetée comme bot dans un endroit et comme humaine dans un autre, c’est un problème de reporting qu’il faut creuser.
Utilisez au moins deux vues si possible. Une vue peut masquer le trafic filtré. Une autre peut exposer les événements bruts. Cette différence est utile, pas gênante. Elle vous indique si la classification existe au niveau de l’événement, de la session, ou seulement dans un rapport dérivé.
Si vous conservez une cartographie de mesure pour la propriété, recoupez le test bot avec les événements que vous souhaitez mesurer : page view, début de session, référent et tout événement personnalisé lié à la campagne. L’article sur quoi mesurer dans l’analytics web peut aider lorsque vous devez nommer clairement ces champs.
Ne négligez pas les exports. Un CSV peut révéler un décalage que le tableau de bord masque par regroupement. Recherchez le même ID de session, le même chemin de page et le même indicateur bot dans les trois emplacements. Si l’indicateur disparaît dans l’export, c’est un échec concret.
6. Recherchez des faux négatifs et des faux positifs dans le jeu de tests
Auditez maintenant un petit échantillon à la main. Choisissez 5 hits de bot évidents et 5 visites clairement humaines. Vous n’avez pas besoin d’un échantillon énorme. Il vous faut des cas évidents. Si un crawler connu n’a pas été détecté, c’est un faux négatif. Si une visite humaine normale a été signalée, c’est un faux positif.
Utilisez la preuve la plus simple à votre disposition. Un test bot issu d’un service de monitoring, un navigateur synthétique ou une IP QA connue peut fournir la partie bot. Un test depuis le Wi-Fi de votre bureau ou un compte salarié peut fournir la partie humaine. Gardez une distinction nette. Les échantillons mixtes font perdre du temps.
Surveillez les cas limites. Une extension de navigateur peut rendre une visite humaine étrange. Un outil de confidentialité peut supprimer les référents. Un proxy d’entreprise peut regrouper plusieurs personnes derrière une seule IP. Rien de tout cela ne prouve à lui seul qu’Astrina se trompe, mais cela explique pourquoi un hit peut tomber dans la mauvaise catégorie.
Si vous voulez comparer l’étiquette bot à un parcours produit, le session replay peut aider. L’article sur le session replay d’Astrina pour vérifier le checkout montre comment utiliser la relecture dans un parcours plus restreint. C’est utile lorsque le test bot touche des remplissages de formulaires, des actions panier ou des étapes de paiement.
7. Vérifiez les rapports en aval et les exclusions
Une classification correcte n’est que la moitié du travail. Vous devez aussi confirmer que le trafic bot est exclu, routé ou compté comme vos rapports l’attendent. Vérifiez les alertes, les exports et toute intégration qui lit les données d’Astrina. Si le trafic bot doit être exclu d’une métrique, vérifiez cette exclusion à l’endroit où la métrique est consommée, et pas seulement dans Astrina.
Regardez un exemple en aval. Si votre rapport hebdomadaire ne récupère que les sessions non bot, le trafic de test disparaît-il bien de là ? Si votre alerte surveille des pics suspects, le test bot la déclenche-t-il ou reste-t-il sous le seuil ? Si un tableau de bord aval utilise un filtre enregistré, ce filtre fonctionne-t-il encore une fois l’étiquette bot appliquée ? Trois contrôles distincts. Trois points de rupture différents.
C’est aussi le moment de revoir les changements produit ou de stack qui modifient le comportement analytique. Si les règles du navigateur ont changé récemment, l’article sur ce qui a changé dans l’analytics web après peut donner un contexte utile pour une variation de rapport qui n’est pas liée du tout à la détection des bots.
Certaines équipes envoient aussi le trafic traité comme bot vers un processus séparé, surtout lorsqu’une alerte ou un workflow support en dépend. Si votre configuration inclut un chemin retiré ou protégé, confirmez que les règles de routage fonctionnent toujours comme prévu une fois l’étiquette bot appliquée. Une seule exclusion manquante peut inonder un rapport en quelques heures.
8. Documentez le résultat et ce qu’il faut retester ensuite
Notez le test avant de l’oublier. Enregistrez la propriété, la fenêtre de test, la source, le chemin, le nombre de hits et le résultat. Cinq lignes suffisent. Si l’étiquette correspondait aux attentes, dites-le. Si ce n’est pas le cas, précisez exactement où cela a échoué : étiquette manquante, mauvaise session, mauvais export ou exclusion cassée.
Gardez le test suivant très précis. Si le premier contrôle utilisait une seule IP, retestez depuis une deuxième IP. Si le premier contrôle utilisait un seul chemin de page, retestez sur une autre page. Si le premier contrôle n’utilisait que des pages vues, retestez avec un changement de référent ou un schéma de clics répétés. Un seul changement à la fois. C’est ainsi qu’on isole le problème.
Utilisez une courte checklist après chaque changement de configuration, réinstallation de l’agent ou nouvelle version. La page de configuration peut aider si vous devez réinstaller l’agent depuis zéro : * et la taille de texte visible normalisée. Si votre équipe travaille depuis une propriété de préproduction, reproduisez d’abord la même validation là-bas. Les échecs en préproduction coûtent moins cher.
Si vous voulez une vue plus claire de la manière dont une visite suivie doit circuler dans la propriété, relisez l’article de base sur comment configurer les alertes de disponibilité Astrina. La disponibilité n’est pas la détection des bots, mais elle enseigne la même discipline : un événement connu, un résultat connu, un chemin vérifiable.
Ensuite, gardez les notes visibles. Une simple phrase comme « 10 hits répétés depuis une IP ont été étiquetés bot dans le tableau de bord, l’export et le filtre d’alerte mardi à 14 h 20 » vaut mieux qu’une note vague de réussite/échec. Écrivez la date. Écrivez le chemin. Écrivez l’échec exact s’il y en a eu un. Puis retestez exactement ce cas la prochaine fois.
