Tracking GA4 et GTM sur Salesforce Commerce Cloud, BigCommerce et Sylius

Sur les grandes plateformes e-commerce (SFCC, BigCommerce, Sylius), GA4 et GTM se branchent, mais rarement en « clic et ça marche » pour le e-commerce complet. Le connecteur natif couvre en général les vues de page, puis le tunnel d’achat demande du code ou un plugin. La méthode reste la même partout : un dataLayer alimenté par le serveur, des événements e-commerce conformes à GA4, et un contrôle du checkout jusqu’à la page de confirmation. Les plateformes ci-dessous ont chacune leur point d’injection, à identifier avant de coder.

Pour un cadrage complet du périmètre à tracker, un tracking e-commerce bien posé évite de découvrir les trous au moment du reporting. Pour les plateformes plus courantes, le hub des plateformes et le guide Magento donnent des cas voisins, et le tracking e-commerce avec GA4 pose le socle commun.

Salesforce Commerce Cloud

SFCC structure son storefront en cartouches (cartridges) empilés dans un chemin. Le tracking s’ajoute en surcharge, sans toucher au cœur de la boutique.

Pour un storefront SFRA, le point d’entrée est le template de page : un fichier ISML inclus dans le <body> construit le dataLayer à partir du contexte de la page (catégorie, produits, panier). Le contrôleur fournit les données, le template les sérialise, et le conteneur GTM les lit. Une cartouche communautaire existe pour GTM sur SFRA : elle s’installe en l’ajoutant au chemin de site dans Business Manager, en important ses métadonnées, puis en saisissant l’identifiant GTM dans les préférences personnalisées. Je la considère comme un point de départ, pas comme une solution livrée : elle doit être testée sur votre version de SFRA et son état de maintenance vérifié avant tout déploiement.

Une règle de configuration revient souvent : la cartouche de tracking doit être placée avant app_storefront_base dans le chemin, car une cartouche située plus à gauche prend la priorité.

Pour PWA Kit, qui repose sur React, le dataLayer se pousse depuis les composants, selon la même logique qu’une SPA. Le guide SPA et headless détaille ce cas.

BigCommerce

BigCommerce expose GTM via le Script Manager, qui injecte les scripts dans le storefront sans modifier le thème. Sa disponibilité dépend de votre plan, à vérifier avant de promettre une mise en place.

Le connecteur GA4 natif gère les vues de page. Les retours de terrain que je lis s’accordent sur ses limites côté e-commerce : les événements standard GA4 ne sont pas tous poussés, et les données du checkout ne sont pas accessibles directement depuis les variables Stencil (le moteur de templates). Trois points à contrôler :

• Pas de double comptage : n’activez pas le connecteur natif et une balise GA4 dans GTM en même temps sur les mêmes événements. Choisissez un seul canal.
• Checkout et domaine : selon la configuration, le checkout peut vivre sur un sous-domaine. Vérifiez la mesure inter-domaines et l’exclusion des référents, sans quoi le paiement apparaît comme une source externe.
• Page de confirmation : vérifiez le ciblage des scripts dans le Script Manager. Le réglage « toutes les pages » et le réglage « pages du storefront » ne couvrent pas forcément la confirmation de commande. Le test d’une commande réelle en mode Preview reste la seule vérification fiable.

Le checkout optimisé en une page peut aussi décaler le moment où le dataLayer est alimenté. Testez le parcours complet, pas seulement la fiche produit.

Sylius

Sylius est une plateforme Symfony. Le tracking se fait par plugin ou par bundle, car le dataLayer se pousse depuis les templates Twig et les événements de l’application.

Pour une boutique Sylius 2.x, trois plugins apparaissent aujourd’hui :

• stefandoorn/google-tag-manager-plugin, qui s’appuie sur le bundle GTM de xynnn et exige Sylius 2.x. Sa dernière version publiée est une alpha de mars 2025 : vérifiez l’activité du dépôt avant de l’adopter.
• stefandoorn/sylius-google-tag-manager-enhanced-ecommerce-plugin, qui ajoute les événements e-commerce par-dessus le premier.
• darksidepro/sylius-gtm-plugin, qui pousse automatiquement des événements comme add_to_cart, begin_checkout ou purchase, et gère le multi-boutique.

Un plugin ancien, comme webburza/sylius-google-ecommerce-bundle, cible Universal Analytics et une clé de propriété UA- : je ne le retiens pas pour GA4.

Le point technique important concerne l’événement d’achat. Il survient souvent après une redirection. Le plugin darksidepro, par exemple, passe par le flash bag de Symfony : l’événement est stocké en session, puis poussé dans le dataLayer sur la page suivante. Si le plugin retenu ne gère pas ce cas, le purchase risque de n’apparaître qu’une fois sur deux.

Oxatis, Wizishop et Shopware

Je n’ai pas vérifié ces trois plateformes à la date de rédaction. Ce que je peux dire sans les connaître en détail : sur une solution fermée, l’accès au code du thème est limité, donc le point d’injection passe par le gestionnaire de tags fourni ou par une injection de script validée par l’éditeur. Shopware, en tant que solution open source, se traite comme un projet à part entière, avec des plugins de tracking à évaluer un par un. Dans les deux cas, je commence par la liste des événements à remonter et je vérifie qu’ils sont possibles dans la plateforme avant de promettre quoi que ce soit.

Tableau de synthèse

Plateforme	dataLayer natif	Connecteur GTM	Consentement	Server-side	Difficulté
SFCC (SFRA)	Non, à construire	Cartouche communautaire à valider	Via la CMP, avant GTM	Possible, à évaluer	Élevée
SFCC (PWA Kit)	Depuis les composants React	Selon l’implémentation	Via la CMP, avant GTM	Possible	Élevée
BigCommerce	Partiel	Script Manager, selon le plan	Via la CMP	Possible	Moyenne
Sylius	Via plugin ou bundle	Plugins Symfony	Via la CMP	Possible	Moyenne
Oxatis, Wizishop, Shopware	À vérifier	À vérifier	À vérifier	À vérifier	À évaluer

Méthode générique quand la plateforme n’est pas documentée

Quand aucun connecteur fiable n’existe, je procède ainsi.

1. Inventorier les événements : vues de catégorie, fiche produit, ajout au panier, début de checkout, achat. Je les liste avant d’ouvrir le code.
2. Trouver le point d’injection : le template commun à toutes les pages (en-tête ou pied de page), puis les templates spécifiques au panier et à la confirmation.
3. Pousser les données serveur dans un bloc unique, sans recalcul côté navigateur.
4. Mapper sur le modèle GA4 : items, value, currency, transaction_id. La référence e-commerce GA4 fixe les paramètres obligatoires pour un achat.
5. Tester le tunnel complet avec une commande réelle, en mode Preview, puis contrôler le transaction_id en DebugView.

Un exemple de bloc poussé sur une fiche produit :

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

Les valeurs ci-dessus sont des exemples. Ce qui compte, c’est que value soit un nombre, que la devise soit au format ISO et que les identifiants produit correspondent à ceux du flux Google Merchant Center.

FAQ

Puis-je tracker BigCommerce sans Script Manager ?

Pas proprement. Le Script Manager reste le point d’injection le plus sûr, car les scripts ajoutés dans le thème disparaissent à la prochaine mise à jour du thème.

Le plugin Sylius suffit-il pour le purchase ?

Il faut vérifier qu’il gère la redirection vers la page de confirmation. Testez une commande de bout en bout et contrôlez l’unicité du transaction_id.

Une cartouche SFCC peut-elle casser le checkout ?

Oui, si elle surcharge un template ou un contrôleur du tunnel. Un test de recette sur le checkout avant la mise en production est indispensable.

Sources

• Google Tag Manager cartridge pour SFRA (redvanworkshop), projet communautaire
• Google Tag Manager plugin pour Sylius (stefandoorn), projet communautaire
• Référence e-commerce GA4, Google for Developers