Conversion / Cart
Build-Your-Own-Bundle auf Shopify: wo die native Bundle-Lösung an die Wand fährt
Die native Shopify-Bundles-App löst fixeBundles und Multipacks sauber – inklusive Bestandsabbuchung je Komponente. An einem echten Build-Your-Own-Bundle, bei dem der Kunde Komponenten frei wählt, der Preis sich nach Auswahlmenge staffelt und der Bestand pro Komponente live greifen muss, fährt sie an die Wand. Das ist kein Bug, sondern eine Architekturgrenze: Sobald die Komposition variabel wird, braucht es die Cart-Transform-Function der Bundles-&-Selling-Plans-API – also eine eigene oder eine Drittanbieter-App.
Die Grenzlinie in einem Satz
Native Bundles = der Händler definiert die Zusammenstellung vorab. BYOB = der Kunde stellt zur Laufzeit zusammen. Genau an dieser Stelle wechselt Shopify intern das Konzept: Fixe Bundles sind „componentized products“, die über die productBundleCreate-Mutation entstehen; ihr Preis kommt vom Parent-Produkt, ihr Bestand wird aus den Komponenten errechnet (shopify.dev, productBundleCreate). Freie Komponentenwahl dagegen ist kein Produkt mehr, sondern eine Warenkorb-Operation – und die läuft über die Cart Transform Function (shopify.dev, Bundles).
Was die native App kann – belegt
- Fixe Bundles & Multipacks: ein Bundle = ein Produkt, das aus mehreren Komponenten besteht. Kostenlose App, auf allen Plänen verfügbar.
- Bestand je Komponente: Der Bundle-Bestand wird aus den Komponenten errechnet; die Komponente mit dem niedrigsten Bestand limitiert. Ein Verkauf bucht je Komponente ab – vorausgesetzt, jede Komponente hat Bestands-Tracking aktiv (Shopify Help, Eligibility).
- Eingeschränkte Variantenwahl: Hat eine Komponente Varianten, kann der Kunde aus den hinterlegten Varianten wählen. Bundle-Grenzen: max. 3 Optionen und 100 Varianten gesamt; pro Komponente bis 2000 Einheiten ([Quelle: shopify.dev / help.shopify.com – Komponenten-Obergrenze 30 (fix) vs. höhere Limits bei dynamischen Bundles je nach Quelle unterschiedlich; vor Go-Live am realen Shop gegenprüfen] factcheck_flag).
Wo es bricht – die drei konkreten Bruchstellen
1. Preislogik: parent-basiert statt auswahlabhängig
Der Preis eines nativen Bundles hängt am Parent-Produkt – nicht an der Summe oder einer Staffel über die gewählten Komponenten. Klassisches BYOB („wähle 3 für 39 €, 5 für 59 €, jedes weitere 12 €“) ist damit nicht abbildbar. Auch der praktische Pflegefehler steckt hier: Ändert sich ein Komponentenpreis, aktualisiert sich der Bundle-Preis nicht automatisch – das ist ein manueller Schritt (Shopify Help, Bundles). Bei einem variablen BYOB skaliert dieser Drift ins Unhaltbare.
2. Bestandslogik: fix komponiert ≠ je Auswahl dekrementiert
Die native Bestandsrechnung funktioniert, weil die Zusammenstellung feststeht. Bei freier Komponentenwahl muss zur Laufzeit pro Warenkorb entschieden werden, welche Komponente in welcher Menge abzubuchen ist – inklusive Sonderfälle wie „dieselbe Komponente zweimal gewählt“ oder „eine Komponente knapp, das Bundle aber sonst lieferbar“. Das ist die Domäne der Cart Transform Function, die im Checkout die Bundle-Zeile in ihre Komponenten auflöst. Faustregel: Sobald derselbe Artikel in verschiedenen Bundle-Kontexten unterschiedlich abgebucht werden soll, ist die native App raus.
3. Checkout-Darstellung: das Bundle „verschwindet“ in seine Teile
Im Order- und Fulfillment-Kontext werden die einzelnen Artikel geführt, nicht ein Bundle-SKU – Gewichte etwa leiten sich aus den Komponenten ab, nicht aus einem Bundle-Produktgewicht (Shopify Help, Bundles). Für fixe Bundles ist das sauber. Bei BYOB wird die Darstellung zur eigenen Design-Aufgabe: Der Kunde will „mein Bundle“ als eine Position sehen, das Lager will die Einzelteile picken, der Beleg muss beides konsistent zeigen. Dazu kommen harte Plattform-Grenzen: Bundles sind nicht mit Kaufoptionen kombinierbar(Subscriptions, Pre-Order, Try-before-you-buy), funktionieren nur über Online Store / Custom Storefront und können keine anderen Bundles enthalten (Shopify Help, Eligibility).
Ab welcher Komplexität Custom/Drittanbieter unvermeidlich wird
Eine einfache Entscheidungslinie aus der Praxis:
- Native App reicht: feste Sets, Geschenkboxen mit definiertem Inhalt, Multipacks, „2er-/3er-Pack“ derselben Komponente – jede Bestellung sieht gleich aus.
- Custom / Cart Transform nötig: Kunde wählt aus einem Pool, Preis staffelt nach Auswahlmenge, einzelne Komponenten haben eigene Bestands-/Lieferzeitlogik, oder die Auswahl koppelt an Subscriptions. Spätestens hier ist die native App keine Verkürzung mehr, sondern eine Sackgasse.
Der teure Fehler ist, BYOB mit fixen Bundles „nachzubauen“ – z. B. jede mögliche Kombination als eigenes Bundle-Produkt anzulegen. Das explodiert kombinatorisch, killt die Bestandswahrheit und macht jede Preisänderung zur Handarbeit. Die Bundles-&-Selling-Plans-API mit Cart Transform existiert genau, um diesen Pfad zu vermeiden.
Die App-Lücke, die wir sehen
Was im Markt fehlt, ist kein weiterer „Bundle-Builder mit hübschem Frontend“, sondern ein BYOB-Builder mit echter Komponenten-Bestandslogik: freie Auswahl + Staffelpreis + saubere Dekrementierung je Komponente über Cart Transform, dazu eine Checkout- und Belegdarstellung, die das Bundle als eine Position zeigt und im Lager als Einzelteile führt. Genau das ist die Lücke der nativen App – und der Punkt, an dem ein durchdachtes Konzept den Unterschied zwischen „funktioniert in der Demo“ und „funktioniert am Black Friday“ macht.
Nächster Schritt
Du willst echtes Build-Your-Own-Bundle, das im Bestand und im Checkout sauber bleibt – statt eines Bundle-Wildwuchses, der bei der ersten Preisänderung kippt? Bundle-Konzept mit leitwert.digital anfragen. Weiter: Shopify-Technik und Operations; verwandt: ab wann ein PIM auf Shopify sinnvoll ist.