Comment configurer le tracking e-commerce GA4 sur PrestaShop (la bonne méthode)

Google Analytics 4 peut être un outil réellement puissant pour une boutique PrestaShop — ou une source de chiffres auxquels vous ne faites secrètement pas confiance. La différence tient presque toujours à la configuration. Réussissez les événements e-commerce, le chiffre d'affaires et la méthode de livraison, et GA4 devient une image fiable de votre tunnel. Ratez-les, et vous prenez des décisions sur des données qui contredisent discrètement votre back-office.

Voici la version pratique : quoi suivre, comment, et les erreurs qui piègent presque tout le monde. C'est écrit pour les e-commerçants, pas pour les analystes, afin que vous puissiez juger si votre configuration fait réellement son travail.

Les événements e-commerce qui comptent

GA4 dispose d'un ensemble défini d'événements e-commerce recommandés, et une bonne configuration PrestaShop déclenche l'ensemble du tunnel PrestaShop : le parcours de la découverte à l'après-achat — navigation et pages produit, chaque mouvement de panier, chaque étape du paiement, la vente elle-même, et les signaux post-vente et de compte qui suivent. La grille étape par étape de notre page module liste chaque événement par son nom. GA4 enregistre aussi de lui-même des événements automatiques — session_start, first_visit, user_engagement — ; une configuration saine les préserve plutôt que de les combattre, pour que vos comptes de sessions et de nouveaux utilisateurs restent justes.

Ensemble, ces événements permettent à GA4 de reconstruire tout le parcours : combien de personnes ont vu une catégorie, consulté un produit, commencé le paiement et terminé. Des lacunes au milieu cassent les rapports de tunnel et rendent impossible de voir où les acheteurs abandonnent.

Chaque événement a aussi besoin des bons paramètres — ID d'articles, noms, prix, quantités et une devise — sinon les rapports e-commerce de GA4 restent vides même si les événements se déclenchent. L'échec le plus courant est de déclencher purchase sans tableau d'articles ni valeur, ce qui rend la remontée du chiffre d'affaires inutilisable. Voyez notre page tracking GA4 pour la vue d'ensemble.

measurement_id : réussir la tuyauterie

Chaque flux de données GA4 possède un measurement_id (la valeur G-XXXXXXX). Il indique à Google à quelle propriété appartiennent les événements. Cela paraît trivial, mais des measurement_id absents ou erronés sont une raison étonnamment fréquente pour laquelle les données n'atterrissent nulle part — ou dans la mauvaise propriété.

Utilisez un seul measurement_id de façon cohérente entre le côté client et le côté serveur, et confirmez qu'il correspond à la propriété depuis laquelle vous faites réellement vos rapports. Une erreur classique est d'avoir l'ID d'une ancienne propriété codé en dur dans un thème pendant que la nouvelle propriété reste vide, vous laissant fixer des zéros et supposer que le tracking est cassé.

Si vous exploitez des boutiques de préproduction et de production, gardez leurs flux séparés pour que les commandes de test ne polluent jamais les données réelles. Rien n'érode plus vite la confiance dans l'analyse que de découvrir que vos achats de test ont gonflé le chiffre d'affaires du trimestre dernier.

Envoyez le chiffre d'affaires TVA incluse

PrestaShop peut remonter le chiffre d'affaires de plusieurs façons, et le mauvais choix sous-estime silencieusement vos chiffres. GA4 devrait recevoir le total TVA incluse que le client a réellement payé — total_paid_tax_incl — et non le sous-total hors taxes.

Si votre chiffre d'affaires dans GA4 paraît systématiquement inférieur à votre back-office d'un pourcentage suspicieusement rond, une valeur hors taxes en est presque toujours la cause. L'écart correspond à votre taux de TVA.

La correction réaligne le chiffre d'affaires GA4 sur l'argent réellement encaissé, ce qui compte dès l'instant où vous calculez le ROAS ou alimentez le Smart Bidding avec des valeurs de conversion. Enchérir sur des valeurs sous-estimées revient à sous-enchérir sur vos meilleurs clients.

Pourquoi la plupart des configurations perdent des conversions en silence

Même une configuration GA4 côté client parfaitement réglée perd des commandes. L'événement purchase se déclenche dans le navigateur, donc les bloqueurs de publicités, l'ITP d'Apple, les connexions mobiles lentes et les acheteurs qui ferment l'onglet de confirmation dévorent tous des conversions avant qu'elles n'atteignent Google. La sous-estimation est la plus lourde sur le mobile et les audiences soucieuses de leur vie privée.

Il y a aussi le problème des doublons dans l'autre sens : si purchase peut se déclencher deux fois — disons lors d'un rechargement de page ou d'un clic sur le bouton retour — avec un ID aléatoire à chaque fois, GA4 compte deux ventes pour une seule commande. Sous-estimation et surestimation empilées rendent le vrai chiffre presque impossible à cerner.

Un transaction_id construit à partir de la commande elle-même empêche les doublons, en réduisant rechargements et nouvelles tentatives à une seule commande. Mais il ne peut pas récupérer les événements qui ne se sont jamais déclenchés — pour cela, c'est la livraison elle-même qui doit changer.

Réparez la livraison, pas seulement les balises

Le changement le plus important est d'arrêter tout bonnement de demander au navigateur de rapporter vos ventes. Quand PrestaShop confirme une commande, PrestaSignal rapporte la vente depuis votre back-office à un serveur de suivi géré que nous opérons pour vous, qui la transmet à GA4 avec le montant réellement payé, la devise et un transaction_id construit à partir de la commande elle-même. La vente est enregistrée exactement une fois — un rechargement ne peut jamais compter double — et les remboursements suivent avec le transaction_id correspondant pour que GA4 reverse le chiffre d'affaires correctement.

Les événements du quotidien restent dans le navigateur, là où les données comportementales ont leur place — mais ils cessent de voyager vers les domaines de Google. Le module place un petit connecteur sur votre propre adresse web, et les pages vues, les vues produit et les événements de panier sont enregistrés à travers lui ; même les bibliothèques de balises Google se chargent depuis votre domaine. Les listes de filtres des bloqueurs de publicités actuels ciblent googletagmanager.com et google-analytics.com — tout étant servi depuis votre propre adresse, il n'y a sur la page aucun domaine d'analyse tiers à leur faire correspondre.

C'est une seule conception intégrée, pas un mode à choisir : les événements navigateur sur une route, vos ventes sur une seconde route sans navigateur, les deux partageant un event_id pour que GA4 les déduplique. Les données personnelles sont traitées là où il faut, elles aussi — le module normalise et hache en SHA-256 l'e-mail, le téléphone et le nom à l'intérieur de votre boutique, avant que quoi que ce soit n'en sorte. Lisez comment ça marche pour les spécificités PrestaShop.

Rien de tout cela ne signifie repartir de zéro. Vous gardez la même propriété GA4, le même measurement_id et tout votre historique ; ce qui change, c'est la route que vos événements empruntent, pas l'endroit où ils atterrissent.

Une courte liste de contrôle

Avant de considérer votre configuration GA4 comme terminée, vérifiez quelques points. Chaque événement du tunnel se déclenche avec les bons paramètres d'articles et la bonne devise. L'événement purchase porte une valeur TVA incluse et un transaction_id construit à partir de la commande elle-même. Le measurement_id correspond à votre propriété de reporting et à rien d'autre. Et la vente est rapportée depuis votre back-office plutôt que par le navigateur, en partageant un event_id avec le versant navigateur pour que rien ne soit compté deux fois.

Parcourez cette liste et vous attraperez les problèmes qui sapent silencieusement la plupart des analyses PrestaShop. Sautez-la, et vous risquez de bâtir une stratégie sur des chiffres qui paraissent précis mais sont discrètement faux.

Si tout cela paraît beaucoup à vérifier à la main, c'est exactement ce que PrestaSignal configure d'emblée. Réservez un audit et nous examinerons vos événements GA4 actuels face à vos vraies commandes, ligne par ligne.