Suivi e-commerce GA4 via GTM : guide 2026

Neuf implémentations de suivi e-commerce GA4 via GTM sur dix que j’audite sont cassées. Pas “un peu perfectibles” : cassées. Un items array vide, un transaction_id qui se duplique, un purchase qui part deux fois, ou une value à null qui transforme votre chiffre d’affaires en zéro dans les rapports. Le pire, c’est que tout a l’air de fonctionner : les événements remontent, le temps réel s’anime, tout le monde est content. Puis quelqu’un compare le CA de GA4 à celui de Stripe et découvre 30 % d’écart. Ce guide reprend le sujet à zéro et vous donne l’implémentation qui tient : la structure exacte du dataLayer, la configuration GTM pas à pas, les cinq erreurs qui faussent vos rapports achat, et comment étendre le tout vers le server-side pour récupérer les signaux que les bloqueurs vous mangent.

Si le dataLayer est encore flou pour vous, lisez d’abord le guide complet du dataLayer GTM : c’est la fondation sur laquelle tout le reste repose. Et si votre propriété GA4 n’est pas encore en place, commencez par configurer GA4 depuis zéro.

Le suivi e-commerce GA4 n’est pas l’Enhanced Ecommerce de Universal Analytics

Première chose à intégrer, parce qu’elle conditionne tout le reste : oubliez ce que vous saviez d’Universal Analytics. L’Enhanced Ecommerce que vous configuriez via le plugin GTM dédié n’existe plus. Mort, enterré, disparu avec UA. GA4 a changé de paradigme.

Concrètement, il n’y a plus de “plugin” ni de type de tag spécial. Tout passe par ce que Google appelle les recommended events, une liste d’événements normalisés (view_item, add_to_cart, purchase, etc.), chacun accompagné d’un paramètre items qui décrit les produits concernés. Vous poussez ces événements dans le dataLayer, GTM les lit et les renvoie à GA4 via un simple tag GA4 Event. C’est à la fois plus simple (un seul mécanisme) et plus exigeant (si votre items array est mal formé, GA4 ne vous le dira pas, il avalera la donnée en silence).

L’autre grand changement : la structure de l’objet items. En UA, on parlait de id, name, category. En GA4, les noms ont changé : item_id, item_name, item_category. Copier-coller un ancien dataLayer UA est la façon la plus rapide de tout casser.

Les recommended events à implémenter

Vous n’êtes pas obligé de tout tracker le premier jour. Voici les événements par ordre de priorité, du strict minimum au funnel complet.

Événement	Déclenché quand	Priorité
`view_item_list`	Affichage d’une liste (catégorie, recherche)	Full funnel
`select_item`	Clic sur un produit dans une liste	Full funnel
`view_item`	Affichage d’une fiche produit	Recommandé
`add_to_cart`	Ajout au panier	Minimum
`remove_from_cart`	Retrait du panier	Full funnel
`begin_checkout`	Entrée dans le tunnel de commande	Recommandé
`add_payment_info`	Saisie du moyen de paiement	Full funnel
`purchase`	Commande validée	Minimum

Si vous n’avez le budget que pour deux événements, implémentez add_to_cart et purchase. Ils vous donnent le taux d’ajout au panier, le CA, et suffisent à alimenter vos audiences remarketing et vos conversions Google Ads. Le reste enrichit l’analyse du funnel, mais purchase est celui qui compte pour votre facturation : soignez-le en priorité.

La structure exacte du dataLayer

Voici le cœur du sujet. Deux exemples complets et commentés, prêts à adapter. Retenez la règle d’or : on pousse toujours un ecommerce: null juste avant, pour vider l’objet précédent et éviter que les données d’un événement ne bavent sur le suivant.

add_to_cart

window.dataLayer = window.dataLayer || [];
dataLayer.push({ ecommerce: null }); // on vide l'objet précédent
dataLayer.push({
  event: "add_to_cart",
  ecommerce: {
    currency: "EUR",
    value: 29.90,
    items: [
      {
        item_id: "SKU_12345",
        item_name: "T-shirt coton bio",
        item_brand: "MaMarque",
        item_category: "Vêtements",
        price: 29.90,
        quantity: 1,
        coupon: "ETE10"     // optionnel
      }
    ]
  }
});

purchase

dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: "purchase",
  ecommerce: {
    transaction_id: "CMD-2026-08-0042", // OBLIGATOIRE et UNIQUE
    currency: "EUR",
    value: 59.80,      // total, hors ou avec frais selon votre choix, mais soyez cohérent
    tax: 9.97,
    shipping: 4.90,
    coupon: "ETE10",
    items: [
      {
        item_id: "SKU_12345",
        item_name: "T-shirt coton bio",
        item_brand: "MaMarque",
        item_category: "Vêtements",
        price: 29.90,
        quantity: 2
      }
    ]
  }
});

Les paramètres item_id, item_name, price, quantity et currency sont votre socle non négociable. Les optionnels (item_brand, item_category, coupon, item_variant) enrichissent vos rapports produit, mais un item_id manquant suffit à rendre une ligne de commande inexploitable. Un point sur value : c’est un nombre, jamais une chaîne. "59.80" entre guillemets est une des erreurs les plus fréquentes, et GA4 traitera votre valeur comme absente.

Configuration GTM pas à pas

Une fois le dataLayer en place côté site, le travail dans GTM est mécanique.

Créez une variable dataLayer nommée ecommerce, version 2, qui récupère l’objet ecommerce complet du push.
Créez un déclencheur d’événement personnalisé pour chaque événement : type “Événement personnalisé”, nom de l’événement purchase (puis add_to_cart, etc.).
Créez un tag GA4 Event : type d’événement purchase, et dans les paramètres, ajoutez items en le mappant sur {{ecommerce}}. Astuce 2026 : activez l’option “Envoyer les données e-commerce” et sélectionnez “Variable de couche de données” pour que GTM récupère automatiquement la structure items, sans mapping manuel champ par champ.
Associez le tag au déclencheur correspondant.
Testez en mode Preview : ajoutez un produit, validez une commande de test, et vérifiez dans l’onglet GA4 du Tag Assistant que l’événement part avec un items array peuplé et un transaction_id présent.

Le mode Preview est votre meilleur ami. Ne publiez jamais un container e-commerce sans avoir vu, de vos yeux, le purchase partir avec la bonne structure sur une vraie commande de test.

Les 5 erreurs qui cassent vos rapports achat

J’ai audité assez de comptes pour établir un top 5. Les voici, par fréquence décroissante.

1. L’items array vide ou absent. L’événement purchase part, GA4 enregistre une transaction, mais aucun produit n’y est rattaché. Vos rapports “Achats par article” restent désespérément vides. Cause classique : le dataLayer est poussé après le déclenchement du tag (course de timing), ou le tableau items est construit à partir d’un panier déjà vidé après paiement.

2. Le transaction_id dupliqué. GA4 déduplique les achats sur cet identifiant. Si votre page de confirmation se recharge et repousse le même transaction_id, GA4 ignore le doublon (bonne nouvelle) mais si vous générez un ID différent à chaque rechargement, vous comptez plusieurs fois la même vente. Utilisez toujours le numéro de commande réel, jamais un timestamp ou un random.

3. La currency absente. Sans devise, GA4 ne peut pas convertir ni consolider vos revenus, et la value est ignorée. La currency doit être présente au niveau ecommerce (format ISO 4217 : EUR, USD).

4. L’événement compté deux fois, client-side et server-side. Quand vous ajoutez une couche server-side (voir plus bas) sans couper l’envoi client, votre purchase part par les deux chemins. Résultat : CA doublé. Choisissez un seul chemin d’envoi par événement de conversion.

5. La value à null ou en chaîne de caractères. value: null, value: "0" ou value: "" : dans les trois cas, votre chiffre d’affaires s’effondre à zéro dans les rapports alors que les transactions, elles, sont bien comptées. Vérifiez que value est un nombre strictement positif.

Étendre vers le server-side

Votre purchase client-side fonctionne. Bravo. Mais il a un talon d’Achille : il vit dans le navigateur, donc les bloqueurs de pub, l’ITP de Safari et les extensions de confidentialité en effacent une partie avant qu’il n’atteigne Google. Selon les audiences, on parle de 15 à 30 % de signaux perdus.

La parade, c’est d’envoyer aussi le purchase depuis un serveur GTM (sGTM), qui reçoit la donnée en first-party et la relaie à GA4 hors de portée des bloqueurs. En 2026, 67 % des sites e-commerce avancés que je croise ont franchi le pas, parce que ces 15 à 30 % de conversions récupérées changent directement la rentabilité affichée de leurs campagnes.

Le principe : votre événement purchase part vers votre endpoint sGTM plutôt que directement vers GA4, le serveur enrichit et déduplique, puis transmet. Attention au piège numéro 4 ci-dessus : quand vous basculez en server-side, coupez l’envoi client-side du même événement, ou dédupliquez proprement. Pour la mise en place complète, j’ai détaillé la démarche dans GTM Server-Side : pourquoi et comment migrer. Si vous êtes sur Shopify, la couche server native est traitée dans Shopify GA4 server-side. Et pour renvoyer ce même signal purchase à Google Ads sans dépendre du cookie tiers, regardez les Enhanced Conversions en server-side.

Récap actionnable

Si vous ne deviez retenir que l’essentiel : implémentez d’abord add_to_cart et purchase proprement, avec un items array peuplé, une currency présente, une value numérique et un transaction_id unique tiré de votre vrai numéro de commande. Testez chaque événement en mode Preview sur une commande réelle avant de publier. Comparez ensuite votre CA GA4 à votre back-office : un écart supérieur à 5 % est le symptôme d’une des cinq erreurs ci-dessus. Une fois le client-side fiable, passez au server-side pour récupérer les 15 à 30 % de signaux que les bloqueurs vous prennent. C’est dans cet ordre, et pas l’inverse, qu’on construit un tracking e-commerce qui tient.