Liste de vérification d’implémentation analytique

Une liste de vérification d’implémentation analytique est un contrôle pré-lancement du plan de mesure, de la conception des événements, du consentement, du QA et de la responsabilité. Elle évite de déployer des balises avant que les questions d’affaires, les définitions de données et les responsabilités de reporting soient claires. Les mécanismes côté outil — limites, formats de nommage, débogage — se trouvent dans les notes GA4 et GTM complémentaires ; cette liste porte sur quoi décider, quoi vérifier et qui valide.

Avant le déploiement de toute balise

• Rédiger un plan de mesure qui relie les questions d’affaires à des événements, paramètres et indicateurs précis. Partez de la question que quelqu’un posera réellement, puis remontez vers ce qu’il faut collecter. Tout ce qui ne se rattache pas à une question est une donnée que vous entretiendrez sans jamais l’utiliser.

  Comment vérifier : Choisissez cinq événements du plan et remontez chacun jusqu’à une question d’affaires et au rapport qui y répond.

  Réussi quand : Chaque événement prévu nomme la question qu’il sert, ses paramètres et l’indicateur qu’il alimente, et aucun événement du plan n’est orphelin.

• S’entendre sur les conversions principales et leur définition. Consignez la définition, y compris les cas limites : un remboursement l’annule-t-il, une soumission répétée compte-t-elle deux fois, un utilisateur interne compte-t-il. La plupart des litiges de reporting sont des litiges de définition déguisés en problèmes techniques.

  Comment vérifier : Demandez aux parties prenantes de trancher par écrit les cas limites : remboursements, soumissions répétées, utilisateurs internes.

  Réussi quand : Chaque conversion principale a une courte définition écrite couvrant ces cas, approuvée par son responsable d’affaires.

• Documenter une convention de nomenclature des événements et paramètres. Fixez une fois la casse, le séparateur et la forme verbale, consignez la convention là où les implémenteurs la trouveront, et nommez qui approuve tout nouveau nom d’événement avant sa mise en production. Les mécanismes de format — sensibilité à la casse, limites de caractères, table de convention — sont dans les notes GA4 et GTM.

  Comment vérifier : Cherchez la convention là où travaillent réellement les intégrateurs : les notes du conteneur ou le dépôt de code.

  Réussi quand : Elle fixe la casse, le séparateur et la forme verbale, et nomme la personne qui approuve les nouveaux noms d’événements.

• Confirmer qui est responsable de l’implémentation après le lancement. Nommez une personne, pas une équipe. Une implémentation sans responsable se dégrade dès la première mise en production, faute de quelqu’un chargé de vérifier si un déploiement a cassé le suivi.

  Comment vérifier : Demandez qui est prévenu quand une mise en production casse le suivi.

  Réussi quand : Une personne nommée, avec un suppléant, a accepté le rôle par écrit.

Conception du suivi

• Définir la structure de la couche de données et les valeurs exposées par chaque page. La couche de données est le contrat entre le site et les balises : traitez-la comme tel — écrite, versionnée et relue par le développeur responsable des gabarits avant chaque mise en production. Le modèle de push, annoté, se trouve dans les notes GA4 et GTM.

  Comment vérifier : Inspectez window.dataLayer sur une page par gabarit et comparez-le à la spécification.

  Réussi quand : Chaque clé de la spécification est présente avec le type documenté, et la spécification porte un numéro de version.

• Normaliser les noms d’événements entre le web et l’application lorsque les deux existent. Des noms divergents transforment le reporting multiplateforme en réconciliation manuelle permanente. Fixez le vocabulaire commun avant la mise en production, car renommer après coup ne corrige pas l’historique.

  Comment vérifier : Exportez les noms d’événements des flux Web et application et comparez les listes.

  Réussi quand : Les actions communes portent des noms d’événements et de paramètres identiques sur les deux plateformes.

• Décider de la collecte côté client ou côté serveur pour chaque événement. La collecte côté serveur résiste aux bloqueurs et aux restrictions des navigateurs et garde les identifiants hors du client, au prix d’une infrastructure et de la perte d’une partie du contexte client. Choisissez événement par événement plutôt qu’un modèle unique.

  Comment vérifier : Lisez la colonne de collecte du plan de mesure.

  Réussi quand : Chaque événement indique côté client ou côté serveur, avec la raison.

• Faire correspondre les événements de commerce ou de prospects au schéma de la plateforme. Décidez dans le plan de mesure quels événements doivent utiliser les noms et structures réservés, et consignez cette décision là où les implémenteurs la verront — un nom personnalisé là où un nom réservé existe oblige à reconstruire chaque rapport à la main.

  Comment vérifier : Comparez les événements de commerce ou de prospects implémentés à la référence des événements recommandés de la plateforme.

  Réussi quand : Chaque événement qui a un nom réservé l’utilise, avec les paramètres exigés par la référence.

Consentement et confidentialité

• Intégrer une plateforme de gestion du consentement avant de déployer les balises. Ajouter le consentement après coup sur des balises actives crée une période de collecte que vous ne pourrez peut-être pas justifier. La CMP est un prérequis, pas une phase ultérieure. Le même enregistrement de consentement doit être lisible par canal par chaque programme automatisé en aval ; le modèle de planification d’automatisation marketing consigne quel système le détient et lesquels ne font que le lire.

  Comment vérifier : Dans un navigateur vierge, chargez le site sans faire de choix de consentement et surveillez l’onglet réseau.

  Réussi quand : La plateforme de consentement se charge en premier, et aucune balise ne se déclenche au-delà de ce que permet l’état de consentement par défaut.

• Vérifier que les balises respectent l’état du consentement et les règles régionales. Faites du chemin refusé et de chaque défaut régional un point explicite du plan de QA, avec un vérificateur nommé, plutôt qu’une supposition. Le test du changement d’avis en cours de session y a sa place aussi ; la procédure pour le mener est dans les notes GA4 et GTM.

  Comment vérifier : Lancez les tests refusé, accordé et changement en cours de session selon chaque réglage régional par défaut.

  Réussi quand : Chaque test a un vérificateur nommé et un résultat consigné, et les balises suivent l’état de consentement dans tous les cas.

• Confirmer le traitement des données personnelles et les politiques d’IP/identifiants. Les adresses courriel et les noms fuient le plus souvent dans l’analytique par les paramètres d’URL lors des soumissions de formulaire : vérifiez-les en priorité. Les politiques de Google interdisent tout envoi de renseignements personnels à GA4. Les nouvelles propriétés masquent par défaut les chaînes qui ressemblent à des adresses courriel dans les flux Web, mais au mieux de leurs capacités seulement, et les paramètres d’URL ne sont masqués que si vous les listez : retirez les renseignements personnels avant l’envoi plutôt que de compter sur l’un ou l’autre.

  Comment vérifier : Soumettez chaque formulaire avec des coordonnées de test, puis cherchez « @ » et ces coordonnées dans les URL de page et les valeurs de paramètres collectées.

  Réussi quand : Aucune adresse courriel, aucun nom ni numéro de téléphone n’apparaît dans les valeurs collectées.

Contrôle qualité

• Tester les événements en mode aperçu et débogage avant publication. L’aperçu détecte tôt les erreurs de configuration, mais ne suffit pas : il contourne le consentement et la politique de sécurité du contenu, donc une balise fonctionnelle en aperçu peut échouer en production.

  Comment vérifier : Déclenchez chaque événement dans l’aperçu de Tag Manager, puis confirmez-le dans DebugView de GA4.

  Réussi quand : Chaque événement prévu arrive une seule fois dans DebugView, avec ses paramètres.

• Valider les valeurs des paramètres, pas seulement le déclenchement. Une coche verte indique que l’événement s’est déclenché, pas qu’il portait les bonnes valeurs — intégrez la vérification des valeurs aux preuves de validation consignées plutôt que d’en faire un contrôle ponctuel. Les valeurs fautives à traquer sont listées dans les notes GA4 et GTM.

  Comment vérifier : Inspectez chaque valeur de paramètre dans DebugView ou dans la requête réseau sortante.

  Réussi quand : Les valeurs respectent le type et le format documentés : aucune chaîne vide, aucun « undefined », aucun nombre envoyé comme texte.

• Vérifier le comportement multi-navigateurs et mobile. Les restrictions de stockage de Safari raccourcissent nettement la durée de vie des cookies, ce qui gonfle les visiteurs connus en nouveaux visiteurs. Testez sur un vrai Safari iOS, pas sur une émulation de bureau. Quelles protections de Safari touchent quelles balises, et comment les vérifier dans le Web Inspector : ce que Safari 27 fait aux balises marketing.

  Comment vérifier : Refaites les parcours clés sur un vrai iPhone dans Safari, sur Android dans Chrome et dans un navigateur de bureau.

  Réussi quand : Les mêmes événements se déclenchent avec les mêmes valeurs dans chacun.

• Confirmer que les conversions concordent avec le système source. Les conversions analytiques resteront sous le système source à cause des bloqueurs et du consentement ; l’enjeu est de connaître la taille de l’écart et sa stabilité. Un écart qui change brusquement est l’alerte à construire.

  Comment vérifier : Comparez une journée complète de conversions dans l’analytique au système source, et recommencez une semaine plus tard.

  Réussi quand : L’analytique est inférieure d’un écart stable, et cet écart est consigné comme référence pour les alertes.

• Consigner qui a validé, et sur quelles preuves, avant la publication du conteneur. Joignez les captures de débogage et le numéro de version du conteneur au ticket de mise en production. Quand le suivi cassera plus tard, la première question sera ce qui a été vérifié la dernière fois — faites en sorte qu’elle ait une réponse.

  Comment vérifier : Ouvrez le billet de mise en production de la version du conteneur publiée.

  Réussi quand : Il contient le numéro de version, les preuves de débogage, ainsi que le nom et la date de la validation.

Après le lancement

• Documenter le conteneur, les événements et la responsabilité. Notez à quoi sert chaque balise et qui l’a demandée. Les conteneurs non documentés accumulent des balises que personne ne supprimera, faute de pouvoir prouver qu’elles sont inutilisées.

  Comment vérifier : Choisissez trois balises au hasard et demandez à quoi sert chacune.

  Réussi quand : Pour chaque balise, l’objectif, le demandeur et le responsable sont écrits.

• Établir une cadence de révision pour les nouveaux événements et les retraits. Sans cela, le nombre d’événements croît et les emplacements de dimensions personnalisées s’épuisent — les plafonds exacts sont tabulés dans les notes GA4 et GTM, et libérer un emplacement ne répare pas rétroactivement les données déjà collectées.

  Comment vérifier : Cherchez la prochaine revue au calendrier, et le résultat de la dernière.

  Réussi quand : Une revue récurrente a un responsable, et la dernière a produit la liste des événements conservés, modifiés et retirés.

• Surveiller la perte de données après des changements de site ou de consentement. Alertez sur les anomalies de volume par événement clé plutôt que de vérifier manuellement. Le suivi casse généralement lors d’une mise en production sans rapport, et l’écart se découvre des semaines plus tard.

  Comment vérifier : Ouvrez la configuration des alertes sur les événements clés.

  Réussi quand : Une baisse du volume quotidien d’un événement clé au-delà du seuil convenu avertit automatiquement une personne nommée.

• Savoir ce que compte le canal AI Assistant de GA4 avant de le rapporter. Le groupe de canaux par défaut classe dans AI Assistant les visites référées par une liste d’assistants tenue par Google, mais les AI Overviews et le mode IA de Google restent dans Organic Search, et un assistant qui n’envoie pas de référent arrive en Direct. Une diapositive intitulée « trafic IA » bâtie sur ce seul canal sous-estime ce qu’elle nomme.

  Comment vérifier : Dans GA4, ouvrez les définitions des groupes de canaux et lisez la règle AI Assistant, puis listez une semaine de sources de session qui ressemblent à des produits d’IA.

  Réussi quand : Chaque source IA trouvée est soit dans le canal, soit documentée comme hors du canal, et tout rapport intitulé « trafic IA » précise que les surfaces IA de Google sont comptées dans Organic Search.

• Consigner quel système répond à quelle question avant de construire un tableau de bord de recherche IA.

  Comment vérifier : Lisez les définitions jointes au tableau de bord de la recherche IA.

  Réussi quand : Chaque chiffre nomme son système source et ce que ce système ne voit pas.