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.
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
-
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é.
-
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.
-
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.
-
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.
-
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
-
Les conversions ne remontent pas
Méthode de diagnostic, étape par étape, quand un évènement se déclenche mais n’apparaît pas dans les rapports.
-
Des statistiques en double
Les causes les plus fréquentes de doublons, notamment sur purchase rejoué au rechargement.
-
Vérifier une installation sans outil payant
Mode aperçu GTM, Tag Assistant, onglet Réseau : comment contrôler ce qui part réellement.
-
Le pixel Meta et l’API de conversions
Le même souci de fiabilité s’applique côté Meta, avec un identifiant d’évènement à dédupliquer.
-
Intégrations et API
Quand le suivi doit s’appuyer sur des données produit ou commande exposées par une API.
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.