Plan de taggage GA4 : méthode et modèle à copier

Un plan de taggage est un tableau qui liste chaque événement à mesurer, son déclencheur, ses paramètres, sa destination et la personne qui le valide. Sans ce document, un setup GA4 dérive : les noms divergent, des balises se doublonnent, et personne ne sait plus quelle action compte comme conversion. Voici la méthode en six étapes que j’applique, le modèle complet pour un site de génération de leads, et les règles de nommage à respecter.

Qu’est-ce qu’un plan de taggage ?

Un plan de taggage, ou plan de marquage, est le document qui décrit chaque point de mesure d’un site. Il fixe, pour chaque événement, son nom, son déclencheur, ses paramètres, ses destinations et son propriétaire. Il sert de contrat entre le site et les outils qui le lisent.

Pourquoi la plupart des setups sans plan dérivent

Le scénario revient souvent. Un prestataire installe GA4 avec les événements par défaut. Un développeur ajoute add_to_cart côté code. Une agence crée addToCart pour une campagne. Puis un thème refait le bouton d’ajout au panier, et la balise cesse de se déclencher sans alerte. Trois mois plus tard, les rapports ne se réconcilient plus avec les commandes.

Le plan ne documente pas le passé. Il décide avant la mise en production : quel événement, avec quels paramètres, validé par qui, à quelle date. Chaque écart devient visible, parce qu’il contredit une ligne du tableau. Si votre setup existe déjà, un paramétrage GA4 complet commence par ce plan, avant toute balise.

Les colonnes du plan

Onze colonnes suffisent pour un site de taille moyenne. Je les garde toutes, même quand une cellule reste vide : un champ vide signale une question sans réponse.

Colonne	Rôle	Exemple
Événement	Nom exact envoyé à GA4	generate_lead
Déclencheur	Action qui lance l’envoi	Succès de la requête serveur du formulaire
Paramètres	Clés transmises avec l’événement	form_id, lead_source
Type	Texte, nombre ou booléen	value en nombre
Valeurs attendues	Liste ou format accepté	currency au format EUR
Source dataLayer	Push ou variable qui fournit la donnée	Push après succès
Destinations	GA4, Google Ads, Meta	GA4 et Google Ads
Conversion	Oui ou non	Oui
Propriétaire	Qui écrit, qui valide	Développeur, puis analyste
Statut	À faire, en recette, en production	En recette
Date de recette	Dernière validation réussie	2026-11-02

La méthode en six étapes

1. Partir des objectifs business. Listez les actions qui rapportent : demande de devis, prise de rendez-vous, téléchargement. Une conversion sans valeur business n’a pas sa place dans le plan.
2. Cartographier les parcours. Pour chaque objectif, notez les étapes : entrée, interaction avec le formulaire, erreur de validation, confirmation.
3. Choisir le nom et le modèle d’événement. Si GA4 propose un événement recommandé qui correspond, je l’utilise. Je n’en crée un nouveau que si aucun ne convient. Le contrat dataLayer décrit comment pousser ces données proprement.
4. Définir paramètres, types et valeurs. Une valeur monétaire doit être un nombre, une devise un code à trois lettres. Notez les valeurs acceptées, pas seulement le nom du champ.
5. Attribuer destinations, propriétaire et statut. Un événement sans propriétaire finit toujours cassé. Le développeur écrit, le responsable marketing valide quelles actions deviennent des conversions.
6. Recetter et dater. Vérifiez chaque événement dans le mode Preview de GTM, puis dans DebugView, et notez la date. Une ligne sans date de recette reste un doute.

Le plan de taggage est le contrat entre marketing, data et développement. Chaque étape produit un livrable ; la recette compare ce qui arrive dans GA4 à ce que le plan promettait.

Le modèle à copier pour un site de génération de leads

Voici le modèle que j’utilise comme base pour un site vitrine avec formulaire, téléphone et téléchargements. Adaptez les noms à vos formulaires, mais gardez la structure.

Événement	Déclencheur	Paramètres	Type	Valeurs attendues	Source	Destinations	Conversion	Propriétaire	Statut	Date recette
page_view	Chargement de page	page_location, page_title	Texte	URL complète	GA4 natif	GA4	Non	Développeur	En production	—
form_start	Premier champ modifié	form_id	Texte	contact, devis	dataLayer	GA4	Non	Développeur	À faire	—
form_error	Erreur de validation affichée	form_id, field_name	Texte	Nom du champ	dataLayer	GA4	Non	Développeur	À faire	—
generate_lead	Succès serveur du formulaire	form_id, lead_source, value, currency	Nombre et texte	value numérique, currency = EUR	dataLayer après succès	GA4, Google Ads, Meta	Oui	Développeur puis analyste	En recette	2026-11-02
lead_qualified	Qualification commerciale du lead	lead_id	Texte	Identifiant CRM	Import CRM	Google Ads	Oui (import)	Commercial	À faire	—
click_phone	Clic sur un lien tel:	link_location	Texte	header, footer, contact	Délégation de clic	GA4	Non	Développeur	À faire	—
click_email	Clic sur un lien mailto:	link_location	Texte	Identique à click_phone	Délégation de clic	GA4	Non	Développeur	À faire	—
cta_click	Clic sur un bouton d’appel à l’action	cta_text, cta_location	Texte	Libellé et zone	dataLayer	GA4	Non	Marketing	À faire	—
file_download	Clic sur un PDF	file_name, file_extension	Texte	pdf	Mesure améliorée	GA4	Non	Analyste	En production	—
video_start	Lecture d’une vidéo	video_title	Texte	Titre de la vidéo	Mesure améliorée	GA4	Non	Marketing	À faire	—
scroll	90 % de la page atteint	percent_scrolled	Nombre	90	Mesure améliorée	GA4	Non	Analyste	En production	—
simulation_complete	Résultat d’un simulateur affiché	simulator_name	Texte	Nom du simulateur	dataLayer	GA4	Non	Développeur	À faire	—
book_meeting	Confirmation d’un rendez-vous	booking_source	Texte	calendly_embed, page_contact	dataLayer	GA4, Meta	Non	Développeur	À faire	—
sign_up	Inscription à la newsletter	method	Texte	newsletter	dataLayer	GA4	Non	Marketing	À faire	—

Si le site vend aussi en ligne, ajoutez les événements e-commerce recommandés par GA4 : view_item_list, view_item, add_to_cart, begin_checkout, add_payment_info et purchase. Chacun porte un tableau items avec au moins un item_id ou un item_name. purchase exige en plus un transaction_id, qui permet de dédupliquer les achats. Le tracking e-commerce avec GA4 reprend la logique du tunnel.

Conventions de nommage GA4

• Noms d’événements et de paramètres en snake_case, en minuscules, sans espace ni accent.
• Limite de 40 caractères pour un nom d’événement ou de paramètre. Au-delà, GA4 ne traite pas l’événement, et une conversion au nom trop long risque de ne pas remonter.
• 25 paramètres maximum par événement, selon la documentation GA4 sur les limites de collecte.
• Pour le web, la documentation ne fixe pas de plafond sur le nombre de noms d’événements distincts. La limite de 500 noms concerne les applications.
• Les événements recommandés passent avant les événements maison. Un nom personnalisé se justifie seulement si aucun événement recommandé ne correspond.
• Aucune donnée personnelle en clair dans un paramètre : pas d’email, pas de téléphone, pas de nom. Le hachage ne se fait que lorsqu’un usage précis l’exige, comme les Enhanced Conversions.

Gouvernance : versionner, revoir, valider

• Tenez le plan dans un tableur versionné ou un dépôt Git. Une version datée à chaque modification, jamais un fichier nommé « final ».
• Revoyez-le à chaque mise en production du site, pas seulement après un incident. Un changement de thème ou de formulaire suffit à casser un événement.
• Désignez qui valide quoi. Le développeur écrit, l’analyste fait la recette, le responsable marketing valide les conversions. Un événement dont personne ne valide la conversion ne doit pas alimenter Google Ads.
• Gardez les noms supprimés dans l’historique. Réutiliser un ancien nom pour un autre sens fausse les séries déjà collectées.

Pour confronter un plan existant au site réel, la méthode d’audit en cinq étapes sert de checklist.

Erreurs fréquentes

• Deux noms pour le même geste. add_to_cart et addToCart coexistent, et les rapports se coupent en deux.
• Conversion au clic. L’événement part quand l’utilisateur clique sur « Envoyer », pas quand le serveur confirme la réception. Les leads fantômes gonflent les chiffres.
• Valeur en texte. Un value envoyé comme "49,90" fausse les totaux sans aucun message d’erreur.
• Pas de colonne source. Quand une donnée casse, impossible de savoir si elle venait du dataLayer ou du DOM.
• Plan figé après refonte. Les lignes restent, les déclencheurs n’existent plus. La FAQ sur le data layer et GTM explique comment éviter ce décalage.

FAQ

Un petit site a-t-il besoin d’un plan de taggage ?

Oui, mais il peut tenir en quelques lignes. Pour un site vitrine avec un formulaire et un numéro de téléphone, une liste courte suffit. Le gain devient net dès qu’un second développeur ou une agence intervient sur le site.

Qui doit écrire le plan : l’agence ou le client ?

L’analyste rédige la structure et les conventions. Le client fournit les objectifs business et valide les conversions. Le développeur renseigne les déclencheurs réels. Un plan écrit sans le développeur reste théorique.

Faut-il un outil spécifique ?

Non. Un tableur ou un document partagé suffit, à condition d’avoir un historique et un propriétaire par ligne. Un outil de gestion de tags peut relier le plan à la configuration GTM, mais il ne remplace pas la validation humaine.

Sources

• Événements recommandés pour Google Analytics 4, Google Analytics
• Limites de collecte des événements GA4, Google Analytics
• Référence des événements GA4, Google for Developers