Shopify et GA4 ne comptent pas la même chose. Shopify enregistre chaque commande payée. GA4 enregistre ce qu'un navigateur lui envoie. L'écart entre les deux n'est donc pas une panne : c'est normal. Pour savoir combien vous avez vendu, croyez Shopify. Gardez GA4 pour savoir d'où viennent les ventes. Et regardez l'écart chaque semaine : ce n'est pas son niveau qui compte, c'est le jour où il bouge.
Pourquoi Shopify et GA4 ne comptent-ils pas la même chose ?
Dans Shopify, une commande payée existe, qu'un tag l'ait vue ou non. Dans GA4, un achat n'existe que si le tag est parti, et seulement pour les visiteurs qui n'ont pas refusé la mesure.
| Shopify | GA4 | |
|---|---|---|
| Ce qui est compté | Les commandes de la boutique : c'est la transaction elle-même | Des événements purchase envoyés par un tag, depuis le navigateur ou un serveur |
| Qui est vu | Tous les acheteurs, quel que soit leur choix de cookies | Ceux dont le tag s'est exécuté, et qui n'ont pas refusé la mesure |
| Le montant | Un rapport au choix : ventes brutes, nettes, ou totales avec taxes et livraison | La valeur que le tag envoie, avec ses taxes et sa livraison en paramètres distincts |
| Les remboursements | Retirés à la date où le retour est traité | Retirés seulement si un événement refund est envoyé |
| Les doublons | Impossibles : une commande a un numéro | Écartés par l'identifiant de transaction, quand il est envoyé |
De quel « chiffre d'affaires » parle-t-on, au juste ?
Avant de chercher une panne, vérifiez que vous comparez la même chose. Concrètement, « chiffre d'affaires » ne veut rien dire tout seul : chaque outil en a plusieurs, et ils ne se recouvrent pas d'office.
Chez Shopify, le rapport des ventes distingue les ventes brutes (prix × quantité, avant taxes, livraison, remises et annulations, commandes en attente, annulées ou impayées comprises), les ventes nettes (brutes, moins remises, moins annulations de ventes) et les ventes totales (nettes, plus taxes, droits, livraison et frais). Un retour apparaît en négatif à la date où il est traité, pas à celle de la commande.

Chez GA4, selon la documentation de Google, les revenus issus des achats sont la somme des événements d'achat, moins les événements de remboursement. Les revenus bruts sont la même somme sans les remboursements. Le revenu généré par l'article vaut le prix multiplié par la quantité des articles de l'achat. Le revenu total ajoute le revenu publicitaire de l'application, quand il existe.

L'écart entre ces métriques n'a rien de théorique. Dans la propriété de démonstration de Google, sur les 28 jours du 7 septembre au 4 octobre 2026, le rapport Transactions donne 320 420,82 $ de revenus issus des achats pour 1 839 transactions. Le rapport Achats d'e-commerce, dans la même propriété et sur la même période, donne 298 474,21 $ de « revenu généré par l'article ». Écart : 21 946,61 $, soit 6,8 % du premier. Même outil, même période, deux « chiffres d'affaires ».

Pourquoi ces 21 946,61 $ ? Google ne publie pas le détail de cette boutique. Hypothèse : la valeur envoyée avec chaque achat n'est pas égale au prix multiplié par la quantité, parce qu'elle inclut les taxes ou la livraison, ou qu'elle tient compte des remises. Seule la lecture des événements bruts le confirmerait. Chez vous, c'est le test à faire en premier : une fois les deux chiffres alignés, l'écart restant est celui de la mesure.
Voici une correspondance de départ entre les deux outils. Elle est à confirmer par un achat de test, parce que ce que GA4 affiche dépend de ce que votre tag envoie :
| Ligne Shopify | Métrique GA4 la plus proche | À vérifier sur un achat de test |
|---|---|---|
| Ventes brutes prix × quantité, avant remises et retours | Revenu généré par l'article prix × quantité des articles de l'événement | Que le prix envoyé dans les articles soit celui d'avant remise |
| Ventes nettes brutes, moins remises, moins annulations | Revenus issus des achats, moins taxes et livraison à calculer à la main | Que la valeur de l'achat, une fois taxes et livraison retirées, retombe sur vos ventes nettes |
| Ventes totales nettes, plus taxes, droits et livraison | Revenus issus des achats somme des événements d'achat, moins les remboursements envoyés | Que la valeur envoyée porte taxes et livraison, et que chaque remboursement soit envoyé |
À quoi ressemble un événement d'achat correct ?
Voici l'exemple de la documentation de Google, simplifié. Chaque ligne décide d'un chiffre que GA4 affichera plus tard :
gtag("event", "purchase", {
transaction_id: "T_12345_1",
value: 30.03,
tax: 4.90,
shipping: 5.99,
currency: "USD",
items: [{
item_id: "SKU_12345",
item_name: "Stan and Friends Tee",
price: 10.01,
quantity: 3
}]
});
Dans cet exemple, la valeur de l'achat (30,03) est égale au prix multiplié par la quantité (10,01 × 3). Les taxes (4,90) et la livraison (5,99) sont envoyées à part, et l'identifiant de transaction (T_12345_1) sert à écarter les doublons. Rien n'oblige une boutique à faire comme cela : certaines mettent les taxes et la livraison dans la valeur. Ce qui compte : savoir ce que votre tag y met. Et comparer avec la ligne Shopify qui correspond, pas avec la première venue.
Les sept causes de l'écart
Sept, que l'on peut vérifier une à une. La troisième est la plus récente.
- Des acheteurs que GA4 ne voit pas. Un visiteur refuse les cookies de mesure, un bloqueur coupe le tag, le script ne se charge pas : la commande est chez Shopify, jamais chez GA4. GA4 peut estimer les refus de consentement, mais seulement si la propriété coche une liste de conditions : mode de consentement avancé, au moins 1 000 événements par jour avec consentement refusé pendant sept jours, au moins 1 000 utilisateurs par jour qui acceptent. Et même là, Google ne promet rien. Une petite boutique a de bonnes chances de rester sous les seuils.
- Un montant qui n'est pas le même. « Chiffre d'affaires » n'est pas un chiffre, c'est une famille, chez Shopify comme chez GA4 (voir plus haut). Les ventes brutes comptent même les commandes en attente, annulées ou impayées. Côté GA4, la valeur, les taxes et la livraison arrivent dans trois paramètres séparés : ce qui s'affiche dépend de ce que votre tag y met.
- Un suivi d'achat qui ne se déclenche plus depuis la migration du checkout. Shopify a fixé au 26 août 2026 l'échéance pour les boutiques hors Plus : leurs pages de remerciement et de statut de commande passent à la nouvelle version, et les scripts ajoutés à la main n'y figurent plus. Les scripts supplémentaires sont en lecture seule depuis le 28 août 2025. Le suivi doit passer par les pixels des événements clients ou ceux des applications. Si votre achat GA4 partait d'un script de la page de remerciement, il a pu s'arrêter net à cette date. À vérifier d'abord si votre écart a sauté fin août ou en septembre.
- Des remboursements datés autrement. Shopify retire un retour le jour où il est traité, pas le jour de la commande. GA4, lui, ne retire rien tout seul : il lui faut un événement refund avec l'identifiant de la transaction. Pas de refund, et GA4 garde des ventes que la boutique a rendues.
- Des commandes comptées deux fois. GA4 s'appuie sur l'identifiant de transaction pour écarter les doublons. Tag déclenché deux fois, page de confirmation rechargée, identifiant absent ou différent d'un envoi à l'autre : l'achat compte double, et GA4 passe devant Shopify.
- Des commandes que le site n'a pas vues. Une commande saisie à la main, un paiement en point de vente, un abonnement renouvelé sans visite : elle est dans Shopify, et le tag de votre site n'avait aucune raison de la voir.
- Une période qui n'est pas la même. Une commande passée à 23 h 50 peut tomber dans la journée de Shopify et pas dans celle de GA4 si les deux ne sont pas réglés sur le même fuseau. Vérifiez le fuseau de la boutique et celui de la propriété avant de chercher plus loin.
Le rapprochement, commande par commande
Un total ne dit pas où est l'écart. Une jointure sur l'identifiant de la commande, si. Comptez une heure, avec un tableur, sur 28 jours entiers.
- Exportez les commandes de Shopify. Dans la liste des commandes, le bouton Exporter produit un fichier CSV avec le nom de la commande, le sous-total, la livraison, les taxes, le total, les remises et la date de création. Au-delà de 50 commandes, le fichier est envoyé par e-mail.
- Exportez le rapport Transactions de GA4. Une ligne par identifiant de transaction, avec le nombre d'achats et les revenus (figure ci-dessous). L'icône de partage du rapport propose de télécharger le fichier.
- Vérifiez ce que contient l'identifiant GA4. Numéro de commande, identifiant interne de Shopify, autre chose : c'est le tag qui décide. Sans identifiant commun, pas de jointure. Un achat de test vous le montre en une minute.
- Joignez sur l'identifiant, et classez chaque commande dans l'une des quatre familles du tableau ci-dessous. Une fois les familles comptées, la cause dominante saute aux yeux.

| La commande est… | Ce que ça veut dire | Où chercher |
|---|---|---|
| Dans les deux, au même montant | La mesure est bonne | Rien à faire |
| Dans les deux, à un montant différent | Une question de base ou de remboursement | L'écart est-il le même pourcentage (taxes) ? Égal à la livraison ? Égal à une remise ? Y a-t-il un remboursement chez Shopify ? |
| Dans Shopify seulement | Le tag n'a pas vu l'achat | Consentement refusé, bloqueur, tag ou pixel non déclenché sur la page de confirmation (migration du checkout comprise), commande saisie à la main ou en point de vente |
| Dans GA4 seulement | GA4 a compté un achat que la boutique n'a pas gardé | Commande de test, commande annulée ou impayée, identifiant de transaction différent d'un envoi à l'autre |
Et résultat ? La part de chaque famille vous dit où agir. Beaucoup de commandes « dans Shopify seulement » : la mesure perd des acheteurs. Le consentement est la première piste, et un pixel non migré vers les événements clients la seconde si l'écart a sauté d'un coup. Beaucoup de montants différents : une affaire de base ou de remboursements. Des commandes « dans GA4 seulement » : un tag qui se déclenche trop, ou des tests.
Quel écart est normal ?
Il n'existe pas de chiffre magique, et mieux vaut se méfier de ceux qu'on vous donne : une boutique dont les visiteurs refusent massivement la mesure aura un gros écart, parfaitement sain. Ce qui renseigne, c'est la stabilité : quand les deux chiffres sont sur la même base (net, hors taxes, hors livraison), un écart qui reste dans la même zone semaine après semaine vient du consentement et des bloqueurs. Un écart qui saute vient d'un changement : un bandeau, un thème, un tag, un moyen de paiement.
Voici quatre semaines d'une boutique d'exemple. Les chiffres sont illustratifs :
| Boutique d'exemple, 4 semaines | Shopify, net hors taxes | GA4 | Écart |
|---|---|---|---|
| Semaine 1 | 21 400 € | 19 300 € | −9,8 % |
| Semaine 2 | 22 800 € | 20 600 € | −9,6 % |
| Semaine 3 | 20 900 € | 18 900 € | −9,6 % |
| Semaine 4 | 23 100 € | 15 400 € | −33,3 % |
Pendant trois semaines, GA4 retrouve environ 90 % des ventes : c'est le niveau de la boutique, et il suffit pour comparer des périodes. La quatrième semaine, il n'en retrouve plus que les deux tiers. Rien n'a changé dans les ventes : c'est la mesure qui a changé. Une hypothèse à vérifier en premier : une mise en production du bandeau de consentement ou du thème, ou la migration du checkout, qui empêche le tag de se déclencher sur la page de confirmation. Sans suivi hebdomadaire de l'écart, on le découvre à la fin du mois. Notre règle : un écart qui bouge se traite comme une alerte, pas comme une curiosité.

Lequel croire ?
Cela dépend de la question. Un chiffre d'affaires est une transaction : la source qui l'est passe devant celles qui l'observent. Kyras applique cet ordre dans son assistant et son serveur MCP :
| Rang | Source | Ce que le chiffre est | Il sert à |
|---|---|---|---|
| 1. Encaissé | Shopify (ou votre outil de gestion) | La transaction elle-même | Dire combien vous avez vendu |
| 2. Mesuré | GA4, Piano Analytics, Matomo | Ce que le tag a vu : chaque commande une fois, mais pas toutes | Dire d'où viennent les ventes et ce que font les visiteurs |
| 3. Déclaré | Meta, Google Ads | Ce que la régie s'attribue, selon sa propre fenêtre | Comparer des campagnes d'une même régie |
Le troisième rang n'est jamais additionné : deux régies peuvent revendiquer la même vente. Et nous ne « recalons » jamais GA4 sur Shopify avec un coefficient : un chiffre forcé ne mesure plus rien. On garde l'écart, on le suit, on le laisse parler. Si Shopify n'est pas branché, Kyras prend l'outil d'analyse. S'il n'a que du déclaré, il l'écrit dans la réponse et nomme ce qui manquerait pour faire mieux. L'écart avec les régies est détaillé dans MER vs ROAS. Pour une boutique, l'analyse e-commerce de Kyras met ces trois chiffres côte à côte, avec leur source.
Réduire l'écart : cinq gestes
Cinq gestes, dans cet ordre. Le premier évite de chercher un écart qui n'existe pas.
- Mettez les deux chiffres sur la même base. Chiffre d'affaires net, hors taxes et hors livraison, côté Shopify. Côté GA4, retirez les taxes et la livraison que votre tag y ajoute. Comparer des ventes totales à une valeur nette fabrique un écart qui n'existe pas.
- Envoyez l'identifiant de transaction sur chaque achat. C'est lui qui évite les doublons, lui qui relie un remboursement à sa commande, et lui qui permet le rapprochement commande par commande.
- Envoyez les remboursements. Un événement refund par retour, avec l'identifiant de la commande. Pour un remboursement partiel, seuls les articles remboursés.
- Passez un achat de test, et suivez-le. De la page de confirmation jusqu'au rapport Transactions de GA4, avec le bandeau de consentement accepté puis refusé. Vous voyez où il disparaît, et ce que contient son identifiant.
- Vérifiez que le suivi d'achat ne dépend plus d'un script de page de remerciement. Dans Shopify, le suivi passe par les pixels des événements clients ou par ceux des applications. Un achat de test confirme que l'événement part.
- Mesurez l'écart chaque semaine, pas une fois. Un écart qui reste autour de la même valeur se comprend et se corrige. Un écart qui saute dit qu'un tag, un bandeau ou un thème a changé.
Sources
- Shopify, « Rapport des ventes » : ventes brutes, remises, retours, ventes nettes, ventes totales
- Shopify, « Pages de remerciement et de statut de commande » : échéance du 26 août 2026, pixels et blocs à la place des scripts
- Shopify, « Exporter des commandes » : le fichier CSV des commandes
- Google Analytics, « Dimensions et métriques » : revenus issus des achats, revenu des articles, revenu total, remboursements, identifiant de transaction
- Google Analytics, « Modélisation du comportement en mode Consentement refusé »
- Google pour les développeurs, « Configurer les événements e-commerce » : transaction_id, value, tax, shipping
- Google pour les développeurs, « Mesurer l'e-commerce » : l'événement refund


