Tracking Magento, Adobe Commerce et GA4 : dataLayer et GTM en 2026

Magento Open Source et Adobe Commerce proposent une configuration GA4 de base, mais elle ne couvre pas à elle seule un tracking e-commerce complet : les événements détaillés, le dataLayer propre et la déduplication demandent presque toujours une extension ou du code. Le choix dépend de votre thème (Luma, Hyvä ou headless), du nombre de vues et du niveau de contrôle attendu. Cette fiche fait le tour de ces options, puis renvoie vers les pages détaillées. Pour un accompagnement, voir le consultant analytics e-commerce.

Ce que Magento et Adobe Commerce fournissent nativement

Dans l’administration, la configuration GA4 se trouve sous Stores > Settings > Configuration, puis Sales > Google API, dans la section Google GTag. Adobe documente cette partie dans sa page Google Analytics. Ce module repose sur gtag et pousse des événements e-commerce de base. La section Enhanced Ecommerce de cette même documentation concerne encore Universal Analytics, aujourd’hui retiré par Google : ne la suivez pas pour une nouvelle installation.

Deux limites à garder en tête. D’abord, la couverture d’événements varie selon la version : les notes de la version 2.4.8 mentionnent des corrections sur add_to_cart pour les produits configurables et sur les montants de transaction envoyés via gtag, ce qui montre que ces points ont posé problème. Ensuite, la configuration native ne donne pas de contrôle fin sur le dataLayer, ni de passerelle server-side. Vérifiez les notes de version de votre instance avant de vous y fier.

Les extensions GTM et GA4 du marché

Le Marketplace Adobe Commerce regorge d’extensions. Les plus souvent citées sont listées ci-dessous. Les positionnements viennent des pages des éditeurs : vérifiez chaque fiche et la compatibilité avec votre version 2.4.x avant installation.

Extension	Positionnement annoncé	Point d’attention
Magefan	GTM et GA4, version gratuite et version payante étendue	Confirmer ce que couvre la version gratuite
WeltPixel	GA4 avec GTM et server-side, éditions Standard et Pro	Support Hyvä annoncé sur l’édition Pro
Anowave	GA4 Enhanced Ecommerce avec gestion de tags GTM	Vérifier le périmètre des événements
Scommerce Mage	GTM GA4 Enhanced Ecommerce, avec remarketing et Meta	Peu d’informations de compatibilité publiées
TAGGRS	dataLayer server-side pour GA4 (view_item, add_to_cart, begin_checkout, purchase)	Version à choisir selon Hyvä ou Luma

Une extension ne remplace pas la recette. Dans tous les cas, comparez les événements poussés avec le parcours réel, et contrôlez qu’il n’existe qu’une seule source de purchase.

Hyvä, PWA Studio et headless

Hyvä est rendu côté serveur. Les modules PHP peuvent donc y injecter leurs balises, à condition d’utiliser la version compatible : les snippets écrits pour Luma peuvent casser sur les boutiques Hyvä ou soumises à une politique de sécurité de contenu (CSP). Certains éditeurs, comme Amasty, annoncent un support Hyvä sur toutes leurs éditions ; d’autres le réservent à une édition payante.

Sur une vitrine headless ou PWA Studio, l’application React ne reçoit pas le HTML généré par un module PHP. Le dataLayer doit alors être alimenté depuis le code frontend. C’est mon inférence à partir des sources consultées, pas une règle documentée : testez-la sur votre architecture avant de l’annoncer comme acquise.

Pièges GA4 propres à Magento

• Produits configurables : le produit parent et la déclinaison enfant ne doivent pas se compter deux fois. Choisissez un identifiant (SKU enfant ou parent) et gardez-le sur tous les événements.
• Multi-store et multi-devise : un flux GA4 par vue de boutique, ou une propriété partagée avec filtres, mais jamais un mélange. Envoyez la devise avec chaque purchase.
• B2B : les prix affichés peuvent dépendre du compte client. Mesurez le prix payé, pas le prix catalogue.
• Paiement redirigé : PayPal ou certains moyens de paiement externes font sortir l’utilisateur du site. La conversion doit être déclenchée à la page de succès, avec un transaction_id unique pour éviter les doublons au rechargement.
• HT et TTC : Magento permet d’afficher les prix hors ou avec taxes. Fixez une convention, par exemple value TTC et tax séparé, et documentez-la.

Extrait : un purchase poussé sur la page de succès

Le code suivant suppose que la page de succès expose les données de commande dans le dataLayer, par exemple via un bloc de template. Les noms de variables sont à adapter à votre thème.

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ ecommerce: null });
window.dataLayer.push({
  event: 'purchase',
  ecommerce: {
    transaction_id: '000000123', // identifiant de commande unique
    value: 149.90,              // TTC
    tax: 24.98,
    shipping: 6.90,
    currency: 'EUR',
    items: [
      { item_id: 'SKU-ENFANT-M-BLEU', item_name: 'Veste', item_variant: 'M / Bleu', price: 129.00, quantity: 1 }
    ]
  }
});

La ligne ecommerce: null vide l’objet précédent, une bonne pratique GA4 pour éviter de reprendre des données d’un événement antérieur. Le transaction_id doit rester identique entre GA4, le sGTM et les autres plateformes.

Consent Mode v2

Magento dispose d’un mode de restriction des cookies, mais il ne suffit pas à répondre aux exigences de Consent Mode v2. Il faut un CMP qui envoie l’état par défaut denied avant le chargement de GTM, et qui met à jour le consentement lors du choix de l’utilisateur. Sans cet ordre, les balises partent avant le consentement. Pour le cadre, voir Consent Mode v2 en pratique et le comparatif des CMP.

Server-side

Le server-side permet d’envoyer les événements depuis votre propre domaine, de limiter la perte liée aux bloqueurs et de déduper proprement avec Meta et Google Ads. Un sGTM peut être alimenté par le dataLayer server-side de TAGGRS ou par une installation sur Stape. Le comparatif des hébergeurs est dans Stape vs Addingwell, et le principe général est détaillé dans Stape et le server-side.

Recette

1. Listez les événements poussés par le module natif et par chaque extension installée, pour repérer les doublons.
2. Testez le parcours complet : catégorie, produit configurable, panier, checkout, paiement redirigé et page de succès.
3. Vérifiez le transaction_id : une commande, un seul purchase, même après rechargement.
4. Contrôlez la devise et les montants (TTC, taxe, livraison) face à une commande réelle.
5. Testez sur Luma et sur Hyvä si les deux thèmes coexistent, en mode consentement accepté et refusé.
6. Validez dans GA4 DebugView, puis dans les rapports de conversion après 48 heures.

Foire aux questions

Le module GA4 natif suffit-il ?

Pour une boutique simple, il peut suffire à démarrer. Dès que vous voulez des événements complets, un dataLayer propre ou une déduplication avec Meta et Google Ads, il faut une extension ou du code.

Faut-il une extension ou du code sur mesure ?

Une extension est plus rapide à déployer et à maintenir. Le code sur mesure se justifie quand le thème est headless, quand les règles de prix sont complexes, ou quand une équipe interne veut garder la maîtrise du dataLayer.

Quelle différence avec Shopify ?

Shopify isole le checkout dans un environnement sandboxé, ce qui impose des Customer Events. Sur Magento, le tunnel est dans votre propre code et le défi est plutôt la cohérence entre thème, extensions et configuration. Voir la fiche Shopify pour le contraste.

Sources

• Adobe Commerce, configuration Google Analytics et GA4
• Adobe Commerce 2.4.8, notes de version