Mesurer les abandons d'un tunnel de commande : les événements à suivre

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. 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 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) 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 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é.