Pour fiabiliser le tracking GA4 sur Shopify, commencez par vérifier l’existant, puis choisissez une seule méthode d’envoi des achats et contrôlez chaque donnée jusqu’à sa source. Je détaille une méthode de validation pour éviter les doublons, réconcilier les commandes et respecter les signaux de consentement.
Besoin d'aide ? Découvrez les solutions de notre agence Google Analytics.
Comment cadrer les tests avant de modifier le tracking ?
Je définis le périmètre et je documente le tracking actuel avant toute modification. Sans cette référence, on ne peut pas distinguer une régression d’un changement volontaire, ni vérifier que GA4 et Shopify décrivent les mêmes commandes.
Je prépare les éléments qui serviront de base aux tests :
- La cartographie du parcours client, de l’arrivée sur le site jusqu’à la commande.
- La définition des champs transmis depuis le système commercial ou de gestion des prospects, avec leur origine et leur signification.
- Des commandes de test réconciliables avec les données Shopify et les données commerciales.
- Les règles métier convenues pour le chiffre d’affaires, la valeur de commande, la devise, les identifiants et le traitement des doublons.
J’inventorie ensuite les pixels, les applications, les événements client et les intégrations de canaux. Pour chaque élément, je documente quatre informations : le résultat observable, le responsable, les dépendances et la procédure de retour arrière. Le résultat observable doit permettre de vérifier concrètement ce qui est envoyé ou enregistré. Le responsable sait qui contacter si le comportement diffère de ce qui était prévu. Les dépendances rendent visibles les autres outils ou configurations concernés. La procédure de retour arrière précise comment rétablir le comportement précédent.
Je conserve cette référence avec une date, pour pouvoir comparer l’état avant et après la modification. Elle doit aussi décrire le comportement observé des événements et des mesures concernés, pas seulement leur nom. Si une modification change la signification d’un événement ou d’une mesure, l’approbation doit être formalisée : le changement attendu, la règle métier associée et la personne qui l’approuve doivent être consignés. Sinon, une évolution de définition peut passer pour un simple ajustement technique, alors qu’elle rend les comparaisons de données incohérentes.
Comment éviter les achats en double dans GA4 ?
Pour éviter les achats en double dans GA4, je choisis une seule méthode d’envoi des achats et je vérifie qu’aucune autre couche ne transmet déjà l’événement. Shopify, un pixel personnalisé, Google Tag Manager, une application ou une intégration de canal peuvent chacun envoyer un achat. Sans responsabilités clairement définies, le même paiement peut être comptabilisé plusieurs fois.
Je commence par cartographier les sources : le suivi géré par Shopify, les personnalisations, les applications et les intégrations de canaux. Pour chacune, je note les événements envoyés, la gestion du consentement, les identifiants utilisés, les connecteurs concernés et les champs qui fournissent les valeurs. Un pixel est un mécanisme de suivi qui transmet des événements à un outil d’analyse. En avoir plusieurs n’est pas forcément un problème ; c’est le chevauchement de leurs envois qui l’est.
Je limite ensuite le changement à la couche la plus sûre. Avant de désactiver ou de modifier un envoi, j’examine ses dépendances en amont et en aval. Un retrait rapide peut supprimer un événement nécessaire, contourner le consentement ou casser un connecteur. Les achats doivent utiliser un identifiant de transaction stable ; les conversions de prospects, un identifiant de prospect stable. Le montant, la devise et les autres valeurs doivent venir de la source qui fait autorité, généralement la commande Shopify. Si une donnée manque, je la corrige à sa source, je ne la déduis pas de l’interface.
Je procède par changements limités, chacun avec un responsable et un résultat attendu. Par exemple :
- Inventaire : le responsable du tracking liste les émetteurs ; résultat attendu, une seule source d’achat identifiée.
- Test : le responsable technique vérifie une commande de test et son identifiant ; résultat attendu, un seul événement d’achat avec les bonnes valeurs.
- Mise en production : le responsable e-commerce contrôle les données après déploiement ; résultat attendu, aucun achat manquant ni doublon.
Je distingue enfin les conversions principales, comme un achat confirmé, des signaux d’intention, comme un clic ou un début de paiement. Ces derniers aident à comprendre le parcours, mais ne doivent pas être comptés comme des ventes.
Comment vérifier les données envoyées de Shopify à GA4 ?
Je vérifie les données en suivant chaque valeur depuis Shopify jusqu’à son arrivée dans GA4. Un écran qui semble correct ne suffit pas : je contrôle aussi une trace de requête ou un enregistrement réellement transmis.
Je rapproche les champs selon leur rôle, sans supposer que leur nom ou leur disponibilité est identique dans toutes les configurations Shopify.
| Produit | Source Shopify : informations du produit. Destination GA4 : article associé à l’événement ecommerce. |
| Variante | Source Shopify : variante réellement sélectionnée ou achetée. Destination GA4 : contexte de l’article, sans la confondre avec le produit parent. |
| Commande | Source Shopify : données de la commande finalisée. Destination GA4 : événement d’achat et informations de transaction nécessaires. |
| Remise | Source Shopify : remise appliquée au produit ou à la commande. Destination GA4 : valeur correspondant à cette même portée. |
| Devise | Source Shopify : devise utilisée pour la transaction. Destination GA4 : même devise que celle des montants envoyés. |
Pour chaque valeur, je vérifie son nom, son type, sa portée — produit, article ou commande — et sa temporalité : à quel moment elle est disponible et transmise. Je contrôle aussi l’identifiant utilisé, la devise, l’état du consentement au moment de l’envoi et le traitement des valeurs vides. Une donnée absente ne doit pas être remplacée silencieusement par une valeur par défaut qui changerait son sens.
Quand le schéma ecommerce de GA4 s’applique, je le respecte et je préserve le contexte des articles. Une variante doit rester rattachée au bon produit, et les montants ou remises doivent garder leur portée. Je vérifie l’origine de chaque valeur : champ Shopify, transformation éventuelle, puis destination GA4. C’est souvent là que les écarts se cachent, notamment après une personnalisation du thème ou de l’intégration.
Je compare enfin l’affichage dans les outils de diagnostic avec le contenu brut d’une requête ou d’un enregistrement transmis. Les contrôles visuels aident à repérer un problème, mais ne montrent pas toujours précisément ce qui a été envoyé. Je retire aussi les champs qui ne sont pas nécessaires au suivi : moins de données inutiles, c’est moins de risques et moins d’ambiguïtés.
Comment valider le consentement et les résultats du tracking ?
Le tracking doit respecter les signaux de confidentialité et de consentement client de la plateforme, et ses résultats doivent être contrôlés avec des tests réconciliables. Je vérifie le consentement dans les mêmes scénarios que les événements et leurs dépendances, pour voir si le tracking observé est cohérent avec le signal présent. Les modalités détaillées de cette vérification ne sont pas établies ici. Je ne présume donc ni d’un mécanisme technique particulier, ni d’une règle juridique précise.
Pour contrôler les résultats, je compare les événements transmis et les achats remontés à des commandes de test que je peux retrouver et rapprocher. La comparaison suit les règles métier convenues : quels événements sont attendus, quelles commandes entrent dans le périmètre et comment les montants doivent être interprétés. Une valeur différente n’est pas automatiquement une anomalie si une règle métier l’explique.
Je contrôle ensuite les identifiants utilisés pour relier l’événement à la commande, la valeur transmise, la devise et la présence éventuelle de doublons. Si un écart apparaît, je le consigne et je le rapproche de la commande de test et du résultat observé. Une validation utile doit permettre à une autre personne de refaire ce rapprochement, pas seulement de constater que des événements apparaissent dans un outil.
Synthèse des contrôles
| Étape | Contrôle attendu | Preuve à conserver |
| Consentement | Vérifier le signal de confidentialité et de consentement dans les scénarios de test, sans présumer du mécanisme. | Résultat observé pour le scénario testé. |
| Événements et dépendances | Contrôler les événements transmis et leurs dépendances dans les scénarios testés. | Trace des événements observés. |
| Achats | Rapprocher les achats transmis des commandes de test selon les règles métier convenues, puis contrôler les identifiants, la valeur, la devise et les doublons. | Référence de la commande de test et résultat du rapprochement. |
Votre tracking Shopify est-il prêt à être validé ?
Un tracking GA4 fiable sur Shopify commence par un état des lieux daté et des règles métier explicites. Il faut ensuite choisir une seule méthode d’envoi des achats, utiliser des identifiants stables et vérifier que chaque valeur vient de la bonne source. Le contrôle ne s’arrête pas à l’interface : les événements transmis doivent être examinés et comparés à des commandes de test réconciliables. Le consentement, les dépendances et les doublons font partie des vérifications, pas d’une étape qu’on peut repousser. Cette méthode rend les changements plus faciles à tester et à valider. Vous gagnez des données plus cohérentes pour piloter votre activité.
FAQ
- Pourquoi vérifier le tracking Shopify avant de le modifier ?
Pour documenter le comportement existant, repérer les dépendances et disposer d’une référence datée avant tout changement. - Comment éviter qu’un achat soit compté plusieurs fois dans GA4 ?
Choisissez une seule méthode d’envoi des achats et vérifiez les pixels, applications, événements et intégrations susceptibles de transmettre le même événement. - Quelles valeurs faut-il vérifier entre Shopify et GA4 ?
Contrôlez notamment les données produit, variante, commande, remise et devise, ainsi que leur source, leur type, leur identifiant et la gestion des valeurs vides. - Comment confirmer qu’un achat transmis correspond à une commande réelle ?
Utilisez des commandes de test réconciliables, des identifiants stables et les règles métier convenues, puis examinez les traces des requêtes ou les enregistrements transmis. - Comment prendre en compte le consentement client ?
Intégrez les signaux de consentement de la plateforme aux vérifications et n’inventez pas de modalités techniques : elles doivent être établies pour la configuration concernée.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation no/low code et intégration de l’IA en entreprise. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des entreprises comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football et Texdecor. Je suis disponible pour aider votre entreprise à fiabiliser sa mesure : contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.