Analytics par secteur
KPI e-commerce : piloter à la marge, aux retours et à la valeur client
KPI e-commerce pour piloter une boutique à la marge, aux retours et à la LTV : définitions, où les mesurer dans GA4 et BigQuery, pièges de tracking.
Par Ron Kopelman, consultant web analytics freelance — publié le 10 novembre 2026
Une boutique en ligne produit beaucoup de chiffres : chiffre d’affaires, panier moyen, taux de conversion, ROAS, nombre de commandes. Aucun ne dit à lui seul si la vente a créé de la valeur. Un ROAS de 4 sur une campagne peut perdre de l’argent si les retours sont élevés et si la marge produit est mince. Le rôle de l’analytics est de rapprocher ces chiffres de ce qui reste réellement après coûts.
Le consultant analytics e-commerce traite la mise en place du tracking. Cette page porte sur la question d’avant : quels indicateurs piloter, avec quelle définition, et d’où vient chaque chiffre.
Le problème de départ : le chiffre d’affaires brut
Les interfaces des plateformes publicitaires affichent un revenu brut, sans retours, sans frais de livraison, sans coût de marchandise. GA4 affiche un revenu issu des transactions, avec les mêmes limites : le montant envoyé par le site n’est pas toujours net. Pour un catalogue avec des tailles, des couleurs ou un taux de retour élevé, l’écart entre le revenu affiché et la marge réelle peut être considérable.
Le pilotage gagne à partir de trois questions simples :
- combien de commandes restent après retours ;
- quelle marge reste par commande, une fois le coût produit, la livraison et les frais de paiement déduits ;
- combien vaut un client sur douze ou vingt-quatre mois, comparé au coût pour l’acquérir.
KPI à suivre
| KPI | Définition | Où le mesurer |
|---|---|---|
| Marge nette par commande | Revenu net moins coût produit, livraison, frais de paiement et SAV | Export de commandes, croisé avec GA4 via l’identifiant de transaction |
| Taux de retour | Commandes ou articles retournés rapportés aux commandes livrées | Logiciel de commande ou ERP, par produit et par source |
| LTV à 12 mois | Marge cumulée d’un client sur douze mois, rapportée à sa première commande | BigQuery, à partir des identifiants clients |
| CAC réel | Coût d’acquisition par nouveau client, toutes dépenses incluses | Données de dépense, rapprochées des nouveaux clients |
| ROAS réel | Marge générée par l’euro investi, après retours | Entrepôt de données, pas le tableau de bord de la plateforme |
| Taux d’annulation | Commandes annulées avant expédition | Back-office, à comparer au total des transactions GA4 |
Le ratio LTV sur CAC est souvent cité comme repère, mais il dépend du modèle économique : un abonnement, un catalogue de cadeaux ou un produit de consommation courante n’ont pas les mêmes seuils. Je le considère comme un point de départ à valider sur vos propres cohortes.
Où les données se perdent
Le pilotage par la marge échoue souvent pour des raisons de données, pas de calcul.
- L’identifiant de transaction manque ou change. Une commande remboursée puis recréée apparaît deux fois. Sans identifiant stable, le croisement avec le back-office est impossible.
- Le revenu envoyé à GA4 n’est pas celui du back-office. Les taxes, les remises et les frais de port sont parfois inclus d’un côté et exclus de l’autre.
- Les retours ne remontent pas. GA4 ne soustrait pas automatiquement un remboursement. Il faut une remontée explicite, ou un calcul dans l’entrepôt.
- Les clients sont identifiés par session. Une même personne achetant depuis deux appareils compte comme deux clients, et la LTV est sous-estimée.
- Le consentement réduit la base. Les utilisateurs qui refusent la mesure sont absents des cohortes. Le taux de conversion est alors calculé sur un échantillon qu’il faut nommer dans le rapport.
Stack type
Pour une boutique de taille moyenne, la stack reste simple : GA4 pour le parcours, un conteneur GTM pour les événements e-commerce, un export des commandes vers BigQuery pour le rapprochement avec la marge et les retours, puis un tableau de bord Looker Studio qui lit les deux sources.
Le choix de la plateforme change la façon d’envoyer les événements. Les réglages Shopify et ceux d’un site sous WooCommerce ou PrestaShop ne se remontent pas de la même manière. Pour les différences, voir le comparatif Shopify Pixels et GTM et les pages plateformes.
Pièges de pilotage fréquents
- Optimiser le ROAS brut. La campagne qui vend beaucoup de produits à marge faible ou à fort taux de retour semble la meilleure, à tort.
- Confondre la première commande et la valeur client. Une acquisition coûteuse peut être rentable sur douze mois, et une acquisition bon marché peut ne jamais revenir.
- Comparer des périodes sans saisonnalité. Les soldes et les fêtes de fin d’année déforment toute comparaison mensuelle si elle n’est pas rapportée à l’année précédente.
- Lire la LTV sans cohorte. Une moyenne globale mélange des clients anciens et récents. Les cohortes par mois d’acquisition donnent une lecture plus fiable.
Pour ce qui concerne le rapprochement des ventes hors ligne ou avec le CRM, la page sur les conversions offline détaille la méthode. Le détail du calcul de retour sur dépense publicitaire est sur la page consultant ROAS.
Services pertinents
Un audit de tracking e-commerce vérifie d’abord la remontée des transactions et des remboursements, puis le rapprochement avec la marge. Le tableau de bord de pilotage reprend ensuite les KPI de cette page sous une forme lisible par l’équipe.
Pour les autres secteurs, voir la page voyage et tourisme, où la valeur se mesure par séjour, et la page B2B SaaS, où le revenu arrive des mois après le premier clic.
Sources
- Aide Google Analytics, données e-commerce et transactions : support.google.com/analytics
- Aide Google Ads, valeur de conversion et ROAS : support.google.com/google-ads
- CNIL, cadre du consentement pour la mesure : cnil.fr