Installer un suivi web : vérifier tout le parcours

Le script est le début, pas la validation

Une installation analytique fonctionne lorsque les actions prévues produisent les enregistrements prévus, que les données indésirables restent exclues et que les rapports correspondent au parcours de test. Une balise script ou un indicateur vert de connexion prouve bien moins. Cela n’établit ni un comptage unique des navigations, ni le respect du consentement, ni la réalité des conversions payantes.

Commencez dans un projet de préproduction avec une activité fictive. Conservez un bref procès-verbal de validation : version du site, configuration du suivi, navigateur, heure, événements attendus et résultats observés. Cela permet de refaire le test et évite qu’une régression ultérieure soit écartée par « cela fonctionnait à l’installation ».

Définissez le contrat avant les outils de développement

Listez les quelques événements nécessaires et leur déclencheur exact. « Inscription » peut signifier clic sur un bouton, envoi d’un formulaire ou création de compte réussie. Choisissez une définition et nommez autrement les autres actions. Définissez quelles routes comptent comme pages vues et quelles valeurs sont autorisées dans les propriétés.

Rédigez votre politique de consentement et de stockage séparément de la liste des événements. Le test ci-dessous suppose une collecte conditionnée au consentement, sans événement analytique avant autorisation. D’autres produits peuvent avoir un comportement documenté différent. Testez votre politique approuvée et les exigences applicables ; « sans cookies » ne signifie pas sans obligations de confidentialité.

pageview : une route publique autorisée devient visible.
signup-completed : l’application confirme la création du compte.
checkout-started : une session de paiement valide est créée.
payment-succeeded : le système de paiement de confiance confirme le succès, pas le navigateur.

Inspectez les requêtes réelles du navigateur

Ouvrez le panneau Réseau avant le parcours, videz l’ancien trafic et filtrez sur le point de collecte. Les outils Chrome documentent l’inspection des requêtes, charges utiles et réponses. Une réponse HTTP réussie est une preuve utile, mais vérifiez aussi l’enregistrement correspondant dans le bon projet.

Contrôlez hôte destinataire, identifiant de projet, nom d’événement, sources catégorielles autorisées et horodatage. Recherchez les adresses e-mail, textes recherchés, jetons ou URL propres aux clients transmis par erreur. Un événement techniquement valide peut tout de même collecter des informations non prévues par le plan.

Si la requête manque, progressez du navigateur vers le serveur : chargement du script, erreurs JavaScript, restrictions de politique, requête réseau, validation serveur, enregistrement. Ne réinstallez pas le script à répétition avant d’avoir localisé la couche défaillante.

Exécutez une matrice de parcours explicite

Ceci est un exemple fictif de validation, pas une affirmation sur un suivi déployé. Utilisez un nouvel identifiant de test à chaque essai et conservez des preuves expurgées. Les comptes ci-dessous correspondent à la politique de consentement choisie, pas au comportement de tous les prestataires.

MATRICE DE TEST FICTIVE
Action                           Collecte navigateur attendue
Charger / avec refus              0 événement
Autoriser sur /                   1 vue initiale autorisée
Naviguer vers /pricing            1 nouvelle page vue
Recharger /pricing                1 vue pour ce chargement
Changer seulement un filtre URL   0 si la politique ignore ce changement
Retirer le consentement           Aucune collecte ultérieure
Terminer un paiement test         Vérification financière séparée, serveur

Testez les applications monopages sans double comptage

Une application monopage peut changer d’écran sans recharger le document. Un suivi limité au premier chargement peut donc manquer des navigations. À l’inverse, un suivi automatique de l’historique ajouté à un événement manuel du routeur peut compter deux fois le même écran. Le guide SPA de Google avertit précisément contre ce chevauchement dans sa mise en œuvre.

Choisissez un seul responsable de l’émission des pages vues et testez chargement initial, navigation côté client, retour, avance et actualisation. Si le routeur utilise des fragments d’URL, testez-les explicitement. Si une requête ne fait que trier un tableau, décidez si elle représente un nouvel écran analytique ; ne laissez pas un détail technique accidentel définir la métrique.

Vérifiez que l’instrumentation ne casse pas la navigation. Boutons, historique, état des formulaires et erreurs doivent fonctionner normalement avec le suivi activé, désactivé ou bloqué. L’analytique doit observer le produit, pas devenir une condition d’utilisation.

Testez changements de permission et échecs

Dans une même session, testez refus, acceptation et retrait du consentement. Inspectez stockage et réseau à chaque transition. Le retrait ne peut pas rappeler un événement déjà reçu ; distinguez donc arrêt de la collecte future et suppression de l’historique.

Bloquez ensuite la requête analytique et répétez l’action principale. L’utilisateur doit pouvoir s’inscrire ou poursuivre son paiement même si l’analytique est indisponible. Testez aussi une connexion lente : une dépendance temporelle invisible sur une machine de développement rapide peut apparaître sur téléphone.

Vérifiez le traitement annoncé des signaux de confidentialité du navigateur et restrictions de stockage. Consignez honnêtement une limite non prise en charge ou non mesurable. Il vaut mieux des données manquantes que contourner le choix du visiteur pour compléter un graphique.

Vérifiez le paiement, puis son association

Créez un paiement de test chez le prestataire et inspectez son état faisant autorité. Confirmez la présence d’un seul paiement de référence dans le projet analytique avec devise et montant corrects. Rejouez la notification et vérifiez l’absence de double encaissement. Un remboursement partiel doit suivre la règle documentée.

Examinez l’association avec la visite autorisée seulement une fois la chaîne financière validée. Recommencez sans visite admissible : Non attribué peut être le bon résultat. Tester uniquement le parcours idéal encourage à dissimuler l’incertitude qu’un système devrait justement rendre visible.

Conservez un contrôle reproductible à chaque livraison

Gardez cette matrice dans la documentation et rejouez-la après toute modification du routage, du consentement, du paiement, des domaines ou du suivi. Conservez des preuves expurgées, pas les charges utiles de clients réels. Notez date et configuration effectives plutôt qu’un badge « vérifié » permanent.

La réussite établit le comportement testé dans les conditions décrites. Elle ne garantit ni une couverture complète, ni une conformité juridique générale, ni les futurs déploiements. Cette conclusion précise est utile : vous savez ce qui fonctionne, ce qui échoue et ce que doit viser la prochaine correction.

Références

Exemple à visée pédagogique. Les données et calculs d’exemple ne représentent pas des résultats commerciaux vérifiés.