10 analyses e-commerce indispensables à réaliser sur Google Analytics

Dix questions de rentabilité — tunnel, produits, listes, canaux, promotions, valeur client — et le rapport GA4 exact qui y répond

Vous ouvrez GA4, vous cliquez sur Monétisation, et le premier chiffre rassure. Le revenu est là, la courbe monte. Puis quelqu’un demande pourquoi le mobile décroche, quel produit plombe la marge, si la promo de la semaine a servi. Personne n’a de réponse chiffrée.

Le problème n’est presque jamais le volume de données. C’est l’ordre des questions. Un compte e-commerce bien tagué produit déjà tout ce qu’il faut pour décider ; encore faut-il savoir quel rapport ouvrir pour quelle décision.

Voici les dix analyses que je fais dans cet ordre, sur des boutiques de 200 références comme sur des catalogues de 40 000. Chacune se traduit en euros ou en heures de développement.

De quoi dépend la fiabilité des dix analyses ?

De trois choses : les événements recommandés sont envoyés, le tableau items est complet, et le modèle d’attribution est choisi consciemment. Si l’un des trois manque, les dix analyses restent disponibles — elles sont juste fausses. Si vous avez des doutes sur la qualité de vos données e-commerce GA4, consultez mon agence spécialisée sur Google Analytics.

Découvrez égalementComment récupérer le Client ID de Google Analytics 4 ?

GA4 ne collecte rien d’e-commerce par lui-même. Les événements d’achat doivent venir de votre implémentation ; sans eux, les rapports Monétisation restent vides.

Les événements à couvrir, dans l’ordre du parcours :

• view_item_list et select_item sur les listes de produits
• view_item sur la fiche produit
• add_to_cart et remove_from_cart au panier
• view_cart à l’ouverture du panier
• begin_checkout, add_shipping_info, add_payment_info dans le tunnel
• purchase sur la page de confirmation

C’est le tableau items qui alimente les dimensions de produit, pas le nom de la page. Les paramètres qui comptent : item_id, item_name, item_brand, item_category, item_variant, price, quantity, discount, coupon. Sans price et quantity, GA4 calcule un revenu par article à zéro — le rapport Achats d’e-commerce le documente explicitement.

Deux détails coûtent des heures de diagnostic. La currency se déclare au niveau de l’événement dès qu’une value part, sinon les montants tombent dans la devise par défaut du flux. Et le transaction_id doit être unique : une page de confirmation rafraîchie envoie un second purchase, et le revenu gonfle d’un pourcentage que personne n’explique en comité.

Dernier préalable : les seuils de données. Avec les signaux Google activés, GA4 masque les lignes identifiantes. Sur une petite boutique, une analyse par produit peut afficher « (other) » ou disparaître. Un seuil, pas un bug — à savoir avant de conclure qu’un produit ne vend pas.

Où les acheteurs décrochent-ils dans le tunnel ?

Découvrez égalementComment configurer le suivi interdomaines dans GA4 ?

Le rapport Parcours d’achat y répond en un écran. Il suit cinq étapes — ouverture de session, affichage du produit, ajout au panier, début du paiement, achat — et affiche le taux d’abandon et le taux de rétention entre chaque marche. C’est le seul rapport GA4 que j’ouvre systématiquement avant toute réunion e-commerce.

L’étape la plus chère n’est presque jamais le paiement

Sur la majorité des boutiques que j’audite, la fuite principale est entre l’affichage du produit et l’ajout au panier. Le paiement, lui, ne perd que quelques points.

Le rapport est un entonnoir fermé par défaut : un utilisateur qui saute une étape sort du calcul. Utile pour un diagnostic strict, trompeur pour un site où le paiement express court-circuite le panier. Le bouton « Ouvrir l’entonnoir » change le diagnostic : avec Apple Pay en page produit, la version fermée fait croire à un effondrement du panier qui n’a jamais eu lieu.

Pour les causes, je duplique ces étapes dans une exploration de l’entonnoir : jusqu’à 10 étapes, ouvert ou fermé, répartition par dimension, temps écoulé, cinq actions suivantes par marche. Cette dernière fiche donne le correctif. Sorties vers la page livraison et retours : promesse floue, pas bug de formulaire.

Baymard Institute chiffre l’enjeu : sur 50 études publiées entre 2006 et 2025, le taux d’abandon panier documenté s’établit en moyenne à 70,22 %, et un travail sur les seuls défauts de tunnel identifiés par l’institut vaudrait 35,26 % de conversion en plus sur un site de taille moyenne, soit 260 milliards de dollars de commandes récupérables aux États-Unis et en Europe (Baymard, 2026). Un point de rétention gagné à l’étape la plus fuyante vaut donc plus cher que dix optimisations de page d’accueil.

Un écart de 5 % entre GA4 et le back-office change le diagnostic

Découvrez égalementComment automatiser vos rapports avec l’API Data GA4 ?

GA4 ne comptera jamais exactement vos commandes. Consentement refusé, bloqueurs, redirection de paiement, changement d’appareil : chaque maillon perd des utilisateurs. La question n’est pas de supprimer l’écart, elle est de le mesurer et de le stabiliser.

Je compare trois sources sur la même période : achats GA4, commandes du back-office, chiffre d’affaires hors taxes des deux côtés. Un écart constant de 5 à 10 % se documente. Un écart qui oscille entre 3 % et 25 % selon les jours signale un défaut de collecte : template non tagué, purchase avant consentement, paiement en redirection.

Le piège classique reste le doublon. Je compte les purchase par transaction_id : au-delà de 1, tous les revenus qui en découlent sont faux, ROAS compris.

Le mobile ne perd pas au paiement, il perd avant

La répartition par catégorie d’appareil dans l’entonnoir est l’analyse la plus mal lue de GA4. Elle attribue l’utilisateur à l’appareil utilisé à sa première étape dans l’entonnoir, pas à celui du paiement. Un client qui commence sur mobile et paie sur ordinateur reste classé mobile.

L’analyse utile n’est donc pas « le mobile convertit mal », c’est « à quelle étape le mobile perd le plus », puis « que se passe-t-il entre cette étape et la suivante sur un écran de 390 pixels ».

Sur presque tous les audits, la perte mobile se concentre sur la fiche produit : chargement, galerie, sélecteur de taille. Le paiement arrive loin derrière.

Quels produits et quelles listes font le chiffre d’affaires ?

Le rapport Achats d’e-commerce répond produit par produit, et la fiche Articles achetés de la Vue d’ensemble de la monétisation donne la même chose en tête de gondole. C’est là que se décide le merchandising, pas dans un tableur exporté une fois par trimestre.

Vingt références font 80 % du revenu, pas votre catalogue

Triez par revenu issu des achats, pas par quantité vendue. Les deux divergent, et c’est cet écart qui compte : une référence à forte quantité et faible revenu coûte parfois plus en logistique qu’elle ne rapporte.

La dimension ID de l’article est plus fiable que le nom, qui change au fil des campagnes. Si les revenus par ID sont vides alors que les quantités sont correctes, le problème est dans items : price absent, quantity envoyé en texte, tableau imbriqué au mauvais niveau.

Deuxième lecture, plus rentable : la catégorie. item_category et ses niveaux 2 et 3 donnent une marge de manœuvre immédiate en category management. C’est un paramètre, pas une dimension personnalisée — aucun quota à consommer. Si vos catégories métier ne rentrent pas dans item_category, passez par une dimension personnalisée de portée article (la procédure ici).

La liste qui vend n’est pas celle qui génère le plus de clics

view_item_list compte les affichages de liste, select_item les clics vers une fiche. Le rapport entre les deux donne un taux de clic ; le rapport entre select_item et add_to_cart donne la qualité réelle du produit proposé.

Tout dépend de item_list_name et de l’index envoyés. Sans eux, toutes vos listes se confondent. Avec, vous comparez accueil, recherche interne, recommandations de fiche et carrousels sur une base commune.

La conclusion est rarement celle qu’on attend. Sur une boutique de cosmétiques, le carrousel de fiche générait deux fois plus de clics que la page catégorie pour un tiers du revenu : de la curiosité, pas de l’intention. Le budget est parti sur la recherche interne.

Les produits vus sans ajout au panier disent quoi corriger

Croisez view_item et add_to_cart par article. Un produit très consulté et jamais ajouté n’est pas un mauvais produit : c’est un produit dont la fiche ne répond pas à la question du visiteur.

L’exploration de chemin en mode inversé est l’outil le plus direct : vous partez de add_to_cart et remontez les événements précédents. L’ajout suit-il un guide des tailles, une recherche interne, un retour depuis le panier ? Les produits absents de ces chemins sont ceux qui posent problème.

Regardez ensuite la répartition par item_variant. Douze tailles dont deux se vendent : problème de stock ou de photo, pas de prix.

Quels canaux et quelles promotions rapportent vraiment ?

Par défaut, GA4 attribue le crédit avec un modèle basé sur les données, et ce modèle s’applique aux dimensions de portée événement. Les dimensions de session et d’utilisateur, elles, restent au dernier clic. Confondre les deux est l’erreur d’analyse la plus répandue sur les rapports d’acquisition.

Le crédit fractionnaire change le classement des canaux

Le modèle basé sur les données répartit le crédit d’un achat entre plusieurs points de contact : un canal peut afficher 12,4 achats. Ce ne sont pas des arrondis, c’est le crédit partagé. Un canal comparé à lui-même reste lisible ; comparé au back-office, il ne tombe jamais juste. Et depuis novembre 2023, les modèles basés sur des règles — linéaire, dépréciation, premier clic, position — ne sont plus disponibles dans GA4.

Le rapport Performances de tous les canaux est le seul endroit où l’attribution rencontre le coût. Avec les coûts importés (Google Ads, SA360, DV360 ou import de données), vous obtenez coût par événement clé et ROAS par canal. Sans coût, vous avez une part de voix, pas une rentabilité. Et la réattribution pouvant modifier une conversion jusqu’à sept jours après l’achat, un rapport figé le lundi ne correspondra pas au même rapport le vendredi.

Une promo qui ne remonte pas dans GA4 ne se mesure pas

Le rapport Promotions existe, mais il ne se remplit que si vous envoyez view_promotion à l’affichage et select_promotion au clic, avec promotion_name, promotion_id et creative_name. Sans ces paramètres, la promotion n’existe pas pour GA4 — et l’équipe marketing continuera de la juger sur son trafic, pas sur son revenu.

Trois chiffres suffisent : vues, clics, revenu attribué. Une bannière vue 200 000 fois et cliquée 400 fois n’est pas un échec si ces 400 clics pèsent 8 % du revenu. À l’inverse, une promo très cliquée qui cannibalise des achats prévus est une remise offerte sans contrepartie.

Complétez avec le rapport sur les bons utilisés dans les commandes : le paramètre coupon donne le revenu par code promo, donc le coût réel de chaque opération.

Combien vaut un client après la première commande ?

La fiche Vue d’ensemble de la monétisation donne les acheteurs au total et les nouveaux acheteurs. La différence entre les deux, suivie dans le temps, vaut plus que n’importe quel panier moyen : elle dit si vous gagnez des clients ou si vous les renouvelez.

Une cohorte de 90 jours vaut mieux qu’un panier moyen

Le panier moyen mélange les primo-acheteurs et les habitués. Une exploration des cohortes, avec purchase comme condition de retour, montre semaine après semaine combien d’acheteurs d’un mois donné rachètent dans les trois mois.

Sur une boutique d’accessoires, cette lecture a renversé une décision : le panier moyen baissait depuis six mois. Les cohortes montraient un réachat en hausse et un panier initial plus petit, porté par une gamme d’entrée de prix. Le chiffre d’affaires par client à 90 jours progressait. Sans cohortes, la conclusion aurait été « on vend moins bien ».

Le préalable est un identifiant stable : user_id si l’authentification existe, sinon le Client ID, sachant que le changement d’appareil sous-estime toujours la fidélité réelle.

Les audiences prédictives ne s’activent qu’au-dessus de 1 000 acheteurs

GA4 calcule une probabilité d’achat et des revenus prédits, mais sous conditions. Il faut, sur les 28 derniers jours et sur une fenêtre de 7 jours, au moins 1 000 utilisateurs de retour ayant déclenché l’achat et 1 000 ne l’ayant pas déclenché. En dessous, pas de modèle : les métriques prédictives restent indisponibles.

Quand le seuil est atteint, l’audience « acheteurs probables à 7 jours » regroupe les utilisateurs au-dessus du 90e percentile de probabilité d’achat. Elle sert au remarketing, mais aussi à la priorisation CRM : mêmes 1 000 contacts, ordre d’appel différent.

La probabilité d’achat porte sur 7 jours, les revenus prédits sur 28 : relance court terme pour l’une, allocation budgétaire pour les autres. Ne mélangez pas les deux dans un même rapport.

Les dix analyses sur une page

Ces dix analyses supposent une collecte saine. Si les rapports Monétisation sont vides ou partiels, commencez par bâtir un plan de taggage Google Analytics : les événements e-commerce, leurs paramètres et l’ordre dans lequel les brancher.

Par quoi commencer demain matin ?

Par l’analyse 2, celle que personne ne veut faire. Tant que l’écart entre GA4 et le back-office n’est pas mesuré, toutes les autres conclusions flottent.

Ensuite le tunnel : une heure sur Parcours d’achat, une répartition par appareil, et vous savez où est le prochain chantier. Ce sera probablement la fiche produit, pas le paiement.

Le reste suit : produits, listes, canaux, promotions, valeur client. Chaque analyse produit une décision, chaque décision se mesure au trimestre suivant.

Pour aller plus vite sur l’exploration et la personnalisation, la formation Google Analytics avancée couvre entonnoir, cohortes et segments. Pour un reporting qui tienne dans le temps, voyez comment créer un tableau de bord Google Analytics et gardez en tête les limites de GA4 sur vos données avant de promettre des chiffres exacts à votre direction.

FAQ

• Quelles analyses e-commerce faire en priorité dans GA4 ?
  Le parcours d’achat, puis la réconciliation entre les achats GA4 et le back-office. Sans tunnel fiable ni chiffres crédibles, le reste est décoratif.
  
• GA4 mesure-t-il automatiquement l’e-commerce ?
  Non. Les événements e-commerce doivent être envoyés par votre implémentation (gtag, GTM, protocole de mesure), avec le tableau items. Sans eux, les rapports Monétisation restent vides.
  
• Pourquoi mon rapport Achats d’e-commerce affiche-t-il des revenus à zéro ?
  Le revenu par article est calculé à partir des paramètres price et quantity du tableau items. Si l’un des deux manque ou arrive au mauvais format, le revenu reste à zéro même quand les quantités vendues sont correctes.
  
• Quelle différence entre le rapport Parcours d’achat et l’exploration de l’entonnoir ?
  Le rapport est prédéfini avec cinq étapes fixes, non modifiables. L’exploration de l’entonnoir accepte jusqu’à 10 étapes personnalisées, une répartition par dimension, le temps écoulé et les actions suivantes.
  
• Pourquoi les métriques prédictives ne s’affichent-elles pas ?
  Le modèle exige au moins 1 000 utilisateurs de retour ayant déclenché l’achat et 1 000 ne l’ayant pas déclenché, sur une fenêtre de 7 jours dans les 28 derniers jours. En dessous de ce volume, GA4 ne génère ni probabilité d’achat ni revenus prédits.
  

Sources

1. Google Analytics Help, « [GA4] Événements recommandés », consulté le 11 novembre 2026 — https://support.google.com/analytics/answer/9267735?hl=fr
2. Google for Developers, « Mesurer l’e-commerce », consulté le 11 novembre 2026 — https://developers.google.com/analytics/devguides/collection/ga4/ecommerce
3. Google Analytics Help, « Rapport Parcours d’achat », consulté le 11 novembre 2026 — https://support.google.com/analytics/answer/13128171?hl=fr
4. Google Analytics Help, « [GA4] Exploration de l’entonnoir », consulté le 11 novembre 2026 — https://support.google.com/analytics/answer/9327974?hl=fr
5. Google Analytics Help, « [GA4] Exploration du chemin », consulté le 11 novembre 2026 — https://support.google.com/analytics/answer/9317498?hl=fr
6. Google Analytics Help, « [GA4] Rapport Vue d’ensemble de la monétisation », consulté le 11 novembre 2026 — https://support.google.com/analytics/answer/13409465?hl=fr
7. Google Analytics Help, « [GA4] Rapport sur les promotions », consulté le 11 novembre 2026 — https://support.google.com/analytics/answer/13458990?hl=fr
8. Google Analytics Help, « Premiers pas avec l’attribution », consulté le 11 novembre 2026 — https://support.google.com/analytics/answer/10596866?hl=fr
9. Google Analytics Help, « [GA4] Predictive metrics », consulté le 11 novembre 2026 — https://support.google.com/analytics/answer/9846734?hl=en
10. Baymard Institute, « 50 Cart Abandonment Rate Statistics 2026 », mis à jour le 28 octobre 2026 — https://baymard.com/lists/cart-abandonment-rate

À propos de l’auteur

Franck Scandolera est analytics engineer et data engineer. Il conçoit des plans de taggage e-commerce, des architectures de collecte GA4 et GTM, et les tableaux de bord qui rendent ces données exploitables. Il forme les équipes e-commerce et data à l’analyse de leurs propres chiffres.

Franck Scandolera

Dev d’applications métier · Data Engineer · Automatisation IA

Clients : Logis Hôtels, Yelloh Village, BazarChic, FFF, Texdecor…

Apps & agents IA : Node.js, Python, API, RAG, OpenAI, Mistral, Claude
Data Engineering : BigQuery, Snowflake, PostgreSQL, ClickHouse, dbt, Airflow, Dataform, Looker, Power BI, Metabase
Automatisation IA : n8n, Apps Script, scraping, API, LLM
Tracking & perf Web : GA4, GTM server, Matomo, Piano, Tealium, CAPI, Core Web Vitals