Recherchez les définitions qui vous manquent !
Un plan de taggage (également appelé plan de tracking ou plan de marquage) est un document essentiel dans tout projet de collecte de données web / application mobile.
Si nous résumons (plus d’informations dans les parties suivantes), il liste l’ensemble des événements (généralement des actions utilisateur) à traquer sur un site web ou une application mobile ainsi que les différents paramètres associés, en spécifiant quand et comment ils doivent être traqués.
La réalisation du plan de taggage intervient après la réalisation du plan de mesure.
Ce dernier, quant à lui, liste les différents objectifs (micro et macro) du site web ou de l’application mobile concernée, les KPIs permettant de mesurer et comprendre l’atteinte de ces objectifs et les événements à traquer afin de pouvoir créer ces KPIs.
Nous vous partagerons des exemples de plan de mesure très prochainement ! 😉
Parce que le plan taggage web avec Google Analytics 4 et Google Tag Manager est le plus commun, cette formation est orientée sur ce dernier.
Voici donc deux autres formations qui pourraient vous être utiles :
Formation sur Google Analytics 4 (2023)
Formation sur Google Tag Manager (2023)
Allez, c’est parti, accrochez-vous, nous n’avons pas fait les choses à moitié ! 🤓 📚
Sommaire
- Qu’est-ce qu’un plan de taggage web GA4/GTM ?
- Pourquoi le plan de taggage est-il indispensable dans tout projet tracking web avec GA4 et GTM ?
- Les différentes étapes d’un projet tracking web avec GA4 et GTM
- Comment construire un plan de taggage web GA4/GTM ?
- Comment réaliser la recette d’un plan de taggage web GA4/GTM ?
Qu’est-ce qu’un plan de taggage web GA4/GTM ?
Comme dit un peu plus haut, un plan de tracking est un document (le plus souvent un spreadsheet) permettant de normaliser la façon dont vous collectez les données issues de votre site web / application mobile.
Il vous permet de tirer pleinement parti de vos solutions analytics (Google Analytics 4, Piano Analytics, Matomo Analytics, etc), ainsi que de vos différentes plateformes publicitaires (Facebook Ads, Google Ads, TikTok Ads, etc) et CRM (Salesforce, Hubspot, ActiveCampaign, etc).
Un plan de taggage web conçut pour Google Analytics 4 et Google Tag Manager (plan de taggage web GA4/GTM) liste l’ensemble des événements (généralement des actions utilisateurs) que vous voulez traquer sur votre site web ainsi que l’ensemble des paramètres associés à chacun, et spécifie quand et comment ils doivent être traqués.
Vous l’aurez deviné, ce dernier respecte donc certaines règles et spécifications propres à Google Analytics 4 et Google Tag Manager.
Il découle des objectifs macro et micro de votre site web ainsi que des KPIs associés (plan de mesure).
Bien entendu, cette liste centrale d’événements peut s’allonger et évoluer avec le temps.
Le plan de tracking web GA4/GTM est un support très important pour les équipes techniques en charge de son implémentation, c’est donc un document essentiel en amont de toute mission de collecte de données avec ces outils.
Utilisé à la fois comme outil de gestion de projet et comme document de référence, il permet d’aligner plusieurs personnes autour d’une même stratégie de collecte de données.
Vous y retrouverez également des informations concernant la configuration des outils utilisés pour collecter les données (en particulier informations de configuration sur Google Analytics 4 et Google Tag Manager).
Pourquoi le plan de taggage est-il indispensable dans tout projet tracking web avec GA4 et GTM ?
Chez Boryl, nous avons relevé 4 grandes raisons principales qui font du plan de taggage un document indispensable dans tout projet de collecte de données web avec Google Analytics 4 et Google Tag Manager :
Des données plus fiables
Un plan de tracking crée une base de référence pour les processus de gouvernance des données et garantit une collecte de données fiable.
L’analyse et la visualisation de vos données dépendent de la qualité de vos données. Des données fiables vous permettront de prendre des décisions plus justes.
Une collecte plus complète
La création et l’implémentation d’un plan de taggage complet vous permettent de collecter des données supplémentaires plus avancées et plus intéressantes que ce que vous permet de collecter nativement la balise de configuration GA4.
Le plan de taggage et le plan de mesure vous permettent de ne pas passer à coter des événements essentiels que vous devez traquer en tant que SaaS, e-commerce ou encore site de génération de lead.
Une meilleure compréhension pour les analystes
Un plan de taggage permet à chaque analyste de savoir comment telle ou telle donnée est collectée, sous quelle condition, etc.
Ce document les aide à comprendre quelles sont les données disponibles et comment ils peuvent les utiliser pour leurs analyses.
Une implémentation facilitée pour les développeurs
Un bon plan de taggage donne tous les détails relatifs à l’implémentation technique de ce dernier, ce qui facilite grandement son implémentation.
Les différentes étapes d’un projet tracking web avec GA4 et GTM
Au sein de notre agence web analytics, une mission tracking web avec Google Analytics 4 et Google Tag Manager se déroule généralement en 7 étapes :
Le cadrage et la création d’un plan de mesure
Dans un premier temps, nous réalisons un brief de cadrage (cahier des charges) ainsi qu’un plan de mesure afin de disposer de l’intégralité des informations essentielles à la bonne exécution de cette mission.
L’objectif étant de répondre à des questions du type :
- Quels sont les objectifs macro et micro du site web ? (augmenter le chiffre d’affaires, augmenter le nombre de lead, etc).
- Quels sont les KPIs qui permettent de mesurer et comprendre l’atteinte de ces objectifs ? (nombre de sessions, taux de conversion, nombre de ventes, etc).
- Quelles sont les différentes étapes du ou des funnels (si il y en a) ?
- Comment gérer le consentement de l’utilisateur ? Avec quelle CMP ?
- Est-ce intéressant de passer sur un déploiement Server-Side ?
Lors de cette étape, il nous arrive également de faire un audit de l’existant s’il y a des choses qui ont déjà été implémentés dans le passé.
La création du plan de taggage
Une fois le brief de cadrage et le plan de mesure terminés, nous créons le plan de taggage recensant l’ensemble des événements (généralement des actions utilisateurs) à traquer ainsi que l’ensemble des paramètres associés à chacun d’eux, en spécifiant quand et comment ils doivent être traqués.
Plus d’information sur la structure d’un plan de taggage un peu plus bas ! 😉
Le déploiement du plan de taggage
Le plan de tracking terminé, il faut maintenant l’implémenter !
La manière la plus fiable d’implémenter un plan de taggage est de passer par un développeur qui fera en sorte que les événements et paramètres associés soient envoyés dans le dataLayer au bon moment depuis le backend.
Il est tout de même possible de faire tout directement depuis Google Tag Manager, mais nous ne le recommandons pas, car beaucoup de facteurs peuvent venir affecter négativement la fiabilité de cette méthode.
Chez Boryl, nous proposons à nos clients deux options pour le déploiement d’un plan de taggage :
- Nous nous chargeons du déploiement (s’ils n’ont pas les ressources en interne)
- Nous nous plaçons en support au déploiement (s’ils ont les ressources en interne)
La recette du dataLayer
Il s’agit d’une étape de vérification. C’est une longue étape, mais elle est nécessaire. Elle permet de vérifier que les données envoyées dans le dataLayer sont fiables et envoyées au bon moment.
Chez Boryl, dans le cas où l’intégration du plan de marquage est gérée du côté du client, nous lançons une recette à la fin de l’intégration afin de vérifier que le travail a correctement été exécuté et que les données remontent correctement dans le dataLayer.
S’il y a des bugs, nous les communiquons directement au développeur concerné afin que ces derniers puissent être résolus.
Dans le cas où nous gérons l’implémentation du plan de marquage, cette vérification se fait de notre côté sans aucune intervention de la part du client.
La configuration des outils
Une fois que la recette du dataLayer est terminée et validée, nous configurons les différents outils utilisés pour la collecte de données :
- Google Tag Manager (création des différentes variables, balises, et déclencheurs)
- Google Analytics 4 (configuration des dimensions personnalisées, des métriques personnalisées, des conversions, etc).
- CMP (Consent Management Platform) envisagée (Axeptio, Didomi, etc)
La recette des balises
À la fin de la configuration des outils, nous effectuons une seconde recette pour vérifier que les données remontent correctement dans Google Analytics 4.
L’idée est de vérifier que les différentes balises se déclenchent au bon moment, et que les “hits” envoyés vers l’outil sont corrects.
La création d’un dashboard
Une fois que les données remontent correctement dans Google Analytics 4, il faut pouvoir les exploiter facilement.
Pour ce faire, chez Boryl, en fin de mission, nous créons un dashboard analytics intuitif et sur-mesure afin que le client puisse piloter son business en ligne intelligemment, et facilement.
Ce dashboard permet (dans les grandes lignes) :
- De mesurer en détail la performance des différentes sources de trafic
- De suivre les différentes conversions et le chiffre d’affaires généré
- De comprendre le comportement des utilisateurs
Pour plus de flexibilité dans les visualisations et les analyses, nous passons généralement par Google Big Query et Google Data Studio. L’interface de Google Analytics 4 ne nous permettant pas de faire tout ce que nous voulons.
Comment construire un plan de taggage web GA4/GTM ?
Comme dit un peu plus haut, un plan de taggage se présente dans la majeure partie des cas sous la forme d’un document spreadsheet.
Chez Boryl, un plan de tracking web pour Google Analytics 4 et Google Tag Manager est généralement constitué de plusieurs pages que nous allons découvrir sans plus attendre !
Le plan de taggage pris pour exemple dans cette partie est disponible ici :
C’est le plan de taggage web e-commerce (GA4/GTM) !
Pour une meilleure compréhension, nous vous conseillons de lire ces deux formations :
Formation sur Google Analytics 4 (2023)
Formation sur Google Tag Manager (2023)
La page d’accueil
Cette page a pour objectif de détailler la façon dont la balise « conteneur » de Google Tag Manager doit être implémentée par le développeur (ou autre personne en charge des implémentations techniques sur le site web).
Chez Boryl, peu importe la solution analytics utilisée (Google Analytics 4, Piano Analytics, Matomo Analytics, etc) nous passerons le plus souvent par Google Tag Manager pour la gestion des balises, car c’est la solution la plus simple, agile, évolutive. Et en plus, c’est gratuit !
La page « Liste des événements »
C’est la page principale du document. C’est dans celle-ci que nous allons lister précisément tous les événements à traquer ainsi que toutes les informations associées.
Chez Boryl, cette page compte généralement 14 colonnes.
Pour que ça soit limpide pour vous, nous allons passer en revue chacune de ces colonnes en prenant à chaque fois pour exemple un événement e-commerce.
L’événement e-commerce en question est un événement qui se déclenche lorsqu’un achat a été effectué et validé. Son nom est “purchase”.
La colonne « Priorité »
Cette colonne détermine la priorité d’implémentation de l’événement concerné.
Généralement, dans un plan de tracking pour Google Analytics 4 et Google Tag Manager, nous retrouvons deux niveaux de priorité.
Les événements devant être implémentés en premier sont généralement ceux collectés avec la balise de type configuration Google Analytics 4 (session_start, scroll, etc).
Pourquoi ? Et bien tout simplement parce que nous pouvons associer certains paramètres à la balise de type configuration Google Analytics 4 qui seront automatiquement associés aux événements traqués avec les différentes balises de type événement Google Analytics 4.
Sans oublier que les événements envoyés dans le dataLayer dans le but donner des informations contextuelles avant la lecture de la balise conteneur de Google Tag Manager sont également prioritaires. En effet, nous pourrons ajouter ces paramètres contextuels dans la balise de type configuration Google Analytics 4.
Dans notre exemple, la priorité d’implémentation de l’événement e-commerce purchase doit donc être : “2”
La colonne “Interaction utilisateur”
Cette colonne indique quand (généralement sous quelle interaction utilisateur) l’événement concerné doit être collecté.
Dans notre exemple, l’interaction utilisateur relative à l’événement e-commerce purchase est : “L’utilisateur réalise un achat avec succès”
La colonne “Page”
Cette colonne indique la page (parfois le type de page) où l’événement concerné doit être collecté.
Dans notre exemple, la page relative à l’événement e-commerce purchase est : “/paiement-reussi”
La colonne “Type d’événement”
Cette colonne indique le type d’événement Google Analytics 4 de l’événement concerné. Il en existe 3 :
- Les événements collectés automatiquement
- Les événements recommandés
- Les événements personnalisés
Dans notre exemple, le type d’événement relatif à l’événement e-commerce purchase est : “Événement recommandé”
La colonne “Nom de l’événement”
Cette colonne indique le nom de l’événement concerné.
Dans notre exemple, le nom de l’événement est : “purchase”
La colonne “Méthode de collecte”
Cette colonne indique la méthode de collecte utilisée pour traquer l’événement concerné.
Pour rappel, il existe 2 “méthodes“ de collecte principales pour traquer un événement.
- Soit via les déclencheurs natifs de Google Tag Manager (Page vue, Clic, etc).
- Soit via le déclencheur événement personnalisé de Google Tag Manager qui écoute les événements qui sont poussés dans le dataLayer depuis le backend.
Dans notre exemple, la méthode de collecte relative à l’événement e-commerce purchase est la seconde énoncée juste au-dessus. Nous l’écrirons de la manière suivante :
”Backend – dataLayer.push + GTM – Déclencheur événement personnalisé + Balise événement GA4”
C’est la méthode la plus fiable pour ce type d’événement !
La colonne “Données à envoyer dans le dataLayer”
Cette colonne indique (si besoin) le code JavaScript à exécuter au moment de l’interaction utilisateur depuis le backend afin d’envoyer l’événement concerné dans le dataLayer ainsi que les paramètres qui lui sont associés.
Dans notre exemple, le code JavaScript à exécuter relatif à l’événement e-commerce purchase est :
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: '{{transaction_id'}}',
value: {{value}},
affiliation: '{{affiliation}}',
coupon: '{{coupon}}',
shipping: {{shipping}},
tax: {{tax}},
items: [{
affiliation: '{{affiliation}}',
coupon: '{{coupon}}',
discount: {{discount}},
price: {{price}},
currency : '{{creative_name}}',
quantity: {{quantity}},
index: {{index}},
item_id: '{{item_id}}',
item_name: '{{item_name}}',
item_brand: '{{item_brand}}',
item_category: '{{item_category}}',
item_category2: '{{item_category2}}',
item_category3: '{{item_category3}}',
item_category4: '{{item_category4}}',
item_category5: '{{item_category5}}',
item_list_id: '{{item_list_id}}',
item_list_name: '{{item_list_name}}',
item_variant: '{{item_variant}}',
}]
}
});La colonne “Statut d’implémentation (recette du dataLayer)”
Cette colonne indique le statut de la recette du dataLayer relatif à l’événement concerné. Deux valeurs possibles :
- OK (implémentation dataLayer correcte)
- KO (implémentation dataLayer incorrecte)
Dans notre exemple, nous allons dire que le statut de la recette dataLayer relatif à l’événement e-commerce purchase est : “KO”
La colonne “Commentaire statut d’implémentation (recette du dataLayer)”
Cette colonne indique pourquoi le statut de la recette du dataLayer relatif à l’événement concerné est KO.
Dans notre exemple, nous allons dire que le statut de la recette dataLayer relatif à l’événement e-commerce purchase est KO parce que : “L’événement est envoyé en double dans le dataLayer”
La colonne “Nom de la balise sur GTM”
Cette colonne indique le nom de la balise sur Google Tag Manager relative à l’événement concerné.
Dans notre exemple, le nom de la balise sur Google Tag Manager relative à l’événement e-commerce purchase est : “GA4 – Event – Purchase”
La colonne “Nom du déclencheur sur GTM”
Cette colonne indique le nom du déclencheur sur Google Tag Manager relatif à l’événement concerné.
Dans notre exemple, le nom du déclencheur sur Google Tag Manager relatif à l’événement e-commerce purchase est : “Purchase”
La colonne “Paramètres non collectés nativement à associer à la balise GA4”
Cette colonne indique les paramètres à associer à l’événement concerné.
Dans notre exemple, les paramètres à associer à l’événement e-commerce purchase sont :
- transaction_id
- shipping
- tax
- value
- affiliation
- coupon
- discount
- price
- currency
- quantity
- index
- item_id
- item_name
- item_brand
- item_category
- item_category2
- item_category3
- item_category4
- item_category5
- item_list_id
- item_list_name
- item_variant
La colonne “Conversion GA4”
Cette colonne indique si l’événement concerné doit être marqué en conversion sur Google Analytics 4.
Dans notre exemple, l’événement e-commerce purchase doit être marqué en conversion. Nous indiquons donc : “Oui”
La colonne “Statut d’implémentation GTM/GA4 (recette analytics)”
Cette colonne indique le statut de la recette analytics relatif à l’événement concerné. Deux valeurs possibles :
- OK (configuration analytics correcte)
- KO (configuration analytics incorrecte)
Dans notre exemple, comme la recette dataLayer indique “KO”, le statut de la recette analytics relatif à l’événement e-commerce purchase est obligatoirement : “KO”
La page « Définition des variables »
Sur cette page, nous définissons l’intégralité des variables non collectées nativement par les différentes balises Google Analytics 4.
C’est une page très importante, car elle permet au développeur en charge de l’implémentation du dataLayer de savoir exactement à quoi correspondent les différents paramètres à envoyer dans ce dernier, leur type, etc.
Cette page servira aussi aux personnes qui analyseront les données collectées a posteriori, grâce à une connaissance précise de leurs types et significations.
Enfin, nous y trouvons également des informations de configuration relatives à Google Analytics 4.
Chez Boryl, cette page compte généralement 6 colonnes.
La colonne « Nom »
Cette colonne indique le nom des variables.
Voici quelques exemples :
- page_category_1
- page_category_2
- user_id
- custom_user_id
- value
- shipping_tier
- affiliation
- coupon
- discount
La colonne « Type »
Cette colonne indique le type des variables.
Les 2 types que nous retrouverons le plus souvent sont :
- String (chaîne de caractère)
- Number (nombre décimal ou entier)
La colonne « Description »
Cette colonne décrit les variables.
Voici quelques exemples :
- La section du site à laquelle appartient de page concernée (pour la variable page_category_1)
- L’identifiant de l’utilisateur (pour la variable user_id)
- Le nom du produit (pour la variable item_name)
- Le montant des frais de livraison (pour la variable shipping)
La colonne « Exemple »
Cette colonne indique des exemples concrets pour chaque variable.
Voici quelques exemples :
- “Page listing” (pour la variable page_category_1)
- “987654321” (pour la variable user_id)
- “Robe verte” (pour la variable item_name)
- “23” (pour la variable shipping)
La colonne « Définition personnalisée »
Cette colonne donne des informations de configuration sur Google Analytics 4 quant aux différentes variables. 3 valeurs possibles :
- Dimension personnalisée (uniquement pour les variables de type string non natives)
- Métrique personnalisée (uniquement pour les variables de type métrique non natives)
- Natif (lorsque la dimension/métrique existe déjà nativement dans Google Analytics 4)
Il ne sert à rien de marquer comme dimension ou métrique personnalisée une dimension ou métrique native accessible dans l’interface, vous allez juste gâcher vos crédits et atteindre plus rapidement vos limites de création.
La création de métriques et dimensions personnalisée sert principalement à pouvoir les visualiser dans vos rapports Google Analytics 4 ainsi que dans l’explorateur.
Chez Boryl, pour des raisons de flexibilité et de consolidation, nous préférerons passer par Google Big Query et Google Data Studio pour visualiser les données issues de Google Analytics 4.
De cette manière, nous avons accès à l’intégralité des données brutes dans un format facilement manipulable.
Il ne sert pas à grand-chose d’utiliser les définitions personnalisées si vous passez par Google Big Query et Google Data Studio pour visualiser les données issues de Google Analytics 4.
La colonne « Portée »
Cette colonne indique la portée de la définition personnalisée relative aux différentes variables. 3 valeurs possibles :
- Événement
- Utilisateur (uniquement pour les dimensions personnalisées)
- Natif
La page « Exemple dataLayer xxxx »
Cette page donne un exemple de ce à quoi pourrait ressembler le code JavaScript à exécuter pour un événement donné.
Voici un exemple de code JavaScript relatif à l’événement e-commerce purchase :
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: 'T_12345',
value: 2000,
affiliation: 'Boryl',
coupon: 'PROMO_CODE_20%',
shipping: 23,
tax: 34,
items: [{
affiliation: 'Boryl',
coupon: 'PRODUCT_PROMO_CODE_20%',
discount: 34.3,
price: 100,
currency : 'EUR',
quantity: 10,
index: 1,
item_id: 'SKU_12345',
item_name: 'Robe verte',
item_brand: 'Jules',
item_category: 'Femme',
item_category2: 'Été',
item_category3: 'Robe',
item_list_id: 'li_23',
item_list_name: 'Produits associés 23',
item_variant: 'Vert',
},{
affiliation: 'Boryl',
coupon: 'PRODUCT_PROMO_CODE_20%',
discount: 34.3,
price: 1030,
currency : 'EUR',
quantity: 10,
index: 2,
item_id: 'SKU_1232345',
item_name: 'Robe verte',
item_brand: 'Jules',
item_category: 'Femme',
item_category2: 'Été',
item_category3: 'Robe',
item_list_id: 'li_23',
item_list_name: 'Produits associés 23',
item_variant: 'Vert',
}]
}
});Comment réaliser la recette d’un plan de taggage web GA4/GTM ?
Comme dit un peu plus haut, la recette est une étape de vérification. Et il existe deux types de recettes dans un projet tracking web avec Google Analytics 4 et Google Tag Manager :
- La recette du dataLayer
- La recette analytics
La recette du dataLayer
L’idée de cette recette est de vérifier que les informations souhaitées remontent correctement dans le dataLayer et au bon moment.
Chez Boryl, nous utilisons deux techniques pour vérifier que les informations souhaitées remontent correctement dans le dataLayer :
- Avec la console de votre navigateur
- Avec le mode debug de Google Tag Manager
Avec la console de votre navigateur
La première méthode consiste à consulter le dataLayer dans la console de votre navigateur en appuyant sur la touche F12.
L’idée est d’effectuer certaines actions et de regarder si toutes les données sont bien envoyées dans le dataLayer (et au bon moment !).
Pour accéder au dataLayer depuis la console, vous devez écrire « dataLayer » dans cette dernière et appuyer sur entrée.
Voici ce que cela donne lorsque nous le faisons sur le site d’un client :
En cliquant sur l’index 0 du dataLayer, nous pouvons par exemple voir que les informations relatives aux produits visibles sur la home page remontent correctement.
impressions: Array(8)
0: {name: "xxxx", id: "11", reference: "STP", price: "26", brand: …}
1: {name: "xxxx", id: "67", reference: "SDE", price: "26", category: …}
2: {name: "xxxx", id: "50", reference: "CSHUI", price: "29", category: …}
3: {name: "xxxx", id: "55", reference: "MPCA", price: "32", category: …}
4: {name: "xxxx", id: "60", reference: "CVCSHUI", price: "81", category: …}
5: {name: "xxxx", id: "61", reference: "CVCP", price: "84", category: …}
6: {name: "xxxx", id: "59", reference: "CV", price: "109", category: …}
7: {name: "xxxx", id: "76", reference: "CV-SDE", price: "135", category: …}
Avec le mode debug de Google Tag Manager
La seconde méthode consiste à accéder au dataLayer par l’intermédiaire du mode debug de Google Tag Manger dans l’onglet “dataLayer” :
La recette analytics
L’idée de cette recette est de vérifier que les données remontent correctement dans Google Analytics 4.
Plus précisément, cela consiste à vérifier que les différentes balises se déclenchent au bon moment lorsque nous effectuons certaines actions, et que les données associées envoyées vers Google Analytics 4 sont correctes.
La meilleure façon d’effectuer une recette analytics lorsque vous utilisez Google Tag Manager est d’utiliser le mode debug (comme pour la recette du dataLayer).
Pour ce faire, direction l’onglet « Tags » (balises en français) :
On peut voir ici par exemple que la balise « SS – GA4 – Config » se déclenche bien lorsque nous arrivons sur la home page du site web concerné (boryl.fr).
Voilà, c’est terminé ! 🤓
N’hésitez pas à nous envoyer un petit message si vous avez des questions 😉
Articles Recommandés
Formation sur le plan de taggage GA4/GTM (2023)