Produktdatenmodell für E-Commerce: So baust du die Basis für dein PIM

Viele Händler starten mit einer Excel-Tabelle. 40 Spalten, auf jedes Produkt angewendet, vom Fahrradsattel bis zur Mountainbike-Gabel. Die Hälfte der Felder bleibt für die meisten Produkte leer. Trotzdem wächst die Liste weiter: neue Kanäle, neue Anforderungen, neue Spalten. Irgendwann pflegt niemand mehr, was die Felder bedeuten, und alle arbeiten trotzdem damit. So ist aus einer Excel-Tabelle ein Produktdatenmodell geworden, das niemand so geplant hatte. Soll dann ein PIM-System eingeführt werden, braucht es einen Rahmen, der die Organisation, die Verknüpfung, die Struktur von Produktinformationen definiert.

In diesem Beitrag erfährst du, was ein Produktdatenmodell ist, aus welchen Bausteinen es besteht, was die Konsequenzen eines schlecht aufgebauten Modells sind und wie du es von Grund auf richtig aufbaust.

Was ist ein Produktdatenmodell?

Unter Produktdatenmodell versteht man nicht die Produktdaten selbst. Es strukturiert Produktdaten und ist das Schema, das die Daten enthält: Welche Entitäten existieren (Produkte, Varianten, Kategorien, Assets), wie sie zueinander in Beziehung stehen, in welchen Hierarchien, welche Attribute sie beschreiben und welche Regeln gelten, bevor ein Datensatz als vollständig gilt.

Der Begriff Produktdatenstruktur meint oft nur einen Teil davon: den hierarchischen Aufbau von Kategorien und Varianten. Das Produktdatenmodell ist der Gesamtrahmen, mit Attributlogik, Vererbungsregeln, Relationstypen und Vollständigkeitskriterien.

Eine Analogie: Stell dir vor, du baust ein Lager. Das Produktdatenmodell ist der Regalplan, bevor du auch nur eine Kiste einräumst. Wer den Plan nicht beachtet, baut nach Augenmaß und sortiert später alles um. Es ist sozusagen der Bauplan dafür, welche Daten ein Produkt haben kann oder muss, um spätere manuelle Bereinigungen zu vermeiden. 

Die Bausteine eines Produktdatenmodells im E-Commerce

1. Artikelstruktur: Welche Art von Artikeln du verkaufst

Bevor du eine einzige Produkteigenschaft anlegst, brauchst du Klarheit darüber, welche Arten von Produkten du überhaupt verwaltest. Die drei häufigsten Typen im E-Commerce:

• Einfaches Produkt: Eine SKU, keine Varianten. Zum Beispiel ein Werkzeug in einer einzigen Ausführung.
• Varianten-Produkt: Ein Elternprodukt mit mehreren Ausprägungen, etwa ein T-Shirt in Größen S bis XL und drei Farben.
• Bundle: Mehrere Produkte, die als Einheit verkauft werden, mit einer eigenen SKU für das Gesamtpaket.

Der Produktstrukturtyp entscheidet, wie das Datenmodell aufgebaut wird. Ein Modell, das nur einfache Produkte kennt, bricht zusammen, sobald du Varianten einführst.

2. Attribute und Property Sets: Was ein Produkt beschreibt

Attribute sind die Eigenschaften, die ein Produkt beschreiben, von EAN und Gewicht bis zur technischen Spezifikation. Im Datenmodell sind sie keine starren Felder, sondern konfigurierbare Objekte mit einem Datentyp (Text, Zahl, Boolean, Auswahlliste, Bild), Validierungsregeln und der Festlegung, ob ein Wert Pflicht ist oder optional.

Attribute lassen sich in Gruppen organisieren. So entsteht Übersicht und die Grundlage dafür, dass verschiedene Teams in derselben Struktur arbeiten:

Ein Aspekt, der bei der Attributdefinition oft zu spät mitgedacht wird: Mehrsprachigkeit. Wer in mehreren Märkten oder Sprachen verkauft, braucht ein Datenmodell, das Sprachvarianten als native Eigenschaft der Produktdaten vorsieht, nicht als nachträglichen Export. Produktbeschreibungen, Bezeichnungen und marketingrelevante Felder müssen pro Sprache gepflegt werden können, während technische Daten und Logistikwerte sprachunabhängig bleiben. Welche Felder übersetzbar sind und welche nicht, ist eine Modellentscheidung, die früh getroffen werden sollte.

Das eigentliche Problem entsteht, wenn diese Gruppen nicht nach Produkttypen differenziert werden. Eine generische Liste mit 800 Feldern, die auf jedes Produkt angewendet wird, erzeugt genau das Chaos aus der Einleitung: viele leere Felder, keine klare Verantwortung, wachsende Pflegekosten.

Die strukturierte Antwort darauf sind Property Sets: Bündel von Attributen, die nur für bestimmte Produkttypen relevant sind. Für Fahrradschläuche sind Reifengröße, -breite sowie Ventilart und -länge relevant. Für Fahrradketten braucht es Kettenzähnezahl und Kettenlinie. Beide Produkttypen teilen Basisdaten wie EAN und Gewicht, ihre technischen Attribute überschneiden sich aber kaum. Property Sets sorgen dafür, dass Produktdarstellungen pro Produkttyp standardisiert und übersichtlicher werden. Das beschleunigt die Anreicherung und Datenpflege, reduziert Fehler (weil jetzt nicht mehr 800 Felder geprüft werden müssen) und macht Pflichtfelder pro Typ steuerbar.

Praxis-Tipp: Denke Attribute von der Output-Seite her. Welche Felder braucht Amazon, um dein Produkt korrekt zu listen? Was filtert dein Shop-Kunde? Was gibt der Katalog aus? Erst danach: Welche Felder brauchst du dafür im Modell, und welche hast du bereits im ERP?

3. Varianten

Ein Varianten-Produkt fasst mehrere Ausprägungen eines Produkts zusammen, etwa ein T-Shirt in verschiedenen Farben und Größen. Im Datenmodell erhält jede Variante einen eigenen vollständigen Datensatz mit einer eigenen eindeutigen Produkt-Nr. (PCode). Was die Varianten zusammenhält, ist ein gemeinsamer Master-PCode, der die Zugehörigkeit zum selben Produkt definiert.

Die Unterschiede zwischen den Varianten werden über Variantenattribute abgebildet: die Felder, die von Variante zu Variante abweichen, etwa Farbe, Größe oder Ausführung. Alle anderen Produktdaten, Beschreibung, Material, Marke, Logistikwerte, werden pro Datensatz gepflegt. Das klingt nach Aufwand, hat aber einen klaren Vorteil: Jede Variante ist vollständig eigenständig und kann ohne Abhängigkeiten an unterschiedliche Kanäle mit unterschiedlichen Anforderungen ausgespielt werden.

Die entscheidende Modellentscheidung ist daher, welche Felder als Variantenattribute definiert werden. Zu wenige, und Varianten lassen sich nicht sauber auseinanderhalten. Zu viele, und jede Änderung muss an dutzenden Datensätzen einzeln vorgenommen werden. Diese Festlegung vor dem ersten Datenimport zu treffen kostet einen Nachmittag. Sie im laufenden Betrieb zu korrigieren, kostet Wochen.

4. Kategorien, Kataloge und Produktklassen

Produktkategorien sind Navigationsstrukturen: Sie spiegeln wider, wie Produkte im Shop oder Katalog präsentiert werden. Dazu dient auch der Kategoriebaum. Kategorien ändern sich, wenn sich der Channel ändert. Ein Relaunch des Shops bringt neue Kategorien, ohne dass sich die Produkte selbst verändern.

Mehrere Kategorien lassen sich zu einem Katalog zusammenfassen, einem Kategoriebaum mit frei definierbaren Unterkategorien. Entscheidend für das Datenmodell: Ein Produkt kann mehreren Kategorien und damit auch mehreren Katalogen gleichzeitig zugeordnet sein. Wer Shop-Katalog, B2B-Preisliste und Print-Katalog parallel betreibt, kann dasselbe Produkt in allen drei Strukturen führen, ohne es mehrfach anzulegen.

Produktklassen hingegen definieren, welchen Attributsatz ein Produkt trägt. Ein Kabel und ein Leistungsschalter sind beide Elektroartikel. Ihre technischen Spezifikationen überschneiden sich aber kaum. Das Datenmodell weist dem Kabel andere Property Sets zu als dem Leistungsschalter, ohne dass beide manuell konfiguriert werden müssen.

Der Fehler, Kategorien und Produktklassen gleichzusetzen, macht sich bei jeder Shop-Umstrukturierung bemerkbar. Die Folge: neue Kategorien erfordern manuelle Attributzuweisungen, die längst hätten automatisiert sein können.

5. Relationen und verknüpfte Entitäten

Produktkataloge sind keine flachen Listen. Produkte beziehen sich aufeinander, als Zubehör, Ersatzteil, Bundle oder Nachfolgeartikel. Diese Relationen gehören als typisierte Beziehungen ins Datenmodell, nicht in den Anwendungscode. Wer Cross-Selling-Logik oder Ersatzteilkataloge mit Produktrelationen im Modell abbildet, kann sie systemübergreifend nutzen: im Shop, im B2B-Portal und im ERP.

Ein eigenes Konzept, das oft übersehen wird: verknüpfte Entitäten. Herstellerdaten, Markeninformationen und Lieferantenangaben tauchen bei vielen Produkten immer wieder auf. Wer sie als Freitextfeld auf jedem Produktdatensatz speichert, erzeugt redundante Daten mit einem klaren Risiko. Ändert sich die Adresse eines Herstellers, muss sie an hunderten Stellen manuell korrigiert werden.

Sauberer modelliert ist der Hersteller eine eigene Entität mit eigenen Attributen, und Produkte referenzieren ihn per Verknüpfung. Ändert sich eine Herstelleradresse, geschieht das einmal und gilt sofort für alle verknüpften Produkte.

Besonders drängend ist das durch die GPSR-Verordnung (General Product Safety Regulation), die seit Dezember 2024 gilt: Für Produkte im Anwendungsbereich der GPSR, insbesondere im Online-/Fernabsatz, müssen relevante Hersteller-, Verantwortlichen-, Identifikations- und Sicherheitsinformationen strukturiert verfügbar und ausleitbar sein.

Die Folgen eines schlechten Produktdatenmodells

Die Konsequenzen eines schlechten Datenmodells zeigen sich selten sofort. Sie sammeln sich über Monate an. Ein Migrationsprojekt, ein neuer Kanal oder eine Compliance-Anforderung macht sie dann sichtbar.

Listing-Ablehnungen auf Marktplätzen: Amazon und Zalando prüfen Pflichtattribute automatisch. Fehlen Felder oder sind sie falsch formatiert, werden Produkte nicht gelistet. Wer Marktplatz-Pflichtfelder nicht von Anfang an als eigene Attributgruppe im Modell verankert, löst das Problem manuell, für jedes neue Produkt neu.

Inkonsistente Daten über Kanäle hinweg: Das ERP nennt die Größe „42", der Shop zeigt „L", der Marktplatz erwartet „Large". Drei Systeme, kein gemeinsames Datenmodell. Die Folge sind Retouren, weil Kunden nicht sicher sein können, ob die Größenangabe stimmt.

Gebremste Time-to-Market: Jedes neue Produkt wird zur Mapping-Aufgabe, wenn das Modell nicht stimmt. Attribute lassen sich nicht zuordnen, Pflichtfelder sind unklar, Kategorien passen nicht zum neuen Sortiment. Was in einem gut aufgebauten Modell ein strukturierter Datenpflegeprozess ist, wird ohne Modell zu einem Projekt.

Compliance-Aufwand, der sich häuft: Ein GPSR-Pflichtfeld als Freitext auf 800 Produkten ergibt bei der nächsten Herstelleranpassung 800 manuelle Edits. Multipliziert mit der Anzahl der Hersteller im Sortiment.

Produktdatenmodell aufbauen: So gehst du vor

Vom Output denken, nicht vom Input

Der häufigste Fehler beim Aufbau eines Produktdatenmodells: Der Startpunkt ist das ERP. Felder, die im ERP vorhanden sind, werden ins PIM übernommen, inklusive technischer Identifikatoren, betrieblicher Flags und Buchungslogiken, die kein Kanal je braucht.

Der richtige Startpunkt ist die Output-Seite. Welche Attribute braucht Amazon, um dein Produkt zu listen? Was filtert dein Shop-Kunde, wenn er ein Produkt sucht? Was enthält das technische Datenblatt für den B2B-Kanal? Diese Anforderungen definieren dein Zielmodell. Danach wird gemappt, was das ERP davon bereits liefert, und was ergänzt werden muss.

Produkttypen und Klassen zuerst kartieren

Bevor du ein einziges Attribut anlegst, kartiere die gesamte Produktpalette und identifiziere natürliche Produktklassen. Für jeden Typ entsteht ein eigener Attributsatz per Property Set, keine generische Gesamtliste. Diese Kartierung gibt dir auch Aufschluss darüber, welche Attribute wirklich geteilt werden (Basisdaten, Logistik) und welche nur für bestimmte Typen gelten (technische Spezifikationen, zertifizierungsrelevante Angaben).

Vererbungslogik früh festlegen

Lege vor dem Go-Live fest, welche Attribute von der Elternebene vererbt werden und welche auf Variantenebene überschrieben werden können. Eine häufige Fehlentscheidung: Produktbeschreibungen als vererbbar einstellen und dann feststellen, dass die Hälfte der Varianten aus regulatorischen oder technischen Gründen eigene Beschreibungen braucht. Das Rückgängigmachen bedeutet, jeden betroffenen Datensatz einzeln anzufassen.

Lieferantendaten-Onboarding und Mapping einplanen

Die wenigsten Händler produzieren ihre Produktdaten selbst. Lieferanten-Feeds, Hersteller-Datenblätter und Großhändler-Exporte fließen ins PIM ein, in unterschiedlichen Formaten, mit unterschiedlichen Feldbezeichnungen und unterschiedlicher Datenqualität. Wer das nicht im Modell berücksichtigt, löst das Problem später manuell, für jeden neuen Lieferanten neu.

Das bedeutet konkret: Definiere für jeden relevanten Datenlieferanten, welches eingehende Feld welchem PIM-Attribut entspricht. Der Lieferant nennt das Feld „Breite_cm", das Modell kennt „Abmessung Breite (mm)". Ohne eine dokumentierte Mapping-Regel landet dieser Wert entweder im falschen Feld oder gar nicht. Halte zusätzlich fest, welche Transformationen nötig sind (Einheiten, Zeichensätze, Datumsformate) und was mit einem Datensatz passiert, der Pflichtfelder nicht befüllt.

Je sauberer das Modell, desto weniger manuelle Eingriffe braucht der Onboarding-Prozess. Ein neuer Lieferant wird dann zur Mapping-Aufgabe, nicht zum Projekt.

Artikel-Lifecycle von Anfang an einplanen

Wann ist ein Produkt aktiv? Was passiert, wenn es ausläuft, gibt es einen Nachfolgeartikel? Ab wann gilt ein Datensatz als gültig? Diese Lifecycle-Felder werden oft als nachträgliche Ergänzung behandelt. Wer sie von Anfang an ins Modell integriert, hat die Grundlage für automatisierte Sortimentspflege und saubere Archivierung.

Governance: Wer darf was ändern?

Ein Datenmodell ohne klare Governance-Regeln erzeugt Attributwuchern: 300 Felder, 80 davon aktiv genutzt, niemand weiß mehr, welche gelöscht werden können. Lege fest, wer neue Attribute anlegen darf, wie sie benannt werden müssen und nach welchem Prozess sie wieder entfernt werden. Diese Regeln sind genauso Teil des Datenmodells wie die Attribute selbst.

Die technische Grundlage für Produktdatenmodelle

Welche technische Grundlage im PIM-System braucht ein Produktdatenmodell? 

Die zentrale Anforderung an eine PIM-Lösung ist nicht, möglichst viele Features zu bieten, sondern das Datenmodell so flexibel zu halten, dass es mit dem Sortiment wachsen kann. Neue Produkttypen, neue Kanäle, neue regulatorische Anforderungen: All das verändert das Modell laufend. Wer dafür jedes Mal Entwicklerressourcen braucht, verliert Tempo.

Hublify PIM ist darauf ausgelegt, das Datenmodell flexibel anzupassen, wenn sich Sortiment oder Anforderungen ändern, ohne dass jede Änderung ein neues IT-Projekt auslöst. Beliebig viele Datenfelder, Ergänzungstabellen für beispielsweise Marken- oder GPSR-Informationen, Property Sets für Attribut-Sets bestimmter Produktgrupppen, Qualitätsprüfung hinsichtlich Vollständigkeit und vielem mehr - das ist die technische Grundlage, die Hublfiy liefert.

Was das in der Praxis bedeutet, zeigt der Use Case von Jungherz, einem Händler für Fahrrad-Ersatzteile und Zubehör: 80.000 Produkte mit knapp 800 Merkmalen und rund einer Million gesetzten Werten. Die Migration von Shopware zu Shopify dauerte zwei Tage, der Basisimport per Konnektor fünf Minuten. 

„Wir haben verschiedene andere Tools vorher ausprobiert, aber keine Lösung gefunden, die unsere Anforderungen überhaupt umsetzen konnte – und dann noch in 2 Tagen. Jeden Tag profitieren wir von Hublifys Datenflexibilität und sind froh, wie einfach die Datenorganisation unserer rund 80.000 Produkte jetzt klappt." – Falko Borkhart, Geschäftsführer Jungherz GmbH

Das Fundament entscheidet, nicht die Software

Der Schlüssel liegt darin, vor dem ersten Attribut zu wissen, was am Ende aus dem System herauskommen soll. Welche Kanäle beliefert werden, welche Compliance-Anforderungen gelten, wie Herstellerdaten organisiert sind und welche Produkttypen welche Attribute brauchen: Das sind Entscheidungen, die das Modell prägen, lange bevor die erste SKU angelegt wird.

Ein PIM-System kann nur so gut sein wie das Datenmodell darunter. Wer diesen Plan sorgfältig aufbaut, profitiert davon bei jeder Migration, jedem neuen Kanal und jeder Sortimentserweiterung.

Wenn du dir nicht sicher bist, wie dein Produktdatenmodell heute aufgestellt ist oder wo es Stellschrauben gibt: Lass dir Hublify zeigen. In 30 Minuten siehst du, wie ein flexibles Datenmodell in der Praxis aussieht.