Retouren analysieren: was die Retourenquote nicht zeigt

Warum die Retourenquote allein in die Irre führt

Die Retourenquote wird fast überall gleich gerechnet: Retouren eines Monats geteilt durch Verkäufe desselben Monats. Diese Rechnung ist systematisch falsch, und zwar immer in dieselbe Richtung. Die Retouren des laufenden Monats gehören überwiegend zu Bestellungen aus den Monaten davor, während die frischen Bestellungen ihre Rückgabefrist noch vor sich haben. Der jüngste Monat sieht dadurch besser aus, als er ist.

Richtig gerechnet wird je Bestell-Kohorte: alle Retouren, die zu den Bestellungen eines Zeitraums gehören, geteilt durch diese Bestellungen. Kohorten, deren Rückgabefenster noch läuft, sind unreif und werden als vorläufig markiert, statt als Trend verkauft zu werden. Der Skill macht das automatisch und schreibt es in den Report.

Dazu kommt die zweite Verkürzung: eine Quote für alles. In der Retourenforschung der Universität Bamberg sind es drei, und sie beantworten verschiedene Fragen.

Und noch eine Trennung, die kaum ein Report macht: Sendungen, die nie abgeholt wurden, sind keine Kundenretoure. Rechtlich ist das kein Widerruf, die Ware war nie ausgepackt. Der Skill weist sie deshalb als eigene Nichtabholquote aus und lässt sie in der Retourenquote weg, in der Kostenrechnung aber drin. Sonst steht im Kopf des Reports eine Zahl, die im Betrieb niemand wiedererkennt.

Was der Skill in den Daten findet

Sieben Muster plus die Quoten, auf denen alles steht, alle aus denselben zwei Exporten. Jedes Finding bekommt ein Evidenz-Tag: belegt für eine Zahl direkt aus den Daten, Hypothese für eine plausible Deutung, fehlende Daten für alles, was erst mit einer weiteren Spalte prüfbar wäre.

Artikel mit zu kleiner Verkaufsbasis werden bewusst nicht bewertet. Eine Quote aus drei Verkäufen ist Zufall, keine Information, und sie in eine Rangliste zu schreiben produziert Arbeit ohne Grund.

Was in einer normalen Auswertung untergeht

Der eigentliche Grund, so eine Analyse überhaupt zu fahren, sind nicht die Zahlen, die ohnehin jeder Report zeigt. Es sind die Befunde, die ein Standard-Report strukturell nicht zeigen kann. Der Skill hat dafür einen eigenen Abschnitt, und er sagt bei jedem Befund dazu, warum er sonst unsichtbar bleibt.

Die Zahlen in diesen Beispielen stammen aus dem synthetischen Demo-Datensatz im Repo, nicht aus einem echten Shop. Der komplette Beispiel-Report liegt dort als Markdown daneben.

Die Evidenz: was gemessen wirkt und was nur behauptet wird

Beim Thema Retouren kursieren mehr Zahlen als Messungen. Deshalb liegt im Skill eine eigene Referenzdatei mit der Evidenzlage: A/B-Tests, Feldexperimente und Meta-Analysen, jede Aussage mit Belegstufe. Der Skill darf nur empfehlen, was dort als gemessen wirksam gilt, und die widerlegten Maßnahmen nie vorschlagen.

Was gemessen wirkt

Drei Empfehlungen, die der Skill deshalb nicht gibt

• Größenberater-Software gegen Retouren. Zalandos eigener A/B-Test mit über 300.000 Kunden je Gruppe brachte 2,1 Prozent mehr Conversion, aber keine statistisch signifikante Senkung größenbedingter Retouren. Eine schwedische Plattform maß bei Nutzern des Beraters sogar 0,65 Prozent mehr Retouren. Größenberatung ist eine Conversion-Investition. Der simple Hinweis am Artikel schlägt sie im Retourenziel deutlich.
• Rechnungskauf abschalten. Die Korrelation ist belegt, 25,3 Prozent Retourenquote bei Rechnung gegen 13,1 bei Vorkasse. Die Wirkungsrichtung ist es nicht: Laut ECC Köln wählen 41 Prozent den Rechnungskauf, weil die Retoure eingeplant ist. Die Zahlart zieht das Verhalten an, sie erzeugt es nicht. Wer sie streicht, verliert eher den Umsatz an den Wettbewerb.
• Die Rückgabefrist verkürzen. Nach der Meta-Analyse von Janakiraman u. a. ist die lange Frist ausgerechnet die Kulanz-Dimension, die Käufe kaum bremst und Retouren sogar senkt. Wer Kulanz zurücknehmen will, setzt am Umfang an, nicht an der Frist. Eine strengere Policy ist im Skill nie die Standardempfehlung.

Zahlen, die kursieren und keiner Prüfung standhalten

Wie ein Lauf abläuft

Das Prinzip dahinter passt in einen Satz: das Script rechnet, die AI interpretiert. Jede Zahl im Report stammt aus einer analysis.json, die ein deterministisches Python-Script erzeugt. Was dort nicht steht, darf nicht im Report stehen. Damit fällt die häufigste Fehlerquelle weg, nämlich ein Modell, das Prozentwerte im Kopf ausrechnet.

1. Mapping. Der Skill liest die Kopfzeilen deiner Exporte und mappt sie auf ein kanonisches Schema. Bei Mehrdeutigkeit fragt er nach, statt zu raten. Fehlende optionale Spalten werden benannt, zusammen mit den Analysen, die dadurch entfallen.
2. Rechnen. Ein Script berechnet Quoten je Kohorte, Muster, Kosten und Kreuzungen. Läuft in unter einer Sekunde, ohne Netzverbindung.
3. Interpretieren und berichten. Verdict zuerst, das teuerste Muster in Euro. Dann Kennzahlen, Findings mit Evidenz-Tag, blinde Flecken, Maßnahmen, offene Fragen und alle getroffenen Annahmen.
4. Dashboard. Eine eigenständige HTML-Datei ohne externe Abhängigkeiten: Kennzahlen, Kohorten-Chart, Kosten je Artikel, Retourengründe, Zahlart-Kontrast, Größenverteilung, dazu alle Zahlen als Tabelle. Öffnet sich im Browser und lässt sich weiterreichen.

Wie eine Maßnahme aussieht

Jede Maßnahme trägt dieselben Felder, damit sie weitergereicht werden kann, ohne dass jemand nachfragen muss: was in den Daten steht, warum es fürs Geschäft zählt, wie groß der Hebel in Euro ist, was konkret zu tun ist, welcher Aufwand dahinter steckt, wer es macht, woran du merkst, dass es wirkt, und was dabei nicht kaputtgehen darf. Das letzte Feld ist Pflicht, weil fast jeder Retouren-Hebel Conversion oder Umsatz kosten kann. Ein Größenhinweis, der Mehrgrößen-Bestellungen stärker treibt als er Retouren senkt, ist unterm Strich negativ.

Höchstens fünf Maßnahmen je Report. Eine Liste mit zwanzig Empfehlungen wird nicht umgesetzt.

Welche Daten du brauchst

Zwei CSV-Exporte, verbunden über die Bestellnummer. Kein API-Zugang, kein Zugriff auf dein Livesystem.

Retouren-Positionen

Pflicht: Retourennummer, Bestellnummer, Retourendatum, Artikelnummer, Menge und Retourengrund. Optional, und jedes davon schaltet eine Analyse frei: Größe und Farbe, Artikelname, Kundennummer, Zahlart, Kanal, Retourentyp, Erstattungsbetrag, Lieferdatum, Zustand der Ware, Charge und der Freitext zum Grund.

Verkaufs-Positionen

Pflicht: Bestellnummer, Bestelldatum, Artikelnummer, Menge und Nettoumsatz. Wichtig ist der Zeitraum: Der Verkaufs-Export muss den Retouren-Zeitraum plus Rückgabefenster nach vorn abdecken, sonst stimmt der Nenner nicht. Mit Einkaufspreis kommt der Deckungsbeitrag nach Retouren dazu.

Aus welchem System

• Xentral: Berichte-Export oder API. Grund hängt an der Position, Größe und Farbe stecken in der Variante. Passt direkt.
• Shopify: kein nativer Retouren-CSV-Export. Die Daten kommen über einen GraphQL-Abzug oder eine Retouren-App, die Gründe aus dem ReturnReason-Enum. Die Normalisierung im Script kennt beides.
• WooCommerce: nativ nur Refunds ohne Grund, Gründe erst mit RMA-Plugin. Ohne Grund-Spalte läuft die Rumpf-Analyse aus Quoten und Kosten, und der Report weist das aus.

Was der Skill bewusst nicht tut

Die Guardrails stehen fest im Skill, nicht im guten Willen des Modells. Sie sind der Grund, warum du das Ergebnis weiterreichen kannst, ohne es Zeile für Zeile gegenzuprüfen.

• Keine erfundene Zahl. Jede Zahl im Report muss in der berechneten analysis.json stehen. Eine benannte Lücke ist eine vollständige Antwort, eine geschätzte Zahl nicht.
• Keine Sanktion gegen Kundinnen und Kunden. Serien-Retournierer sind eine Prüfliste für Menschen, mit Nettobeitrag daneben. Zur Einordnung: Händler schätzen den Missbrauchsanteil auf 19,1 Prozent, gemessen geben 3,6 Prozent der Befragten eine Missbrauchsabsicht an. Faktor fünf zwischen gefühlt und gemessen.
• Keine Ersparnis-Versprechen. „Bis zu X Euro, wenn das Muster verschwindet“ ist zulässig, „spart X Prozent“ nicht.
• Keine Rangliste auf dünner Basis. Artikel unter dem Mindest-N werden nicht bewertet, Kohorten- und Perioden-Quoten nie vermischt.
• Keine Daten bei mir. Es gibt keinen Upload, keinen Account, keine Datenbank. In Claude Code bleibt alles auf deinem Rechner.

Dazu gehört ein Abschnitt, den kein Report sonst hat: was auffällig aussieht, aber in Ordnung ist. Mindestens zwei geprüfte und für unbedenklich befundene Punkte, mit Zahl. Der Abschnitt verhindert, dass jede Abweichung zum Problem erklärt wird und am Ende niemand mehr weiß, wo er anfangen soll.

Wie der Skill entstanden ist

Die meisten bauen einen Skill in zwei Schritten: Workflow erkennen, dann „bau mir dafür einen Skill“. Genau da geht die Qualität verloren. Der Wert steckt nicht im Schreiben der Datei, sondern in dem, was vorher passiert.

1. Session aufmachen und das Vorhaben erzählen, nicht mit einer Anweisung starten.
2. Alles reingeben, am besten diktiert. Beim Reden kommt deutlich mehr Kontext raus als beim Tippen.
3. Recherchieren lassen: gibt es das schon? Ein Framework mit vielen Sternen auf GitHub schlägt den Eigenbau. Für die Retouren-Analyse gab es nichts Brauchbares.
4. Recherchieren lassen: was weiß die Welt über das Thema? Hier kam die Evidenzdatei her, und mit ihr zwei Empfehlungen, die sonst falsch im Skill gelandet wären.
5. Erste Version bauen, ausdrücklich noch nicht als Skill.
6. Echte Daten reingeben und das Ergebnis ausspielen lassen.
7. Prüfen und iterieren. Ein Modell weiß nicht von allein, was für dich ein gutes Ergebnis ist. Sagst du es nicht, liefert es trotzdem etwas, nur eben nach seinem eigenen Maßstab.
8. Erst wenn das Ergebnis sitzt, daraus einen Skill bauen lassen.

Danach ist nicht Schluss. Im Einsatz kommen laufend neue Muster dazu, die wieder einfließen. Wenn du wissen willst, wie das im Alltag aussieht: unter Claude-Skills liegen die anderen Skills aus dem Kundeneinsatz, und in how-to-claude die Lernpfade dahinter.

Häufige Fragen