Sommaire
Réponse directe
Sur une cohorte created_at, commencez par COD Delivery Insights : summary global (refused_returned_orders regroupe refus et retours), pires villes via getWorstCitiesByRefusedRate (minimum 10 commandes par ville), tops produit/variante sur quantités livrées uniquement — pas de classement Insights « refus par SKU ». Pour les produits/variantes à fort refus ou retour, croisez export CSV, filtres module livraison (delivery_status, libellés provider) et lignes OrderItem, plus notes confirmation. Exigez volume suffisant avant action ; corrélation ≠ causalité.
Trois dimensions à analyser séparément
Un taux global masque trois signaux distincts : la géographie (ville), l’offre (produit parent) et la granularité opérationnelle (variante SKU).
ERP-STOK ne les traite pas avec la même profondeur dans Insights : les villes disposent d’un classement « pire taux refus/retour » filtré ; produits et variantes n’ont que des tops sur quantités livrées.
| Dimension | Ce qu’Insights expose réellement | Limite à connaître |
|---|---|---|
| Ville | getWorstCitiesByRefusedRate : taux refused_returned, tri décroissant | Minimum WORST_CITY_MIN_ORDERS = 10 commandes par ville |
| Produit | getTopProducts : somme quantités livrées (delivery_status delivered) | Pas de top « refus par produit » dans CodDeliveryAnalyticsService |
| Variante | getTopVariants : somme quantités livrées par produit + variante | Pas de widget Insights « pire variante par taux refus » |
| Global | refused_returned_orders + refused_rate_pct sur la cohorte | Regroupe refus à la porte et retours — pas refus pur isolé |
Étape 1 — Villes avec le plus de refus ou retours
Ouvrez COD Delivery Insights sur une plage de dates (cohorte created_at). Lisez d’abord le summary : total_orders, delivered_orders, refused_returned_orders, refused_rate_pct.
Le widget « pires villes » (getWorstCitiesByRefusedRate) liste uniquement les villes avec au moins 10 commandes sur la période — une ville à 6 commandes et 100 % de refus n’y apparaît pas volontairement.
La ville affichée combine delivery_city_override → customer_city → provider_city_name, avec normalisation d’alias pour le rapport (données source inchangées).
- Choisir une cohorte comparable (ex. 30 jours calendaires).
- Lire refused_rate_pct global pour le contexte.
- Consulter le classement pires villes (≥ 10 commandes).
- Ignorer les conclusions fortes sur villes sous le seuil — notez « échantillon insuffisant ».
- Croiser avec overrides ville et notes confirmation sur les commandes signalées.
Étape 2 — Produits et variantes : ce que montrent les tops livrés
getTopProducts et getTopVariants comptent les quantités des lignes OrderItem dont la commande est delivery_status = delivered — ce sont des classements de volume livré, pas de refus.
Un produit très vendu peut aussi générer beaucoup de refus en volume absolu sans être « le pire en taux » : le top livré indique où concentrer l’attention si vous croisez manuellement avec les échecs.
Il n’existe pas, dans CodDeliveryAnalyticsService, de méthode getWorstProductsByRefusedRate ni de widget Insights dédié « refus par SKU » — ne cherchez pas un écran qui n’est pas livré.
- Top produit livré = signal de volume, pas de taux refus.
- Top variante livrée = même limite — utile pour prioriser un export manuel.
- Pour un taux refus/retour par variante : export ou filtres livraison + recoupe lignes commande.
- Notes agent (taille, couleur, attente) complètent la lecture quantitative.
Étape 3 — Identifier produits/variantes à fort refus ou retour (hors widget dédié)
Puisqu’Insights ne classe pas les SKU par refused_returned, construisez une analyse ops en croisant plusieurs sources ERP-STOK.
Module livraison : filtrez les commandes cohorte avec delivery_status returned, return_pending_scan, ou libellés provider contenant refusé/refused/retourné/returned (selon sync).
Export CSV Insights ou export commandes : reliez chaque commande échouée à ses lignes OrderItem (product_name, variant_name, SKU).
Comptez manuellement ou en tableur : refus/retours par variante sur volume minimum interne (même prudence que le seuil 10 villes).
| Source ERP-STOK | Usage pour produit/variante |
|---|---|
| COD Insights summary | Taux global refused_returned — contexte, pas détail SKU |
| COD Insights tops livrés | Prioriser quels SKU investiguer en premier (volume) |
| Module livraison + filtres | Lister commandes refus/retour avec lignes visibles |
| Export CSV | Agréger refus/retours par variante en externe |
| Notes confirmation | Motifs qualitatifs (taille, prix, photo annonce) |
Limites Insights à ne pas contourner dans le discours
refused_returned_orders (et refused_rate_pct) regroupe refus à la porte et retours en transit/retournés pour le KPI — comparable en tendance, pas équivalent à « refus pur par produit ».
Les tops produit/variante = quantités livrées uniquement ; confondre « top livré » et « top refus » fausse les priorités.
Pires villes : seuil 10 commandes codifié (WORST_CITY_MIN_ORDERS) — pas de seuil produit identique dans le service.
Aucun widget Insights « refus par SKU » ou « pire variante par taux refus » — ne le promettez pas en marketing ni en formation équipe.
Les libellés transporteur et le polling influencent la classification ; deux périodes ne sont comparables que si la définition du numérateur est documentée.
Questions du cadre (à se poser avant d’agir)
La variante ou la ville a-t-elle assez de commandes pour un signal stable ?
Le pattern est-il localisé (une ville) ou global sur plusieurs villes ?
Les notes confirmation mentionnent-elles taille, couleur, attente marketing ?
Le libellé retour distingue-t-il refus vs retour produit côté transporteur — ou tout est-il dans refused_returned groupé ?
Le produit est-il aussi en top livré (volume) — ce qui change l’interprétation du nombre absolu de retours ?
Interprétation prudente et actions compatibles ERP-STOK
Une corrélation (variante X + ville Y + taux élevé) n’établit pas causalité : confirmation, transporteur, saison et promesse marketing peuvent expliquer le signal.
- Renforcer questions confirmation sur variante/ville signalées.
- Ajouter note type agent sur commandes futures même SKU.
- Croiser photos/descriptions boutique — hors ERP.
- Ne pas retirer un SKU sur 5 retours sans volume et recoupe notes.
- Documenter la définition du numérateur (KPI groupé vs libellés « refusé » seuls).
| Observation | Interprétation prudente |
|---|---|
| Ville pire taux, ≥ 10 cmd | Prioriser script confirmation + données adresse/téléphone |
| Ville taux élevé, < 10 cmd | Surveiller — absent du widget pires villes |
| Variante : beaucoup de retours absolus, gros volume livré | Investiguer (export) — pas automatiquement « mauvais produit » |
| Variante : taux élevé sur faible volume export | Classer « surveiller », pas de retrait catalogue |
| Concentré une ville + une variante | Hypothèse logistique ou démographique en plus de l’offre |
Ce que ce cadre n’autorise pas
Affirmer « ce produit est mauvais » sans volume et sans recoupe notes/transporteur.
Publier des statistiques inventées (% retour garanti par SKU).
Confondre retour entrepôt validé (scan + validation) et simple libellé transporteur.
Présenter getTopProducts comme un classement des refus — c’est un top livré.
Prétendre à un écran Insights « refus par variante » s’il n’existe pas dans le produit.
Exemple fictif
Exemple illustratif (fictif) — ville + variante
Cohorte 30 jours : refused_rate_pct global 22 % (refused_returned_orders groupés). Ville « Oujda » : 14 commandes, 6 refused_returned → apparaît dans pires villes (≥ 10). Ville « Taza » : 5 commandes, 4 refused_returned → absente du widget (sous seuil). Top variante livrée : « Robe été — M » (volume élevé). Export manuel : 12 refused_returned sur « Robe été — M » sur 48 commandes contenant cette variante → hypothèse taille ; notes : « client attendait L ». Action : script confirmation taille + photo ; pas de retrait catalogue. Variante « Ceinture one-size » : 4 commandes, 2 retours → « surveiller ».
Données ERP-STOK pour l’analyse ville / produit / variante
CodDeliveryAnalyticsService : summary (refused_returned_orders groupé), getWorstCitiesByRefusedRate (≥ 10 cmd), getTopProducts / getTopVariants (quantités livrées uniquement).
Module livraison : filtres delivery_status, libellés provider, export pour recoupe OrderItem par variante.
Lignes commande avec product_name, variant_name, SKU pour remonter aux échecs hors widget dédié.
Notes et historique confirmation pour contexte qualitatif.
Pour conclure
Identifiez d’abord les villes via Insights (seuil 10), puis croisez produits/variantes via tops livrés + export manuel — sans widget refus par SKU.
Volume + définition KPI + notes + prudence causalité = cadre sain pour agir sur confirmation et offre.
Limites et points d’attention
- Corrélation ≠ causalité — toujours.
- refused_returned_orders regroupe refus et retours — pas refus pur ni typologie qualité fine.
- getTopProducts / getTopVariants = quantités livrées — pas taux refus par SKU.
- Pas de widget Insights « refus par produit/variante » dans CodDeliveryAnalyticsService.
- Seuil 10 commandes codifié pour pires villes — pas de seuil produit équivalent dans le service.
- Pas de module RMA avancé imposé par ce guide.