Décrivez une action métier, son déclencheur exact, ses paramètres et son test. Le plan de marquage doit rester lisible après une refonte ou un changement d’équipe.
| Champ du plan | Exemple fictif | Vérification |
|---|---|---|
| Question | Combien de demandes sont acceptées ? | Comparaison avec un jeu de demandes test |
| Événement | demo_request_success | Uniquement après succès confirmé |
| Paramètre | offer_category | Valeur issue d’une liste définie |
| Données exclues | E-mail et commentaire libre | Absence dans les événements collectés |
| Cas difficile | Double clic ou erreur serveur | Pas de faux succès ni de doublon |
À quoi sert un plan de marquage ?
Le plan de marquage est le document qui relie les questions de l’entreprise aux événements à mesurer sur le site ou l’application. Il précise ce qui doit se produire pour qu’un événement soit émis, quelles informations l’accompagnent et quels outils peuvent le recevoir. Il sert de référence commune au métier, au développement et à l’analyse.
Commencez par quelques questions utiles : combien de demandes sont réellement reçues, quelles offres sont concernées et où surviennent les erreurs ? Une liste de tous les clics possibles ne répond pas nécessairement à ces questions. Le choix doit rester compatible avec les données que l’entreprise peut collecter et exploiter.
Décrire chaque événement sans ambiguïté
Pour une demande de devis, distinguez le clic sur le bouton, la tentative d’envoi et la confirmation serveur. L’événement retenu comme résultat doit correspondre au comportement attendu. Donnez-lui un nom stable, une définition et un responsable de validation.
Le document peut contenir le parcours, le déclencheur, les paramètres, le type de valeur, la destination, les conditions de consentement et le test attendu. Les paramètres doivent avoir un sens partagé. Une référence d’offre contrôlée est généralement plus facile à maintenir qu’un texte libre différent selon chaque écran.
Un exemple pour une demande de démonstration
Exemple fictif : après un envoi accepté par le service qui reçoit les demandes, le site émet demo_request_success avec une catégorie d’offre. Le message ne contient ni le nom, ni l’adresse e-mail, ni le commentaire saisi. Un identifiant technique peut être prévu si son usage et son traitement sont nécessaires et encadrés.
La recette vérifie une soumission réussie, une erreur de validation et un double clic. Le résultat attendu est un seul événement de succès pour une demande acceptée. Un simple affichage du formulaire ne doit pas produire la même mesure. Les conventions exactes dépendent toutefois des outils retenus et de leurs événements recommandés.
Organiser la couche de données et les balises
La couche de données, souvent appelée data layer, transmet des informations structurées aux outils de balisage. Elle permet de séparer une action métier d’un détail visuel fragile. Une mesure fondée uniquement sur la position ou la classe d’un bouton peut cesser de fonctionner après une refonte.
Google Tag Manager peut lire ces informations selon sa configuration. Le tracking server side peut ensuite modifier le trajet de certains événements. Ces choix techniques doivent rester alignés avec le même document fonctionnel, sans multiplier des définitions contradictoires.
Prévoir une recette et une maintenance
Testez les parcours sur téléphone et ordinateur, les acceptations et refus de traceurs, les erreurs et les changements de page. Comparez les événements attendus à ceux reçus dans les destinations. Notez les écarts, la date du contrôle et la version testée.
Conservez un historique lorsque le site ou la définition d’une conversion change. Un événement supprimé doit être retiré des rapports qui le supposent encore présent. L’implémentation du tracking et les tableaux de bord gagnent ainsi une référence vérifiable plutôt qu’une simple liste de balises installées.