Un plan de marquage est le document de référence qui recense les données qu’un site ou une application doit collecter, et précise pour chacune l’événement déclencheur, ses paramètres et l’outil de destination.
Il traduit des questions d’analyse en spécifications techniques. Il part des objectifs de l’entreprise et des indicateurs clés de performance qui les mesurent. Il décrit ensuite les interactions à observer : vues de page, clics, envois de formulaire, étapes d’un achat. Les développeurs ou l’équipe chargée du gestionnaire de balises s’en servent pour poser les marqueurs. L’analyste s’en sert pour vérifier que la collecte correspond à ce qui était prévu.
Un plan de marquage comprend en général la liste des événements, chacun sous un nom normalisé, et les paramètres associés avec leurs valeurs possibles. Il indique les pages ou écrans concernés, la règle de déclenchement et les variables attendues dans la couche de données. Il désigne l’outil ou le partenaire destinataire de chaque donnée et le statut de chaque marqueur au regard du consentement. Un historique des versions complète l’ensemble.
Le plan de marquage se distingue du marquage analytics, qui désigne l’opération technique de pose des marqueurs, et du tag management, qui organise le déploiement des balises dans un outil dédié. L’expression plan de taggage, calquée sur l’anglais tagging plan, désigne le même document. Le plan est rédigé lors de la mise en place d’un outil de web analyse, d’une refonte de site ou d’un changement d’outil, puis tenu à jour à chaque évolution du site.
Quand deux rapports donnent des chiffres différents, le plan de marquage dit ce que chaque événement est censé mesurer. Sans lui, cette connaissance reste dans la tête du développeur ou du prestataire qui a posé les marqueurs, et elle part avec eux. À notre avis, la valeur du plan tient moins à sa première version qu’à sa mise à jour. Nous estimons qu’un plan non révisé après une refonte est plus dangereux qu’une absence de plan : il donne une fausse assurance.
Nous proposons quatre repères de pilotage, qui ne sont pas des normes :
Nous recommandons un audit de web analytics au moins annuel pour confronter ces repères au site réel.
En assistance à maîtrise d’ouvrage, Advalians analyse vos pratiques, évalue vos dispositifs et vous remet une restitution priorisée avant le lancement ou la refonte.
Advalians, cabinet de conseil indépendant en marketing et communication, vous aide à clarifier vos choix et à décider.
Le plan de marquage est la spécification ; le marquage analytics est sa réalisation technique. Le plan dit quoi collecter, quand et vers quel outil. Le marquage pose les balises et le code qui exécutent ces règles.
La distinction compte au moment de répartir les rôles. L’annonceur, avec son analyste, reste propriétaire du plan. Le développeur ou l’agence réalise le marquage à partir de ce plan. Quand un écart apparaît entre les deux, c’est le plan qui fait foi : corrigez le marquage, ou modifiez d’abord le plan si le besoin a changé.
L’analyste web, en lien avec les équipes métier et les développeurs. Les métiers apportent les décisions à éclairer. L’analyste les traduit en événements et en paramètres. Les développeurs valident la faisabilité et la couche de données.
Désignez un propriétaire unique du document, côté annonceur, même si un prestataire le rédige. Exigez sa livraison dans un format modifiable et versionné. Prévoyez un circuit simple pour les demandes d’évolution : formulaire de demande, validation par le propriétaire, mise à jour du plan, puis seulement mise en production.
Comparez régulièrement la liste des événements du plan avec les événements reçus par l’outil de mesure. Deux écarts sont à suivre : les événements prévus qui n’arrivent pas, et les événements reçus qui ne figurent pas au plan.
Complétez par des tests de parcours après chaque mise en production : un formulaire envoyé, un achat de test, une inscription. Pour chaque test, vérifiez le nom de l’événement, ses paramètres et l’outil destinataire. Rapprochez aussi chaque mois les transactions mesurées des commandes enregistrées : un écart qui se creuse révèle souvent un marquage cassé.
La principale est l’absence de mise à jour : après une refonte ou l’ajout d’un parcours, le plan ne décrit plus le site. Viennent ensuite les noms d’événements incohérents, définis par chaque équipe, et les plans trop détaillés que personne ne relit.
Pour l’éviter, liez la mise à jour du plan à chaque mise en production touchant les pages marquées. Limitez le plan aux événements qui servent une décision identifiée. Datez chaque version et conservez l’historique : il permet d’expliquer une rupture de série des mois plus tard.
Oui, dans une version légère. Dès qu’un site suit au moins une conversion, comme un formulaire de contact ou une vente, un document d’une page évite les erreurs de mesure.
Cette version minimale tient en quelques lignes : les conversions suivies, le nom de chaque événement, sa règle de déclenchement et son statut au regard du consentement. Renoncez au plan détaillé si le site n’a qu’un objectif simple et une seule source de mesure. Passez à un plan complet dès que plusieurs outils, partenaires ou équipes interviennent sur la collecte.
