Aller au contenu

Événements e-commerce

| Article: 2 min de lecture | Analytique

Les événements e-commerce sont des messages que le site d'une boutique envoie à l'outil d'analyse à chaque étape du parcours de l'acheteur : liste de produits affichée, produit consulté, ajout au panier, début du paiement, achat, remboursement. Ils permettent de construire le tunnel de conversion, les rapports de chiffre d'affaires par source et par produit.

En clair

Sans ces événements, l'outil d'analyse voit les pages ouvertes mais ne comprend pas ce qui s'y passe. Avec eux, on voit combien de personnes ont regardé un produit, combien l'ont mis au panier et combien ont payé. Pour GA4, Google décrit un ensemble d'événements recommandés ; si vous respectez ses noms, les rapports et les tunnels standard fonctionnent sans configuration supplémentaire.

L'ensemble d'événements GA4 recommandé

Dans l'ordre du parcours de l'acheteur (documentation Google) :

Étape

Événement

Liste de produits

`view_item_list`, `select_item`

Fiche produit

`view_item`, `add_to_wishlist`

Panier

`add_to_cart`, `view_cart`, `remove_from_cart`

Paiement

`begin_checkout`, `add_shipping_info`, `add_payment_info`

Résultat

`purchase`, `refund`

Pour les promotions, il existe `view_promotion` et `select_promotion`.

Ce qu'il faut envoyer

D'après la documentation de Google :

  • dans `purchase` et `refund`, un `transaction_id` (un numéro de commande unique) ;
  • dans les événements comportant un montant, `currency` avec `value` ;
  • dans `purchase`, `value` doit être égal à la somme « prix × quantité » de tous les produits ;
  • chaque produit du tableau `items` doit avoir un `item_id` ou un `item_name` (Google recommande les deux) ; si la quantité n'est pas indiquée, 1 est utilisé ;
  • `items` peut contenir jusqu'à 200 éléments ;
  • envoyez tous les paramètres pour lesquels vous avez des données.

Les anciens noms `ecommerce_purchase` et `ecommerce_refund` ont été remplacés par `purchase` et `refund`.

Exemple (chiffres illustratifs)

Un acheteur a acheté une bouilloire à 45 € et deux filtres à 6 € pièce. L'événement `purchase` correct : `currency = EUR`, `value = 57`, `transaction_id = "A-10452"`, deux lignes dans `items` (la bouilloire avec la quantité 1, le filtre avec la quantité 2). Si `value` est fixé à 45, le chiffre d'affaires dans les rapports sera sous-estimé, et si l'événement est envoyé deux fois avec le même numéro de commande, il sera surestimé.

Comment vérifier les données

  1. Activez DebugView. Il affiche les événements en temps réel, mais exige le mode débogage (Tag Assistant ou le paramètre `debug_mode`). Si l'utilisateur n'a pas consenti aux cookies d'analyse, les événements n'apparaîtront pas (Aide Google Analytics).
  2. Parcourez à la main le parcours de l'acheteur sur un téléphone et sur un ordinateur, et comparez la séquence d'événements avec le tableau ci-dessus.
  3. Passez une commande de test et vérifiez le numéro, le montant, la devise et les produits par rapport à votre système de comptabilité.
  4. Au bout de quelques jours, comparez le nombre d'achats et le chiffre d'affaires dans GA4 avec le CRM. Un petit écart est normal (refus de cookies, annulations) ; un écart important est une raison de chercher un bug.
  5. Après chaque mise à jour du modèle du site, refaites une vérification rapide : c'est précisément alors que les événements se cassent.

Pour les rapports standard, le nombre de paramètres et d'événements est limité ; pour les événements clés, le nom ne doit pas dépasser 40 caractères (Aide Google Analytics).

Erreurs courantes

  • Un `purchase` en double lorsque la page de remerciement est actualisée.
  • Une devise manquante, ou un `value` qui ne tient pas compte de la quantité.
  • Des événements envoyés avant le consentement de l'utilisateur, ou pas envoyés du tout à cause du bandeau.
  • Des noms d'événements différents selon les pages (`add_to_cart` et `addToCart`).
  • Pas de `refund` : les retours ne sont pas déduits du chiffre d'affaires.

FAQ

Quels événements sont obligatoires pour une boutique ? Au minimum : `view_item`, `add_to_cart`, `begin_checkout`, `purchase`. Les autres ajoutent du détail au tunnel.

Comment vérifier que `purchase` n'est pas envoyé en double ? Passez une commande de test, actualisez la page de remerciement et cherchez dans DebugView un second événement avec le même `transaction_id`.

Peut-on envoyer des événements depuis le serveur ? Oui, voir Suivi côté serveur.

Termes associés

Sources

Vous voulez le vérifier sur votre boutique ?

Audit

Nous analysons le parcours d’achat, le catalogue, l’état technique et les données. Un plan de modifications hiérarchisé en trois jours.

À propos du service →

Partager

À lire aussi

  • Enregistrements de sessions et cartes de chaleur

    | Article: 3 min de lecture

    Un enregistrement de session est la relecture de la façon dont un visiteur a utilisé un site : où il a déplacé le curseur, où il a cliqué, comment il a fait défiler la page. Une carte de chaleur (heatmap) est la synthèse de ces actions pour de nombreux…

  • LTV (valeur vie client)

    | Article: 5 min de lecture

    La LTV (lifetime value, ou CLV, CLTV) est le montant qu'un client rapporte à la boutique pendant toute la durée de la relation. Pour les décisions de gestion, il vaut mieux la calculer non pas en chiffre d'affaires mais en marge : combien d'argent la boutique…

  • Incrémentalité et modèles de mix média

    | Article: 3 min de lecture

    L'incrémentalité est la part des ventes que la publicité a apportée en plus de ce que la boutique aurait obtenu sans elle. Si une personne aurait acheté chez vous de toute façon, la publicité n'a rien ajouté pour elle, même si le rapport l'enregistre comme…

  • CAC (coût d'acquisition client)

    | Article: 5 min de lecture

    Le CAC (coût d'acquisition client) est la somme qu'une boutique dépense pour obtenir un nouveau client : l'ensemble des coûts de marketing et de vente d'une période, divisé par le nombre de clients ayant acheté pour la première fois pendant cette période.