Ops / Inventory
Wenn Shopify-Bordmittel nicht mehr reichen — ab wann ein PIM Pflicht wird
Die direkte Antwort: Ein PIM wird nicht ab einer bestimmten Anzahl Produkte „sinnvoll" — sondern in dem Moment, in dem dieselbe Produktinformation an mehreren Stellen gepflegt werden muss und niemand mehr garantieren kann, dass sie überall gleich ist. Shopify-Admin plus Metafields tragen einen einsprachigen, einkanaligen Katalog erstaunlich weit. Sie brechen vorhersehbar, sobald die Produktpflege zwei Dimensionen gleichzeitig multipliziert: Varianten × Sprachen × Kanäle × Bundles. Dieser Artikel liefert die Schwellen-Logik als Diagnose — keine erfundene SKU-Zahl, ab der „es so weit ist".
Warum „Anzahl Produkte" die falsche Frage ist
Die meisten PIM-Diskussionen starten mit „Wir haben jetzt X-tausend SKUs". Das ist die falsche Achse. Ein Shop mit 50.000 simplen, einsprachigen Produkten ist im Shopify-Admin gut beherrschbar — solange jede Information genau einmal existiert und genau einen Ort hat. Schmerzhaft wird nicht das Volumen, sondern die Redundanz: dieselbe Materialangabe, die in der Produktbeschreibung, im Pflege-Metafeld, in der Bundle-Komponente und in der englischen Übersetzung getrennt gepflegt wird. Jede dieser Kopien ist eine Gelegenheit für Drift. Ein PIM ist im Kern keine Datenbank für mehr Produkte, sondern eine Single Source of Truth, die Redundanz auflöst.
Die echten Grenzen der Bordmittel (belegbar)
Bevor wir zur Heuristik kommen: Shopify hat harte, dokumentierte Grenzen. Die meisten Shops erreichen sie nie — aber wer komplexe Produktdaten über Metafields modelliert, läuft schneller hinein, als gedacht. Merchants können pro Ressourcentyp bis zu 256 Metafeld-Definitionenanlegen; pro Ressourcentyp sind 50 Definitionen pinnbar, der Rest verschwindet im Drawer. Die meisten Metafeld-Typen haben ein Größenlimit von 64 KB; Listen fassen 128 Einträge (Metaobjekt-Referenzen 256), und vordefinierte Auswahllisten sind auf 128 Werte begrenzt. [Quelle: shopify.dev/docs/apps/build/metafields/metafield-limits]
Diese Zahlen sind selten das Problem. Das Problem ist, was vor der Grenze passiert: Wer Attribute, Pflegehinweise, technische Datenblätter, Größentabellen und Kanal-Texte alle als Metafelder modelliert, baut faktisch ein PIM nach — nur ohne Validierung, ohne Vererbung, ohne Workflow und ohne Übersetzungs-Synchronisation. Metaobjects mildern das, ersetzen aber kein Pflege- und Governance-Modell.
Die Heuristik: vier Multiplikatoren, nicht eine Zahl
Die belastbare Schwelle ist kein Schwellenwert, sondern ein Produkt. Multipliziere die folgenden vier Achsen für ein durchschnittliches Produkt. Je höher das Produkt, desto mehr Stellen müssen bei einer einzigen inhaltlichen Änderung konsistent nachgezogen werden:
| Achse | Bordmittel tragen, solange… | PIM-Signal, sobald… |
|---|---|---|
| Varianten / Attribute | Varianten sich auf Größe/Farbe beschränken; Attribute in wenige Metafelder passen | strukturierte Attribute (Material, Pflege, Maße, Zertifikate) je Produkttyp variieren und versioniert werden müssen |
| Sprachen / Locales | ein bis zwei Sprachen, übersichtlich über Translate & Adapt pflegbar | mehrere Sub-Locales (en-GB/en-US, nl-NL/nl-BE) auseinanderdriften und niemand Konsistenz pro Markt prüft |
| Vertriebskanäle | nur die Shopify-Storefront bedient wird | Marktplätze, Feeds (Merchant Center, Meta), Print/B2B mit je eigenen Feldanforderungen dazukommen |
| Bundle-Komplexität | Bundles statisch sind und Komponentendaten selten ändern | Build-your-own/dynamische Bundles dieselbe Komponente in viele Bundles vererben und Änderungen überall greifen müssen |
Faustregel statt Zahl: Sobald zwei dieser Achsen gleichzeitig „hoch" stehen, gewinnt ein PIM die Bordmittel. Eine Achse allein ist fast immer im Admin beherrschbar — viele SKUs, aber einsprachig und einkanalig: kein PIM. Wenige hundert SKUs, aber in vier Locales, auf drei Kanälen, mit dynamischen Bundles: PIM. Die Mathematik ist multiplikativ, nicht additiv — deshalb täuscht die reine SKU-Zahl.
Locales und Bundles als die unterschätzten Treiber
Zwei Achsen kippen das Bild häufiger als alle anderen. Sprachen, weil jede Übersetzung die Pflegelast nicht addiert, sondern multipliziert: Eine Materialkorrektur muss in jeder Locale konsistent ankommen — und genau hier driften saubere Sub-Locales auseinander, wie wir es für hreflang je Sub-Locale beschrieben haben. Bundles, weil dynamische Bundles eine Komponente in N Verkaufseinheiten referenzieren: Ändert sich die Komponente, müssen N Stellen folgen. Ohne Vererbung wird das zur manuellen Fleißaufgabe mit garantierter Fehlerquote.
Was ein PIM löst — und was nicht
- Single Source of Truth: Produktinformation existiert einmal, fließt in alle Locales, Kanäle und Bundles.
- Vererbung & Strukturierung: Attribute je Produkttyp, Validierung, Pflichtfelder — statt freier Metafeld-Wildwuchs.
- Workflow & Freigabe: wer pflegt, wer gibt frei, was ist „channel-ready" — bevor es in den Feed geht.
- Übersetzungs-Orchestrierung: Quelltext-Änderung markiert abhängige Locales als „stale", statt sie still veralten zu lassen.
Was ein PIM nicht löst: ein unsauberes Datenmodell. Wer Attribute heute inkonsistent pflegt, exportiert die Inkonsistenz nur in ein teureres System. Die ehrliche Reihenfolge ist Datenmodell zuerst, Werkzeug danach — sonst kauft man Migrationskosten ohne Nutzen.
Der Anti-Pattern: das „PIM aus Metafeldern"
Der häufigste Zwischenschritt ist kein bewusster — er passiert schleichend: Immer mehr Metafelder, immer mehr Metaobjects, ein paar Liquid-Schleifen, ein selbstgebautes Google Sheet als „Stammdaten", aus dem per CSV importiert wird. Das funktioniert, bis es bricht — und es bricht leise, in Form falscher Preise im Feed, veralteter EN-Beschreibungen oder eines Bundles, dessen Komponente vor drei Wochen umbenannt wurde. Wenn dein Team mehr Zeit mit der Synchronisation von Produktdaten verbringt als mit ihrer Pflege, hast du das PIM bereits gebaut — nur das schlechtere.
PIM-Readiness in fünf Fragen
- Existiert eine Produktinformation an mehr als einer Stelle, die jemand manuell synchron halten muss?
- Bedienst du mehr als einen Locale und mehr als einen Kanal mit je eigenen Feldanforderungen?
- Vererben dynamische Bundles Komponentendaten, die sich ändern?
- Kann jemand verlässlich sagen, dass die EN-Texte heute mit den DE-Texten übereinstimmen?
- Wächst die Pflege-Zeit schneller als der Katalog?
Drei oder mehr „Ja" sind das Signal — unabhängig von der SKU-Zahl. Ob ein PIM, ein härteres Metaobject-Modell oder schlicht ein sauberer Pflegeprozess die richtige Antwort ist, hängt davon ab, welche Achsen bei dir hoch stehen.
Unsicher, auf welcher Seite der Schwelle du stehst? Mach den PIM-Readiness-Check mit leitwert.digital — wir bewerten deine vier Achsen und sagen klar, ob Bordmittel reichen oder kippen. Weiter: operative Produktpflege und Shopify-Technik.