Tracking Shopify en 2026 : le guide complet GA4 + server-side

Le changement architectural de Shopify en 2024

En aout 2024, Shopify a deprecie checkout.liquid, le fichier qui permettait d’injecter du code custom directement dans les pages de checkout. Ce changement a casse le tracking de milliers de boutiques du jour au lendemain. Les scripts GA4 ou GTM que les marchands avaient places dans le checkout ne fonctionnent plus.

L’approche recommandee repose desormais sur deux mecanismes complementaires : le Theme Liquid pour les pages du site (collection, produit, panier) et les Customer Events pour le checkout. Les Customer Events sont un environnement sandboxe (un pixel isole dans une iframe) qui impose des contraintes specifiques sur le tracking.

Comprendre cette architecture est indispensable pour implementer un tracking e-commerce fiable sur Shopify en 2026.

Les 14 evenements e-commerce standards

GA4 definit une sequence d’evenements e-commerce qui couvre l’integralite du parcours d’achat. Sur Shopify, vous devez implementer chacun de ces evenements dans le bon contexte technique.

Dans le Theme Liquid : view_item_list (page collection), select_item (clic sur un produit), view_item (page produit), add_to_cart (ajout au panier), remove_from_cart, view_cart et begin_checkout.

Dans les Customer Events (sandbox pixel) : add_shipping_info, add_payment_info, purchase, et eventuellement refund via webhook server-side.

Les evenements view_promotion, select_promotion et view_search_results sont optionnels mais recommandes pour les boutiques avec des bannieres promotionnelles et une recherche interne active.

Le piege classique que je rencontre regulierement lors de mes missions de setup GA4 et GTM : ne jamais envoyer le client_id dans les objets ecommerce items. Ce parametre n’a rien a faire dans le payload e-commerce et gonfle artificiellement les (not set) dans vos rapports produits.

Le piege du debugging dans l’environnement sandbox

Les Customer Events de Shopify s’executent dans un environnement pixel sandboxe, c’est-a-dire une iframe isolee du reste de la page. Cette isolation a une consequence pratique majeure : le mode apercu de GTM ne fonctionne pas dans cet environnement.

Quand vous activez le mode preview de GTM, il injecte un script dans la page principale. Mais les evenements du checkout sont fires depuis l’iframe pixel, hors de portee du debugger GTM. Vous ne verrez aucun evenement du checkout dans le mode apercu.

La solution : ouvrez les outils de developpement du navigateur, naviguez vers l’iframe pixel dans le selecteur de contexte de la console, et inspectez les requetes reseau depuis cet iframe. C’est la seule maniere fiable de debugger le tracking checkout sur Shopify.

Alternativement, utilisez le DebugView de GA4 en activant le parametre debug_mode directement dans votre configuration pixel. C’est moins granulaire que le mode apercu GTM, mais cela confirme que les evenements arrivent bien dans GA4.

Server-side et Cookie Restore

Le checkout Shopify restreint l’acces aux cookies du domaine principal. Quand un utilisateur passe du site au checkout (qui s’execute sur un sous-domaine ou dans un contexte sandboxe), les cookies first-party ne sont pas accessibles. Le client_id GA4 est perdu, ce qui cree des sessions fragmentees et des utilisateurs dupliques.

La solution est le Cookie Restore, une technique server-side qui stocke le client_id cote serveur et le restaure lors de la transition vers le checkout. Le principe : quand l’utilisateur arrive sur le checkout, un appel server-side recupere son client_id original et le reinjecte dans le hit GA4. Cela garantit la continuite de la session et une attribution correcte de la conversion.

Cette technique est indispensable pour tout tracking server-side sur Shopify et fait partie des configurations que je mets en place systematiquement.

Applications et approches specialisees

Trois applications dominent le marche du tracking Shopify. Elevar se positionne sur l’optimisation du taux de conversion avec un data layer preconstruit et une interface no-code. Stape se concentre sur le server-side tracking avec une integration native des Customer Events. Addingwell propose une application Shopify native qui gere la proxification et le Cookie Restore.

Le choix depend de votre priorite : si votre enjeu principal est le tracking e-commerce GA4 avec une mise en place rapide, Elevar est un bon point de depart. Si vous avez besoin d’un controle total sur la collecte de donnees et la conformite RGPD, une approche server-side avec Stape ou Addingwell sera plus adaptee.

Dans tous les cas, testez systematiquement le parcours complet (view_item jusqu’a purchase) dans un environnement de staging Shopify avant de deployer en production. Un evenement purchase manquant ou duplique a un impact direct sur vos decisions marketing.