Entwerfen Sie einen Produktkatalog mit Varianten und Bundles unter Verwendung klarer SKU‑Regeln, Inventarlogik und UI‑Muster, die schlechte Kombinationen und Overselling verhindern.
Ein Katalog wirkt einfach, wenn jedes Produkt ein einzelnes Element mit einem Preis und einer Lagerzahl ist. Fügst du Farbe, Größe, Laufzeit eines Abos oder regionalspezifische Verpackung hinzu, bricht diese Einfachheit zusammen. Eine einzelne „Products“-Tabelle kann grundlegende Fragen nicht mehr beantworten: Welches genaue Produkt verkaufen wir und wie verfolgen wir es?
Kundinnen und Kunden erwarten außerdem korrekte Details. Sie wollen Optionen wählen, sofort den richtigen Preis sehen und wissen, ob ihre genaue Auswahl heute versandbereit ist. Wenn die Seite „Auf Lager" anzeigt, die ausgewählte Größe aber fehlt, schwindet das Vertrauen schnell. Ändert sich der Preis erst beim Checkout, entstehen Support‑Tickets und Rückgaben.
Bundles fügen eine zweite Komplexitätsebene hinzu, weil sie wie Produkte aussehen, aber sich wie Regeln verhalten. Ein „Starter Kit“ kann eine Flasche, eine Pumpe und ein Set Filter enthalten. Die Verfügbarkeit hängt von den Teilen ab, und deine Kosten‑ sowie Reporting‑Logik muss trotzdem Sinn ergeben.
Anzeichen dafür, dass dein Katalog anfängt zu bröckeln:
Die Lösung ist größtenteils Disziplin: ein Datenmodell, das konsistent bleibt, und UI‑Muster, die Optionsauswahl und Verfügbarkeit für Kundschaft und Team klar machen.
Wenn Leute „Varianten" sagen, vermischen sie oft verschiedene Ideen. Begriffe früh zu klären macht spätere Entscheidungen (Schema, UI, Inventar) wesentlich einfacher.
Die meisten Teams nutzen diese Definitionen:
IDs werden in der Praxis ebenfalls oft verwechselt. Eine interne ID nutzt die Datenbank. Eine SKU ist dein operativer Code (für Kommissionierung, Nachbestellung, Reports). Ein Barcode (UPC/EAN) wird von Scannern gelesen. Eine SKU kann mehrere Barcodes haben (verschiedene Regionen), und manche Artikel haben gar keinen Barcode.
Eine gute Faustregel, ob etwas eine verkaufbare Variante sein sollte: Wenn es einen anderen Preis, ein eigenes Inventar, Gewicht oder Versandregeln haben kann, behandle es als verkaufbar. Dasselbe T‑Shirt in Größe M und Größe XL braucht meist separate Bestände und sollte daher eigene SKUs haben.
Bevor du ein Schema wählst, starte mit den Fragen, die das Geschäft täglich beantworten muss. Wenn jemand einen Artikel anschaut, kannst du sicher sagen: ist er jetzt verfügbar, was kostet er, wie wird er versendet und welche Steuerregeln gelten?
Hilfreich ist, zu entscheiden, wo jede „Tatsache" sitzt. Lege gemeinsame Eigenschaften auf dem Produkt ab und veränderliche Eigenschaften auf der Variante (SKU). Wenn du sie mischst, reparierst du denselben Fehler an zwei Stellen.
Fragen, die meist entscheiden, ob ein Feld auf Produkt‑ oder Varianten‑Ebene gehört:
Behalte eine einzige Quelle der Wahrheit. Zum Beispiel: Speichere „Preis" nicht sowohl auf Produkt als auch auf Variante, außer die Rollen sind klar (Produkt = UVP, Variante = tatsächlicher Verkaufspreis).
Plane für Änderungen. Du kannst später eine neue Option hinzufügen (z. B. „Length"), Varianten ausphasen oder SKUs nach Lieferantenwechsel zusammenführen. Das geht reibungsloser, wenn Varianten echte Datensätze sind und nicht nur Labels.
Wenn du in AppMaster baust, hilft klare Entitätsbenennung im Data Designer, das bei sich ändernden Anforderungen wartbar zu halten.
Ein klares Schema hält den Katalog verständlich, wenn aus einem einfachen Produkt Dutzende verkaufbare Kombinationen werden. Ziel ist, Auswahlmöglichkeiten (was Kundschaft auswählt) getrennt von verkaufbaren Einheiten (was du tatsächlich lagerst und verschickst) zu modellieren.
Eine verlässliche Menge von Entitäten:
Die Einzigartigkeit von Varianten ist ein häufiger Fehlerpunkt. Der sicherste Ansatz ist normalisiert: erlaube pro Variante genau einen OptionValue pro Option und verhindere doppelte Kombinationen. Für Performance kannst du einen berechneten „variant key" wie color=red|size=m (oder einen Hash davon) auf Variant speichern und als einzigartig pro Product erzwingen.
Felder, die sich pro Kombination ändern, gehören auf die Variant‑Ebene, nicht zum Product: SKU, Barcode, Preis, Vergleichspreis, Kosten, Gewicht, Abmessungen, Status (aktiv/ausgelaufen) und Bilder (entweder ein Hauptbild oder ein kleines Set).
Für benutzerdefinierte Attribute (z. B. „Material“ oder „Pflegehinweise") vermeide endlose neue Spalten. Ein JSONB‑Feld auf Product oder Variant funktioniert gut in PostgreSQL, zusammen mit einer kleinen Validierungsschicht in deiner App.
Eine SKU ist ein Identifier für eine verkaufbare Einheit, den du stabil halten solltest. Sie sollte eine Frage beantworten: „Welches genaue Item haben wir verkauft?" Sie sollte nicht versuchen, den Marketingnamen, vollständige Optionstexte, Saison oder eine ganze Geschichte zu transportieren. Wenn du sie überlädst, wird später jede Änderung ohne Brüche schwer.
Entscheide früh, ob SKUs manuell vergeben oder generiert werden. Manuelle SKUs sind sinnvoll, wenn ein ERP, Barcodes oder Lieferanten‑SKUs übereinstimmen müssen. Generierte SKUs sind praktisch bei vielen Varianten, aber nur, wenn die Regeln nicht mitten im Jahr wechseln. Ein guter Mittelweg ist ein festes Basis‑SKU, das du kontrollierst, plus ein kurzes generiertes Suffix für Variantenattribute.
Regeln, die lesbar bleiben und Wachstum überstehen:
Ausgemusterte SKUs nicht löschen. Inaktiv markieren, Preis‑Historie behalten und in alten Bestellungen, Rückerstattungen und Reports auswählbar halten. Wenn du eine SKU ersetzt, speichere eine „replaced by“-Referenz, damit Support nachvollziehen kann, was passiert ist.
Validierungsregeln verhindern langsame Schäden: SKU‑Einzigartigkeit über alle verkaufbaren Items erzwingen, nur Buchstaben, Zahlen und Bindestriche erlauben, klare Maxlänge setzen (oft 20–32 Zeichen) und Präfixe für Sonderfälle reservieren (z. B. „BND-" für Bundles). In AppMaster passen diese Checks gut als Datenbank‑Constraints plus ein Business Process, der Speichern blockiert, wenn eine Regel verletzt wird.
Inventar wird kompliziert, wenn dasselbe „Produkt" viele verschiedene verkaufbare Einheiten bedeuten kann. Bevor du Regeln schreibst, entscheide die Inventareinheit: verfolgst du Bestand auf Produkt‑ oder Varianten‑Ebene oder beides?
Wenn Kundschaft Größe oder Farbe wählt, ist Varianten‑Level meist am sichersten. Ein Shirt kann „insgesamt auf Lager" sein, aber die Variante Small‑Blue ausverkauft. Produkt‑Level reicht für Artikel, bei denen Varianten das physische Lager nicht ändern (z. B. digitale Lizenzen mit verschiedenen Abrechnungsplänen). Manche Teams halten beides: Produkt‑Level fürs Reporting, Varianten‑Level fürs Verkaufen.
Overselling‑Vermeidung ist weniger eine einzelne Flagge als klare Zustände. Die meisten Kataloge brauchen Reservations (Einheiten kurz für Warenkörbe oder unbezahlte Bestellungen reservieren), Backorders (Verkauf mit klarem Versanddatum erlauben), Stock‑Puffer (versteckte Menge gegen Sync‑Verzögerungen) und atomare Updates (Bestand im selben Schritt reduzieren, in dem die Bestellung bestätigt wird).
Edge‑Fälle erzeugen „mystery stock". Rücksendungen sollten Bestand erst nach Prüfung wieder hinzufügen, nicht beim Erstellen des Rücksendeetiketts. Beschädigte Artikel sollten in einen separaten Status oder Ort verschoben werden, damit sie nicht als verkaufbar erscheinen. Bestandsanpassungen brauchen ein Audit‑Trail (wer hat was warum geändert), besonders wenn mehrere Kanäle Inventory updaten.
Bundles und Kits fügen eine wichtige Regel hinzu: reduziere nicht einen „Bundle“-Datensatz, wenn das Bundle nur eine Gruppierung ist. Reduziere die Komponentenartikel. Ein 3‑Pack sollte drei Einheiten derselben SKU reduzieren; ein Kit reduziert je eine Einheit jeder Komponente.
Beispiel: Ein „Starter Kit" enthält 1 Flasche und 2 Filter. Hast du 10 Flaschen und 15 Filter, ist die Kit‑Verfügbarkeit 7, weil die Filter limitieren. Komponentenbasierte Mathematik hält Reporting, Rückerstattungen und Bestandsführung konsistent.
In AppMaster lässt sich das sauber auf Variant‑Tabellen im Data Designer und Reservierungs/Decrement‑Logik im Business Process Editor abbilden, sodass jeder Checkout denselben Regeln folgt.
Bundles sind oft die Stellen, an denen Kataloge zu Sonderfällen verfallen. Der einfachste Ansatz ist, Bundles als normale verkaufbare Items zu modellieren und eine klare Liste von Komponenten anzuhängen.
Eine saubere Struktur ist: Product (verkaufbares Item) plus BundleLines. Jede BundleLine verweist auf eine komponenten‑SKU (oder ein Komponenten‑Produkt plus eine erforderliche Variante) und speichert eine Menge. Bestellungen zeigen weiterhin „ein Item“, lassen sich aber bei Bedarf in Teile aufklappen für Kosten, Inventar und Erfüllungsdetails.
Die meisten Bundle‑Setups fallen in eine dieser Kategorien:
Beim Pricing passieren meist Fehler im Reporting. Entscheide im Voraus, was in der Bestellzeile erscheint und was Meldungen für Marge/Inventar antreibt. Gängige Ansätze: fixer Bundle‑Preis, Summe der Teile oder ein rabattierter Summenpreis mit Regeln pro Komponente (z. B. „Wähle 3 Artikel, der günstigste ist 50% reduziert").
Inventar muss ebenso strikt sein: Ein Kit ist nur verfügbar, wenn jede erforderliche Komponente in der nötigen Menge vorhanden ist. Für Reporting speichere zwei Ansichten des Verkaufs:
In AppMaster passt das natürlich: eine Bundle‑Tabelle plus BundleLine‑Zeilen, mit Business Processes, die Komponenten beim Checkout expandieren und sowohl den Bundle‑Verkauf als auch den Komponenten‑Verbrauch in einer Transaktion schreiben.
Gute Options‑UI hält Kundinnen und Kunden in Bewegung. Schlechte UI lässt sie raten, Fehler treffen und abspringen. Wichtig ist, die Nutzerinnen zu einer echten, kaufbaren Variante früh zu führen und klar zu zeigen, was sich mit ihrer Wahl ändert.
Ein verlässliches Muster ist, Optionen (Size, Color, Material) zu zeigen und nur die Kombinationen anzuzeigen, die noch Sinn ergeben.
Statt Kundschaft eine beliebige Kombination wählen zu lassen und beim „In den Warenkorb" zu scheitern, deaktiviere unmögliche Kombinationen sofort, sobald eine Auswahl getroffen wurde. Wenn jemand Color = Black wählt, sollten Größen, die in Schwarz nicht existieren, deaktiviert (nicht entfernt) werden, damit klar ist, was nicht verfügbar ist.
Bei jeder Änderung aktualisiere die Teile, die am wichtigsten sind: Preis (inkl. Sale‑Preis und Bundle‑Rabatt), Hauptbilder (passend zur Farbe/Optik), Lagerstatus (exakter Variantenbestand, nicht generischer Produktbestand), Lieferzeit (wenn sie pro Variante variiert) und optional die SKU oder „Artikelcode" für Support.
Halte die Oberfläche ruhig. Zeige nur wenige Optionsgruppen gleichzeitig, vermeide riesige Dropdowns, wenn Swatches oder Buttons besser funktionieren, und mache die aktuelle Auswahl deutlich.
Im Admin brauchen Leute Geschwindigkeit, nicht hübsche Karten. Ein Varianten‑Grid funktioniert gut: jede Zeile ist eine SKU, jede Spalte eine Option oder Regel (Preis, Barcode, Gewicht, Bestand, aktiv/inaktiv). Ergänze Massenaktionen für gängige Aufgaben wie Preisupdates, Verfügbarkeitsumschaltung oder Bildzuweisung.
Wenn du das in AppMaster baust, ist ein praktischer Aufbau ein Grid, das an deine Variant‑Tabelle gebunden ist, mit Filtern (OptionValue, aktiver Status, niedriger Bestand) und einer Bulk‑Update‑Aktion, die Regeln vor dem Speichern validiert.
Ein Auswahlfluss soll einfach wirken, braucht aber strikte Regeln im Hintergrund. Ziel ist, immer zu wissen, welche genaue SKU die Käuferin konfiguriert und ob sie jetzt gekauft werden kann.
Lade mehr als Produktname und Bilder. Du brauchst die vollständigen OptionValues (Size, Color) und die Liste gültiger Variantenkombinationen, die als SKUs existieren.
Ein verlässlicher Ablauf:
Ein kleines UI‑Detail, das Frust verhindert: Deaktiviere unmögliche OptionValues sofort, sobald frühere Entscheidungen getroffen wurden. Wenn Size=M nur in Schwarz existiert, zeige andere Farben als nicht verfügbar, sobald M gewählt ist.
Bei Bundles ist „auf Lager" keine einzelne Zahl. Sie hängt von Komponenten ab. Übliche Regel ist:
bundle_available = minimum über Komponenten von floor(component_stock / component_qty_per_bundle)
Beispiel: Ein „Starter Kit" braucht 1 Flasche und 2 Filter. Hast du 10 Flaschen und 9 Filter, ist die Verfügbarkeit min(floor(10/1)=10, floor(9/2)=4) = 4 Kits.
Fehlermeldungen sollten konkret sein. Bevorzuge „Nur 4 Kits verfügbar (Filter limitieren dieses Bundle)" statt „Ausverkauft". In AppMaster lässt sich diese Prüfung leicht in einem Business Process ausdrücken: zuerst die passende Variante ermitteln, dann Bundle‑Limits berechnen und einen klaren Status für die UI zurückgeben.
Kataloge brechen, wenn du für „alles, was existieren könnte" modellierst statt für „was du tatsächlich verkaufen wirst". Der schnellste Weg, sich einzumauern, ist, alle möglichen Optionskombinationen vorab zu generieren und dann versuchen, die Ordnung zu halten.
Varianten zu erstellen, die niemals gelagert werden, ist der klassische Fehler. Bei 4 Farben × 6 Größen × 3 Materialien sind das 72 Varianten. Wenn nur 10 wirklich verkauft werden, erzeugen die anderen 62 Datensätze Unordnung, laden zu Fehlern ein und verlangsamen Reports.
Preise sind eine stille Fehlerquelle. Probleme entstehen, wenn derselbe Preis an mehreren Stellen liegt (Produkt, Variante, Preistabelle, Promo‑Tabelle) ohne eine Quelle der Wahrheit. Eine einfache Regel hilft: Basispreis einmal speichern und Überschreibungen nur dort speichern, wo sie wirklich nötig sind (z. B. eine einzelne Variante hat einen anderen Preis).
Bundles und Kits scheitern bei Inventar, wenn sowohl das Bundle als auch seine Komponenten dekrementiert werden. Verkauft man ein „Starter Kit" mit 1 Flasche und 2 Filtern, reduziert das Entfernen von 1 Kit und zusätzlich 1 Flasche und 2 Filter den Bestand zu stark. Behandle das Bundle als verkaufbares Item, berechne Verfügbarkeit und Abzüge aber aus den Komponenten.
Admin‑Tools können Schaden anrichten, wenn sie ungültige Daten zulassen. Baue Guardrails früh ein:
Plane schließlich für Änderungen. Eine neue Option später (z. B. „Width" bei Schuhen) ist eine Migration, kein Häkchen. Entscheide, was mit bestehenden Varianten passiert, wie Defaults gesetzt werden und wie alte Bestellungen ihr ursprüngliches SKU‑ und Options‑Snapshot behalten.
Vor dem Start mach einen Durchgang bei den Dingen, die in der Praxis brechen: SKUs finden, Bestand updaten und unmögliche Käufe blockieren.
Stelle sicher, dass jedes verkaufbare SKU leicht auffindbar ist. Suche sollte es nach Name, SKU‑Code, Barcode/GTIN und Schlüsselattributen (z. B. Größe oder Farbe) finden. Wenn du Scanning im Lager nutzt, teste ein paar physische Scans und bestätige, dass sie auf die exakte SKU und nicht nur auf das Elternprodukt zeigen.
Sei strikt darin, wo Bestandsänderungen stattfinden. Wähle eine Quelle der Wahrheit (deine Inventarbewegungs‑Logik) und sorge dafür, dass jedes Ereignis sie verwendet: Bestellungen, Stornierungen, Rückerstattungen, manuelle Anpassungen und Bundle‑Montage. Wenn Bestand in zwei Screens oder Workflows editiert werden kann, ist Drift vorprogrammiert.
Launch‑Checks, die sich lohnen:
Wenn du in AppMaster baust, halte Stock‑Update‑Regeln in einem Business Process und rufe diesen von allen Pfaden aus auf. Diese einzige Gewohnheit verhindert die meisten Inventarbugs.
Stell dir einen Apparel‑Shop vor, der noch einen ernsthaften Katalog braucht.
Du verkaufst ein T‑Shirt mit zwei Optionen: Size (S, M, L) und Color (Black, White). Jede kaufbare Kombination ist eine eigene Variante mit eigener SKU, eigenem Preis (falls nötig) und eigenem Inventar.
Im Schema behalte einen Product‑Datensatz für „Classic T‑shirt", zwei Option‑Datensätze (Size, Color) und mehrere Variant‑Datensätze. Jede Variant speichert ihre ausgewählten OptionValues (z. B. Size=M, Color=Black) und die SKU (z. B. TSH-CL-M-BLK). Inventar wird auf Variant‑Ebene getrackt, nicht auf Product‑Ebene.
In der UI schränke die Auswahl ein und vermeide Sackgassen. Ein sauberes Muster ist: Zeige zuerst alle Colors, dann nur noch die Sizes, die für die gewählte Color existieren (oder umgekehrt). Wenn „White + L" nicht existiert, darf es nicht auswählbar sein oder wird deaktiviert mit einem klaren Hinweis.
Füge jetzt ein Bundle hinzu: „Gift Set", das enthält:
Die Bundle‑Verfügbarkeit wird vom knappsten Bauteil begrenzt. Wenn Sticker Pack Bestand 5 ist, kannst du nicht mehr als 5 Bundles verkaufen, selbst wenn bei T‑Shirts viel Bestand vorhanden ist. Wenn das Bundle eine spezifische T‑Shirt‑Variante verlangt (z. B. Black M), ist die Bundle‑Verfügbarkeit min(StickerPackStock, BlackMStock).
Praktische nächste Schritte in AppMaster:
Wenn du schnell ein Ende‑zu‑Ende‑Prototyp brauchst: AppMaster (appmaster.io) ist dafür ausgelegt, komplette Apps mit echter Business‑Logik zu bauen — genau das, wovon Varianten‑Auswahl und Bundle‑Inventarregeln abhängen.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
