Basket Completion: Ein datengestützter Ansatz für smartere E-Commerce-Upsells

Die meisten Upsell-Systeme starten mit einer einfachen Frage:

Welches Produkt sollen wir diesem Kunden empfehlen?

Es gibt oft eine bessere:

Welches Produkt fehlt in diesem Warenkorb?

Der Unterschied klingt klein, verändert aber, wie Empfehlungen funktionieren. Statt zu raten, was einem Shopper generell gefallen könnte, können wir aus historischen Bestellungen lernen, welche Produkte natürlicherweise zusammengehören.

Wenn Tausende Kund:innen, die A und B gekauft haben, auch C gekauft haben, ist jemand mit A und B im Warenkorb ein starker Kandidat für C. Das ist der Kern eines Basket-Completion-Modells: Empfehlungen, die auf echtem Kaufverhalten basieren - nicht auf manuellen Regeln, Produktähnlichkeit oder generischen Bestsellern.

Die Grundidee

Stell dir einen Shopify-Katalog mit drei Produkten vor: A, B und C. Historische Bestellungen zeigen, dass die Kombination A + B + C besonders oft vorkommt.

Allein das sagt: Die drei Produkte gehören zusammen. Nützlicher ist, wie wir diesen Warenkorb in unvollständige Körbe zerlegen:

Vorhandener Warenkorb	Fehlendes Produkt
A + B	C
A + C	B
B + C	A

Jede Zeile stellt eine andere Frage: Von Kund:innen, die bereits diese Teilmenge hatten - wie oft haben sie auch den fehlenden Artikel gekauft? Die Richtung ist entscheidend: Wir speichern nicht „diese Produkte sind verwandt“, sondern Completion-Regeln.

1. Starte mit historischen Bestellungen

Behandle jede Bestellung als Menge von Produkten. Mengen kannst du anfangs meist ignorieren: zwei Einheiten A und eine Einheit B werden trotzdem zu {A, B}.

Beispiel-Historie:

Bestellung	Produkte
#1	A
#2	A, B
#3	A, B, C
#4	A, B, C
#5	A, B, D
#6	A, C
#7	A, B, C
#8	B, C
#9	A, C, D
#10	A, B, C

Das Signal, das zählt, ist Co-Occurrence: Welche Produkte tauchten im selben Warenkorb auf?

2. Zerlege Warenkörbe in kleinere Kombinationen

Eine Bestellung mit drei Produkten {A, B, C} ergibt die Zwei-Produkt-Teilmengen {A, B}, {A, C} und {B, C} - jeweils mit einem fehlenden Completion-Kandidaten.

Aus einem vollständigen Warenkorb speichern wir drei gerichtete Beziehungen:

• Kund:innen mit A + B legen häufig C hinzu
• Kund:innen mit A + C legen häufig B hinzu
• Kund:innen mit B + C legen häufig A hinzu

3. Zähle, wie oft jeder Warenkorb vervollständigt wird

Über Hunderttausende Bestellungen hinweg könnten wir sehen:

Vorhandener Warenkorb	Zusätzliches Produkt	Bestellungen
A + B	C	4.000
A + B	D	1.200
A + B	E	300
A + C	B	4.000
A + C	D	500
B + C	A	4.000

Rohe Zählungen legen schon nahe, für A + B C zu empfehlen - aber Häufigkeit allein reicht nicht.

4. Berechne die Wahrscheinlichkeit für das fehlende Produkt

Angenommen, A + B + C kommt in 4.000 Bestellungen vor. Das klingt stark - bis wir erfahren, dass A + B in 1.000.000 Bestellungen vorkommt. Dann vervollständigt C nur 0,4% dieser Warenkörbe.

Was wir wirklich wollen, ist die bedingte Wahrscheinlichkeit (Confidence im Sinne von Assoziationsregeln):

$$P(C \mid A,B) = \frac{\text{Bestellungen mit } A,B,C}{\text{Bestellungen mit } A,B}$$

Wenn 10.000 Bestellungen A + B enthalten und 4.000 davon A + B + C:

$$P(C \mid A,B) = \frac{4000}{10000} = 0.40 = 40\%$$

Auf Deutsch: 40% der historischen A-+-B-Warenkörbe enthielten auch C.

5. Die Richtung ist extrem wichtig

Dieselben drei Produkte können sehr unterschiedliche Empfehlungsstärken erzeugen - je nachdem, was schon im Warenkorb liegt.

Bei 10.000 A-+-B-Bestellungen und 4.000 A-+-B-+-C-Bestellungen:

$$P(C \mid A,B) = 40\%$$

Aber wenn nur 5.000 Bestellungen A + C enthalten (und dieselben 4.000 A + B + C):

$$P(B \mid A,C) = 80\%$$

Also ist A + B → C mit 40% schwächer als A + C → B mit 80% - obwohl der Cluster {A, B, C} identisch ist. Das Modell muss Warenkorb-Completion-Beziehungen bewerten, keine ungerichteten Produktcluster.

6. Ein praktisches Shopify-Beispiel

Ein Supplement-Shop verkauft Proteinpulver, Creatin, Shaker, Proteinriegel und T-Shirts.

Unter 50.000 Proteinpulver-Bestellungen:

• 30.000 hatten auch einen Shaker → 60%
• 20.000 hatten auch Creatin → 40%
• 5.000 hatten auch ein T-Shirt → 10%

Für einen Ein-Artikel-Warenkorb mit Proteinpulver gewinnt der Shaker.

Eine Ebene tiefer: 20.000 Bestellungen enthielten Proteinpulver + Creatin, und 18.000 davon auch einen Shaker:

$$P(\text{Shaker} \mid \text{Protein}, \text{Creatin}) = 90\%$$

Niemand hat konfiguriert: „Wenn jemand Pulver und Creatin kauft, zeig diesen Shaker.“ Die Beziehung wurde aus dem Verhalten entdeckt - nicht aus Bestsellers, Collection-Zugehörigkeit oder Produktähnlichkeit.

7. Warum das anders ist als Produktähnlichkeit

Ähnlichkeits-Engines empfehlen mehr vom Gleichen: nach Laufschuhen noch mehr Laufschuhe. Das hilft bei Discovery, kann bei Upsells aber Entscheidungsreibung erzeugen.

Basket Completion tendiert zu Komplementen:

• Laufschuhe + Socken → Laufgürtel
• Kamera + Objektiv → Speicherkarte
• Protein + Creatin → Shaker
• Kaffeemaschine → Bohnen
• Grill + Fleisch → Sauce

Das System fragt: Was kaufen Kund:innen mit einem ähnlichen Warenkorb üblicherweise, das dieser Kunde noch nicht hat?

8. Nutze alle Bestellungen, nicht nur Drei-Produkt-Warenkörbe

Eine Bestellung mit vier Produkten {A, B, C, D} liefert viele Regeln auf einmal: Implikationen von Einzelartikeln, Paar-Completions und sogar A + B + C → D. Größere Warenkörbe solltest du nicht verwerfen - sie verdichten den Graph der Completion-Regeln.

9. Spezifischere Warenkörbe erzeugen meist bessere Empfehlungen

Für einen Warenkorb mit A + B könnten wir sehen:

• A → C mit 25%
• B → C mit 20%
• A + B → C mit 65%

Zu wissen, dass A und B beide vorhanden sind, transportiert mehr Intent als jedes Produkt allein. In Production solltest du den spezifischsten Match mit genug Evidenz bevorzugen und dann zurückfallen:

1. Exakter Warenkorb A + B + C → ?
2. Paare A + B, A + C, B + C
3. Einzelartikel A, B, C
4. Metadaten / Merchant-Defaults / Bestsellers

10. Das Problem kleiner Stichproben

A + B + C → D = 100% mit Support von 3 Bestellungen ist weniger vertrauenswürdig als A + B → E = 72% mit 15.000 Bestellungen.

Jede Regel braucht mindestens zwei Metriken:

Confidence - wie oft der Kandidat mit dem Warenkorb vorkommt:

$$\text{Confidence} = \frac{\text{Bestellungen mit Warenkorb + Kandidat}}{\text{Bestellungen mit Warenkorb}}$$

Support - wie viele historische Bestellungen die Regel belegen.

Ein harter Mindest-Support kann winzige Stichproben komplett verwerfen. Das hilft, ist aber grob: Eine Regel mit 50 Beobachtungen wird genauso behandelt wie eine mit 50.000, sobald beide die Schwelle schaffen - und alles darunter verschwindet, selbst wenn es Richtung gibt.

11. Nutze Bayesian Smoothing statt roher Confidence

Das ist eines der wichtigsten statistischen Upgrades für eine Basket-Completion-Engine.

Stell dir zwei Kandidaten für denselben Warenkorb A + B vor:

Regel	Evidenz	Rohe Confidence
A + B → C	1 / 1	100%
A + B → D	8.000 / 10.000	80%

Rohe Confidence wählt C. Offensichtlich ist D die vertrauenswürdigere Empfehlung.

Statt einen einzelnen Glückstreffer als Gewissheit zu behandeln, zieht Bayesian Smoothing dünne Schätzungen zu einem Prior, bis genug Evidenz vorliegt.

Mit einem Beta-Prior, parametrisiert durch$\alpha$ und$\beta$, lautet die geglättete Schätzung:

$$\hat{P} = \frac{\text{Erfolge} + \alpha}{\text{Beobachtungen} + \alpha + \beta}$$

Hier sind Erfolge Bestellungen, die den Warenkorb und den Kandidaten enthalten; Beobachtungen sind alle Bestellungen mit dem Warenkorb.

Wähle einen Prior, der eine konservative Baseline widerspiegelt - zum Beispiel einen schwachen Prior nahe der shopweiten Kaufrate des Kandidaten, oder einen schwach informativen Prior wie$\alpha = 2$,$\beta = 18$ (Mittelwert$10\,\%$). Dann:

• 1 / 1 wird von$100\,\%$ auf etwas wie$\sim\!15\,\%$ gezogen (oder was der Prior-Mittelwert impliziert)
• 8.000 / 10.000 bleibt nah bei$80\,\%$

Der dünne Spike bricht zusammen; die gut belegte Regel bewegt sich kaum.

Diese Stabilität ist besonders wichtig für kleinere Shopify-Merchant:innen, neue Produkte und Long-Tail-SKUs - genau dort, wo rohe Confidence am übermütigsten ist. Du kannst weiterhin eine weiche Support-Untergrenze behalten, aber mit Smoothing bewertet das Ranking keinen einzelnen Zufallstreffer mehr als perfekten Score.

In der Ranking-Formel der nächsten Abschnitte solltest du geglättete Confidence der rohen vorziehen:

$$\text{Score} = \hat{P} \times \log(1 + \text{Support}) \times \text{Lift}$$

12. Beliebte Produkte können das Ergebnis verzerren

Wenn 70% der A-+-B-Bestellungen C enthalten, wirkt das hervorragend - es sei denn, C kommt in 80% aller Shop-Bestellungen vor. Dann macht A + B C nicht wahrscheinlicher; C ist einfach populär.

Lift vergleicht die bedingte Wahrscheinlichkeit mit der Basisrate:

$$\text{Lift}(A,B \rightarrow C) = \frac{P(C \mid A,B)}{P(C)}$$

Wenn$P(C \mid A,B) = 40\,\%$ und$P(C) = 10\,\%$, dann ist$\text{Lift} = 4$: Käufer:innen von A + B kaufen C viermal so häufig wie der Durchschnitt.

Wenn$P(C \mid A,B) = 70\,\%$ und$P(C) = 80\,\%$, ist der Lift$0{,}875$ - A + B macht C sogar weniger wahrscheinlich als normal. Ohne Lift degradiert die Engine still zu „immer den Bestseller empfehlen“.

13. Ranking der Kandidaten

Für den Warenkorb A + B könnten wir haben:

Kandidat	Confidence	Support	Lift
C	62%	8.400	3,2
D	74%	180	1,8
E	38%	12.000	4,1

Keine einzelne Spalte gewinnt immer. Ein praktischer Score nutzt geglättete Confidence und dämpft schwachen Support:

$$\text{Score} = \hat{P} \times \log(1 + \text{Support}) \times \text{Lift}$$

Die Formel kannst du später gegen Live-Upsell-Conversion tunen. Die Frage verschiebt sich von „Was kam am häufigsten vor?“ zu „Was hat die stärkste und zuverlässigste Beziehung zu diesem Warenkorb?“

14. Precompute den teuren Teil

Kombinationen über die gesamte Bestellhistorie zu minen ist teuer. Diese Arbeit kann offline nach Zeitplan laufen. Speichere Ergebnisse als Lookup-Zeilen:

Warenkorb	Kandidat	Confidence	Support	Lift
A	C	25%	12.000	1,4
A + B	C	62%	4.200	3,2
A + C	B	74%	3.900	4,1

Zur Cart- oder Post-Purchase-Zeit ist der Runtime-Pfad ein keyed Lookup für die aktuelle Warenkorb-Menge, danach Ranking und Filter - schnell genug für Storefront-UX.

15. Business-Regeln bleiben wichtig

Wahrscheinlichkeit sollte nicht ungeprüft ausgeliefert werden. Vor der Anzeige filtere Kandidaten:

• Schon im Warenkorb?
• Auf Lager / Variante verfügbar?
• Markt- und Channel-fähig?
• Merchant-Exclusions?
• Kompatibel mit Abo / Selling Plan?
• Preisband akzeptabel?
• Veröffentlicht und kaufbar?

Halte zwei Schichten klar getrennt:

• Empfehlungs-Schicht - statistisch beste Completion
• Commerce-Schicht - was tatsächlich angeboten werden darf

16. Cold Start und dünne Daten

Große Shops haben vielleicht Millionen Bestellungen; kleine Shops oder neue SKUs fast keine. Nutze die Fallback-Hierarchie aus Abschnitt 9, damit Verhaltensdaten gewinnen, wenn sie existieren - ohne leere Zustände, wenn sie fehlen.

17. Das Modell kann sich kontinuierlich verbessern

Eine erste Version braucht kein ML - nur Bestellungen, Kombinationen, Zähler, Confidence (idealerweise Bayesian-geglättet), Support, Lift und Ranking. Sobald live:

• Impressions, Klicks, Accept-Rate
• Conversion und inkrementeller Umsatz
• inkrementelle Bruttomarge
• durchschnittlicher Upsell-Wert

Historische Co-Purchases sagen: Kund:innen haben C oft mit A + B gekauft. Live-Daten sagen: Kund:innen haben C akzeptiert, als es angeboten wurde. Das zweite Signal ist das, worauf du langfristig optimieren solltest.

18. Optimiere Expected Value, nicht nur Wahrscheinlichkeit

Das wahrscheinlichste Add-on ist nicht immer das beste Angebot.

Angenommen für A + B:

• C konvertiert mit 25% und €3 inkrementeller Marge → Expected €0,75
• D konvertiert mit 15% und €15 inkrementeller Marge → Expected €2,25

$$\text{ExpectedValue} = P(\text{Kauf} \mid \text{Warenkorb}, \text{Empfehlung}) \times \text{InkrementellerWert}$$

D gewinnt bei Expected Margin trotz niedrigerer Conversion.

Eine reife Engine entwickelt sich von „wahrscheinlichste Completion“ zu „höchster erwarteter inkrementeller Wert für diesen Warenkorb (und irgendwann diesen Kunden)“.

Von Basket Completion zur intelligenten Upsell-Engine

Der Ansatz kann fast naiv starten:

1. Historische Shopify-Bestellungen in Warenkörbe verwandeln
2. Warenkörbe in Kombinationen zerlegen
3. Completions fehlender Produkte zählen
4. Confidence mit Bayesian Smoothing berechnen, plus Support und Lift
5. Kandidaten ranken und Commerce-Filter anwenden
6. Precomputete Lookups zur Cart- / Post-Purchase-Zeit ausliefern
7. Den Loop mit Live-Accept- und Margen-Daten schließen

Ein live Warenkorb {A, B} wird zur Query:

$$\{A,B\} \rightarrow ?$$

und der historische Graph kann C antworten, weil Tausende früherer Kund:innen gezeigt haben:

Wenn du A und B kaufst, fehlt dir wahrscheinlich C.

Das ist eine andere Philosophie als klassische „empfohlene Produkte“. Statt zu raten, was einem Shopper gefallen könnte, lernt das System wie echte Kund:innen ihre Warenkörbe vervollständigen - und die Bestellhistorie selbst wird zur Recommendation Engine.

Wie das von Shopifys nativen Empfehlungen abweicht

Es gibt Überschneidungen mit dem, was Shopify bereits anbietet. Ein architektonischer Unterschied sticht trotzdem heraus.

Was Shopify macht

Shopify sagt, dass automatisch generierte Related-Product-Empfehlungen nutzen können:

• Kaufhistorie - Produkte, die historisch zusammen gekauft wurden
• ähnliche Produktbeschreibungen
• verwandte Collections als Fallback

Shopifys öffentliche API ist grundsätzlich produktzentriert. Du fragst Empfehlungen für eine bestimmte productId oder einen productHandle ab, und Shopify gibt bis zu 10 Empfehlungen zurück.

Konzeptionell:

Die aktuelle Shopify-Entwicklerdokumentation sagt: Related-Empfehlungen werden automatisch generiert, während Complementary-Empfehlungen manuell über Search & Discovery konfiguriert werden müssen.

Shopify nutzt also durchaus Co-Purchase-Informationen. Die dokumentierte Storefront-Recommendation-Schnittstelle ist aber keine allgemeine Basket-Completion-API.

Der Warenkorb ist der Input, nicht ein einzelnes Produkt

Dieses Modell startet mit dem gesamten aktuellen Warenkorb.

Das ist ein anderes Problem als:

Betrachte diese historischen Daten:

• A → C = 20%
• B → C = 18%
• A + B → C = 82%

A oder B einzeln zu betrachten, legt die wichtige Beziehung nicht offen. Die Kombination tut es.

Das System erfasst die Interaktion$P(C \mid A,B)$ statt nur$P(C \mid A)$ oder$P(C \mid B)$. Dieser Unterschied ist für Upsells extrem wertvoll.

Ein konkretes Beispiel

Stell dir einen Supplement-Shop vor. Ein Kunde hat Whey-Protein + Creatin.

Shopifys produktbezogenes System könnte effektiv Beziehungen wie diese haben:

Das ist nützlich. Basket Completion fragt etwas Spezifischeres:

Historische Daten könnten zeigen: Whey + Creatin → Shaker mit Confidence 78%, Support 12.430 und Lift 3,7.

Die Empfehlung ist dann nicht mehr nur „Leute, die Whey kaufen, kaufen auch Shaker.“ Sie lautet: Kund:innen, die genau diese Kombination kaufen, kaufen einen Shaker 3,7× häufiger als der Durchschnitt. Das ist ein stärkeres Warenkorb-Signal.

Wo die Architektur weitergehen kann

Die in diesem Artikel beschriebene volle Architektur geht deutlich über das hinaus, was Shopify öffentlich dokumentiert:

Fähigkeit	Shopify nativ	Basket-Completion-Engine
Purchase-History-Signal	Ja	Ja
Produktähnlichkeit	Ja	Kann ergänzt werden
Collection-Beziehungen	Ja	Kann ergänzt werden
Einzelprodukt-Empfehlungen	Ja	Ja
Multi-Produkt-Warenkorb-Matching	Nicht öffentlich als Recommendation-API-Modell dokumentiert	Ja
A + B → C-Regeln	Nicht exponiert / dokumentiert	Ja
Confidence	Nicht exponiert	Ja
Support	Nicht exponiert	Ja
Lift	Nicht exponiert	Ja
Bayesian Smoothing	Nicht exponiert	Kann ergänzt werden
Time Decay	Nicht exponiert	Kann ergänzt werden
Promotion Correction	Nicht exponiert	Kann ergänzt werden
Margen-Optimierung	Nicht exponiert	Kann ergänzt werden
Upsell-Conversion-Lernen	Nicht als Ranking-Steuerung exponiert	Kann ergänzt werden
Exploration / Bandits	Nicht exponiert	Kann ergänzt werden
Kundenhistorie	In dieser API nicht exponiert	Kann ergänzt werden

Sei vorsichtig mit der Behauptung, Shopify würde intern keine dieser Techniken nutzen. Shopify veröffentlicht die internen Details seines Recommendation-Algorithmus nicht - das können wir also nicht wissen.

Die belastbare Aussage ist: Shopify exponiert und dokumentiert dieses Niveau von warenkorb-bewusstem Ranking und Optimierung öffentlich nicht.

Die größte Chance ist nicht, Shopify bei Empfehlungen zu schlagen

Shopifys natives System ist primär auf Product Discovery ausgelegt. Die Related-Product-Dokumentation beschreibt das Ziel als: Produkte empfehlen, die dem Produkt ähneln, mit dem die Kund:innen gerade interagieren.

Basket Completion hat ein engeres Ziel: inkrementellen Wert aus einer Upsell-Gelegenheit maximieren.

Dir muss nicht unbedingt interessieren, ob C das „relevanteste“ Produkt ist. Dich interessiert, ob das Zeigen von C dazu führt, dass mehr ausgegeben wird als ohne die Empfehlung.

Irgendwann kann das System so scoren:

$$\text{Score}(C) = P(C \text{ akzeptiert} \mid \text{Warenkorb}, \text{Kunde}, \text{Kontext}) \times \text{Marge}(C)$$

Dann betrachte einen Warenkorb Protein €35 + Creatin €25 = €60:

Kandidat	Acceptance	Marge	Expected Margin
Shaker €10	24%	€6	€1,44
Proteinriegel €3	35%	€1	€0,35
Pre-Workout €30	11%	€18	€1,98
BCAA €20	8%	€12	€0,96

Der Shaker hat die stärkste Warenkorb-Beziehung. Der Proteinriegel hat die höchste Conversion-Wahrscheinlichkeit. Pre-Workout erzeugt die höchste erwartete inkrementelle Marge - und könnte deshalb die optimale Empfehlung sein.

Das ist kein Standard-„People also bought“ mehr. Es ist eine Optimierungs-Engine.

Ein weiterer Vorteil: Du siehst den tatsächlichen Warenkorb

Das ist besonders relevant für ein Upsell-Produkt. Shopifys dokumentierte Recommendation-Query nimmt ein Produkt als Input.

Die Engine kann Kunde, gesamten Warenkorb, Bestellhistorie, Warenkorbwert, aktuelle Produkte, Preise, Bestand, frühere Käufe, Upsell-Impression-Historie und Upsell-Conversion-Historie nehmen - und beantworten: Was soll ich diesem konkreten Kunden genau jetzt zeigen?

Statt$\text{Recommendation}(\text{Product})$ ist das Ziel$\text{Recommendation}(\text{Customer}, \text{Basket}, \text{Context})$:

$$\operatorname*{argmax}_{x} \mathbb{E}[\text{IncrementalMargin} \mid \text{Customer}, \text{Basket}, \text{Context}, \text{Show}(x)]$$

Das ist deutlich ambitionierter.

Wie du die Idee positionierst

Pitch es nicht als „wir haben einen besseren Recommendation-Algorithmus als Shopify.“ Das ist schwer zu belegen, weil Shopify intern nicht alles offenlegt.

Ein besserer Frame: Shopify empfiehlt Produkte. Wir optimieren den nächsten Kauf.

Oder technisch: Klassische Empfehlungen fragen, welche Produkte verwandt sind. Eine Basket-Completion-Engine fragt, welches Produkt in diesem konkreten Warenkorb fehlt - und irgendwann, welche Empfehlung den höchsten erwarteten inkrementellen Wert erzeugt.

Dieser Unterschied ist sowohl belastbar als auch, für ein Upsell-Produkt, deutlich interessanter.