Une boutique qui n’envoie que l’événement d’achat à GA4 dispose d’un chiffre d’affaires et de rien d’autre. Aucun taux d’abandon par étape, aucun produit vu sans être ajouté, aucune analyse de la performance des listes. La valeur de GA4 sur une boutique vient de la chaîne complète, pas du dernier maillon.
Sept événements suffisent à la reconstituer.
Les sept événements
- view_item_list : affichage d’une liste de produits, catégorie, résultats de recherche, bloc de recommandations. Il permet de comparer la performance des emplacements entre eux.
- select_item : clic sur un produit depuis une liste. Couplé au précédent, il donne le taux de clic par liste.
- view_item : consultation d’une fiche produit. La base de tout le reste.
- add_to_cart : ajout au panier. Rapporté à view_item, il donne le taux d’ajout, indicateur le plus utile au niveau produit.
- begin_checkout : entrée dans le tunnel. C’est la borne qui sépare la navigation de l’achat.
- add_payment_info : choix du moyen de paiement. Le dernier point de mesure avant la validation, et celui qui isole les abandons liés au paiement.
- purchase : commande validée, avec le détail des articles.
Un huitième mérite d’être ajouté quand il est simple à câbler : remove_from_cart, qui signale les produits retirés au moment de découvrir les frais de port.
La structure des articles
Tous ces événements partagent la même structure de description des articles, et la cohérence entre eux est ce qui fait la différence entre des données exploitables et un rapport illisible.
Cinq paramètres comptent par article : l’identifiant, le nom, la catégorie, le prix unitaire et la quantité. Deux autres sont utiles : la marque et la variante.
L’identifiant est le point critique. Il doit être strictement le même dans tous les événements, et surtout identique à celui utilisé dans votre flux produit vers Google. Une boutique qui envoie la référence dans un événement et l’identifiant interne dans un autre obtient deux fiches produit distinctes dans ses rapports, pour le même article.
La déclinaison doit être traitée explicitement. Décidez si l’identifiant porte sur le produit ou sur la déclinaison, et tenez cette règle partout. Les deux choix se défendent, le mélange non.
Google Tag Pro - Plug & PlayLe tracking e-commerce qui ne perd plus de conversions.€190.00
Prix hors taxes ou toutes taxes comprises
Question qui n’a pas de réponse universelle et qui doit être tranchée avant le câblage.
La convention la plus courante en Europe consiste à envoyer les prix toutes taxes comprises, parce que c’est ce que le client paie et ce qui figure sur la commande. L’alternative, hors taxes, facilite le rapprochement avec la comptabilité.
Ce qui compte davantage que le choix : que la valeur de la commande soit calculée de la même façon, et que vous sachiez laquelle vous avez retenue quand vous comparerez GA4 à votre back-office six mois plus tard.
Deux éléments à exclure de la valeur de la transaction : les frais de port et les taxes se déclarent dans des paramètres dédiés, pas dans le montant total. Les inclure gonfle artificiellement le chiffre d’affaires produit.
Les erreurs classiques
L’achat compté deux fois. La page de confirmation rechargée ou remise en cache renvoie l’événement. C’est de loin l’anomalie la plus fréquente, et elle fausse le chiffre d’affaires à la hausse. La protection consiste à marquer la commande comme déjà envoyée, côté serveur ou en stockage local, et à ne jamais déclencher l’événement deux fois pour un même identifiant de transaction.
L’identifiant de transaction absent ou non unique. Sans lui, GA4 ne peut pas dédoublonner. Utilisez la référence de commande, jamais un horodatage.
Les frais de port dans la valeur. Voir plus haut.
L’événement d’achat déclenché avant la validation du paiement. Sur un paiement redirigé, la commande peut échouer après l’envoi de l’événement. Le déclenchement doit se faire sur la page de confirmation réelle, après retour du prestataire.
Les listes non nommées. Si toutes vos listes portent le même nom, vous ne saurez jamais si vos blocs de recommandation fonctionnent.
Le consentement
Sans consentement, aucun de ces événements ne doit partir avec des identifiants. Le mode de consentement permet de conserver une mesure agrégée en l’absence de consentement, à condition qu’il soit correctement câblé et que les signaux soient transmis avant le chargement des balises.
Un point pratique souvent découvert trop tard : si votre bandeau bloque les scripts jusqu’au consentement, les événements déclenchés pendant ce délai sont perdus. Prévoyez une file d’attente qui les rejoue après acceptation, plutôt que de les laisser tomber.
Vérifier
Trois niveaux de contrôle, à faire dans cet ordre.
La couche de données. Dans la console du navigateur, inspectez son contenu à chaque étape et vérifiez la présence et la forme des paramètres. C’est là que se voient les identifiants incohérents et les prix mal formatés.
Le mode de débogage de GA4. Il affiche les événements en temps réel avec leurs paramètres, et signale ceux qui sont rejetés. Passez une commande complète en observant cet écran.
Le rapprochement chiffré. Après deux semaines, comparez le nombre de commandes et le chiffre d’affaires de GA4 avec votre back-office.
L’écart normal avec le back-office
Ne cherchez pas l’égalité parfaite, elle n’existe pas. Un écart de 5 à 15 % en moins dans GA4 est attendu, et il s’explique : refus de consentement, bloqueurs de publicité, navigations privées, commandes prises par téléphone, et clients quittant la page avant l’envoi de l’événement.
Ce qui doit vous alerter, c’est un écart supérieur à 25 %, ou un écart positif, GA4 comptant plus de commandes que votre back-office. Le second signale presque toujours un double comptage.
Le module Google Tag Pro pour PrestaShop câble cette chaîne sur PrestaShop 8 et 9 : les événements e-commerce avec une structure d’articles cohérente, la protection contre le double envoi de l’achat, et l’articulation avec le consentement.