Returer per produkt: hva bør du undersøke først?
Et syntetisk CSV-eksempel med beregnbare resultater skiller ordrer, enheter og åpne kohorter før en returgrunn behandles som bevist årsak.
TL;DR: Undersøk returer ved å sammenligne samme produkt etter like lang oppfølging og beholde to mål: berørte ordrer og returnerte enheter. Kundens valgte grunn gir retning, men beviser ikke hva som sviktet.
Innhold
Undersøk returer ved å sammenligne samme produkt etter like lang oppfølging og beholde to mål: berørte ordrer og returnerte enheter. Kundens valgte grunn gir retning, men beviser ikke hva som sviktet.
Fire ryggsekker kommer tilbake, og noen vil stoppe kampanjen. Hvor mange ble levert, hvilke ordrer tilhører de, og hvor lenge har kjøperne hatt dem? Diagnosen skal ende i en tildelt kontroll, ikke en skyldig valgt fra en kolonne.
Definer hendelsen du teller
En forespørsel, en fysisk mottatt vare og en refusjon er forskjellige hendelser. Her teller vi enheter fysisk mottatt i retur, knyttet til opprinnelig ordrelinje. Refusjon uten vare og ventende forespørsel inngår ikke i telleren. Ventende saker trenger en separat arbeidskø.
Shopify skiller Reversed quantity, som kan omfatte kanselleringer og endringer, fra Returned quantity for fysiske returer. Salgsdato og justeringsdato er også forskjellige. Kontroller feltet før alle negative tall kalles returer. Shopifys offisielle definisjoner.
Arket er et eget arbeidsformat, ikke en Frihet-eksport eller produktfunksjon. Les guiden til netthandelsdata og integrasjoner på engelsk for sammenhengen med andre registre.
Fastsett skjæringsdato og kohort
Eksemplet er helt syntetisk. Skjæringsdatoen er 2026-09-13, med 30 dagers analytisk oppfølging fra levering, inkludert returer mottatt på dag 30. Dette er verken en lovfrist eller anbefalt returpolitikk. Velg en horisont som passer prosessen, og dokumenter begrunnelsen.
Vi grupperer på SKU og leveringsdato. Kohorten 2026-08-01 har fullført oppfølgingen; 2026-09-06 har bare sju dager. «Moden» betyr at vinduet er fullført, ikke at senere returer er umulige. Behold sene saker til separat analyse.
Del delleveranser i linjer, men behold nøkkelen som samler ordren. Uten leveringsdato kan posten ikke klassifiseres; den er ikke automatisk uten retur. Åpne forespørsler skal være synlige for saksansvarlig, utenfor den fysiske returraten.
Beregn tabellen på nytt
Pakken (ZIP) inneholder order-lines.csv, results.csv og recalculate.py: 30 fiktive leverte linjer, beregnede resultater og et skript som bare bruker standardbiblioteket i Python 3. Behold originalene og kjør python3 recalculate.py i en kopi.
| SKU og kohort | Ordrer | Levererte enheter | Ordrer med retur | Returnerte enheter |
|---|---|---|---|---|
| BAG-A, 2026-08-01, moden | 10 | 20 | 3 | 4 |
| BAG-B, 2026-08-01, moden | 10 | 10 | 1 | 1 |
| BAG-A, 2026-09-06, åpen | 10 | 20 | 1 | 1 |
Moden BAG-A gir 3 / 10 × 100 = 30 % berørte ordrer og 4 / 20 × 100 = 20 % returnerte enheter. For BAG-B er begge 1 / 10 × 100 = 10 %. En ordre kan ha to enheter og returnere begge, som den første BAG-A-linjen.
Nyere BAG-A viser 10 % per ordre og 5 % per enhet, men er åpen. Det beviser ingen forbedring; ingen endring er simulert. Det finnes heller ingen universell grense som gjør 20 % akseptabelt eller uakseptabelt.
Behold forklarlige linjer
line_id,order_id,sku,cohort,channel,delivered_at,units_delivered,units_returned,return_received_at,reason_codeline_id identifiserer linjen; order_id lar deg telle unike ordrer. Ikke summer ordretall per SKU til butikkens total: en ordre kan ha flere produkter. Her har hver ordre én SKU.
SIZE betyr oppgitt uegnet størrelse; DAMAGE, oppgitt skade; UNKNOWN, manglende grunn; NONE, ingen registrert fysisk retur. Koden er ikke en lagerkontroll. Oppbevar originaltekst separat med begrenset tilgang, uten unødvendige personopplysninger.
Hver linje er forenklet til ett mottak og én grunn. Ved flere datoer eller grunner brukes en hendelsestabell knyttet med line_id; summer bare hendelser innenfor horisonten. Ikke gjenta units_delivered per hendelse: det blåser opp nevneren. Undersøk dupliserte ID-er før sletting.
Grunnen viser hvor du bør lete
Moden BAG-A har tre enheter SIZE og én UNKNOWN. 3 / 4 = 75 % beskriver grunnfordelingen blant returnerte enheter, ikke produktets returrate. Å fjerne ukjent ville skape tilsynelatende 100 % størrelsesproblemer fra ufullstendige data.
Sammenlign målene på de tre enhetene, bestilt variant og produktsiden kjøperne så. Riktige mål med andre forventninger gir en hypotese om informasjonen. Avvikende mål krever undersøkelse av enheten og partiet. Den valgte grunnen avgjør ikke mellom forklaringene.
BAG-B har én DAMAGE. Undersøk emballasje, mottaksbevis og parti; koden beviser ikke transportørens skyld. Ett tilfelle viser heller ingen stabil trend.
Ikke gi kanalen skylden
Eksemplets returer ligger i web. Det åpner et spørsmål, ikke et vedtak om å stenge kanalen. Sammenlign samme SKU, variant og horisont; undersøk kampanje, parti og registreringskvalitet. Fem ordrer per kanal gir lite informasjon. Flere små segmenter skaper ikke presisjon.
Ved ulike rapporttall, bevar filtre, skjæringsdato og definisjoner. Shopify dokumenterer forskjeller som følger av periode og rapportlogikk. Kontroller at de samme delene av ordren sammenlignes. Avvik i Shopify-rapporter. Oversikten over integrasjoner hjelper deg å kontrollere tilgjengelig kilde; en oppføring garanterer ikke disse feltene.
Avslutt med en tildelt kontroll
Kopier notatet: «BAG-A, kohort 2026-08-01; 4/20 enheter, 3/10 ordrer; tre SIZE og én UNKNOWN; kontroller mål og produktside; katalogansvarlig; bevis mangler; gjennomgang etter kontroll av de fire returnerte enhetene fra tre ordrer».
Legg til hvilket funn som ville endre handlingen, og behold forrige analyseversjon. Ikke fjern ukjente saker eller endre kohorten for penere tall. Med dokumentasjon kan du velge en begrenset test og senere sammenligne like modne kohorter. Vurder økonomisk effekt separat med marginkalkulatoren: disse ratene måler ikke fortjeneste.
Var denne artikkelen nyttig?
Ofte stilte spørsmål
Kan jeg bruke en ny kohort til å påvise en forbedring?
En kohort som fortsatt observeres, påviser ikke en forbedring sammenlignet med en kohort som har fullført observasjonsperioden. Sammenlign samme produkt over like lange perioder, og hold rater per ordre og per enhet atskilt.
Beviser den vanligste returgrunnen hva problemet skyldes?
Nei: Den er et spor som må undersøkes ut fra produktet og tilgjengelig dokumentasjon. Prosenten beskriver grunner blant de returnerte enhetene, ikke produktets returrate; behold også ukjente grunner.
