dataLayer e-commerce GA4 : le guide complet (items, add_to_cart, purchase)

En bref : le dataLayer e-commerce GA4 est la structure qui décrit chaque étape du tunnel d'achat (vue produit, ajout au panier, checkout, achat) sous forme d'événements standardisés. Chacun s'appuie sur un tableau items commun, qui liste les produits avec leur identifiant, leur nom, leur prix et leur quantité, plus une devise et une valeur. C'est lui qui alimente les rapports de monétisation de GA4.

Un tunnel e-commerce, c'est là que se joue votre chiffre d'affaires. Et pourtant, c'est aussi la partie du tracking où je vois le plus d'approximations : un add_to_cart maison mal nommé, un tableau items à moitié rempli, un purchase compté deux fois. Résultat, des rapports GA4 qui ne reflètent pas la réalité de vos ventes.

La bonne nouvelle : GA4 attend une structure précise, documentée, et une fois qu'on l'a comprise, elle se réutilise partout. Dans ce guide, je vais vous détailler le dataLayer e-commerce GA4 de bout en bout : le tableau items, les événements du tunnel dans le bon ordre, un exemple complet de purchase, et les pièges à éviter. On y va.

Qu'est-ce que le dataLayer e-commerce GA4 ?

Le dataLayer e-commerce est la partie de votre dataLayer dédiée au tunnel d'achat. Concrètement, c'est un ensemble d'événements normalisés que vous poussez à chaque étape clé : consultation d'un produit, ajout au panier, entrée en checkout, paiement, achat.

Pourquoi « normalisés » ? Parce que GA4 ne reconnaît ces événements que s'ils portent les noms attendus (view_item, add_to_cart, purchase) et la structure attendue (un objet ecommerce contenant un tableau items). Un événement maison appelé ajout_panier avec vos propres paramètres ne remplira jamais les rapports de monétisation de GA4. Il faut parler la langue de GA4.

En effet, c'est tout l'enjeu : ces rapports (revenus, produits les plus vendus, taux de conversion du tunnel) ne se remplissent que si le dataLayer envoie exactement ce que GA4 sait lire.

Le tableau items, la brique commune à tous les événements

Avant les événements, parlons de la brique qu'ils partagent tous : le tableau items. Il liste les produits concernés par l'événement, et on le retrouve dans presque tous les événements du tunnel, de view_item à purchase.

Voici sa structure type, sur un produit :

items: [{
  item_id: 'SKU-123',              // identifiant produit (requis*)
  item_name: 'T-shirt col rond',   // nom produit (requis*)
  item_brand: 'MaMarque',
  item_category: 'Vêtements',
  item_variant: 'Bleu / M',
  price: 29.90,
  quantity: 1
}]

À noter (*) : GA4 demande au minimum item_id ou item_name. En pratique, renseignez les deux, plus price et quantity, sinon vos rapports produits seront incomplets.

Gardez à l'esprit une règle qui évite beaucoup d'ennuis : le même produit doit garder le même item_id d'un bout à l'autre du tunnel. Si view_item envoie SKU-123 et que purchase envoie 123-SKU, GA4 considère qu'il s'agit de deux produits différents et ne relie pas la vue à l'achat.

Les événements e-commerce GA4 dans l'ordre du tunnel

GA4 propose une série d'événements e-commerce recommandés. Vous n'êtes pas obligé de tous les implémenter, mais plus votre tunnel est couvert, plus vos rapports sont exploitables. Les voici dans l'ordre logique du parcours.

Avant chaque push, une bonne pratique : vider l'objet ecommerce avec dataLayer.push({ ecommerce: null }). Cela évite que les données d'un événement se mélangent au suivant, un bug classique et sournois.

view_item_list et view_item

view_item_list se déclenche à l'affichage d'une liste de produits (une page catégorie, des résultats de recherche). view_item se déclenche à la consultation d'une fiche produit :

window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: 'view_item',
  ecommerce: {
    currency: 'EUR',
    value: 29.90,
    items: [{ item_id: 'SKU-123', item_name: 'T-shirt col rond', price: 29.90, quantity: 1 }]
  }
});

add_to_cart et view_cart

add_to_cart se déclenche à l'ajout au panier, view_cart à la consultation du panier. La structure est la même, avec la quantité ajoutée :

window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: 'add_to_cart',
  ecommerce: {
    currency: 'EUR',
    value: 59.80,
    items: [{ item_id: 'SKU-123', item_name: 'T-shirt col rond', price: 29.90, quantity: 2 }]
  }
});

begin_checkout et add_payment_info

begin_checkout marque l'entrée dans le tunnel de commande, add_payment_info l'ajout d'un moyen de paiement. Ce sont des jalons précieux pour mesurer les abandons étape par étape :

window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: 'begin_checkout',
  ecommerce: {
    currency: 'EUR',
    value: 59.80,
    items: [{ item_id: 'SKU-123', item_name: 'T-shirt col rond', price: 29.90, quantity: 2 }]
  }
});

purchase

L'événement roi, celui qui remonte le chiffre d'affaires. Il mérite sa propre section, parce que c'est là que se concentrent les erreurs les plus coûteuses.

Exemple complet : un purchase de bout en bout

Le purchase est le plus riche des événements. En plus des items, il porte des informations de transaction : un identifiant, une valeur, la TVA, les frais de port, un éventuel code promo.

window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: 'CMD-2026-000123',   // identifiant unique de commande (requis)
    currency: 'EUR',
    value: 59.80,                         // valeur de la transaction
    tax: 9.97,
    shipping: 4.90,
    coupon: 'BIENVENUE10',
    items: [
      { item_id: 'SKU-123', item_name: 'T-shirt col rond', price: 29.90, quantity: 2 }
    ]
  }
});

Deux points méritent votre attention. D'abord, le transaction_id est requis et doit être unique : c'est lui qui permet à GA4 de dédupliquer. Sans lui, ou s'il se répète, vos achats risquent d'être comptés plusieurs fois. Ensuite, la value : décidez d'une convention claire (généralement le montant des produits, frais de port inclus ou non selon votre choix) et tenez-vous-y sur tout le tunnel, sinon vos analyses de valeur deviennent incohérentes.

Les pièges e-commerce les plus fréquents

Le dataLayer e-commerce concentre quelques classiques que je retrouve sur la plupart des audits :

• Le tableau items qui part vide, souvent après une migration : les données produit ne sont plus disponibles au moment du push, et vos revenus sont sous-estimés.
• La value manquante sur le purchase : les achats sont comptés, mais le chiffre d'affaires reste à zéro.
• Les item_id incohérents d'une étape à l'autre : GA4 ne relie plus la vue à l'achat.
• L'oubli de vider l'objet ecommerce : les données d'un événement fusionnent avec le suivant.
• Le purchase rejoué à chaque rechargement de la page de confirmation : sans transaction_id fiable, chaque F5 ajoute une vente fantôme.

Je détaille les symptômes et les correctifs de plusieurs de ces cas dans mon article sur les erreurs de dataLayer qui faussent GA4. Le fil rouge reste le même : ces bugs ne déclenchent aucune alerte, ils polluent vos données en silence.

Comment recetter son dataLayer e-commerce

Un tunnel, ça se recette de bout en bout. Concrètement : vous rejouez le parcours complet, de la fiche produit jusqu'à la commande, et vous vérifiez à chaque étape que le bon événement se déclenche, avec le bon tableau items et les bonnes valeurs. Le mode Preview de GTM et le DebugView de GA4 sont vos deux alliés pour ça. Je décris la méthode pas à pas dans mon article sur la recette du dataLayer.

Le hic, vous le connaissez maintenant : ce tunnel change à chaque évolution du site, et une recette manuelle ne se refait pas intégralement à chaque mise en prod. C'est précisément ce que MayIA° automatise : il rejoue le tunnel e-commerce comme un vrai client et vérifie chaque événement du dataLayer en continu, pour attraper la régression avant qu'elle ne fausse vos revenus.

Pour conclure

Si vous ne devez retenir qu'une chose : le dataLayer e-commerce GA4 n'a rien de sorcier une fois qu'on tient la logique. Un tableau items cohérent, des événements normalisés dans l'ordre du tunnel, un purchase propre avec son transaction_id unique, et vos rapports de monétisation deviennent fiables.

Le vrai travail n'est pas de le poser une fois, c'est de garantir qu'il reste juste au fil des mises en production. Un tunnel qui déraille en silence, c'est du chiffre d'affaires qu'on ne mesure plus.

Vous voulez sécuriser le tracking de votre tunnel avant une refonte ou un pic de trafic ? Parlez-en à l'équipe MayIA°, on regarde ça ensemble.

FAQ

Quels événements e-commerce GA4 sont obligatoires ?

Aucun n'est techniquement obligatoire, mais le purchase est indispensable pour mesurer le chiffre d'affaires. Les autres (view_item, add_to_cart, begin_checkout) sont recommandés : plus le tunnel est couvert, plus on analyse les abandons étape par étape.

Faut-il vider l'objet ecommerce entre deux événements ?

Oui, c'est une bonne pratique. Pousser dataLayer.push({ ecommerce: null }) avant chaque nouvel événement évite que les données d'un événement se mélangent au suivant et faussent les rapports.

Que doit contenir le tableau items au minimum ?

Au minimum un item_id ou un item_name par produit. Pour des rapports exploitables, ajoutez price et quantity, idéalement item_category et item_brand, et gardez le même item_id pour un produit sur tout le tunnel.

Pourquoi mon purchase est-il compté deux fois ?

Le plus souvent parce que l'événement se redéclenche au rechargement de la page de confirmation, ou parce que le transaction_id n'est pas unique. GA4 s'appuie sur ce transaction_id pour dédupliquer les achats.

Le dataLayer e-commerce fonctionne-t-il en server-side ?

Oui. La même structure d'événements et de tableau items peut être envoyée via un tracking server-side (Server-Side GTM). La logique reste identique, seul le mode d'envoi change.