Disponible pour missions & renforts d’agence · Réponse rapide, par la personne qui intervient

Suivi ecommerce GA4 : les évènements qui comptent vraiment

GA4 propose une quinzaine d’évènements ecommerce recommandés, du view_item_list jusqu’au refund. Un tunnel de vente n’a besoin que de cinq ou six d’entre eux pour être mesuré correctement : le reste sert à affiner une base déjà fiable, pas à la remplacer.

Décrire mon problème Discuter sur WhatsApp

Ce que je constate le plus souvent

  • Un conteneur GTM avec douze à quinze balises ecommerce, dont la moitié ne se déclenche jamais
  • Un évènement purchase qui remonte deux fois quand le client actualise la page de confirmation
  • Des rapports ecommerce GA4 vides malgré des balises qui se déclenchent bien en mode aperçu
  • Un projet qui veut tout suivre dès le lancement et qui n’a, six mois plus tard, ni dataLayer fiable ni personne pour le maintenir
  • Un panier moyen ou un taux de conversion produit impossibles à calculer faute de value ou de currency correctement transmis

Comment je priorise l’installation

  1. purchase, seul évènement obligatoire dès le lancement

    Sans lui, aucun chiffre d’affaires n’est mesurable, aucun ROAS calculable côté Google Ads ou Meta. Je vérifie qu’il se déclenche une seule fois par commande, avec un transaction_id stable et un value/currency qui correspondent exactement au montant encaissé.

  2. add_to_cart et begin_checkout, pour mesurer l’abandon

    Ces deux évènements suffisent à voir où le tunnel perd des visiteurs entre l’ajout au panier et le début du paiement. C’est la deuxième priorité, une fois purchase fiable.

  3. view_item et view_item_list, quand le catalogue est le point faible

    Utiles pour calculer un taux de conversion par fiche produit ou par page de catégorie. Je les installe en troisième priorité, surtout sur un catalogue large ou plusieurs gammes à comparer.

  4. view_cart, add_shipping_info, add_payment_info, pour affiner

    Ces étapes intermédiaires précisent où, dans le tunnel de paiement, un visiteur abandonne. Elles ont du sens une fois la base stable, rarement en priorité un.

  5. refund, en dernier, sauf activité avec beaucoup de retours

    Pertinent seulement si le volume de remboursements ou d’annulations pèse dans le pilotage ; sinon, ce n’est pas une priorité de lancement.

Des noms et des paramètres qui ne se négocient pas

Les principaux évènements ecommerce recommandés par GA4 — view_item_list, view_item, add_to_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, refund — ont des noms et des paramètres fixés par Google. La liste complète en compte d’autres, notamment select_item, remove_from_cart, add_to_wishlist, view_promotion et select_promotion. Renommer un évènement ou modifier la structure de son paramètre items ne casse rien visuellement, mais rend les rapports ecommerce standard de GA4 incapables de le reconnaître.

Deux paramètres méritent une attention particulière. transaction_id doit être unique par commande : c’est lui qui permet à GA4 de dédupliquer un purchase rejoué au rechargement de la page de confirmation. value et currency doivent refléter exactement le montant réellement encaissé, dans la bonne devise : une valeur mal transmise (hors taxes au lieu de toutes taxes comprises, devise fixe sur un site multi-devises) fausse tout le chiffre d’affaires mesuré, sans qu’aucune erreur ne s’affiche nulle part.

Pages liées

Décrivez votre besoin en 1 minute

Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.

Quel outil faut-il connecter ?
L’outil dispose-t-il d’une API documentée ?

Sans API, il reste souvent l’import de fichiers — c’est faisable, mais différent.

Dans quel sens les données doivent-elles circuler ?
À quelle fréquence la synchronisation doit-elle tourner ? (facultatif)
Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Indiquez au moins un e-mail ou un téléphone pour que je puisse vous répondre.

Questions fréquentes

Faut-il installer tous les évènements ecommerce dès le lancement ?
Non. purchase est le seul indispensable dès le premier jour. Les autres s’ajoutent progressivement, dans l’ordre où ils apportent une information exploitable, pas tous en même temps.
Que se passe-t-il si je renomme un évènement à ma façon ?
Les rapports ecommerce standard de GA4 ne le reconnaîtront pas. L’évènement peut très bien se déclencher et n’apparaître nulle part dans les tableaux prévus pour lui.
Pourquoi mon chiffre d’affaires GA4 ne correspond-il jamais exactement à mes commandes réelles ?
C’est un écart structurel connu (refus de consentement, bloqueurs, parcours multi-appareils…), pas forcément un bug. Je vérifie d’abord que value et transaction_id sont bien transmis avant de chercher plus loin.
Google Tag Manager ou gtag.js directement dans le thème ?
Les deux fonctionnent techniquement. GTM centralise les balises et évite une mise en production à chaque changement ; c’est ce que je recommande dès qu’il y a plus de deux ou trois évènements à gérer.
Combien de temps pour mettre en place les évènements prioritaires ?
Poser purchase, add_to_cart et begin_checkout avec des paramètres fiables se fait généralement en quelques heures, une fois le dataLayer ou le point d’intégration identifié sur la plateforme.