Passer au contenu
← Retour au Journal
Guides
6 min de lecture

Retours par produit : quoi vérifier en premier

Un CSV fictif et un diagnostic recalculable pour distinguer commandes, unités et cohortes encore ouvertes avant de conclure sur la cause.

Par Equipo Frihet
Retours par produit : quoi vérifier en premier

TL;DR: Pour analyser les retours, comparez le même produit après la même durée de suivi et conservez deux taux : commandes touchées et unités retournées. Le motif choisi par le client oriente la recherche ; il ne prouve pas ce qui a échoué.

Sommaire

Pour analyser les retours, comparez le même produit après la même durée de suivi et conservez deux taux : commandes touchées et unités retournées. Le motif choisi par le client oriente la recherche ; il ne prouve pas ce qui a échoué.

Quatre sacs à dos reviennent et quelqu’un propose d’arrêter la campagne. Il manque encore le nombre d’unités livrées, celui des commandes concernées et le temps dont les acheteurs ont disposé. Le résultat attendu est une vérification attribuée à quelqu’un, pas un coupable désigné dans une colonne.

Définir l’événement compté

Une demande, un article reçu physiquement et un remboursement sont des événements distincts. Nous comptons les unités physiquement revenues, reliées à leur ligne d’origine. Un remboursement sans retour et une demande en attente sont exclus du numérateur. Cette dernière reste dans une file opérationnelle séparée.

Shopify distingue Reversed quantity, qui peut inclure annulations et modifications, de Returned quantity, consacré aux retours physiques. Les dates de vente et d’ajustement sont également distinctes. Vérifiez donc le champ avant d’appeler « retour » toute valeur négative. Définitions officielles Shopify.

Notre feuille est un format de travail indépendant, pas un export ni une fonction de Frihet. Pour la situer parmi les autres données, consultez le guide des données ecommerce et intégrations, en anglais.

Fixer la date d’arrêté et la cohorte

L’exemple est entièrement fictif. L’arrêté est au 2026-09-13, avec 30 jours de suivi analytique après livraison, retours reçus le jour 30 compris. Ce n’est ni un délai légal ni une politique commerciale recommandée. Choisissez un horizon adapté à votre processus et documentez pourquoi.

Les groupes réunissent SKU et date de livraison. La cohorte du 2026-08-01 a terminé son suivi ; celle du 2026-09-06 ne compte que sept jours. « Mature » signifie que notre fenêtre est complète, pas que tout retour ultérieur est impossible. Conservez les cas tardifs pour une analyse distincte.

Séparez les livraisons partielles en lignes tout en gardant la clé de commande. Sans date de livraison, le dossier est non classable, pas une commande sans retour. Les demandes ouvertes restent visibles pour la personne qui les traite, hors du taux physique.

Recalculer le tableau

Le dossier (ZIP) comprend order-lines.csv, results.csv et recalculate.py : 30 lignes fictives livrées, leurs résultats et un script utilisant uniquement la bibliothèque standard de Python 3. Gardez les originaux et lancez python3 recalculate.py dans une copie.

SKU et cohorteCommandesUnités livréesCommandes avec retourUnités retournées
BAG-A, 2026-08-01, mature102034
BAG-B, 2026-08-01, mature101011
BAG-A, 2026-09-06, ouverte102011

BAG-A mature donne 3 / 10 × 100 = 30 % de commandes touchées et 4 / 20 × 100 = 20 % d’unités retournées. BAG-B mature donne 1 / 10 × 100 = 10 % pour les deux taux. Une commande peut contenir deux unités et retourner les deux, comme la première ligne BAG-A.

BAG-A récente affiche 10 % par commande et 5 % par unité, mais reste ouverte. Cela ne prouve aucune amélioration : aucune intervention n’a été simulée. Aucun seuil universel ne rend non plus 20 % acceptable ou inacceptable.

Conserver des lignes explicables

line_id,order_id,sku,cohort,channel,delivered_at,units_delivered,units_returned,return_received_at,reason_code

line_id identifie la ligne et order_id permet de compter les commandes distinctes. N’additionnez pas les comptes par SKU pour obtenir le total de la boutique : une commande peut contenir plusieurs produits. Ici, chaque commande contient un seul SKU.

SIZE signifie taille inadaptée déclarée ; DAMAGE, dommage déclaré ; UNKNOWN, motif indisponible ; NONE, aucun retour physique enregistré. Ces codes ne sont pas une vérification de l’entrepôt. Conservez séparément le texte d’origine, avec accès limité et sans données personnelles inutiles.

Nous simplifions chaque ligne à une réception et un motif. Si plusieurs dates ou motifs existent, créez une table d’événements reliée par line_id et ne cumulez que ceux de l’horizon. Ne répétez pas units_delivered à chaque événement : le dénominateur serait gonflé. Examinez les identifiants dupliqués avant toute suppression.

Utiliser le motif comme piste

BAG-A mature comporte trois unités SIZE et une UNKNOWN. 3 / 4 = 75 % décrit la répartition des motifs parmi les retours, pas le taux de retour du produit. Retirer l’inconnu fabriquerait 100 % de problèmes de taille à partir de données incomplètes.

Comparez les mesures des trois unités, la variante commandée et la fiche vue par ces acheteurs. Des mesures conformes mais une attente différente suggèrent une hypothèse sur l’information. Une mesure non conforme appelle une vérification de l’unité et du lot. Le motif ne départage pas ces explications.

BAG-B présente une unité DAMAGE. Vérifiez emballage, constat à réception et lot : le transporteur n’est pas automatiquement responsable. Une observation ne démontre pas une tendance stable.

Ne pas accuser le canal

Tous les retours fictifs sont dans web. Cela ouvre une question, pas une décision de fermeture. Comparez SKU, variante et durée identiques ; examinez promotion, lot et qualité de saisie. Cinq commandes par canal donnent peu d’information ; les subdiviser ne crée pas de précision.

En cas de divergence, conservez filtres, date d’arrêté et définition des champs. Shopify documente des différences dues aux périodes et à la logique des rapports. Vérifiez que vous comparez les mêmes parties d’une commande. Écarts des rapports Shopify. L’annuaire des intégrations aide à vérifier la source accessible ; sa présence ne garantit pas ces champs.

Terminer par une vérification attribuée

Copiez cette fiche : « BAG-A, cohorte 2026-08-01 ; 4/20 unités, 3/10 commandes ; trois SIZE et un UNKNOWN ; vérifier mesures et fiche ; responsable catalogue ; preuves en attente ; revue après examen des quatre unités retournées provenant de trois commandes ».

Ajoutez quel constat changerait l’action et gardez la version précédente. Ne supprimez ni l’inconnu ni une partie de la cohorte pour améliorer le taux. Une fois les preuves recueillies, testez un changement limité et comparez ensuite des cohortes aussi matures. Pour l’impact économique, traitez les coûts séparément avec le calculateur de marge : ces taux ne mesurent pas le bénéfice.

Partager

Cet article vous a-t-il été utile ?

Questions fréquentes

Une cohorte récente peut-elle démontrer une amélioration ?

Une cohorte encore en observation ne démontre pas une amélioration par rapport à une cohorte dont la période d’observation est terminée. Comparez le même produit sur des durées identiques et séparez les taux par commande et par unité.

Le motif de retour le plus fréquent prouve-t-il la cause ?

Non : c’est une piste à confronter au produit et aux éléments disponibles. Son pourcentage décrit les motifs parmi les unités retournées, pas le taux de retour du produit ; conservez aussi les motifs inconnus.

Frihet — Gestion sans drame

Commencer