---
type: "blog"
id: 13
url: "https://prestadev.pl/fr/blog/news/ga4-prestashop-absence-d-achats-mesure-des-ventes"
markdown_url: "https://prestadev.pl/fr/markdown/blog/13.md"
title: "Les commandes sont là, mais GA4 ne les voit pas ? Mesure des ventes dans PrestaShop"
description: "Des achats manquent dans GA4 ? Vérifiez les événements e-commerce, les statuts des commandes, le Measurement Protocol et les consentements, ainsi que le rôle de Google Analytics 4 Pro dans PrestaShop."
language: "fr"
published: "2026-09-12 17:03:43"
updated: "0000-00-00 00:00:00"
author: "Patryk Marek"
category: "News"
---

# Les commandes sont là, mais GA4 ne les voit pas ? Mesure des ventes dans PrestaShop

**La commande est dans PrestaShop, le paiement a été accepté, et Google Analytics 4 n’affiche pas l’achat. Avant de considérer la campagne comme inefficace, vérifiez si la boutique transmet à GA4 les événements appropriés et à quel moment elle le fait.** Le simple code de suivi sur le site ne suffit pas à mesurer les ventes. Le mode de finalisation de la commande, les identifiants de transaction, les consentements du client et les montants envoyés aux rapports ont également leur importance.

**La commande est bien présente dans PrestaShop, le paiement a été accepté, mais Google Analytics 4 n’affiche pas l’achat. Avant de considérer la campagne comme inefficace, vérifiez si la boutique transmet à GA4 les bons événements et à quel moment elle le fait.** Le simple code de suivi sur le site ne suffit pas pour mesurer les ventes. Le mode de finalisation de la commande, les identifiants de transaction, les consentements du client et les montants envoyés dans les rapports ont également leur importance.

 ## Pourquoi GA4 affiche-t-il les visites, mais pas les ventes ?

 L’affichage d’une page et un achat sont deux événements distincts. Pour que GA4 reçoive les informations de vente, l’intégration doit envoyer `purchase` avec les données de transaction et des produits. Google décrit ce mécanisme dans le [guide de configuration de l’événement d’achat](https://developers.google.com/analytics/devguides/collection/ga4/set-up-ecommerce). La présence d’utilisateurs dans le rapport en temps réel ne confirme donc qu’une partie de l’implémentation.

 Un autre piège fréquent consiste à comparer des données différentes. Dans le panneau de la boutique, vous pouvez compter toutes les commandes créées, tandis qu’en analytique, l’achat n’est enregistré qu’après un statut précis. Commencez par une transaction concrète : identifiez son numéro, son statut, sa valeur et le moment où elle devrait être transmise à GA4.

 ## Que mesurer entre l’entrée sur un produit et l’achat ?

 Les événements e-commerce permettent de vérifier à quelle étape le parcours d’achat s’interrompt. Un ensemble pratique comprend :

 | Événement GA4 | Ce qu’il décrit | À quoi il sert |
| --- | --- | --- |
| view\_item | Affichage du produit | Évaluation de l’intérêt pour l’offre |
| add\_to\_cart | Ajout du produit au panier | Comparaison entre la consultation et la décision d’achat |
| begin\_checkout | Début du processus de commande | Vérification du passage du panier à la finalisation |
| add\_shipping\_info, add\_payment\_info | Transmission des informations de livraison et de paiement | Analyse des étapes suivantes de la commande |
| purchase | Enregistrement de l’achat | Analyse des transactions et du chiffre d’affaires |

 Ces événements sont prévus par la [documentation e-commerce de GA4](https://developers.google.com/analytics/devguides/collection/ga4/ecommerce) et pris en charge par Google Analytics 4 Pro. Le rapport ou l’exploration du parcours se prépare dans Google Analytics. Une forte baisse entre les étapes est un signal pour vérifier la boutique : elle peut résulter aussi bien du comportement des clients que d’un événement manquant dans un checkout personnalisé.

 ## Le client n’est pas revenu après le paiement. L’achat sera-t-il transmis à GA4 ?

 **Si la mesure ne se déclenche que sur la page de confirmation, le client doit l’ouvrir.** La fermeture de l’onglet après le paiement peut interrompre ce scénario, même si la commande existe bien dans la boutique. C’est pourquoi le mode d’envoi de l’achat doit être adapté au déroulement réel du paiement.

 [Google Analytics 4 Pro pour PrestaShop](https://prestadev.pl/pl/google-analytics-4-pro-modul-dla-prestashop.html) propose trois modes :

 1. **Page de confirmation de commande.** L’événement est préparé après l’arrivée du client sur la confirmation. Avec un API Secret configuré, le module peut en plus envoyer l’achat depuis le serveur.
2. **Changement de statut de la commande.** Le module envoie l’achat via Measurement Protocol lors du passage à l’un des statuts sélectionnés. Ce mécanisme ne nécessite pas que le client rouvre la page ; il exige une configuration de l’API et un identifiant client GA4 préalablement enregistré.
3. **Clic sur le bouton de confirmation de commande.** Il s’agit d’une variante dépendante du fonctionnement du formulaire d’achat. Le simple clic ne confirme pas la réception du paiement ; il faut donc également vérifier le scénario d’échec de paiement.

 Si vous souhaitez mesurer les commandes payées, choisissez les statuts correspondant à l’acceptation du paiement. Pour le paiement à la livraison, définissez une règle distincte : l’acceptation de la commande et l’encaissement ultérieur sont deux moments différents.

 ## Le Measurement Protocol résout-il le problème des bloqueurs de publicité ?

 Le Measurement Protocol permet d’envoyer des événements depuis le serveur de la boutique directement vers Google Analytics. Il peut réduire la dépendance de la mesure d’achat au script du navigateur. Google le présente comme un [complément à la collecte standard des données](https://developers.google.com/analytics/devguides/collection/protocol/ga4).

 **Dans Google Analytics 4 Pro, l’envoi côté serveur nécessite également l’identifiant `client_id` enregistré avec la commande.** Le module le récupère à partir du cookie `_ga`. Si cet identifiant n’existe pas, le code ignore l’envoi via l’API. De plus, l’envoi de secours en mode page de confirmation exige toujours l’ouverture de cette page. Pour le problème de l’absence de retour après paiement, c’est donc le mode de changement de statut qui est déterminant. Aucun de ces mécanismes ne permet de promettre la mesure de chaque commande.

 ## Pourquoi le montant dans GA4 diffère-t-il du montant de la commande ?

 Vérifiez ce que vous comparez. Selon la [spécification de l’événement `purchase`](https://developers.google.com/analytics/devguides/collection/ga4/reference/events#purchase), le paramètre `value` doit correspondre à la somme des prix des produits multipliés par leurs quantités, hors taxe et hors livraison. Les champs `tax` et `shipping` sont distincts. Lors de la transmission des valeurs, la devise est également requise, par exemple `PLN`.

 **Exemple :** deux produits à 100 zł net donnent `value = 200`. Le montant payé par le client sera plus élevé si la TVA et la livraison ont été ajoutées. Comparer ces 200 zł au montant total TTC de la commande ne prouve pas en soi une perte de chiffre d’affaires.

 Lors de l’implémentation, vérifiez également la remise, le coupon, les quantités et la devise. Un contrôle séparé est nécessaire pour un panier avec une remise appliquée à l’ensemble de la commande : la valeur de la transaction et la somme des lignes doivent être cohérentes entre elles.

 ## D’où viennent les achats en double et les remboursements non pris en compte ?

 Vérifiez que `purchase` n’est pas envoyé simultanément par le module, Google Tag Manager et un code supplémentaire dans le thème. Pour le flux Web, GA4 utilise `transaction_id` afin de [supprimer les doublons d’achats du même utilisateur](https://support.google.com/analytics/answer/12313109?hl=en). Chaque transaction doit avoir son propre identifiant non vide, conservé lors d’un nouvel envoi du même achat.

 En mode confirmation et en envoi côté serveur, Google Analytics 4 Pro utilise la référence de la commande comme `transaction_id`. Malgré cela, si plusieurs intégrations sont combinées, vérifiez les événements réels : des identifiants différents pour un même achat peuvent fausser le résultat.

 Le module prend également en charge `refund` après le passage de la commande à un statut de remboursement sélectionné. Cet envoi nécessite un API Secret ainsi qu’un `client_id` enregistré et couvre la valeur totale ainsi que les lignes de la commande. **En cas de remboursement partiel, par exemple une unité sur trois, une gestion distincte des montants et quantités corrects est nécessaire.** L’attribution d’un statut de remboursement dans ce module ne traite pas automatiquement n’importe quelle correction partielle.

 ## Qu’en est-il des consentements et du Consent Mode v2 ?

 Le Consent Mode transmet aux balises Google des informations sur les consentements de l’utilisateur. Il nécessite une coopération avec la bannière ou un autre mécanisme de collecte des décisions. La documentation Google distingue [le mode de base et le mode avancé](https://developers.google.com/tag-platform/security/concepts/consent-mode), dans lesquels l’envoi des données avant consentement et après refus fonctionne différemment.

 Le module GA4 ne remplace pas la configuration des consentements. Dans son intégration avec PD Cookie Pro, la prise en charge des signaux publicitaires `ad_user_data` et `ad_personalization` a été prévue pour l’envoi côté serveur. Le comportement de l’ensemble de la mesure doit toutefois être vérifié avec la bannière utilisée dans la boutique concernée. L’activation de l’API Secret ne signifie pas que l’utilisateur a consenti à l’analytique ou à la publicité.

 ## Comment vérifier la mesure sur une seule commande ?

 1. **Vérifiez la destination des données.** L’identifiant `G-…` dans le module doit correspondre au flux Web que vous consultez dans GA4. Déterminez également quelles autres intégrations envoient des événements.
2. **Parcourez le tunnel d’achat.** Ouvrez un produit, ajoutez-le au panier et commencez la commande. Le module dispose d’un mode de débogage des événements navigateur ; vous pouvez consulter les paramètres dans [DebugView](https://support.google.com/analytics/answer/7201382?hl=en). Effectuez ce contrôle avec le consentement analytique accordé, puis vérifiez séparément le comportement en cas de refus.
3. **Vérifiez l’achat.** Comparez `transaction_id`, `value`, `currency` et `items` avec la commande. Tenez compte des produits avec variante et remise.
4. **Vérifiez le moment d’envoi sélectionné.** En mode statut, faites-le passer au statut d’achat configuré. Testez séparément un paiement sans retour à la boutique et un paiement échoué.
5. **Vérifiez la répétition et le remboursement.** Actualisez la confirmation, contrôlez le nombre de transactions et vérifiez un remboursement complet. Confirmez séparément dans GA4 le résultat des événements côté serveur : l’option de débogage du module concerne la balise dans le navigateur.

 Les rapports standards nécessitent du temps pour traiter les données. Google indique que cela peut prendre [24 à 48 heures](https://support.google.com/analytics/answer/11198161?hl=en). L’absence d’achat dans le rapport juste après le test ne signifie donc pas encore qu’il y a une erreur.

 ## GA4 dans PrestaShop : questions fréquentes

 ### Google Tag Manager est-il obligatoire ?

 Non. Google Analytics 4 Pro charge la balise Google et envoie les événements via `gtag.js`. Si la boutique utilise déjà GTM, définissez le périmètre des deux implémentations afin qu’elles n’envoient pas indépendamment les mêmes achats.

 ### Toutes les commandes doivent-elles correspondre exactement une à une ?

 Comparez d’abord la même période, les statuts, la devise et la méthode de calcul des montants. Les écarts peuvent aussi résulter des consentements, du blocage de la mesure et des délais de traitement. GA4 sert à analyser le comportement et les ventes ; pour le rapprochement des commandes, appuyez-vous sur les données de la boutique et des paiements.

 ### Par quoi commencer si les rapports sont vides ?

 Commencez par vérifier l’identifiant GA4 et un seul achat. Déterminez si l’événement est bien généré, s’il contient les produits ainsi que la valeur, et s’il est envoyé vers le bon flux. Ce n’est qu’ensuite que vous pourrez comparer les rapports agrégés des campagnes.

 [Google Analytics 4 Pro](https://prestadev.pl/pl/google-analytics-4-pro-modul-dla-prestashop.html) permet d’implémenter les événements e-commerce dans PrestaShop et d’adapter le mode d’enregistrement des achats au fonctionnement de la boutique. Commencez par cette configuration et par une transaction vérifiée : il sera alors plus facile de déterminer si les faibles résultats de la campagne proviennent des ventes ou de lacunes dans la mesure.