Vos conversions Shopify manquent dans GA4 parce que Shopify enregistre des commandes réelles, alors que GA4 dépend du tracking, du consentement, des événements et des redirections de paiement. Je vous montre où l’écart se crée, comment le lire, et quoi vérifier en priorité.
Besoin d'aide ? Découvrez les solutions de notre agence Google Analytics.
Pourquoi Shopify et GA4 ne collent jamais vraiment ?
Shopify et GA4 ne collent jamais vraiment parce qu’ils ne mesurent pas la même chose. Shopify enregistre des commandes réelles. GA4 reconstruit des conversions à partir d’événements, de consentement et de signaux de tracking. C’est une grosse différence.
Dans Shopify, une vente existe dès qu’elle est validée côté plateforme. Le paiement est passé, la commande est créée, elle est en base. Même si le client ferme son navigateur juste après, Shopify garde la commande. C’est votre source de vérité pour le chiffre d’affaires.
Dans GA4, c’est plus fragile. Une conversion, c’est souvent un événement purchase envoyé depuis le navigateur ou via une intégration. Si cet événement ne part pas, arrive trop tard, est bloqué ou n’est pas autorisé par le consentement, GA4 ne verra rien. La vente existe bien, mais l’outil analytics ne peut pas la reconstruire.
C’est là que beaucoup d’écarts apparaissent. Un client refuse les cookies. Un bloqueur de pub coupe les scripts. Une redirection de paiement casse la session. Une page de confirmation se ferme trop vite. Un navigateur limite le tracking. Tout ça peut faire disparaître une conversion dans GA4 alors que Shopify l’a parfaitement enregistrée.
J’ai souvent vu des équipes paniquer sur 10 ou 15 % d’écart. Franchement, l’écart seul ne dit pas grand-chose. Le vrai sujet, c’est de savoir s’il est faible, stable et explicable. Si vous avez toujours 8 à 12 % d’écart, c’est peut-être normal dans votre contexte. Si vous passez de 8 % à 35 % après un changement de thème, une app de consentement ou une nouvelle passerelle de paiement, là oui, il faut creuser.
Chercher une correspondance parfaite entre Shopify et GA4, c’est rarement le bon objectif. Le bon objectif, c’est de comprendre ce que chaque outil sait mesurer, ce qu’il ne sait pas mesurer, et de surveiller les ruptures.
| Point comparé | Shopify | GA4 |
| Rôle | Source des commandes réelles | Outil d’analyse du comportement et des conversions |
| Donnée principale | Commandes, paiements, chiffre d’affaires | Événements, sessions, sources de trafic, conversions |
| Limite | Peu de contexte marketing détaillé | Dépend du tracking, du consentement et du navigateur |
| Usage recommandé | Piloter les ventes et la comptabilité | Analyser les tendances, les parcours et les canaux |
Votre installation GA4 est-elle propre ?
Oui, votre installation GA4 doit être propre, sinon vous allez perdre du temps à accuser GA4 alors que le problème vient souvent de Shopify, du thème, d’une app ou d’un vieux bout de script oublié. Sur Shopify, une base saine évite surtout trois choses : les doubles suivis, les anciens scripts et les configurations concurrentes.
Je commence toujours par vérifier l’identifiant de mesure GA4, le fameux G-XXXXXXXXXX. C’est l’ID qui dit à Shopify, Google Tag Manager ou une app où envoyer les données. Si cet ID est présent à plusieurs endroits, ça sent déjà le problème. Il peut être connecté via l’application Google & YouTube, ajouté dans Google Tag Manager, collé dans le thème, ou injecté par une app marketing. Et parfois tout ça en même temps. J’ai déjà vu des boutiques avec trois méthodes actives, chacune persuadée d’être la source officielle. Résultat : des achats en double un jour, puis des achats absents le lendemain.
Les erreurs fréquentes sont assez classiques. Un même événement envoyé par plusieurs méthodes. Un tag GA4 posé à la fois via une app Shopify et via GTM, c’est-à-dire Google Tag Manager, l’outil qui centralise les balises de tracking. Un vieux script gtag encore présent dans le fichier theme.liquid après une migration depuis Universal Analytics. Un changement de thème qui supprime un bout de tracking custom. Une app d’avis, d’upsell ou de pixels publicitaires qui injecte son propre code sans vraiment vous le dire. Ça peut créer des conversions manquantes, des doublons, ou pire, des rapports incohérents où les sessions, les revenus et les événements ne racontent pas la même histoire.
Ma méthode reste simple. Je pars de l’ID de mesure. Je regarde qui envoie quoi. Puis je vérifie si l’événement purchase, donc l’achat final, arrive une seule fois, au bon moment, avec la bonne valeur et la bonne devise. Si l’achat part depuis Shopify, je ne veux pas le revoir partir depuis GTM avec une logique parallèle. Une architecture propre, c’est une méthode principale, une responsabilité claire, et pas trois couches qui font le même boulot.
- Conversions en double dans GA4 sans raison commerciale réelle.
- Achats absents alors que les commandes existent bien dans Shopify.
- Événements reçus sans valeur, sans devise ou avec des montants à zéro.
- Rupture nette après un changement de thème ou une mise à jour Shopify.
- Différence brutale après l’ajout d’une app marketing, tracking, avis ou upsell.
Le purchase contient-il les bonnes données ?
Le purchase, c’est l’événement central pour suivre les ventes Shopify dans GA4. Mais je vois souvent le même piège : GA4 reçoit bien l’événement, la conversion apparaît quelque part, et pourtant les données e-commerce sont presque inutilisables.
Un événement techniquement reçu n’est pas forcément un bon événement analytics. Si le purchase arrive sans valeur, sans devise ou sans détail produit, GA4 sait qu’une vente a eu lieu, mais il ne sait pas vraiment quoi en faire. Et là, vos rapports e-commerce commencent à raconter une histoire incomplète.
Les paramètres à vérifier sont simples, mais ils changent tout :
| Paramètre | Exemple | Utilité |
| transaction_id | #1048 | Dédupliquer les achats et rapprocher les ventes entre Shopify, GA4 et les plateformes publicitaires. |
| value | 89.90 | Calculer le chiffre d’affaires dans GA4. |
| currency | EUR | Éviter les montants impossibles à interpréter, surtout si vous vendez dans plusieurs pays. |
| items | Nom produit, ID produit, quantité | Alimenter les rapports produits, catégories, paniers et performances e-commerce. |
| tax | 14.98 | Comprendre ce qui compose le montant total payé. |
| shipping | 4.90 | Identifier la part liée aux frais de livraison. |
| coupon | WELCOME10 | Analyser l’impact réel des codes promo sur les ventes. |
Le transaction_id mérite une attention spéciale. S’il est absent, incohérent, ou réutilisé sur des commandes tests, GA4 peut compter deux fois, ignorer une vente, ou rendre la comparaison avec Shopify complètement floue. J’ai déjà vu des comptes où les écarts venaient juste de commandes de test avec les mêmes IDs envoyées plusieurs fois.
Le value et la currency servent au chiffre d’affaires. Les items servent aux rapports produits. Les taxes, le shipping et les coupons donnent le contexte. Sans ça, vous avez une conversion, oui, mais pas une donnée vraiment exploitable.
C’est souvent ici que je trouve les écarts les plus bêtes, pas les plus visibles.
La page de confirmation casse-t-elle le suivi ?
Oui, clairement. Une grosse partie du suivi d’achat Shopify dépend encore du bon déclenchement sur la page de confirmation, la fameuse page de remerciement. C’est le moment où GA4, Google Analytics 4, doit recevoir l’événement purchase. Et c’est aussi un endroit fragile, parce qu’il se passe plein de choses à ce moment-là.
Shopify connaît la commande dès qu’elle est validée côté plateforme. Là-dessus, il n’y a pas de débat. Mais GA4 ne voit l’achat que si l’information arrive correctement jusqu’à lui. Si le navigateur n’envoie pas l’événement, si un script ne se charge pas, ou si le consentement bloque la collecte, GA4 peut rater la conversion alors que la commande existe bien dans Shopify.
C’est souvent là que l’écart commence. Un script de checkout qui ne se déclenche pas. Une modification du thème qui a retiré un bout de code sans que personne ne s’en rende compte. Une app qui injecte son propre JavaScript et perturbe l’ordre de chargement. Une redirection vers un moyen de paiement externe qui coupe la session. Un client qui ferme l’onglet trop vite après avoir payé. Ou une bannière de consentement qui dit à GA4 : “Non, tu ne collectes rien tant que l’utilisateur n’a pas accepté”.
Sur Shopify Plus, ça peut devenir encore plus subtil. Le checkout est parfois plus personnalisé, avec des scripts spécifiques, des intégrations métier, des outils de paiement ou de fidélité. Plus il y a de couches, plus il y a de chances qu’un événement d’achat se perde en route. J’ai déjà vu des boutiques avec des commandes parfaitement remontées dans Shopify, mais zéro achat dans GA4 sur certains moyens de paiement. Le problème n’était pas la vente. Le problème, c’était le signal envoyé au mauvais moment, ou pas envoyé du tout.
Je ne me contente jamais de regarder les rapports finaux. Je teste le parcours d’achat, je passe une vraie commande test, et je vérifie que l’événement part vraiment avec les bons paramètres. Sinon on pilote avec un tableau de bord qui a l’air propre, mais qui ment un peu.
- Achat test passé jusqu’au bout, avec paiement réel ou mode test fiable.
- Page de confirmation bien chargée après la validation de commande.
- Événement purchase bien envoyé vers GA4.
- Transaction_id présent et unique pour éviter les doublons.
- Valeur de commande correctement transmise.
- Devise bien renseignée, surtout si la boutique vend dans plusieurs pays.
- Items présents avec les bons produits, quantités et prix.
- Impact des apps vérifié, surtout celles qui touchent au checkout, au paiement ou au tracking.
- Impact du consentement testé selon les choix accepté, refusé et non répondu.
Comment rendre l’écart enfin explicable ?
Je ne cherche jamais à faire matcher Shopify et GA4 au centime près. C’est souvent une perte de temps. Shopify doit rester la source de vérité pour les ventes, le chiffre d’affaires, les commandes remboursées ou annulées. GA4 sert à comprendre le parcours, les sources d’acquisition, les campagnes qui ont influencé la vente. Ce n’est pas le même rôle, donc ce n’est pas toujours le même chiffre.
Le vrai sujet, c’est de rendre l’écart explicable. Quand je vois 8% d’écart stable, documenté, avec des causes connues, ça ne m’inquiète pas. Quand je vois 25% qui bouge selon les jours et personne ne sait pourquoi, là on a un problème de pilotage.
Je regarde les choses dans un ordre simple, parce que sinon on part vite dans tous les sens :
- Installation : Est-ce que GA4 est bien installé une seule fois, sans double balise, sans conflit entre Shopify, GTM et une app tierce.
- Événement purchase : Est-ce que l’achat se déclenche vraiment au bon moment, avec le bon montant, la bonne devise et les bons produits.
- ID de transaction : Est-ce que chaque commande a un identifiant unique, sinon GA4 peut dédupliquer ou compter n’importe comment.
- Page de confirmation : Est-ce que l’utilisateur revient bien sur la page thank you après paiement, surtout avec PayPal, Klarna, Apple Pay ou un paiement 3D Secure.
- Consentement : Est-ce que le refus des cookies analytics bloque bien GA4, et dans quelle proportion.
Il faut aussi séparer deux cas. Une conversion absente parce que l’événement purchase ne se déclenche pas, c’est un bug de collecte. Une conversion absente parce que l’utilisateur refuse les cookies analytics, c’est une limite normale. Pas agréable, mais normale. Même chose pour l’attribution. Shopify dit “vente réalisée”, GA4 peut dire “vente attribuée à Google Ads, organic, email ou direct” selon sa logique. Ce n’est pas une erreur si la règle est comprise.
Chez un client, on avait un écart qui semblait énorme. Au final, une partie venait des paiements externes qui ne ramenaient pas toujours les gens sur la confirmation, et une autre partie venait du consentement. Une fois documenté, les réunions ont changé. On ne débattait plus du chiffre, on décidait quoi couper, quoi pousser, quoi tester.
| Problème | Symptôme | Impact | Priorité |
| Purchase ne se déclenche pas | Commandes Shopify absentes de GA4 | Perte directe de mesure des conversions | Très haute |
| ID de transaction manquant ou instable | Doublons ou déduplication incorrecte | Chiffre d’affaires GA4 peu fiable | Haute |
| Retour paiement incomplet | Moins de ventes trackées sur PayPal ou 3D Secure | Sous-estimation de certains parcours | Haute |
| Consentement refusé | Conversions non visibles dans GA4 | Écart attendu avec Shopify | Moyenne |
| Différence d’attribution | Source de vente différente entre outils | Débats marketing si non expliqué | Moyenne |
Vous voulez des chiffres parfaits ou des chiffres utiles ?
Shopify et GA4 ne raconteront presque jamais exactement la même chose, et c’est normal. Shopify garde la commande réelle. GA4 dépend du tracking, du consentement, des événements, des redirections et de la qualité des paramètres e-commerce. Le vrai travail, c’est de réduire l’écart, puis de le rendre stable et explicable. Je commencerais toujours par l’installation GA4, l’événement purchase, le transaction_id, la page de confirmation et les règles de consentement. Une fois ces points propres, vos rapports deviennent beaucoup plus fiables. Le bénéfice est simple : vous pilotez votre acquisition avec moins de doute et plus de confiance.
FAQ
- Pourquoi Shopify affiche plus de ventes que GA4 ?
Shopify enregistre les commandes réelles dans la plateforme e-commerce. GA4 enregistre des événements envoyés par le tracking. Si l’utilisateur refuse les cookies analytics, si la page de confirmation ne charge pas correctement ou si le purchase ne part pas, Shopify garde la vente mais GA4 peut la manquer. - Est-ce grave si Shopify et GA4 ne correspondent pas exactement ?
Pas forcément. Une correspondance parfaite est rare. Ce qui m’inquiète, c’est un écart brutal, instable ou impossible à expliquer. Shopify doit rester la source de vérité pour les ventes. GA4 sert surtout à comprendre le parcours, l’attribution et la performance marketing. - Quel événement GA4 faut-il vérifier en priorité sur Shopify ?
L’événement purchase. Il doit contenir au minimum un transaction_id unique, une value, une currency et les items vendus avec leurs noms, IDs et quantités. Sans ces données, GA4 peut recevoir un achat mais produire des rapports e-commerce incomplets ou difficiles à exploiter. - Pourquoi le transaction_id est si important dans GA4 ?
Le transaction_id permet de reconnaître une commande unique. Il aide à éviter les doublons et à rapprocher les données entre Shopify, GA4 et les plateformes publicitaires. S’il manque, change selon les outils ou se répète sur des commandes tests, l’analyse devient vite bancale. - Le consentement peut-il vraiment faire disparaître des conversions GA4 ?
Oui. Si un utilisateur refuse les cookies ou le suivi analytics, GA4 peut ne pas enregistrer tout le parcours ni l’achat. Shopify conserve quand même la commande, parce qu’elle existe côté e-commerce. C’est une cause très classique d’écart entre les deux systèmes.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, IA appliquée aux entreprises et SEO/GEO. J’accompagne des équipes qui veulent fiabiliser leurs données, pas juste empiler des tags. Avec webAnalyste et Formations Analytics, j’ai travaillé pour des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous avez besoin de remettre à plat votre tracking Shopify, GA4 ou vos automatisations data, 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.




