Produktkatalog - Strukturierte Produktdaten in beliebiger Größenordnung

Ein Produktkatalog ist mehr als eine Liste aus Artikelnummer, Titel und Preis. Sobald Produkte unterschiedliche Attribute, Varianten, Sprachen, Lieferanten oder Vertriebskanäle haben, braucht der Katalog ein Datenmodell, das diese Unterschiede sauber abbildet.

Ein PIM übernimmt genau diese Aufgabe: Es trennt Produktstruktur von Ausgabekanälen und schafft eine zentrale, konsistente Datenbasis. PIMSuite setzt dafür auf flexible Attribute, Produktfamilien, Varianten, Beziehungen und Validierung.

Welche Daten gehören in einen Produktkatalog?

Ein vollständiger Produktkatalog umfasst typischerweise:

• SKU / Artikelnummer
• Name / Titel
• Marke
• Beschreibung
• technische Merkmale
• Maße und Einheiten
• Farben / Größen
• Varianten
• Preise
• Medien
• Dokumente
• Kategorien
• Produktbeziehungen
• Lieferanteninformationen
• Übersetzungen
• Status
• kanalabhängige Inhalte

Diese Felder lassen sich grob in vier Gruppen einteilen: Stammdaten (Identifikatoren, Marke, Maße), Marketingdaten (Titel, Beschreibungen, Nutzenargumente), technische Daten (Spannung, Material, Abmessungen) und Beziehungen (Varianten, Zubehör, Ersatzteile, Bundles).

Warum Tabellen bei komplexen Katalogen an Grenzen stoßen

Das Problem ist nicht, dass Tabellen schlecht sind - es ist, dass ihr Datenmodell (eine Zeile, feste Spalten) für einen wachsenden Katalog nicht mitwächst.

Unterschiedliche Produkte brauchen unterschiedliche Felder. Ein T-Shirt braucht Größe, Material, Pflegehinweis. Eine Akkubohrmaschine braucht Spannung, Leistung, Drehmoment. In einer flachen Tabelle entstehen daraus Hunderte Spalten, von denen für jedes einzelne Produkt die meisten leer und irrelevant sind.

Varianten duplizieren Daten. Zehn Farben mal fünf Größen werden schnell zu 50 Zeilen, die dieselbe Beschreibung und Markendaten wiederholen - jede Änderung muss 50-mal nachgezogen werden.

Mehrsprachigkeit vervielfacht Spalten. title_de, title_en, title_fr - und das für jedes übersetzbare Feld einzeln.

Mehrere Kanäle brauchen unterschiedliche Strukturen. Marktplatz, Shop, Print-Katalog und B2B-Feed wollen jeweils andere Felder in anderer Form.

Validierung wird brüchig. Fehlende Einheiten, uneinheitliche Schreibweisen, vertauschte Werte fallen in einer Tabelle erst auf, wenn der Export schon fehlgeschlagen ist.

Produktfamilien

Eine Produktfamilie legt fest, welche Attribute für einen Produkttyp gelten:

Familie: T-Shirt
- Material
- Schnitt
- Geschlecht
- Pflegehinweis
- Farbe
- Größe

Familie: Akku-Bohrschrauber
- Spannung
- Drehmoment
- Akkukapazität
- Bohrfutter
- Gewicht

PIMSuite gruppiert Attribute in Familien, damit unterschiedliche Produktkategorien genau die richtigen Felder erhalten. Redakteure sehen nur relevante Felder, Validierung kann je Familie unterschiedlich streng sein, und Exporte werden vorhersehbarer, weil jede Familie ein festes Schema hat. Attribute sind innerhalb jeder Familie geordnet und gruppiert - das Bearbeitungsformular zeigt immer genau das, was gebraucht wird.

Attribute: den richtigen Datentyp wählen

Attributmodellierung ist mehr als "Feld hinzufügen". Ein häufiger Fehler ist Freitext, wo ein kontrolliertes Feld gehört:

Schlecht: material = "Stahl", "Edelstahl", "rostfrei", "SS" - vier Schreibweisen für denselben Wert.

Besser: ein Select-Feld mit festem Wert material = edelstahl, dazu lokalisierte Labels (DE: "Edelstahl", EN: "Stainless steel"). Filter, Auswertungen und Kanalexporte funktionieren nur zuverlässig, wenn derselbe Wert immer gleich geschrieben ist.

Dasselbe gilt für Zahl vs. Text: 12.5 als Zahl mit separater Einheit ist etwas anderes als der String "12,5 kg". Erst die strukturierte Zahl lässt sich sortieren, filtern, umrechnen und validieren - der String kann das nicht.

PIMSuite unterstützt dafür 12 Attributtypen: Text, Textarea, Rich Text, Zahl, Boolean, Datum, Datum+Uhrzeit, Select, Multiselect, Bild, Datei und Preis. Jedes Attribut wird individuell konfiguriert - als lokalisierbar, erforderlich, filterbar, eindeutig, KI-vervollständigbar oder massenbearbeitbar. Das System passt sich eurem Schema an, nicht umgekehrt.

Taxonomie ist nicht dasselbe wie Produktfamilie

Diese Verwechslung ist verbreitet, und der Unterschied ist wichtig:

Produktfamilie bestimmt, welche Felder ein Produkt hat.

Kategorie/Taxonomie bestimmt, wo ein Produkt einsortiert ist.

Eine Bohrmaschine gehört zur Familie "Elektrowerkzeug", kann aber in der Taxonomie unter "Werkzeuge → Bohrmaschinen → Akku-Bohrmaschinen" stehen. Dieselbe Familienzugehörigkeit sagt nichts über die Navigationsstruktur aus - und dieselbe Kategorie kann Produkte aus mehreren Familien enthalten.

Varianten: wann sind sie sinnvoll?

Die praktisch wichtigste Modellierungsfrage: Wann ist etwas eine Variante, und wann ein eigenständiges Produkt?

Für Varianten spricht: dasselbe Kernprodukt, geteilte Beschreibung, Unterschied nur in Größe/Farbe/ähnlichen Achsen, gemeinsame Merchandising-Identität.

Für ein eigenständiges Produkt spricht: wesentlich unterschiedliche technische Daten, unterschiedliche Funktion, unterschiedliche regulatorische Angaben, eine eigenständige Produktidentität.

PIMSuite behandelt Varianten als erstklassige Datenstruktur: Definiert Achsenkombinationen (Größe × Farbe), legt eine Hauptvariante fest, und gemeinsame Attribute bleiben über die gesamte Gruppe synchron - ändert sich die Beschreibung, zieht sie automatisch bei allen Varianten nach. Variantengruppenregeln beim Import ermöglichen die automatische Zusammenführung eingehender Lieferanten-SKUs in die richtigen Variantengruppen nach Muster, statt sie von Hand zuzuordnen.

Bundles und Kits

Ein Bundle ist eine kaufmännische Zusammenstellung eigenständig verkaufbarer Produkte - zum Beispiel Kamera, Objektiv und Tasche zusammen angeboten. Ein Kit ist eher ein Set, bei dem die Komponenten gemeinsam das Angebot definieren.

Beide werfen dieselben praktischen Fragen auf: Wie wirkt sich eine Bestandsänderung einer Komponente auf das Bundle aus? Ist der Preis fix oder berechnet sich aus den Einzelpreisen? Was passiert, wenn eine Komponente sich ändert?

PIMSuite unterstützt Bundles und Kits mit Stückzahlen pro Position; der Bundle-Preis kann fix festgelegt oder aus den Komponentenpreisen berechnet werden.

Produktbeziehungen sind nicht dasselbe wie Kategorien

Reale Kataloge brauchen neben Varianten und Bundles oft auch Beziehungen wie Zubehör, Ersatzteile, Cross-Sells, Nachfolge- oder Vorgängerprodukte. Das sind keine Varianten - sie teilen keine Attribute und keine Merchandising-Identität, sondern verweisen aufeinander. PIMSuites Datenmodell enthält Produktbeziehungen als eigenes Konzept, getrennt von Varianten- und Kategoriezuordnung.

Geteilte Daten und Vererbung

Ein großer Katalog wird schnell teuer zu pflegen, wenn jedes Feld auf jedem Produkt einzeln gesetzt werden muss. Das klassische PIM-Konzept dafür ist Vererbung über mehrere Ebenen - Marke, Familie, übergeordnetes Produkt, Variante -, bei der ein Wert auf einer höheren Ebene automatisch für alle darunterliegenden gilt, sofern er nicht gezielt überschrieben wird.

PIMSuite deckt einen Teil davon bereits strukturell ab: Das Familienschema legt fest, welche Felder gelten, und innerhalb einer Variantengruppe bleiben geteilte Attribute automatisch synchron. Eine durchgängige Vererbungskette über beliebig viele Ebenen (etwa Marke → Familie → Hauptprodukt → Variante mit gezieltem Override auf jeder Stufe) ist heute keine eigenständige, konfigurierbare Funktion - für Kataloge, die das systematisch brauchen, ist das ein naheliegender Ausbauschritt.

Vollständigkeit ist nicht dasselbe wie Datenqualität

Jedes Produkt erhält in PIMSuite eine Vollständigkeitsbewertung, berechnet pro Sprache. Ihr wisst immer, was fehlt, bevor ihr veröffentlicht, und könnt den gesamten Katalog nach Vollständigkeitsbereich filtern, um Lücken systematisch zu schließen.

Wichtig ist dabei eine Unterscheidung: 100 % Vollständigkeit bedeutet nicht automatisch gute Daten. Ein Produkt mit Titel "Produkt 123" und Beschreibung "Gutes Produkt" ist technisch vollständig - alle Pflichtfelder sind gefüllt - aber kommerziell nutzlos. Vier Ebenen lohnt es sich auseinanderzuhalten:

• Vollständigkeit - sind die erforderlichen Felder gefüllt?
• Gültigkeit - sind die Werte strukturell korrekt (richtiger Typ, richtiges Format)?
• Qualität - sind die Inhalte tatsächlich nützlich und zutreffend?
• Kanalfähigkeit - erfüllt der Datensatz die Anforderungen des jeweiligen Zielkanals?

PIMSuites Vollständigkeitsbewertung deckt die erste Ebene ab. Für weitergehende inhaltliche Qualitätsprüfungen gibt es die Datenqualitäts-Tools.

Lieferantenkataloge und Normalisierung

Der interne, kanonische Katalog ist nicht dasselbe wie die Kataloge eurer Lieferanten. Lieferant A nennt ein Feld vielleicht Item No: 00124, Lieferant B SKU: X992, während intern eine eigene Produkt-ID gilt. Diese Zuordnung - eingehende Lieferantenfelder auf euer eigenes Attributschema abbilden - übernimmt PIMSuites automatisierter Lieferantenimport, inklusive der oben beschriebenen Variantengruppenregeln für Muster in Lieferanten-SKUs.

Ein Produkt, mehrere Kanäle

Kanonischer Produktdatensatz
        ↓
Shop
Marktplatz
B2B-Portal
Print-Katalog
Marktplatz-Feed

Jeder Kanal kann eine andere Titellänge, eine andere Kategorietaxonomie, andere Pflichtattribute, andere Medien oder eine andere Sprache verlangen. Genau dafür existiert ein PIM: um zu vermeiden, dass fünf unabhängige Kopien desselben Produkts gepflegt werden müssen. PIMSuites Multi-Channel-Publishing bildet diese Zuordnung vom kanonischen Datensatz auf die jeweiligen Kanalfelder ab.

Versionshistorie und Audit-Log

Die eigentliche Frage, die eine Versionshistorie beantworten muss, ist selten abstrakt: Wer hat die Spannung von 18V auf 20V geändert? Wann? War es ein manueller Edit oder ein Import? Was war der vorherige Wert?

PIMSuite protokolliert jede Änderung an jedem Produkt mit Benutzer, Zeitstempel und feldgenauen Alt- und Neuwerten. Nichts geht je verloren - außer ihr entscheidet bewusst, dass es sein soll.

Massenoperationen

Massenbearbeitung wird erst dann wirklich nützlich, wenn ein konkreter Fall dahintersteht: eine Marke über 8.000 SKUs umbenennen, eine Kategorie verschieben, "Made in PRC" auf eine einheitliche Ursprungslandbezeichnung vereinheitlichen, eingestellte Produkte archivieren, ein neues Feld für eine ganze Familie befüllen.

PIMSuite aktualisiert Status, Marke, Ursprungsland, Taxonomie oder ein beliebiges benutzerdefiniertes Attribut über Tausende Produkte in einem einzigen Vorgang. Massentext-Suchen und -Ersetzen mit Regex-Unterstützung ermöglicht katalogweite Umbenennungen ohne Einzelbearbeitungen.

Draft / Aktiv / Archiviert

Produkte durchlaufen drei Status: Entwurf für laufende Arbeiten, Aktiv für veröffentlichte Produkte und Archiviert für eingestellte. Archivierte Produkte können wiederhergestellt werden; weich gelöschte Produkte bleiben wiederherstellbar, bis sie explizit endgültig gelöscht werden.

Wie ein guter Produktkatalog aufgebaut sein sollte

Ein paar Grundsätze, unabhängig davon, welches System ihr einsetzt:

• Bei Produkten anfangen, nicht bei Kanälen. Übernehmt nicht einfach das Schema eures Shopsystems als Datenmodell.
• Wiederkehrende Werte normalisieren. Marken, Materialien, Kategorien gehören in kontrollierte Felder, nicht in Freitext.
• Strukturierte Werte bevorzugen. gewicht = 12.5 mit Einheit kg statt dem String "12,5kg".
• Produkt- und Variantendaten trennen. Geteilte Attribute nicht auf jeder Variante duplizieren.
• Beziehungen explizit modellieren. Zubehör ist keine Variante.
• Herkunft nachvollziehbar halten. Wissen, aus welcher Lieferantenquelle ein Wert stammt.
• Vor dem Export validieren. Der Kanal sollte nicht die einzige Qualitätskontrolle sein.

Wie PIMSuite einen Produktkatalog abbildet

PIMSuite kombiniert alle oben beschriebenen Bausteine zu einem strukturierten Katalog, der mit eurem Unternehmen wächst: 12 Attributtypen mit individueller Konfiguration, Produktfamilien mit geordneten Feldgruppen, erstklassige Varianten mit automatischer Attributsynchronisation, Bundles mit fixer oder berechneter Preisbildung, Vollständigkeitsbewertung pro Sprache, ein Draft/Aktiv/Archiviert-Workflow mit wiederherstellbarem Soft-Delete, lückenlose Versionshistorie mit Benutzer und Zeitstempel, und Massenoperationen über Tausende Produkte in einem Vorgang.