> Les événements e-commerce GA4 à envoyer pour voir à quelle étape un tunnel de commande perd ses visiteurs : view_item, add_to_cart, begin_checkout, add_shipping_info, add_payment_info, purchase, avec le code dataLayer et les pièges courants. *Source : https://coder-studio.com/tutoriels/mesurer-abandons-tunnel-de-commande/* --- [// JavaScript](https://coder-studio.com/tutoriels/) # Mesurer les abandons d'un tunnel de commande : les événements à suivre Par **Kévin Papot** · publié le 12 novembre 2026 Une boutique en ligne qui vend moins que prévu pose presque toujours la même question à l’équipe technique : à quel moment les visiteurs abandonnent-ils ? Sur la fiche produit, au panier, au moment de saisir l’adresse, devant le formulaire de paiement ? Sans mesure, chacun a son hypothèse. Avec une poignée d’événements bien placés, Google Analytics 4 dessine l’entonnoir étape par étape et montre où la perte se concentre. Ce tutoriel décrit les événements à envoyer, la façon de les pousser dans le `dataLayer` et les erreurs qui rendent les chiffres faux sans que personne ne s’en aperçoive. ## Une étape du tunnel, un événement GA4 propose une liste d’événements e-commerce recommandés, documentée dans le [guide e-commerce de Google Analytics](https://developers.google.com/analytics/devguides/collection/ga4/ecommerce). Reprendre ces noms exacts, plutôt que d’inventer les vôtres, permet aux rapports de monétisation et aux explorations en entonnoir de les reconnaître. Pour un tunnel de commande classique, six suffisent : Étape du parcours Événement GA4 Moment de l’envoi Consultation d’un produit `view_item` affichage de la fiche produit Ajout au panier `add_to_cart` clic sur le bouton, une fois l’ajout confirmé Début du paiement `begin_checkout` arrivée sur la première étape de commande Livraison renseignée `add_shipping_info` validation de l’adresse et du mode de livraison Paiement renseigné `add_payment_info` choix du moyen de paiement Achat `purchase` affichage de la page de confirmation La liste officielle en compte d’autres (`view_item_list`, `select_item`, `view_cart`, `remove_from_cart`, `refund`…), utiles pour affiner, mais ces six-là couvrent le chemin qui mène à la vente. Chaque événement transporte un tableau `items` décrivant les produits concernés, avec au minimum un `item_id` ou un `item_name`, ainsi que `currency` et `value` pour les étapes qui portent un montant. ## Pousser les événements dans le dataLayer Avec Google Tag Manager, le site ne parle pas directement à GA4 : il dépose des objets dans `window.dataLayer`, et une balise GA4 configurée dans Tag Manager les transmet. Voici l’ajout au panier, déclenché après la réponse du serveur plutôt qu’au simple clic, pour ne pas compter un ajout qui a échoué : ``` window.dataLayer = window.dataLayer || []; async function ajouterAuPanier(produit, quantite) { const reponse = await fetch('/api/panier', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ id: produit.id, quantite }), }); if (!reponse.ok) return; window.dataLayer.push({ ecommerce: null }); // vide l'objet de l'événement précédent window.dataLayer.push({ event: 'add_to_cart', ecommerce: { currency: 'EUR', value: produit.prix * quantite, items: [{ item_id: produit.sku, item_name: produit.nom, price: produit.prix, quantity: quantite, }], }, }); } ``` La ligne `{ ecommerce: null }` évite qu’un champ de l’événement précédent, resté dans la mémoire du `dataLayer`, se retrouve fusionné avec le suivant. Le branchement sur le bouton relève d’un écouteur classique ; si vous hésitez entre délégation et écoute directe, notre article sur les [écouteurs d’événements en JavaScript](https://coder-studio.com/tutoriels/event-listener-javascript/) compare les deux. L’achat suit la même forme, avec un champ de plus, `transaction_id`, que Google marque comme obligatoire : ``` window.dataLayer.push({ ecommerce: null }); window.dataLayer.push({ event: 'purchase', ecommerce: { transaction_id: commande.numero, currency: 'EUR', value: commande.totalHt, shipping: commande.fraisPort, tax: commande.tva, items: commande.lignes.map(l => ({ item_id: l.sku, item_name: l.nom, price: l.prix, quantity: l.quantite, })), }, }); ``` Les données de la commande doivent venir du serveur (injectées dans la page de confirmation), jamais d’un calcul refait dans le navigateur. ## Trois pièges qui faussent l’entonnoir **Les achats comptés deux fois.** Le client recharge la page de confirmation, revient en arrière, rouvre l’onglet le lendemain : à chaque affichage, `purchase` repart. La documentation de Google indique que `transaction_id` aide à éviter les doublons d’achat, c’est la première protection, à condition d’envoyer le vrai numéro de commande et non une valeur générée à chaque chargement. Ajoutez une seconde barrière côté navigateur : notez le numéro envoyé (par exemple avec [localStorage](https://coder-studio.com/tutoriels/localstorage-javascript/)) et ne poussez pas l’événement s’il y figure déjà. Le plus sûr reste de faire rendre l’événement par le serveur une seule fois, au premier affichage de la commande. **Le consentement qui efface une partie du trafic.** Tant que le visiteur n’a pas accepté les cookies de mesure, GA4 ne doit pas déposer ses cookies. Selon la configuration du mode Consentement de Google, les événements de ces visiteurs sont soit absents, soit envoyés sans identifiant et partiellement modélisés. Conséquence : l’entonnoir ne décrit qu’une partie de votre audience, et si le bandeau apparaît en plein tunnel, une étape peut sembler perdre des visiteurs qui n’ont en réalité jamais été mesurés. Comparez le nombre d’achats dans GA4 avec celui de votre base de commandes : l’écart donne l’ordre de grandeur de ce que vous ne voyez pas. **Les événements envoyés trop tôt.** Un `dataLayer.push` exécuté avant le chargement du conteneur Tag Manager n’est pas perdu, puisque le tableau est lu à l’initialisation. En revanche, un appel direct à `gtag()` avant sa définition lève une erreur, et un événement poussé juste avant une redirection (vers la banque, par exemple) peut ne jamais partir si la page se ferme avant l’envoi. Déclarez `window.dataLayer` tout en haut de la page, et pour les étapes suivies d’une navigation, envoyez l’événement depuis la page d’arrivée plutôt qu’au clic. ## Lire l’entonnoir, puis regarder les pages Une fois les six événements en place, l’exploration « Entonnoir » de GA4 affiche, étape par étape, le nombre d’utilisateurs et le taux d’abandon. Si une grande part des paniers n’atteint jamais `begin_checkout` sur votre boutique, vous savez où chercher. Les chiffres s’arrêtent là : ils montrent où l’on perd les visiteurs, pas pourquoi. Des frais de port découverts trop tard, un champ de formulaire refusé sans message clair, un bouton de paiement sous la ligne de flottaison sur mobile, une création de compte imposée : aucun de ces freins n’apparaît dans un rapport. Il faut alors un regard sur les pages elles-mêmes, idéalement par quelqu’un qui n’a pas construit le site. Des agences comme [Newp](https://www.newp.fr/audit-cro/) proposent un audit de conversion gratuit qui part de cette lecture manuelle du tunnel de commande et rend un plan d’action priorisé. En interne, quelques tests utilisateurs sur l’étape qui décroche donnent déjà beaucoup d’indices. ## Vérifier avant de faire confiance aux chiffres Avant de tirer la moindre conclusion, passez la commande vous-même avec le mode Aperçu de Tag Manager et la vue DebugView de GA4 ouverts. Contrôlez que chaque étape apparaît une seule fois, dans le bon ordre, avec le tableau `items` rempli et des montants cohérents. Rechargez la page de confirmation pour vérifier qu’aucun second `purchase` ne part. Refusez les cookies, puis acceptez-les, pour voir ce que GA4 reçoit dans les deux cas. Ces dix minutes de test évitent de passer des semaines à optimiser une étape dont la baisse ne venait que d’un événement mal déclenché.