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 ceux qui correspondent à votre tunnel. La liste principale va de la découverte à l'après-achat : page_view, view_item_list, view_item, add_to_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, et des signaux post-vente comme refund, plus des événements de compte tels que sign_up.

Ensemble, ces quelque treize é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 inutile. Voyez notre page tracking GA4 pour la correspondance complète avec les hooks PrestaShop.

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. Une sous-estimation de 30 à 50 % est courante, et elle 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 commande. Sous-estimation et surestimation empilées rendent le vrai chiffre presque impossible à raisonner.

Un transaction_id déterministe dérivé de la référence de commande empêche les doublons, réduisant rechargements et nouvelles tentatives à une seule commande. Mais il ne peut récupérer les événements qui ne se sont jamais déclenchés — seule la livraison côté serveur le peut.

Faites-le côté serveur

La solution aux fuites est d'envoyer vos événements e-commerce — surtout purchase — depuis le serveur, pas le navigateur. Un conteneur sGTM auto-hébergé reçoit les événements de PrestaShop et les transmet à GA4 avec la bonne valeur, la bonne devise et un transaction_id stable, immunisé contre ce que le navigateur fait ou échoue à faire.

La bonne pratique est hybride : des événements côté client pour le comportement, des événements côté serveur comme filet de sécurité fiable, les deux partageant un event_id pour que GA4 les déduplique. Cela vous donne à la fois la richesse complète du tunnel et des chiffres de commandes dignes de confiance, plutôt que de forcer un choix entre les deux.

C'est aussi là que la gestion des PII se place. Router les données par un serveur que vous contrôlez vous permet de hacher l'e-mail et le téléphone avant qu'ils n'atteignent Google, ce qui garde votre configuration plus propre sur le plan de la confidentialité et vous offre un endroit unique pour décider de ce qui quitte votre boutique. Lisez comment ça marche pour les spécificités PrestaShop.

Rien de tout cela ne signifie arracher ce que vous avez. Vous gardez la même propriété GA4, le même measurement_id et vos balises côté client existantes ; la livraison côté serveur s'installe simplement à côté comme la couche fiable qui rattrape ce que le navigateur laisse tomber.

Une courte liste de contrôle

Avant de considérer votre configuration GA4 comme terminée, vérifiez quelques points. Chaque événement de 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 déterministe. Le measurement_id correspond à votre propriété de reporting et à rien d'autre. Et les événements critiques sont envoyés côté serveur, dédupliqués face à la version côté client sur un event_id partagé.

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.