dataLayer e-commerce : variables GA4 et valeur Google Ads

Le dataLayer fait partie des fondations d’une installation Google Tag Manager : le site y dépose ses données de vente, sans rien envoyer lui-même. Google Tag Manager (GTM) lit ces données, puis ses balises les envoient aux outils de mesure. GTM sait lire d’autres sources, mais toutes ne sont pas fiables pour le montant d’une commande.

Lire le montant affiché ou le recevoir du site ?

Pour envoyer le montant d’une commande à une balise de conversion, vous avez deux chemins. Le premier lit le texte affiché sur la page de confirmation, par exemple dans l’élément .total-price. Pour un besoin simple, cette lecture peut suffire. Mais elle dépend du nom de l’élément, du format du prix et du moment où il s’affiche.

Le second chemin part du système qui enregistre la commande. Le code du paiement, un module de votre boutique en ligne ou un serveur publie value: 187.50 dans un format convenu. Le montant vient alors de la source, pas de l’écran.

Si le développeur renomme .total-price en .order-summary__amount, la lecture peut renvoyer une valeur vide, bloquer la balise ou envoyer une valeur de secours. Ce que Google Ads reçoit alors dépend de la façon dont la variable et la balise sont configurées. Prévoyez une alerte sur les achats reçus sans montant.

Le plus sûr est de faire publier le montant par le site dans le dataLayer. Il ne dépend plus de l’affichage, mais rien ne garantit pour autant qu’il soit juste. Une erreur de format peut fausser le montant ; un consentement mal réglé peut empêcher son envoi.

Créer la couche de données sans l’écraser

Le code d’installation standard de GTM crée déjà le dataLayer. Ajoutez vous-même window.dataLayer = window.dataLayer || []; avant ce code si le site doit envoyer des données plus tôt, ou si votre installation est personnalisée. Cette ligne crée la liste si elle n’existe pas, et garde sinon celle déjà en place.

Ensuite, ne remplacez plus la liste par window.dataLayer = [] ou par un autre tableau. Ajoutez les messages avec dataLayer.push(). Un remplacement peut couper l’écoute de GTM ou perdre des messages en attente, selon le moment où il survient. L’ordre réel des messages se contrôle dans Tag Assistant, pas seulement dans le code.

Quels champs envoyer à GA4 et à Google Ads ?

Pour un achat, Google Analytics 4 (GA4) attend l’événement purchase avec ses articles. Google Ads attend autre chose : les champs reliés à votre action de conversion. Donnez au développeur une liste de champs pour chaque outil.

Le trajet est simple : le système de commande publie dans le dataLayer, GTM lit les champs, puis une balise GA4 ou Google Ads les envoie. Importer dans Google Ads un événement GA4 est un autre trajet, avec ses propres réglages.

Avec un objectif standard, reliez le montant à une action principale utilisée par la campagne. Une action secondaire sert à l’observation, sauf si un objectif personnalisé l’utilise pour les enchères. Pour un achat, choisissez le comptage « Toutes », qui compte chaque achat distinct fait après un clic. Enfin, Google Ads attribue les conversions qui surviennent dans la fenêtre choisie, soit 90 jours au plus après un clic.

Les campagnes Shopping et Performance Max s’appuient, pour vos produits, sur le catalogue envoyé à Google dans le Merchant Center. Le dataLayer sert, lui, à la mesure et, selon les réglages et le consentement, aux audiences ou au remarketing.

Les champs de l’achat, outil par outil

Un transaction_id vide est un piège. Sur un site, GA4 déduplique les achats portant le même identifiant pour un même utilisateur : des achats à identifiant vide partagent donc le même identifiant, et GA4 peut en écarter certains. Google Ads reconnaît un doublon au sein d’une même action seulement, et à condition que la balise reçoive ce champ.

La devise s’écrit en code à trois lettres (norme ISO 4217), comme EUR, même si vous ne vendez qu’en euros. Google Ads convertit ensuite le montant reçu dans la devise de facturation du compte.

Pour relier une vente au catalogue, gardez un item_id stable et notez sa correspondance avec les identifiants du Merchant Center, pays et langues compris. Chaque article doit avoir item_id ou item_name ; le mieux est d’envoyer les deux quand ils existent. Les autres champs utiles sont les suivants :

• item_variant désigne la déclinaison réellement vendue.
• item_brand indique la marque du produit.
• item_category à item_category5 décrivent les catégories, de la plus large à la plus précise.
• item_list_id et item_list_name identifient la liste d’origine, quand elle est réellement connue.

Aucune de ces informations ne doit contenir de donnée personnelle. Pour calculer une marge, il vous faut en plus le coût de chaque produit, car items et price ne donnent pas le bénéfice.

Que mettre dans value ?

Dans GA4, value est la somme de price × quantity pour tous les articles, sans tax ni shipping. Si une remise s’applique à un article, price contient le prix unitaire déjà remisé. Le champ discount peut alors indiquer la remise unitaire. Par exemple, si un client achète deux articles à 40 € après remise et paie 6 € de port, value vaut 80, pas 86.

Cette règle de GA4 ne fixe pas le montant envoyé à Google Ads. Une action Google Ads peut recevoir le chiffre d’affaires, la marge ou une autre valeur documentée. Gardez une seule convention par action et écrivez-la. La marge ne se justifie que si vous connaissez le coût de chaque produit. L’erreur est de mélanger deux conventions sans savoir laquelle sert aux enchères.

Le coupon de la commande et celui d’un article sont deux champs distincts. Une promotion affichée sur votre site se suit avec view_promotion quand elle est vue et select_promotion quand elle est cliquée. Reportez promotion_id ou promotion_name dans les événements suivants pour suivre le parcours. Un coupon utilisé ne prouve pas, à lui seul, que la promotion a été vue.

Des nombres, pas du texte

Envoyez value, price et quantity comme des nombres, pas comme du texte. Écrit entre guillemets, "187.50" n’est pas le nombre 187.50. Avec un mauvais type, la donnée peut être ignorée, mal lue ou rejetée, selon la façon dont elle est collectée. Si quantity manque, GA4 compte 1. Corrigez le type à la source ; une transformation dans GTM reste possible si elle est écrite, testée et surveillée.

Envoyer un achat dans GTM, étape par étape

Suivez les étapes dans cet ordre.

1. Vider l’objet précédent. Avant chaque nouveau message e-commerce, le site doit envoyer dataLayer.push({ ecommerce: null }).
2. Publier un message complet. Le message d’achat ressemble par exemple à dataLayer.push({ event: 'purchase', ecommerce: { transaction_id: 'CMD-8042', value: 187.50, currency: 'EUR', items: […] } }).
3. Relier chaque champ à sa destination. Créez les variables ecommerce.transaction_id, ecommerce.value, ecommerce.currency et ecommerce.items. Notez lesquelles vont à la balise GA4 et lesquelles vont à la balise Google Ads.
4. Contrôler l’envoi. Vérifiez dans Tag Assistant le déclencheur et les valeurs lues, puis dans l’onglet Réseau ce qui part vraiment du navigateur. Les données traitées doivent enfin correspondre à la commande d’origine.

Le même soin vaut pour les étapes qui précèdent l’achat. Envoyez add_to_cart quand l’ajout au panier est confirmé, pas au simple clic. Gardez les identifiants produit cohérents. Les champs price et quantity doivent refléter le prix et la quantité à chaque étape, remises et modifications du panier comprises. À begin_checkout, la liste items doit correspondre au panier réellement validé. Envoyez add_shipping_info et add_payment_info seulement quand ces étapes sont atteintes.

Pourquoi vider ecommerce d’abord ?

Google place cette remise à zéro avant chaque événement e-commerce dans ses exemples. Sans elle, un champ d’un message précédent peut encore être lu quand le nouveau message ne le remplace pas. Le résultat dépend du format et de la version de la variable. Contrôlez en mode aperçu qu’aucune ancienne valeur ne subsiste.

Variable de couche de données : version 1 ou 2 ?

Dans GTM, la variable qui lit le dataLayer existe en deux versions, qui traitent différemment les points dans le nom d’une clé. La Version 1 les lit comme de simples caractères : ecommerce.value cherche une clé qui a exactement ce nom. La Version 2 les lit comme des niveaux : ecommerce.value va chercher value à l’intérieur de ecommerce.

Avec l’objet imbriqué montré plus haut, choisissez la Version 2 par défaut. La Version 1 peut convenir à une structure plate dont les clés contiennent des points. Aucune des deux ne dispense de vider l’objet entre deux messages. Notez ce choix dans la documentation du conteneur.

Tester l’achat de bout en bout

Chaque outil montre une étape du trajet :

• La console du navigateur montre la liste des messages du dataLayer.
• Tag Assistant montre le message traité, le déclencheur et la balise déclenchée.
• L’onglet Réseau montre ce qui a vraiment quitté le navigateur.
• DebugView montre les événements d’un appareil passé en mode debug, ce qui n’est pas le rapport Temps réel.

Ne testez pas seulement la page de confirmation. Couvrez aussi les cas suivants :

• Le retour depuis le prestataire de paiement et la navigation sans rechargement de page.
• Un panier vide, un coupon et une autre devise.
• Un rafraîchissement de la confirmation, un remboursement et une annulation.
• Un refus de consentement, un bloqueur de publicité et plusieurs navigateurs.

Deux messages purchase dans le dataLayer ne prouvent pas un double comptage. Vérifiez que le même transaction_id non vide arrive dans GA4, puis dans chaque action Google Ads concernée. Refaites ces tests à chaque changement du site, du conteneur GTM ou des réglages de GA4 et Google Ads, paiement et consentement compris.

Documenter les données et leurs destinataires

Documentez les données que le site publie et les champs attendus par GA4 ou Google Ads. Une personne en est responsable et valide chaque changement ; d’autres l’appliquent. Tout changement est testé avant la mise en ligne, puis surveillé après. Sinon, une panne risque de n’apparaître que dans le rapport du mois suivant.

Pour chaque événement, la documentation précise ces points :

• Elle nomme son responsable et les outils qui le reçoivent.
• Elle indique son déclencheur et sa version.
• Elle donne le type et les valeurs autorisées de chaque champ.
• Elle prévoit le cas d’un champ vide.

La documentation couvre aussi la vie privée. N’envoyez ni nom, ni e-mail, ni téléphone dans les paramètres ordinaires de GA4. Un User-ID opaque reste possible dans le cadre prévu par Google. Les fonctions de Google prévues pour les données client suivent un cadre à part. Dans GTM, définissez l’état du consentement avant les balises déclenchées par le même événement.

Les limites de GA4 à vérifier avant la mise en ligne

Google indique une limite de 25 paramètres par événement. Un article peut en recevoir jusqu’à 27 en plus des champs prévus par Google. La limite de 100 caractères par valeur comporte des exceptions, notamment pour les URL et le titre de page. GA4 n’enregistre pas les paramètres qui dépassent ces limites. Ne comptez ni sur une valeur coupée à 100 caractères, ni sur une alerte dans DebugView.

Pour utiliser un paramètre personnalisé dans les rapports, déclarez aussi une définition personnalisée. Une propriété standard accepte 50 dimensions personnalisées de portée événement, 10 de portée article et 50 métriques personnalisées. N’y placez pas d’identifiants uniques ni d’horodatages. Trop de valeurs différentes peuvent être regroupées sous la ligne « (other) » et brouiller la lecture. Gardez seulement les paramètres qui répondent à une vraie question.

Questions fréquentes

Vincent Duquesne

Expert Google Ads Certifié depuis 2011 : j’ai audité et restructuré des centaines de comptes dans des dizaines de thématiques différentes. +20M€ gérés.

Google Partner Premier 2026