# 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.

- Source canonique : [https://allaux.fr/services/tracking/evenements-ecommerce-qui-comptent](https://allaux.fr/services/tracking/evenements-ecommerce-qui-comptent)
- Langue : FR
- Dernière mise à jour : 2026-09-30

## Réponse directe

> Commencez par purchase : sans lui, aucun chiffre d’affaires n’est mesurable. Vérifiez qu’il part une seule fois par commande, avec transaction_id, value, currency et le tableau items renseignés. Ajoutez ensuite add_to_cart et begin_checkout pour situer l’abandon, puis view_item. Les autres évènements recommandés n’ont d’intérêt qu’une fois ces quatre-là fiables dans DebugView.

## 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.

## Cinq évènements fiables valent mieux que quinze approximatifs

> Un rapport ecommerce GA4 basé sur purchase, add_to_cart et begin_checkout bien alimentés donne des chiffres exploitables. Quinze évènements posés à la hâte, avec des paramètres incomplets ou incohérents d’une page à l’autre, donnent des chiffres qu’il faut vérifier avant de les croire — ce qui revient à ne pas en avoir.

## 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. ([/services/tracking/conversions-ne-remontent-pas](/services/tracking/conversions-ne-remontent-pas))
- **Des statistiques en double** — Les causes les plus fréquentes de doublons, notamment sur purchase rejoué au rechargement. ([/services/tracking/doublons-statistiques-causes](/services/tracking/doublons-statistiques-causes))
- **Vérifier une installation sans outil payant** — Mode aperçu GTM, Tag Assistant, onglet Réseau : comment contrôler ce qui part réellement. ([/services/tracking/verifier-installation-balise-sans-outil-payant](/services/tracking/verifier-installation-balise-sans-outil-payant))
- **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. ([/services/tracking/pixel-meta-api-conversions-woocommerce](/services/tracking/pixel-meta-api-conversions-woocommerce))
- **Intégrations et API** — Quand le suivi doit s’appuyer sur des données produit ou commande exposées par une API. ([/services/integrations-api](/services/integrations-api))
- **Suivi des conversions ChatGPT Ads** — Pixel OpenAI, Conversions API, oppref et consentement : la même logique pixel plus serveur, appliquée aux annonces ChatGPT. ([/services/tracking/suivi-conversions-chatgpt-ads](/services/tracking/suivi-conversions-chatgpt-ads))

## FAQ

### 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.