Tracking e-commerce GTM : configurer sans erreur

Sommaire

• Ce qu'il faut en place avant de poser le moindre tag
• Construire un dataLayer e-commerce propre, source par source
• Configurer les événements clés : view_item, add_to_cart, purchase
• Gérer le consentement avec Consent Mode v2
• Vérifier la qualité des données avant de s'y fier
• Les erreurs de tracking qui coûtent le plus cher
• Passer d'un tracking posé à un tracking sur lequel décider
• Questions fréquentes

Ce qu'il faut en place avant de poser le moindre tag

Trois briques suffisent pour démarrer : Google Tag Manager, un compte Google Analytics 4, et un accès en modification à la boutique. Rien de plus pour une petite structure.

Tag Manager joue le rôle de chef d'orchestre. Au lieu de retoucher le code du site à chaque changement de suivi, tout passe par une seule interface qui gère l'ensemble des balises. Si vous n'avez jamais installé le conteneur, le pas-à-pas Google Tag Manager pour débutant couvre la pose initiale. GA4 reçoit et range les données. La boutique, elle, est la source : c'est elle qui doit annoncer « un visiteur vient d'ajouter ce produit au panier ».

De quoi a-t-on besoin : GTM, GA4 et un accès à la boutique ?

Le conteneur GTM doit être installé sur toutes les pages. Une propriété GA4 avec son identifiant de mesure, plus un accès administrateur au CMS : sans ces trois éléments, aucune donnée d'achat ne peut circuler.

L'ordre compte. On installe GTM d'abord, GA4 ensuite via GTM (pas en dur dans le thème), puis on branche les événements. Mettre GA4 directement dans le code en plus de GTM reste le moyen le plus courant de dédoubler les données. Je vois cette double installation sur une bonne partie des boutiques que j'ouvre pour la première fois.

Comment fonctionne le dataLayer en une minute ?

Le dataLayer est une petite liste d'informations que le site publie à chaque action importante. Imaginez un tapis roulant : à chaque événement (vue produit, ajout panier, achat), la boutique y dépose un paquet de données que GTM vient lire.

Sans ce tapis roulant, GTM devine. Il peut deviner un clic de bouton, mais pas le prix du produit, la devise ou l'identifiant de commande. C'est là que réside la vraie fondation : tout le reste en dépend. La documentation officielle GA4 sur la mesure e-commerce détaille le format attendu pour chaque événement.

Construire un dataLayer e-commerce propre, source par source

Un dataLayer e-commerce propre expose, pour chaque achat, le détail des produits, le montant total, la devise et l'identifiant unique de transaction. Ces quatre blocs ne sont pas négociables.

Le piège classique : croire que le CMS fait tout bien par défaut. Certaines plateformes fournissent un dataLayer natif, mais presque toujours incomplet pour GA4. Il manque souvent la devise, parfois le prix hors taxe, parfois l'identifiant produit cohérent avec le catalogue publicitaire. Résultat : un purchase part, mais à moitié vide.

Que doit contenir le dataLayer pour un achat ?

Pour un événement purchase, le dataLayer doit contenir au minimum : le transaction_id (identifiant unique de commande), la value (montant total), la currency (devise, format EUR), et le tableau items (liste des produits avec nom, identifiant, prix et quantité). Sans transaction_id, impossible de dédoublonner.

value et currency vont ensemble. Envoyer une valeur sans devise, c'est comme écrire un prix sur une étiquette sans préciser s'il s'agit d'euros ou de dollars : GA4 ne sait pas convertir, et le chiffre d'affaires devient illisible. Le tableau items alimente ensuite tous les rapports produit et conditionne le lien avec Google Merchant Center pour les campagnes Shopping.

Shopify, WooCommerce, PrestaShop : où récupérer les données produit ?

Les trois CMS les plus courants en France gèrent le dataLayer différemment, et aucun ne couvre tout nativement sans réglage. Ce qu'il faut réellement prévoir selon la plateforme :

Shopify restreint l'accès au tunnel de paiement hors formules avancées, ce qui complique un purchase fiable. WooCommerce s'appuie en général sur l'extension GTM4WP, gratuite et solide, qui pousse un dataLayer conforme GA4. PrestaShop demande presque toujours un module payant ou une intervention technique.

Quand j'arbitre une mise en place, je commence par cartographier ce que le CMS pousse déjà, parce que réinventer un dataLayer qui existe déjà à moitié fait perdre des jours inutilement. La configuration du suivi d'une boutique piloté par la data suit la même logique de priorisation.

Configurer les événements clés : view_item, add_to_cart, purchase

Quatre événements suffisent pour piloter une boutique : view_item (vue produit), add_to_cart (ajout panier), begin_checkout (entrée dans le tunnel) et purchase (achat). Vouloir tout tracker d'un coup, c'est le moyen le plus sûr de ne rien finir.

Je les pose toujours dans cet ordre d'impact. Le purchase d'abord, parce que c'est lui qui alimente le chiffre d'affaires et les décisions pub. L'add_to_cart ensuite : il mesure l'intérêt réel pour un produit. Le begin_checkout pour repérer les fuites dans le tunnel. Le view_item en dernier, utile mais rarement décisif pour une boutique de taille modeste.

Caler les sept événements enhanced e-commerce dès le départ fait capoter la moitié des projets par excès de complexité. Ce n'est pas de la prudence, c'est de l'expérience.

Comment créer le déclencheur et la balise purchase dans GTM ?

On crée un déclencheur sur l'événement personnalisé « purchase » poussé dans le dataLayer, puis une balise GA4 de type « événement » nommée purchase, reliée à l'identifiant de mesure. Le déclencheur écoute, la balise envoie.

Dans GTM, les variables de couche de données permettent de récupérer value, currency, transaction_id et items depuis le dataLayer. Chaque paramètre GA4 pointe vers sa variable. Le centre d'aide Google Tag Manager détaille la création des variables de type « Variable de couche de données ». Une fois branché, un seul achat réel doit déclencher une seule balise purchase, pas deux.

Quels paramètres GA4 ne pas oublier (value, currency, items) ?

Les trois paramètres à ne jamais oublier : value (le montant), currency (la devise) et items (le détail produit). Un purchase sans l'un des trois est techniquement envoyé, mais commercialement inexploitable.

1. Envoyer un transaction_id unique Sans lui, GA4 ne peut pas dédoublonner, et un rechargement de la page de confirmation compte un second achat fantôme.
2. Toujours accompagner value de currency Un montant sans devise casse la conversion et le calcul du ROAS dans les campagnes.
3. Remplir le tableau items proprement Nom, identifiant et prix par produit alimentent les rapports et le lien Merchant Center.
4. Aligner les identifiants produit sur le catalogue Un item_id différent entre GA4 et Google Ads empêche le reciblage dynamique.
5. Tester avant d'activer les conversions Ads On ne branche une conversion d'achat sur Google Ads qu'une fois le purchase validé.

Si je ne devais regarder qu'un seul de ces cinq points en premier, ce serait le transaction_id : c'est lui qui conditionne la fiabilité de tout le reste.

Gérer le consentement avec Consent Mode v2

Sans Consent Mode v2 correctement câblé, une part réelle des transactions européennes n'est jamais collectée dans GA4. Ce n'est pas un détail réglementaire. C'est un trou direct dans le chiffre d'affaires suivi.

Le Consent Mode v2 relie le bandeau cookies (la CMP) à Google Tag Manager et ajuste le comportement des balises selon le choix du visiteur. Quand un internaute refuse, Google envoie des signaux anonymisés et modélise ensuite les conversions manquantes. Mais si le câblage est bâclé, aucune modélisation ne compense : les balises se bloquent, et les ventes correspondantes s'évaporent sans laisser de trace.

Pourquoi mes transactions disparaissent-elles sans consentement ?

Vos transactions disparaissent parce qu'une balise purchase bloquée par défaut, sans signal de consentement, n'envoie tout simplement rien à GA4. Le taux de refus devient alors un taux de ventes invisibles.

L'ampleur dépend du secteur. D'après le baromètre du taux de consentement cookies par secteur, le e-commerce plafonne souvent autour de 45 % d'acceptation, contre 75 % pour les médias. Autrement dit, sans Consent Mode v2 pour modéliser le reste, vous ne voyez qu'une fraction de vos ventes réelles. La CNIL rappelle le cadre français du consentement, qui impose un refus aussi simple que l'acceptation.

Le câblage pratique passe par GTM et une CMP certifiée Google. Le guide pour configurer Consent Mode v2 sans casser GA4 ni Ads détaille le réglage des quatre signaux de consentement, étape par étape.

Vérifier la qualité des données avant de s'y fier

On ne fait confiance à un tracking qu'après l'avoir testé transaction par transaction, jamais sur la foi d'une balise « verte » dans GTM. Le mode aperçu et Tag Assistant sont les deux outils de contrôle qui comptent.

Le mode aperçu de GTM (Preview) ouvre une session de test où l'on voit, en temps réel, quelles balises se déclenchent à chaque action. Vous ajoutez un produit au panier, vous regardez si add_to_cart part avec les bons paramètres. Vous passez une commande test, vous vérifiez que purchase envoie un transaction_id, une value et une currency cohérents. L'extension Tag Assistant confirme côté navigateur ce que GA4 reçoit vraiment. Ces deux outils sont complémentaires, pas interchangeables.

Comment tester un achat avec le mode aperçu de GTM ?

On lance le mode aperçu, on reproduit un achat complet du début à la fin, puis on vérifie dans le panneau de debug que la balise purchase se déclenche une seule fois avec tous ses paramètres remplis. Un paramètre vide signale un problème à corriger avant publication, sans exception.

Je recommande toujours un achat test réel, remboursé ensuite, plutôt qu'une simulation. Un vrai passage en caisse révèle les surprises du tunnel de paiement que le mode aperçu seul ne montre pas. Les mêmes statistiques de fréquentation à suivre ne valent rien si le purchase sous-jacent est faux.

Comment repérer un purchase compté en double ?

Un purchase compté en double se repère quand le chiffre d'affaires GA4 dépasse celui du back-office, ou quand un même transaction_id apparaît plusieurs fois dans les rapports. La cause la plus fréquente : le client recharge la page de confirmation, qui rejoue l'événement.

Voici les sept contrôles à passer systématiquement avant de déclarer un tracking fiable :

Les erreurs de tracking qui coûtent le plus cher

L'erreur la plus coûteuse n'est pas technique. Décider sur des données jamais vérifiées, voilà ce qui brûle le budget pub en silence pendant des mois, en pilotant sur un ROAS faux.

Juste derrière viennent le purchase dédoublé et le consentement non câblé, déjà traités. Mais une erreur plus subtile guette les boutiques qui grandissent : croire qu'il faut passer rapidement au tracking côté serveur parce que la documentation et les agences le recommandent.

Faut-il passer au tracking côté serveur ?

Pour une boutique dont le chiffre d'affaires mensuel reste sous environ 30 000 €, le tracking côté serveur est le plus souvent surdimensionné. Il ajoute un coût d'hébergement et une complexité de maintenance rarement justifiés à ce stade.

Le server-side consiste à faire transiter les données par son propre serveur avant GA4, ce qui améliore la résistance aux bloqueurs et le contrôle des données. Les analyses de l'HTTP Archive sur l'usage des conteneurs serveur montrent une adoption réelle, concentrée sur les gros sites. Pour une boutique modeste, le gain marginal de données ne couvre pas la facture ni le temps de configuration.

Je ne recommande le passage au serveur qu'au moment où les pertes dues aux bloqueurs deviennent chiffrables et pèsent réellement sur les arbitrages média. Pas avant. Le vrai levier d'abord : fiabiliser le tracking côté navigateur, propre et testé. Ce socle sain posé, le passage au serveur devient une évolution logique plutôt qu'une fuite en avant. Ce travail de fiabilisation en continu, aucun dirigeant ne le refait tous les mois à la main : c'est exactement le genre de contrôle que nous avons industrialisé dans Lysible.

Passer d'un tracking posé à un tracking sur lequel décider

Un tracking n'a de valeur qu'au moment où il change une décision. Tant qu'on le regarde sans agir, c'est un coût. Dès qu'il dit quel produit pousser ou quel canal couper, c'est un investissement.

Le seuil est net. À partir du moment où les données d'achat sont fiables et stables sur plusieurs semaines, on peut enfin comparer les canaux, calculer un vrai coût d'acquisition et arbitrer le budget sans deviner. Avant ce seuil, chaque décision repose sur du sable. Après, le même temps passé sur GA4 rapporte des euros concrets. C'est tout l'enjeu de relier Search Console, GA4 et les ventes dans une lecture unique, ce que Lysible centralise pour les petites structures qui veulent décider sans prestataire permanent. Votre prochaine étape concrète : passer un achat test cette semaine et vérifier que le purchase est propre.