Plan de marquage GA4 : la méthode pas à pas et un modèle prêt à l’emploi

Un plan de marquage (on dit aussi plan de taggage, ou tracking plan) est le tableau qui décrit tout ce que votre site envoie à Google Analytics 4 : quel événement, à quel moment, avec quels paramètres, et lequel compte comme un résultat. Sans lui, la mesure se construit au fil des demandes : des événements en double, des noms qui changent d’un développeur à l’autre, et des rapports que personne n’ose utiliser pour décider.

La méthode tient en six étapes : partir des questions, choisir les événements, les nommer, définir les paramètres, désigner les événements clés, puis tout vérifier avant la mise en ligne. Vous trouverez plus bas un modèle de tableau à reprendre, et deux exemples concrets : le plan de ce site et celui de Reviu, ma boutique en ligne.

Étape 1 : partir des questions, pas des clics

La tentation est de tout mesurer « au cas où ». C’est l’inverse qu’il faut faire : écrivez d’abord les trois à cinq questions auxquelles la mesure doit répondre, puis cherchez l’action qui y répond. Chaque ligne du plan doit pouvoir se relier à une question.

• Quels canaux amènent des demandes de contact ? Un événement sur l’envoi de la demande, marqué comme événement clé.
• À quelle étape les acheteurs abandonnent-ils ? Les événements e-commerce de l’entonnoir : fiche produit, panier, paiement, achat.
• Notre fiche technique est-elle lue ? Un événement sur son téléchargement, avec le nom du fichier.
• La version anglaise sert-elle à quelque chose ? Un événement sur le changement de langue.

Une question sans décision possible derrière (« combien de personnes survolent le menu ? ») n’a pas sa place dans le plan. Moins d’événements, c’est aussi moins de code à maintenir et moins de recette à refaire à chaque évolution du site.

Étape 2 : choisir les événements, du plus standard au plus spécifique

Google distingue quatre familles d’événements : ceux collectés automatiquement (page_view, session_start…), ceux de la mesure améliorée (activés dans l’interface), les événements recommandés (noms et paramètres définis par Google, que vous implémentez) et les événements personnalisés. Google conseille de ne créer un événement personnalisé que lorsqu’aucun autre ne convient, et précise qu’un événement personnalisé n’apparaît pas dans la plupart des rapports standards.

L’ordre de choix est donc simple :

1. Ce qui est déjà collecté : vérifiez ce que la mesure améliorée envoie déjà avant d’écrire une ligne de code.
2. Un événement recommandé s’il existe : generate_lead pour une demande envoyée, sign_up, login, search, et pour la vente en ligne view_item, add_to_cart, begin_checkout, purchase. Leurs paramètres sont décrits dans la référence pour les développeurs.
3. Un événement personnalisé seulement pour ce qui vous est propre.

Attention aux recouvrements avec la mesure améliorée : elle envoie déjà file_download au clic sur un PDF (et sur d’autres extensions courantes), click pour les liens sortants, form_start et form_submit pour les formulaires. Si vous créez votre propre événement pour la même action, notez-le dans le plan et décidez lequel fait foi : sinon, vous aurez deux chiffres pour une seule action.

Étape 3 : une convention de nommage qui tient dans le temps

GA4 impose quelques règles de dénomination : un nom d’événement commence par une lettre, ne contient que des lettres, des chiffres et des underscores, sans espace, et il est sensible à la casse : my_event et My_Event sont deux événements distincts. Certains noms sont réservés sur le Web, dont page_view, click, scroll, file_download, form_submit ou session_start, ainsi que les préfixes de paramètres _, ga_, google_, firebase_ et gtag..

Les limites de collecte sont à connaître avant d’écrire le premier nom, car GA4 n’enregistre pas ce qui les dépasse :

• 40 caractères pour un nom d’événement ; au-delà, l’événement n’est pas traité, et ne peut donc pas compter comme événement clé ;
• 25 paramètres par événement, 40 caractères par nom de paramètre ;
• 100 caractères par valeur de paramètre (300 pour page_title, 1 000 pour page_location) ;
• 25 propriétés utilisateur par propriété.

La convention que j’applique ajoute trois règles à celles de Google :

• Tout en minuscules, mots séparés par des underscores, sans accent, comme les événements recommandés : contact_email_click, pas ClicEmail.
• Objet d’abord, action ensuite : contact_email_click, contact_form_submit, cv_download. Les événements d’un même sujet se suivent dans les rapports.
• Les mêmes noms de paramètres partout : link_location désigne toujours l’endroit du clic, quel que soit l’événement. Quand Google a déjà un nom pour une information (link_domain, file_name), reprenez-le.

Étape 4 : des paramètres utiles, sans donnée personnelle

Un paramètre apporte le contexte d’un événement : où le clic a eu lieu, quel fichier, quelle langue. Pour chaque paramètre, le plan précise son nom, ses valeurs possibles et un exemple. Privilégiez des valeurs issues d’une liste fermée (un identifiant de section, une option de menu déroulant) plutôt qu’un texte saisi par le visiteur.

C’est aussi une question de conformité : les règles de Google interdisent d’envoyer des informations permettant d’identifier une personne, comme une adresse e-mail ou un nom, y compris dans les dimensions personnalisées et les paramètres UTM. Un champ libre de formulaire envoyé tel quel peut en contenir.

Un paramètre n’est pas exploitable dans les rapports tant que vous ne l’avez pas enregistré comme dimension personnalisée. Une propriété standard en accepte 50 de portée événement, 25 de portée utilisateur et 10 de portée article ; elles deviennent utilisables 24 à 48 heures après leur création. Google déconseille d’en créer pour un paramètre qui a déjà sa dimension (comme l’identifiant de transaction) et pour des valeurs quasi uniques (identifiant de session, horodatage), qui finissent regroupées sous la ligne « (other) ». Indiquez donc dans le plan quels paramètres doivent être enregistrés.

Étape 5 : désigner peu d’événements clés

Un événement clé (anciennement « conversion ») est un événement que vous déclarez important pour votre activité. Une propriété standard peut en compter 30, sans compter purchase, marqué par défaut. Ma règle : un événement clé mesure une action réellement accomplie, pas une intention. Un achat payé, oui ; un clic sur « Payer », non. Une demande confirmée par le serveur, oui ; l’ouverture d’un formulaire, non.

Le choix, la valeur, la méthode de comptage et le lien avec Google Ads méritent un guide à part : configurer les événements clés sans fausser vos conversions.

Le modèle de plan de marquage à reprendre

Un tableur partagé suffit. Voici les colonnes que je recommande, avec ce qu’on écrit dans chacune. L’exemple est un cas type : un formulaire de devis dont l’envoi est confirmé par le serveur.

Ajoutez un onglet « Historique » : date, modification, auteur. C’est lui qui expliquera, dans un an, pourquoi une courbe s’arrête net.

Deux exemples concrets : ce site et Reviu

Voici le plan de marquage de ce site, tel qu’il est documenté dans son dépôt. Précision importante : la mesure est prête mais pas activée. Tant qu’aucun identifiant GA4 n’est renseigné, le site ne charge aucun script Google et ne dépose aucun cookie. Le script du site annonce déjà les événements ; le jour où GA4 sera activé, ils ne lui seront transmis qu’après l’accord du visiteur, et les événements clés seront déclarés à ce moment-là.

Trois choix méritent une explication :

• contact_form_submit n’est pas prévu comme événement clé. Le formulaire prépare un e-mail dans la messagerie du visiteur : rien ne prouve qu’il l’envoie. Le jour où le formulaire enverra la demande directement, l’événement recommandé generate_lead, déclenché après la réponse du serveur, deviendra l’événement clé.
• Le paramètre subject reprend l’option choisie dans la liste déroulante, jamais le texte du message : aucune donnée personnelle ne peut partir.
• Pas de Google Tag Manager. Pour un site de cette taille, la balise gtag.js seule suffit : moins de scripts à charger, et moins de domaines à autoriser dans la politique de sécurité du contenu (CSP).

Sur Reviu, le plan suit la vente. begin_checkout marque le début du paiement ; purchase porte la valeur, les produits et un transaction_id qui empêche de compter deux fois la même commande ; qr_download, un événement personnalisé, signale l’usage de l’outil gratuit de QR code, un intérêt pour le produit avant l’achat. GA4 n’y est chargé qu’après consentement, comme je l’explique dans le guide GA4 et Consent Mode pour un e-commerce.

Étape 6 : la recette avant la mise en ligne, puis un document vivant

Chaque ligne du plan se teste avant d’être déclarée « en ligne ». L’outil de référence est DebugView, qui affiche en direct les événements et leurs paramètres pour un appareil en mode débogage. Pour activer ce mode sur votre seul navigateur, passez par Tag Assistant, qui ajoute un paramètre _dbg à l’adresse. Ajouter debug_mode: true à la configuration de la balise met au contraire tous les visiteurs en mode débogage : réservez-le à un environnement de test, et pour le désactiver, retirez le paramètre (le passer à false ne suffit pas).

Deux pièges fréquents : avec le Consent Mode, DebugView ne montre rien tant que vous n’avez pas accepté les cookies de mesure dans la bannière ; et un filtre de données « Trafic des développeurs » actif exclut volontairement vos tests en mode débogage des rapports.

• Chaque événement du plan apparaît dans DebugView, avec le nom exact (casse comprise)
• Chaque paramètre porte une valeur attendue, jamais vide ni personnelle
• Aucune action n’envoie deux événements concurrents (mesure améliorée comprise)
• Les achats portent un transaction_id unique
• Les événements clés sont marqués, les dimensions personnalisées créées
• Rien ne part avant le consentement, et le refus est respecté

Ce contrôle trouve naturellement sa place dans la recette du site. Ensuite, le plan vit avec le site : une page ajoutée, un formulaire modifié, un prestataire qui change de balise, et le tableau doit être mis à jour avant le code, pas après.

En résumé

Un bon plan de marquage est court : quelques questions, une dizaine d’événements nommés selon une seule convention, des paramètres sans donnée personnelle, très peu d’événements clés, et une recette documentée. Commencez par les événements de Google, n’inventez que ce qui vous est propre, et gardez le tableau à jour. Si vous voulez un plan adapté à votre site ou à votre boutique, c’est une partie de mon accompagnement SEO et web analytics.