Kann ich mit einer neuen Kohorte eine Verbesserung nachweisen?

Eine noch beobachtete Kohorte belegt keine Verbesserung gegenüber einer Kohorte mit abgeschlossenem Beobachtungszeitraum. Vergleiche dasselbe Produkt über gleich lange Zeiträume und trenne die Quoten nach Bestellungen und nach Stückzahlen.

Beweist der häufigste Rückgabegrund die Ursache?

Nein: Er ist ein Hinweis, den du anhand des Produkts und der verfügbaren Belege prüfen musst. Sein Anteil beschreibt die Gründe unter den zurückgegebenen Stückzahlen, nicht die Rückgabequote des Produkts; behalte auch unbekannte Gründe bei.

Retouren je Produkt: Was zuerst prüfen?

Um Retouren zu untersuchen, vergleichen Sie dasselbe Produkt nach derselben Beobachtungsdauer und behalten zwei Quoten bei: betroffene Bestellungen und zurückgesandte Einheiten. Der ausgewählte Rückgabegrund ist ein Hinweis, kein Beweis für die Ursache.

Vier Rucksäcke kommen zurück, und jemand will die Kampagne stoppen. Noch fehlen die ausgelieferte Stückzahl, die Zahl der zugehörigen Bestellungen und die bisherige Beobachtungsdauer. Das Ergebnis dieser Diagnose ist eine zugewiesene Prüfung, kein Schuldiger aus einer Tabellenspalte.

Das gezählte Ereignis festlegen

Ein Antrag, ein physisch eingegangenes Produkt und eine Erstattung sind verschiedene Ereignisse. Hier zählen physisch zurückerhaltene Einheiten mit Bezug zur ursprünglichen Bestellposition. Erstattungen ohne Warenrückgabe und offene Anträge gehören nicht in den Zähler. Offene Anträge brauchen eine eigene Bearbeitungsliste.

Shopify unterscheidet Reversed quantity, das auch Stornierungen und Änderungen umfassen kann, von Returned quantity für physische Rückgaben. Verkaufs- und Korrekturdatum sind ebenfalls verschieden. Prüfen Sie das Feld, bevor Sie jeden negativen Wert als Retoure bezeichnen. Offizielle Shopify-Definitionen.

Unsere Tabelle ist ein eigenes Arbeitsformat, kein Frihet-Export und keine Produktfunktion. Zur Einordnung dient der Leitfaden zu Ecommerce-Daten und Integrationen auf Englisch.

Stichtag und Kohorte festlegen

Das Beispiel ist vollständig synthetisch. Stichtag ist 2026-09-13, die analytische Beobachtungsdauer beträgt 30 Tage ab Lieferung, einschließlich Eingängen am Tag 30. Das ist weder eine gesetzliche Frist noch eine empfohlene Rückgaberichtlinie. Wählen und begründen Sie einen zu Ihrem Prozess passenden Zeitraum.

Gruppiert wird nach SKU und Lieferdatum. Die Kohorte 2026-08-01 hat die Beobachtung abgeschlossen; 2026-09-06 ist erst sieben Tage alt. „Ausgereift“ bedeutet vollständiges Beobachtungsfenster, nicht Unmöglichkeit späterer Retouren. Spätere Fälle bleiben für eine getrennte Auswertung erhalten.

Teillieferungen werden in Positionen getrennt, behalten aber den Bestellschlüssel. Fehlt das Lieferdatum, ist der Datensatz nicht klassifizierbar, nicht automatisch retourenfrei. Offene Anträge bleiben für die zuständige Person sichtbar, außerhalb der physischen Quote.

Ergebnisse nachrechnen

Das Arbeitspaket (ZIP) enthält order-lines.csv, results.csv und recalculate.py: 30 fiktive Lieferpositionen, berechnete Ergebnisse und ein Skript mit ausschließlich Python-3-Standardbibliothek. Bewahren Sie die Originale auf und führen Sie python3 recalculate.py in einer Kopie aus.

SKU und Kohorte	Bestellungen	Gelieferte Einheiten	Bestellungen mit Retoure	Zurückgegebene Einheiten
BAG-A, 2026-08-01, ausgereift	10	20	3	4
BAG-B, 2026-08-01, ausgereift	10	10	1	1
BAG-A, 2026-09-06, offen	10	20	1	1

Für die ausgereifte BAG-A-Kohorte sind 3 / 10 × 100 = 30 % der Bestellungen betroffen; 4 / 20 × 100 = 20 % der Einheiten wurden retourniert. Bei BAG-B ergeben beide Quoten 1 / 10 × 100 = 10 %. Eine Bestellung kann zwei Einheiten enthalten und beide zurückgeben, wie die erste BAG-A-Position.

Die neue BAG-A-Kohorte zeigt 10 % nach Bestellungen und 5 % nach Einheiten, ist aber offen. Das beweist keine Verbesserung; es wurde kein Eingriff simuliert. Auch gibt es keinen universellen Grenzwert, der 20 % akzeptabel oder unakzeptabel macht.

Nachvollziehbare Zeilen behalten

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

line_id bezeichnet die Position; order_id ermöglicht eindeutiges Zählen der Bestellungen. Addieren Sie Bestellzahlen einzelner SKU nicht zum Shopgesamtwert: Eine Bestellung kann mehrere Produkte enthalten. Im Beispiel enthält jede nur eine SKU.

SIZE bedeutet gemeldete unpassende Größe, DAMAGE gemeldeten Schaden, UNKNOWN fehlenden Grund und NONE keine erfasste physische Rückgabe. Der Code ist keine Lagerprüfung. Bewahren Sie Originalangaben getrennt und zugriffsbeschränkt auf, ohne unnötige personenbezogene Daten.

Die Tabelle vereinfacht jede Position auf einen Eingang und Grund. Bei mehreren Terminen oder Gründen verwenden Sie eine über line_id verknüpfte Ereignistabelle und summieren nur Ereignisse im Zeitraum. Wiederholen Sie units_delivered nicht je Ereignis: Das bläht den Nenner auf. Doppelte IDs werden untersucht, bevor Zeilen gelöscht werden.

Der Grund zeigt, wo zu prüfen ist

Bei ausgereiftem BAG-A tragen drei Einheiten SIZE, eine UNKNOWN. 3 / 4 = 75 % beschreibt die Gründe innerhalb der Retouren, nicht die Produktretourenquote. Ohne den unbekannten Grund entstünden scheinbare 100 % Größenprobleme aus unvollständigen Daten.

Vergleichen Sie Maße der drei Einheiten, bestellte Variante und damalige Produktbeschreibung. Richtige Maße bei anderer Erwartung ergeben eine Informationshypothese. Abweichende Maße verlangen die Prüfung von Einheit und Charge. Der ausgewählte Grund entscheidet nicht zwischen diesen Erklärungen.

Bei BAG-B gibt es eine Einheit DAMAGE. Prüfen Sie Verpackung, Eingangsnachweis und Charge; der Code beweist keine Schuld des Transporteurs. Ein Fall zeigt auch keinen stabilen Trend.

Den Kanal nicht vorschnell verantwortlich machen

Alle Retouren des Beispiels liegen in web. Das eröffnet eine Frage, rechtfertigt aber keine Kanalschließung. Vergleichen Sie gleiche SKU, Variante und Beobachtungsdauer; prüfen Sie Aktion, Charge und Erfassungsqualität. Fünf Bestellungen je Kanal liefern wenig Information. Weitere Unterteilung schafft keine Genauigkeit.

Bei widersprüchlichen Berichten sichern Sie Filter, Stichtag und Felddefinition. Shopify dokumentiert Abweichungen durch Zeitraum und Berichtslogik. Prüfen Sie zuerst, ob dieselben Teile einer Bestellung verglichen werden. Shopify-Berichtsabweichungen. Das Verzeichnis der Integrationen hilft, die zugängliche Quelle zu prüfen; ein Eintrag garantiert diese Felder nicht.

Mit einer zugewiesenen Prüfung abschließen

Übernehmen Sie diese Notiz: „BAG-A, Kohorte 2026-08-01; 4/20 Einheiten, 3/10 Bestellungen; dreimal SIZE, einmal UNKNOWN; Maße und Beschreibung prüfen; Katalogverantwortliche Person; Nachweise ausstehend; Wiedervorlage nach Prüfung der vier zurückgegebenen Einheiten aus drei Bestellungen.“

Ergänzen Sie, welcher Befund die Handlung ändern würde, und behalten Sie die vorherige Analyseversion. Entfernen Sie weder Unbekannte noch Kohortenteile für schönere Zahlen. Mit Belegen lässt sich ein begrenzter Test wählen und später mit gleich ausgereiften Kohorten vergleichen. Wirtschaftliche Folgen werden separat mit dem Margenrechner bewertet: Diese Quoten messen keinen Gewinn.