[GUIDE COMPLET] Google Tag Manager
Tout comprendre et créer son premier tracking sans être développeur
Google Tag Manager, à quoi ça sert vraiment ?
Quand tu gères un site web (en SaaS ou en e-commerce), tu veux comprendre ce qui se passe :
Qui visite ton site ?
Qui clique où ?
Qui remplit un formulaire, et comment envoyer l’informations à Meta ou Google par exemple.
Par défaut, un site web affiche des pages, laisse les gens cliquer et envois des informations dans ce qu’on appelle le Data Layer.
Google Tag Manager (GTM) est là pour ça. Il sert à écouter ce qui se passe sur ton site (le data layer), puis à transmettre l’info aux bons outils (GA4, Google Ads, etc.).
Mais GTM ne “devine” rien tout seul. Il faut le configurer.
Il te donne un cadre clair pour dire :
“Quand il se passe X sur mon site, j’envoie Y à tel outil, avec telles infos.”
Différence entre GTM et GA4
C’est la confusion classique.
GA4
C’est l’outil qui reçoit les données et te les affiche.
Tu y vois :
les pages vues
les events
les conversions
GTM
C’est l’outil qui déclenche les envois de données.
Il décide :
quel event envoyer
à quel moment
avec quels paramètres
Image simple :
GA4 = le tableau de bord où tu lis ce qui s’est passé. (NB: tu peux installer GA4 sans le tag manager).
GTM = l’électricien qui a tiré tous les câbles pour que la lumière s’allume au bon endroit.
Sans GTM, tu peux faire du tracking, mais :
ce sera souvent mal structuré
très dur à maintenir
Quand utiliser GTM sur un site ?
Dès que tu as besoin de faire transiter de l’information entre ton site et d’autres plateformes (régie publicitaire, outils de tracking, de cookies, etc.)
Si tu fais du growth ou du marketing, GTM devient ton hub de tracking.
Les bases GTM
Avant de poser ton premier tracking, tu dois comprendre les briques de base du GTM.
Compte, container, workspace, version, et environnement :
Compte
Ton organisation. Exemple : lemlist
Container
Ton site ou ton app. Exemple : lemlist.com - prod
Règle simple : 1 site = 1 container. (Il peut y avoir des exceptions, souvent avec les SaaS).
Workspace
Ton “brouillon” de travail. Tu fais tes changements dedans.
Version
Une photo figée de l’état du container à un instant T.
Chaque fois que tu publies, GTM crée une nouvelle version.
Environnement (optionnel au début)
Permet d’avoir des versions différentes pour prod, staging, etc.
À retenir :
Tu travailles dans un workspace.
Quand tu cliques sur “Envoyer” (Publish).
Ça crée une version.
Cette version devient active sur ton site.
Comment créer un container Web
Tu crées ton compte GTM (si ce n’est pas déjà fait).
Tu ajoutes un nouveau container.
Tu choisis “Web” comme type de container.
Tu le nommes clairement :
mon-site.com - prod
ou Mon produit - site marketing
Où coller les snippets GTM (Webflow / WordPress)
Quand ton container est créé, GTM t’affiche deux scripts.
Un script à placer dans le <head>
Un script à placer juste après l’ouverture du <body>
Ces deux scripts permettent à GTM :
de se charger correctement
d’avoir accès à ce qui se passe sur la page
Sur Webflow
Dans Webflow :
Settings du projet → onglet “Custom Code”
Dans la zone “Head code” → coller le script <head>
Dans la zone “Footer code” → coller le script <body>
Tu publies ensuite le site pour que GTM soit actif.
Sur WordPress
Tu as deux options :
utiliser un plugin (le plus simple quand tu débutes)
coller les snippets dans le thème (functions / header / footer)
⚠️ Erreur fréquente : ne coller qu’un seul des deux scripts → résultat : GTM ne se déclenche pas dans tous les cas.
Le trio “Tags, Triggers, Variables”
C’est le cœur de GTM.
Si tu comprends ça, tu comprends 80 % de l’outil.
Un tag se déclenche grâce à un trigger en utilisant des variables.
Un tag, c’est ce que tu veux envoyer.
Exemples :
un event d’achat à GA4
une conversion “nouvel essai gratuit’” à Google Ads
Tu peux voir le tag comme :
“Le message que tu envoies à un outil externe.”
Un trigger, c’est la condition.
Il répond à la question :
“À quel moment ce tag doit se déclencher ?”
Exemples :
à chaque chargement de page
quand quelqu’un clique sur un bouton précis
quand un event demo_request arrive dans le dataLayer
Une variable, c’est une information.
Elle peut venir :
de la page (URL, titre, texte du bouton)
du dataLayer (plan, email, nom du formulaire)
ou de valeurs définies par toi (constantes, tables, etc.)
Tu peux voir la variable comme :
“Le morceau d’info que tu veux inclure dans le tag.”
Comment les trois travaillent ensemble
Scenario typique :
Quand un utilisateur clique sur “Book a demo” (trigger),
alors j’envoie un event “demo_booked “GA4 (tag),
en incluant le texte du bouton et l’URL de la page (variables).
C’est tout.
Tout ce que tu feras dans GTM revient à :
choisir quel trigger
pour quel tag
avec quelles variables
Exemple concret : un tag GA4 event déclenché sur un clic
Objectif : chaque fois qu’un utilisateur clique sur un bouton “Book a demo”, tu veux un event dans GA4.
Activer les variables de clic
Dans “Variables” → activer Click Text, Click URL, etc.
(Tu en auras besoin pour filtrer sur le bon bouton et pour envoyer des infos).
Etape 1:
Etape 2:
Créer un trigger de clic
Type : “Just Links” ou “All Elements”
Condition : Click Text contient “Book a demo”
→ Tu peux aussi filtrer sur la classe ou l’ID du bouton si tu les connais.
Créer un tag GA4 event
Nom : GA4 - event - book_demo_click
Event name : book_demo_click
Paramètres personnalisés :
button_text = Click Text
page_location = Page URL
Associer le trigger au tag
Tu choisis le trigger “Click - Book a demo” pour ce tag.
Résultat :
dès que quelqu’un clique sur ce bouton,
un event book_demo_click part dans GA4
avec button_text et page_location pour l’analyse.
Pour aller plus loins sur les 3 éléments :
tag, trigger, variable
À quoi sert un tag, concrètement
Dans GTM, un tag sert à faire deux grandes choses :
Envoyer des infos à un outil externe
Déclencher ou “préparer d’autres choses” sur ton site (par exemple pousser des éléments dans le dataLayer)
On peut donc les voir comme deux types de tags :
1. Les tags “connectés” à des outils (GA4, Google Ads, etc.)
Ce sont les tags les plus utilisés. GTM a déjà des modèles pour eux. Tu n’as qu’à remplir les champs.
Exemples typiques en B2B SaaS :
Tag GA4 Configuration
Il dit à GA4 :
“Voici l’ID de propriété, envoie les page_view à chaque chargement de page.”
Tag Google Ads Conversion
Il dit à Google Ads :
“Une conversion a eu lieu, avec telle valeur et telle devise.”
Tu y mets :
Conversion ID
Conversion Label
éventuellement une valeur dynamique (via variable)
Autres tags “officiels”
Meta, LinkedIn, Hotjar, etc.
GTM propose souvent des modèles où tu n’as plus qu’à coller ton ID.
Ces tags :
ont un type déjà prédéfini (GA4, Google Ads, etc.)
exposent des champs assez simples (ID, event_name, value, currency, etc.)
servent à parler directement à une plateforme externe
Tu les utilises pour toutes les actions du style :
“Quand il se passe X sur mon site, je veux que GA4 / Google Ads / [autre] reçoive l’info.”
2. Les tags “techniques” qui exécutent du code ou poussent dans le dataLayer
Ensuite, tu as des tags plus “libres” :
Tag HTML personnalisé (Custom HTML)
Tag script / Custom JS (via HTML)
Avec ces tags-là, tu peux :
exécuter du JavaScript au moment d’un event
lancer un script de chat, un pixel, une lib externe
pousser de nouvelles infos dans le dataLayer au bon moment
Par exemple, tu peux avoir un tag qui :
<script>
dataLayer.push({
event: "pricing_view",
user_plan: "pro",
source: "banner_test"
});
</script>Ce tag ne parle pas directement à GA4 ou Google Ads.
Il enrichit ton dataLayer en communicant que quelqu’un a consulté la page de pricing, et que son plan est un plan “Pro”. Donc potentiellement un utilisateur avec un potentiel d’upsell.
Ensuite, d’autres tags (GA4, Ads, etc.) pourront écouter cet event pricing_view et envoyer ces infos aux bonnes plateformes.
C’est là que la logique devient vraiment intéressante :
Un tag peut servir à déclencher une action immédiate vers un outil externe, ou à préparer des données pour que d’autres tags s’en servent.
Ce que tous les tags ont en commun
Quel que soit le type de tag, tu retrouves toujours deux choses :
Un type de tag
GA4 Configuration
GA4 Event
Google Ads Conversion
HTML personnalisé
etc.
Des paramètres
ID de propriété / compte (GA4, Ads, etc.)
Nom d’event (lead_submit, book_demo_click)
Valeur (value), devise (currency)
ou un bout de code à exécuter (pour les HTML custom)
Et toujours :
Le tag ne se déclenche pas tout seul.
Il a besoin d’un trigger.
C’est le trigger qui dit :
“À ce moment précis, lance ce tag.”
Et derrière, ce tag peut :
soit envoyer les infos direct à un outil externe (GA4, Ads, etc.)
soit pousser dans le dataLayer des infos qui seront captées par d’autres tags plus tard.
Comment penser tes tags
Pour ne pas te perdre, tu peux classer tes tags mentalement en trois catégories :
Tags “fondations”
ex : GA4 Configuration, Consent Mode
Ils tournent sur toutes les pages
Tags “évènements business”
ex : lead_submit, book_demo_click, pricing_view
Ils correspondent à des actions importantes dans ton funnel
Tags “campagnes / médias”
ex : conversions Google Ads, pixels Meta, Snapchat, etc.
Ils aident les plateformes à optimiser tes campagnes
Tu peux ensuite les nommer en suivant un schéma simple :
GA4 - config - main
GA4 - event - lead_submit
Google Ads - conversion - lead_submit
L’idée : quand tu jettes un œil à ta liste de tags, tu comprends qui parle à qui, et dans quel but.
Les triggers
Si le tag est “le message à envoyer”, le trigger est “le moment où tu l’envoies”.
Un trigger répond à la question :
“Dans quelles conditions ce tag doit-il se déclencher ?”
Sans trigger :
le tag ne se déclenche jamais
Avec un mauvais trigger :
le tag se déclenche trop souvent (donc génère des doublons)
ou ne se déclenche pas du tout
Comment fonctionne un trigger
Tu le maintenant, GTM écoute les évènements qui se passe sur ton site.
Et sur ton site, il se passe plein de choses :
une page se charge
un utilisateur clique
un formulaire est soumis
le site pousse un dataLayer.push
etc.
GTM observe tout ça.
Un trigger est un filtre que tu poses sur ce flux d’évènements pour dire :
“Quand c’est ce type d’évènement, sur cette page, avec ces conditions, alors déclenche ce tag.”
Types de triggers les plus utiles
Tu n’as pas besoin de tout connaître au début. Tu peux déjà faire 90 % du boulot avec ces cinq-là :
Page View / All Pages
Se déclenche à chaque chargement de page
Sert surtout aux tags “fondations” (GA4 config)
Click
Se déclenche lorsqu’un clic a lieu sur un élément (lien, bouton, etc.)
Tu l’affines ensuite avec des conditions : texte du bouton, URL, ID, classes…
Form Submission
Se déclenche lorsqu’un formulaire est soumis
Marche bien pour des formulaires “classiques” de 70% des sites web (mais peut être capricieux avec des forms ultra JS)
Custom Event
Se déclenche quand un event spécifique apparaît dans le dataLayer
Exemple: demo_request, pricing_view, feature_used
C’est le type le plus propre quand tu bosses avec du dataLayer.
Timer / Scroll (optionnel pour démarrer)
Timer : se déclenche toutes les X secondes si l’utilisateur reste sur la page
Scroll : se déclenche quand l’utilisateur atteint un certain pourcentage de scroll
Utile plus tard pour mieux comprendre l’engagement.
Comment construire un trigger intelligemment
Un bon trigger, c’est un trigger :
qui se déclenche seulement quand l’action t’intéresse
qui dépend de choses stables (ID, dataLayer, attributs, pas juste un texte fragile)
qui est facile à relire dans 3 mois
Exemple pour un clic “Book a demo” :
Type : Click
Conditions :
Click Text contient “Book a demo”
ou
Click ID = book-demo-btn (encore mieux si tu peux)
Nom du trigger : Click - book_demo_button
Tu sais :
sur quel type d’action tu écoutes (clic)
sur quel élément (bouton demo)
Exemple pour un submit de formulaire via dataLayer :
Type : Custom Event
Event name : demo_request
Nom du trigger : CE - demo_request
Tu sais que tu déclenches quand le site a explicitement poussé cet event.
Tags et triggers ensemble
Tu peux maintenant rebrancher la logique complète :
Tu as un event côté site (clic, form, dataLayer).
Tu crées un trigger qui écoute ce type d’évènement et filtre les bons cas.
Tu crées un tag qui envoie les bonnes infos à GA4 / Google Ads.
Tu relies le tag au trigger.
Exemple complet :
Trigger : CE - demo_request (Custom Event)
Tag 1 : GA4 - event - lead_submit
Tag 2 : Google Ads - conversion - lead_submit
Résultat :
au moment où ton form démo est vraiment envoyé,
GA4 reçoit lead_submit
Google Ads reçoit une conversion
avec les bonnes variables (plan, page, etc.)
Les variables
Les variables te permettent de rendre ton tracking utile, pas juste “oui / non”.
Sans variable, tu sais “un clic a eu lieu”.
Avec variables, tu sais :
sur quel bouton
sur quelle page
dans quel contexte
On distingue deux grandes familles :
les variables intégrées (GTM les connaît déjà)
les variables personnalisées (que tu configures)
Les variables intégrées
Ce sont des variables que GTM sait déjà lire, mais qu’il faut activer.
Les plus utiles :
Page URL
C’est l’adresse complète de la page que l’utilisateur est en train de voir.
Exemple :
https://www.saasboarding.com/pricing?utm_source=google&utm_campaign=brand
À quoi ça sert
Savoir précisément sur quelle page un event s’est produit.
Filtrer des triggers par URL (ex : ne déclencher un tag que sur /pricing).
Envoyer page_location à GA4, qui aime bien recevoir l’URL complète comme paramètre.
Cas d’usage typique
Dans un event book_demo_click, tu peux envoyer page_location = {{Page URL}}.
Ça te permet de savoir si les clics viennent de /, /pricing, /product, etc.
Pour un event de conversion type lead_submit, tu peux analyser ensuite dans GA4 :
“Quels formulaires / pages génèrent le plus de leads ?”
Point à noter
Page URL inclut :
le protocole (https)
le domaine
le path
les paramètres UTM, etc.
Page Path
C’est la partie “chemin” de l’URL, sans domaine ni paramètres.
Exemple :
Pour l’URL https://www.lemlist.com/pricing?utm_source=google
→ Page Path = /pricing
À quoi ça sert
Regrouper plus facilement les pages du même type sans te soucier du domaine ou des UTM.
Filtrer des triggers par chemin (ex : “toutes les pages qui commencent par /blog/”).
Cas d’usage typique
Créer un trigger qui ne se déclenche que sur /pricing :
Condition : Page Path égale /pricing.
Analyser les events par template de page, sans polluer les données avec les paramètres.
Différence clé avec Page URL
Page URL = tout, complet
Page Path = uniquement la “route” du site
Referrer
Referrer, c’est la page d’où vient l’utilisateur avant d’arriver sur la page actuelle.
Exemple :
Si quelqu’un vient de Google sur ta page d’accueil, Referrer peut être un lien google.com.
Si quelqu’un vient de /blog/article-x vers /pricing, Referrer = /blog/article-x.
À quoi ça sert
Comprendre le contexte de l’action.
Savoir si un clic ou un event important vient :
d’une landing d’ads
d’un article de blog
d’une page produit
Cas d’usage typique
Tu peux envoyer referrer comme param GA4 sur certains events pour savoir :
“Combien de clics ‘Book a demo’ viennent de telle page ou telle source interne ?”
Limites
Le referrer peut être vide dans certains cas (navigation directe, certaines redirections, protection du navigateur).
Pour la vraie acquisition, tu t’appuies plutôt sur les paramètres UTM / attribution GA4. Le referrer est plus utile pour du contexte interne au site.
Click Text
Click Text = le texte visible sur l’élément cliqué (le bouton, le lien).
Exemples :
Bouton : <button>Book a demo</button> → Click Text = Book a demo
Lien : <a>Start free trial</a> → Click Text = Start free trial
À quoi ça sert
Filtrer les clics sur un bouton spécifique (ex : tous les endroits où le texte contient “Book a demo”).
Envoyer le texte du bouton dans GA4 pour analyser l’efficacité des différents CTA.
Cas d’usage typique
Trigger :
Type : Click
Condition : Click Text contient Book a demo
Tag GA4 event :
Paramètre button_text = {{Click Text}}
Points de vigilance
Si tu changes le texte du bouton (AB test, refonte), ton trigger peut casser si tu ne surveilles pas.
Pour un tracking très robuste, c’est mieux d’ajouter un ID ou un data-attribute au bouton, mais Click Text reste très pratique pour démarrer.
Click URL
Click URL = l’adresse vers laquelle pointe le lien cliqué.
Exemple :
<a href="https://lemcal.com/demo-lemlist">Book a demo</a>→ Click URL = https://lemcal.com/demo-lemlist
À quoi ça sert
Savoir où l’utilisateur s’en va quand il clique.
Filtrer les clics sortants vers des domaines externes (lemcal, doc, partenaires, etc.).
Déclencher un event outbound_click seulement quand l’URL ne contient pas ton domaine.
Cas d’usage typique
Trigger pour les clics sortants :
Type : Just Links
Condition : Click URL ne contient pas lemlist.com
Tag GA4 event :
event_name = outbound_click
Param link_url = {{Click URL}}
Point important
Tu peux utiliser Click URL aussi pour distinguer plusieurs boutons qui ont le même texte mais mènent à des destinations différentes.
Click Classes
Click Classes = les classes CSS appliquées à l’élément cliqué.
Exemple :
<a class="btn-primary cta-demo" href="/demo">Book a demo</a>→ Click Classes = btn-primary cta-demo
À quoi ça sert
Filtrer les clics sur un groupe d’éléments stylés de la même façon.
Eviter d’être dépendant du texte (si le designer change “Book a demo” en “Talk to sales”).
Cas d’usage typique
Trigger :
Type : Click
Condition : Click Classes contient cta-demo
Tag GA4 event : book_demo_click
Points de vigilance
Les classes peuvent parfois changer lors de refontes ou si tu utilises des frameworks CSS.
Essaye d’avoir une classe “tracking-friendly” (cta-demo) plutôt que des classes purement visuelles (btn-primary).
Click ID
Click ID = l’ID HTML de l’élément cliqué.
Exemple :
<a id="book-demo-header" href="/demo">Book a demo</a>→ Click ID = book-demo-header
À quoi ça sert
Identifier de manière unique un bouton ou un lien.
Avoir des triggers robustes : tant que l’ID ne change pas, ton tracking reste valide, même si le texte ou les classes changent.
Cas d’usage typique
Trigger :
Type : Click
Condition : Click ID = book-demo-header
Tag GA4 event : book_demo_click
Pourquoi c’est intéressant
Pour du tracking sérieux (genre boutons critiques comme “Book a demo”), demander à ton dev d’ajouter des IDs propres (book-demo-header, book-demo-pricing) est une très bonne pratique.
Ça t’évite d’être dépendant du texte ou de classes qui changent au gré des refontes.
Form ID / Form Classes
Comme pour les clics, mais pour les formulaires :
Form ID = l’ID du formulaire soumis
Form Classes = les classes CSS du formulaire
Exemple :
<form id="demo-form" class="lead-form main-form">
...
</form>→ Form ID = demo-form
→ Form Classes = lead-form main-form
À quoi ça sert
Déclencher un trigger uniquement pour certains formulaires.
Éviter de déclencher le même event sur tous les formulaires du site (newsletter, contact, etc.).
Cas d’usage typique
Si tu veux une solution “rapide” sans dataLayer (même si moins propre) :
Trigger :
Type : Form Submission
Condition : Form ID = demo-form
Tag GA4 event :
event_name = lead_submit
Ensuite, quand tu passes à un setup plus propre avec dataLayer, tu peux garder Form ID pour debug ou pour filtrer certains cas.
Points de vigilance
Comme pour les clics, si ton dev change l’ID / les classes, ton trigger casse.
Sur certains formulaires très JS, le trigger “Form Submission” ne se déclenche pas du tout → d’où l’intérêt d’utiliser un dataLayer.push côté site.
Tu les actives dans :
Variables → Configurer → cocher les cases utiles
Les variables personnalisées
1) Data Layer Variable
À quoi ça sert :
Récupérer une info qui est poussée dans le dataLayer par ton site. (On voit juste après ce qu’est le Data Layer.)
Exemple côté site :
dataLayer.push({
event: "demo_request",
form_name: "demo",
plan: "pro",
page_location: window.location.href
});Côté GTM, tu crées une variable de type Data Layer Variable :
Nom de la variable : DLV - plan
Nom de la clé (Data Layer Variable Name) : plan
Cas d’usage :
envoyer le nom d’un plan dans GA4
construire des audiences (ex : seulement ceux qui demandent une démo depuis plan “pro”)
adapter la valeur de conversion dans Google Ads
2) Constant
À quoi ça sert :
Stocker une valeur fixe, pour ne pas la retaper partout.
Exemples de variables “Constant”:
currency = EUR
environment = prod
GA4_measurement_id = G-XXXXXXX
En pratique :
tu crées une variable “Constant”
tu la réutilises dans plusieurs tags
Ça évite :
les fautes de frappe et les incohérences (tu changes une fois, tout suit)
3) Lookup Table
À quoi ça sert :
Traduire une valeur en une autre, selon des règles.
Exemple : tu veux donner une valeur de conversion selon la taille d’équipe sales.
Si sales_team_size = “only me” → valeur = 20
Si sales_team_size = “2-5” → valeur = 100
Si sales_team_size = “6-10” → valeur = 500
Tu crées une variable Lookup Table :
Input : sales_team_size (Data Layer Variable)
Output : conversion_value
Cas d’usage growth :
donner une valeur différente à chaque lead en fonction de son profil
optimiser Google Ads sur une valeur business plus réaliste
4) Regex Table
À quoi ça sert :
Grouper plusieurs valeurs sous une même étiquette à l’aide de modèles (regex).
Exemple :
toutes les URLs qui contiennent /pricing ou /plans → catégorie = pricing
toutes celles qui commencent par /blog/ → catégorie = content
Cas d’usage :
analyser les conversions par type de page (pricing vs blog vs home)
créer des dimensions plus propres dans GA4
5) Custom JavaScript
À quoi ça sert :
Cas particuliers où tu dois calculer ou transformer une valeur avec un peu de logique.
Exemple simple :
function() {
return document.title;
}Cas d’usage :
récupérer le titre de la page si tu ne veux pas dépendre du dataLayer
faire une transformation légère quand tu n’as pas de meilleur endroit pour le faire
⚠️ À utiliser avec modération. Si tu peux le faire côté dataLayer, fais-le côté dataLayer directement sur ton site.
C’est quoi le dataLayer, concrètement ?
Imagine que ton site ait une petite “boîte aux lettres invisible” entre lui et Google Tag Manager.
Cette boîte s’appelle dataLayer.
Quand il se passe quelque chose d’important sur ton site (un formulaire envoyé, un plan choisi, un bouton cliqué),
ton site va/peut glisser un message dans cette boîte,
et GTM peut lire ce message et agir en fonction.
Ce “message” prend la forme d’un petit bloc de données :
dataLayer.push({
event: "demo_request",
form_name: "demo",
plan: "pro"
});Tu peux le lire comme une phrase :
“Il vient de se passer un évènement appelé demo_request,
venant du formulaire demo,
avec le plan pro.”
GTM voit passer ce message, et toi tu lui dis :
“Quand tu vois un event demo_request, déclenche tel tag.”
Pourquoi le dataLayer est important
Tu as deux façons de faire du tracking :
En lisant la page (les classes CSS, l’ID des éléments, la structure HTML)
En lisant le dataLayer (les messages que le site t’envoie)
La première façon marche, mais :
dès que le dev change une classe, ton tracking casse
dès qu’un formulaire change de structure, ton trigger ne marche plus
tu passes ton temps à suivre les refontes
Le dataLayer, lui, est indépendant du design.
Le dev peut changer le style du bouton, le texte, le layout
Tant qu’il pousse toujours le même dataLayer.push({ event: “demo_request”, ... }), ton tracking continue de fonctionner.
C’est pour ça qu’on dit qu’un tracking “propre” repose sur le dataLayer :
→ tes events sont plus stables et tu maîtrises les infos envoyées (plan, form_name, etc.)
Exemple simple : form “demo_request”
Prenons ton cas classique: Un utilisateur remplit le formulaire “Request a demo”.
1) Côté site : pousser l’évènement dans le dataLayer
Au moment où le formulaire est vraiment envoyé, le dev (ou toi même) peut ajouter ce genre de code sur le site (dans le header ou footer) :
dataLayer.push({
event: "demo_request",
form_name: "demo",
email: "john@company.com",
company: "Acme",
plan: "pro",
page_location: window.location.href
});Ce qu’on vient de faire :
event: “demo_request” → c’est le nom de l’évènement
le reste (form_name, email, company, plan, page_location) → ce sont les infos utiles qu’on attache à cet event
Tu as maintenant :
un signal clair : demo_request
avec des données réutilisables : form_name, plan, page, etc.
2) Côté GTM : créer le trigger “Custom Event”
Maintenant, tu vas dire à GTM :
“Quand tu vois passer un message avec event = demo_request, réveille-toi.”
Dans GTM :
Va dans Triggers → Nouveau
Type : Custom Event
Event name : demo_request
Nom du trigger : CE - demo_request
Ce trigger se déclenchera à chaque fois que le site pousse un dataLayer.push avec event: “demo_request”.
3) Côté GTM : créer les Data Layer Variables
Tu veux maintenant utiliser les infos form_name, plan, etc. dans tes tags (GA4, Google Ads…).
Pour ça, tu crées une variable par champ que tu veux récupérer :
Dans GTM → Variables → Nouvelle → Data Layer Variable :
DLV - form_name
Data Layer Variable Name : form_name
DLV - plan
Name : plan
DLV - page_location
Name : page_location
Tu peux en faire d’autres (company, email) selon ce que tu veux utiliser.
Workflow simple pour ne pas partir dans tous les sens
Tu peux garder ce process comme check-list, à chaque nouveau tracking.
1. Définir le besoin
Tu commences sans GTM, juste avec une phrase claire :
“Je veux savoir combien de personnes envoient le formulaire démo.”
“Je veux suivre les clics sur ‘Book a demo’ par page.”
“Je veux que Google Ads optimise sur les leads qualifiés, pas juste les visites.”
Si tu n’arrives pas à faire cette phrase clairement, ne touche pas encore à GTM.
2. Voir si tu peux passer par le dataLayer
Tu discutes avec un dev, ou tu notes ce qu’il faudrait lui demander :
Quel est l’évènement clé ?
ici : demo_request
Quelles infos tu veux récupérer avec ?
exemple : form_name, plan, page_location, company, etc.
La demande ressemble à ça :
“À chaque fois que le formulaire démo est réellement envoyé,
peux-tu pousser un dataLayer.push avec event = demo_request + quelques champs (form_name, plan, page_location, company) ?”
Plus tu es clair sur ce que tu veux, plus le dev peut te faire une intégration propre.
3. Créer les variables dans GTM
Une fois le dataLayer en place, tu fais :
une Data Layer Variable par champ important
tu les nommes proprement (préfixe DLV -)
tu vérifies en Preview qu’elles ont bien une valeur quand l’event se produit
4. Créer le trigger
Tu crées ensuite le trigger qui va écouter ton event :
Custom Event demo_request
ou un autre type (Click, Form Submit…) si tu n’as pas de dataLayer
Mais idéalement :
pour tout ce qui est vraiment important dans ton funnel, tu passes par un event dataLayer dédié.
5. Créer le tag
Tu crées le tag qui enverra l’info à GA4, Google Ads, etc.
Exemple GA4 :
Tag : GA4 - event - lead_submit
Event name : lead_submit
Paramètres : form_name, plan, page_location, etc.
Trigger : CE - demo_request
6. Tester en Preview
C’est une étape à ne jamais zapper.
En mode Preview :
tu vas sur la page du formulaire
tu le remplis
tu l’envoies
Puis dans Tag Assistant :
Tu repères l’event demo_request dans la colonne de gauche
Tu cliques dessus
Tu vérifies :
Onglet Tags
que ton tag GA4 - event - lead_submit apparaît bien dans Tags Fired
Onglet Variables
que DLV - plan, DLV - form_name, etc. ont bien une valeur
Si :
le tag ne se déclenche pas → tu regardes “Tags Not Fired” pour voir pourquoi
les variables sont vides → tu compares leurs noms avec ceux du dataLayer.push
7. Publier… puis vérifier dans GA4 / Ads
Quand tout est bon en Preview :
tu publies dans GTM
tu vas dans GA4 → DebugView ou Realtime
tu reproduis l’action une nouvelle fois
tu confirmes que l’event arrive bien côté GA4
Si tu utilises ensuite cet event comme conversion (GA4 ou Google Ads), tu le feras dans un second temps.
Mode Preview et debug
C’est une des parties les plus importantes pour comprendre vraiment GTM.
Comment lancer le mode Preview / Tag Assistant
Dans GTM :
tu cliques sur “Preview”
tu entres l’URL de ton site
tu cliques sur “Connect”
Une nouvelle fenêtre s’ouvre avec ton site.
En parallèle, tu as l’interface Tag Assistant qui affiche ce qui se passe.
Comment lire ce qui se passe
Dans Tag Assistant, tu vas voir une timeline d’évènements sur la gauche.
Chaque ligne correspond à quelque chose qui s’est passé sur la page :
page_view
click
custom event (ex : demo_request)
etc.
Quand tu cliques sur un event dans la timeline, tu as plusieurs onglets.
Les plus importants :
1) Onglet “Tags”
Tu y vois deux sections :
Tags Fired
Tags Not Fired
Tags Fired = tags qui se sont déclenchés sur cet event.
En cliquant sur un tag dans cette liste, tu peux :
voir pourquoi il s’est déclenché
vérifier quelles conditions étaient vraies
voir quelles valeurs ont été envoyées (par exemple à GA4)
C’est là que tu comprends :
“OK, au moment où demo_request est arrivé, mon tag GA4 lead_submit s’est bien déclenché.”
Tags Not Fired = tags qui auraient pu se déclencher sur cet event, mais dont les conditions n’étaient pas remplies.
C’est très utile quand tu t’attendais à ce qu’un tag parte et qu’il ne part pas
Tu peux cliquer sur le tag non fired et regarder :
quelle condition n’a pas été remplie
si ton trigger était trop strict, mal configuré, ou si l’event ne correspondait pas
En gros :
“Tags Fired” = ce qui fonctionne
“Tags Not Fired” = ce qui t’aide à débugger ce qui ne fonctionne pas
2) Onglet “Variables”
Là, tu vois toutes les variables disponibles au moment précis de cet event :
Page URL
Click Text
DLV - plan
DLV - form_name
etc.
C’est ici que tu peux vérifier :
si ton dataLayer.push contient bien ce que tu crois
si les Data Layer Variables récupèrent correctement les valeurs
si les valeurs sont nulles, vides, ou incorrectes
Exemple :
tu cliques sur l’event demo_request
dans Variables, tu vérifies :
event = demo_request
DLV - plan = pro
DLV - form_name = demo
Si ce n’est pas le cas :
soit le dataLayer.push côté site est mal fait
soit le nom de ta DLV dans GTM ne correspond pas exactement à la clé (plan vs plan_type, etc.)
Comment diagnostiquer un tag qui ne se déclenche pas
Cas typique :
Tu t’attends à voir un event dans GA4, mais rien.
Process simple :
Tu ouvres GTM → Preview.
Tu reproduis l’action sur le site (clic, form…).
Tu cherches l’event correspondant dans la timeline :
clic
demo_request
etc.
Tu cliques sur l’event, onglet “Tags” :
Le tag attendu est-il dans “Tags Fired” ?
Oui → Regarde s’il envoie bien ce que tu veux.
Non → Va voir “Tags Not Fired”.
Si ton tag est dans “Tags Not Fired” :
clique dessus
regarde les détails :
quelle condition est fausse ?
est-ce le bon event name ?
est-ce la bonne URL ?
est-ce qu’un filtre est trop strict ?
Va ensuite dans l’onglet “Variables” :
vérifie que les variables utilisées par ton trigger sont bien remplies
par exemple : event = demo_request et pas demo-request
ou Click Text contient bien “Book a demo”
Ce combo :
Timeline → Tags → Variables
C’est le meilleur moyen d’apprendre GTM.
Tu vois ce que tu as config, et ce que la page te renvoie vraiment.
Les erreurs fréquentes et checklist
Mauvais container installé sur le site
Tu configures tout dans un container, mais l’ID collé sur le site est un autre → Toujours vérifier l’ID dans le code source.
Snippets mal placés ou incomplets
Un seul script GTM installé sur deux, ou dans un endroit incorrect.
Triggers trop larges
Par exemple “All Clicks” sans condition → tu te retrouves avec des milliers d’events inutiles.
Nom d’event mal orthographié
demo_request côté dev vs demo-request côté GTM → rien ne se déclenche.
Variables dataLayer mal nommées
Tu appelles ta DLV plan, alors que la clé envoyée est plan_type. Résultat : variable vide.
Pas de test en Preview avant publication
Tu publies, tu crois que tout marche, tu te rends compte un mois plus tard que rien n’a été reçu.
GA4 installé deux fois
Une fois via GTM, une fois en dur dans le code → visites et events doublés, données inutilisables.
Checklist avant publication
Avant de cliquer sur “Envoyer” dans GTM :
Mode Preview lancé
L’action que tu veux tracker a été testée manuellement
Tu vois le bon event dans la timeline (click, demo_request, etc.)
Ton tag apparaît bien dans Tags Fired au bon moment
Tes variables ont des valeurs non vides dans l’onglet Variables
Le nom de l’event GA4 est correct (lead_submit, book_demo_click, etc.)
Tu as donné un nom clair au tag / trigger / variables
Tu as noté quelque part à quoi sert cet event (doc rapide)
Checklist après publication
Une fois publié :
Tu ouvres GA4 → DebugView → tu verifies que l’event remonte bien.
Tu vérifies dans GA4 Realtime que les events arrivent quand tu testes toi-même.
Si conversion Google Ads :
tu vois des conversions de test remonter
tu n’as pas de doublons (évolution cohérente)
Tu notes la date de mise en prod → utile pour relire certaines courbes plus tard.
Pour finir !
On va être honnête : cette édition est longue.
Mais vous êtes maintenant des pros avec Tag Manager.
Souvent les gens ont soit peur de l’ouvrir, soit ils l’utilisent “vite fait”, et se retrouvent avec un tracking plein d’erreurs, de doublons et d’events impossibles à lire.
L’idée de ce guide : que tu le lises une fois pour comprendre la logique, que tu crées ton premier combo variables + triggers + tags, et que tu aies une base solide vers laquelle revenir.
Mon conseil :
Tu lis le guide une fois, au calme.
Tu ouvres un container GTM et tu poses un vrai tracking simple (un seul event) pour comprendre l’interface.
En suite:
Tu exportes cette édition en PDF pour l’avoir sous la main.
Tu en fais ton propre GPT “GTM Helper”… ou tu utilises le mien, juste ici créé pour l’occasion : lien.
À partir de là, GTM arrête d’être une boîte noire. Ça devient un levier de plus dans ta stack growth.