Referenzdaten im Produktkatalog: Codes, Wertelisten und Governance

Referenzdaten sind die erlaubten Werte, auf die andere Daten verweisen: Ländercodes, Währungen, Maßeinheiten, Farbnamen, Größensysteme und Klassifikationscodes. Sie beschreiben kein einzelnes Produkt und keine einzelne Bestellung, sondern die Listen, aus denen Produkte und Bestellungen auswählen, etwa NL, EUR, KGM oder „navy“.

In einem Produktkatalog sorgen Referenzdaten dafür, dass bei 4.000 Produkten „navy“ steht statt navy, Navy, dunkelblau und marine. Sie ändern sich selten, jedes Produkt und jeder Kanal nutzt sie, und wenn sie falsch sind, wiederholt sich der Fehler auf einen Schlag im ganzen Katalog. Deshalb brauchen sie eine verantwortliche Person, eine Version und ein Mapping auf die eigene Codeliste jedes Kanals.

Referenzdaten, Stammdaten, Bewegungsdaten und Metadaten im Vergleich

Datenteams teilen Geschäftsdaten in vier Arten ein. In der Praxis verschwimmen die Grenzen (manche behandeln Referenzdaten als Teilmenge der Stammdaten), aber die Einteilung hilft bei der Frage, wem was gehört und wie oft es sich ändert.

Ein einfacher Test: Ergibt ein Wert nur als eine Auswahl aus einer festen Liste Sinn, sind es Referenzdaten. Das Gewicht des Produkts (1,25) sind Stammdaten; die Einheit daneben (kg) stammt aus einer Referenzliste. Das Land des Kunden in einer Bestellung sind Bewegungsdaten, die Liste der Länder, aus denen die Bestellung wählen kann, sind Referenzdaten. Mehr zur Seite der Stammdaten findest du unter Stammdatenmanagement.

Externe Codelisten, von denen jeder Produktkatalog abhängt

Viele Referenzdaten erfindest du nicht selbst. Internationale Organisationen veröffentlichen sie, und Kanäle erwarten, dass du ihre Codes exakt verwendest. Das sind die Listen, denen ein typischer Onlinehändler oder Großhändler zuerst begegnet.

Ein paar Fakten hinter der Tabelle. Feeds und Marketplace-Dateien kombinieren einen Preis mit einem ISO-4217-Währungscode; das Google Merchant Center zum Beispiel erwartet 15.00 USD statt $15. Die Liste der UN/ECE-Empfehlung 20, die die Peppol-E-Rechnung in Revision 11e verwendet, definiert KGM als Kilogramm und H87 als Stück (Peppol-Codeliste); unser Leitfaden zu Maßeinheiten zeigt, wie du sie modellierst. Das Harmonisierte System umfasst mehr als 5.000 Warengruppen mit je einem sechsstelligen Code und wird von mehr als 200 Ländern und Volkswirtschaften genutzt (WCO); die EU ergänzt für ihre Kombinierte Nomenklatur zwei Stellen, die du ab Position 8539 abwärts durchsuchen kannst.

Auch Klassifikationsstandards haben Versionen. Laut ETIM International ist das aktuelle offizielle Release ETIM 10.0, veröffentlicht im Dezember 2024, mit dynamischen Releases dazwischen für Klassen, die veröffentlichungsreif sind. Ist dein Katalog nach einem älteren Release klassifiziert, haben sich einige Klassen und Merkmale geändert. GS1 GPC verwendet auf jeder Ebene achtstellige Codes, zum Beispiel Segment 47000000 (Cleaning/hygiene products) und Family 47100000 (Cleaning products), und über GS1-Datenpools wird nur der Brick ausgetauscht; Segment, Family und Class helfen dir, den richtigen Brick zu finden (GS1 Niederlande). Die Leitfäden zu ETIM und GS1 GPC erklären beide Strukturen.

Interne Wertelisten: Farben, Größen und Materialien

Die zweite Art von Referenzdaten gehört dir: die Farbnamen, Größenläufe, Materialien und Passformen, die dein Katalog zulässt. Niemand veröffentlicht sie für dich, und genau hier laufen die meisten Kataloge auseinander. In einer Lieferantendatei steht Midnight, in einer anderen Dk Navy, in einer dritten 410, und ohne feste Liste landen alle drei im Farbfilter.

Eine gute interne Liste speichert jeden Wert als stabilen Code mit Labels pro Sprache, plus ein Mapping auf jeden Kanal, der eine eigene Liste hat. Ein Beispieleintrag für eine Farbe:

• Code: navy (ändert sich nie, wird in Exporten und Regeln verwendet)
• Labels: Navy (en), Marineblauw (nl), Marineblau (de), Bleu marine (fr)
• Filtergruppe im Shop: Blau
• Farbe für Google Shopping: Navy, derselbe Name, den die Produktseite zeigt
• Synonyme der Lieferanten: Midnight, Dk Navy, 410 (beim Import gemappt, nie veröffentlicht)

Die Regeln der Kanäle machen das Mapping nötig. Googles Attribut color nimmt bis zu drei Farben, getrennt durch Schrägstriche (Red/Green/Black), lehnt Werte wie „siehe Bild“ oder „N/A“ ab und verlangt denselben Farbnamen wie auf der Landingpage (Google Merchant Center). Für Bekleidungsgrößen akzeptiert size_system nur AU, BR, CN, DE, EU, FR, IT, JP, MEX, UK und US, und lässt du es weg, greift Google auf das System des Ziellands zurück. Freitext kann solche Regeln nicht konsequent erfüllen; eine codierte Liste mit Mapping schon.

Ein Größenlauf, gemappt auf drei Kanalformate

Größen zeigen, warum ein Mapping besser ist als Kopieren. Nimm als Beispiel einen Damen-Strickpullover in den EU-Größen 36 bis 44. Deine Referenzliste speichert fünf Codes: eu_36, eu_38, eu_40, eu_42 und eu_44. Jeder Kanal bekommt dann, was er erwartet:

• Filter im Webshop: die Labels 36, 38, 40, 42, 44, mit einer Größentabelle, die die internationalen Entsprechungen deiner Marke zeigt (zum Beispiel S für 36 und 38).
• Google Shopping: size 38 mit size_system EU, damit Google 38 nicht als US-Größe liest.
• Ein Marketplace nur mit Buchstabengrößen: ein Mapping, das für eu_38 ein M sendet, einmal von der verantwortlichen Person der Liste entschieden statt pro Produkt von dem, der gerade hochlädt.

Ändert die Marke ihre Passform und entspricht 38 nun einer anderen Buchstabengröße, änderst du eine Zeile im Mapping. Die 300 Produkte mit dem Größencode eu_38 bleiben unberührt, und jeder Kanal bekommt beim nächsten Export den neuen Wert. Wäre die Buchstabengröße in jedes Produkt eingetippt worden, wäre dieselbe Änderung eine Massenbearbeitung, bei der leicht ein paar Produkte durchrutschen.

Dasselbe Muster gilt für Materialien (dein cotton_organic auf das Organic cotton eines Marketplace), für Einheiten (dein kg auf KGM in einer B2B-Datei) und für Kategorien (deine Kategorie auf eine Google-Produktkategorie). Speichere deinen Wert einmal, mappe ihn pro Kanal und halte das Mapping am selben Ort wie die Liste.

Referenzdaten steuern: Verantwortung, Versionen und Kanal-Mappings

Governance für Referenzdaten ist überschaubar im Vergleich zur Stammdaten-Governance, muss aber streng sein. Vier Regeln decken die meisten Kataloge ab:

1. Eine verantwortliche Person pro Liste. Eine Person entscheidet, ob „teal“ eine neue Farbe wird oder auf eine bestehende gemappt wird. Ohne Verantwortung fügt jeder, der importiert, Werte hinzu.
2. Codes sind dauerhaft, Labels nicht. Ändere ein Label (Navy zu Navy blue) nach Belieben; verwende einen Code, von dem Exporte und Regeln abhängen, nie neu und benenne ihn nie um. Einen Wert, den du nicht mehr brauchst, markierst du als inaktiv.
3. Version jedes externen Standards festhalten. Notiere, welches ETIM-Release, welches GPC-Release und welches KN-Jahr deine Klassifikation nutzt, und plane das Update, wenn ein neues erscheint.
4. Kanallisten mappen, nicht kopieren. Behalte deine eigene Liste als Quelle und pflege ein Mapping auf die Codes jedes Kanals, sodass eine Änderung beim Kanal das Mapping betrifft, nicht jedes Produkt.

Eine umfassendere Data Governance ergänzt Rollen, Richtlinien und Audits für Stammdaten; für Referenzdaten reicht der Ablauf oben meistens aus.

Was zu tun ist, wenn ETIM, die KN oder eine ISO-Liste eine neue Version veröffentlicht

Externe Listen ändern sich nach eigenem Zeitplan, und jede braucht eine andere Reaktion. ETIM International veröffentlicht etwa alle drei Jahre ein offizielles Release, mit dynamischen Releases dazwischen (ETIM International). Die EU veröffentlicht Anhang I ihrer Kombinierten Nomenklatur jedes Jahr neu als eigenständige Verordnung im Amtsblatt, mit den Änderungen, die bei der WCO für das Harmonisierte System vereinbart wurden, und eigenen Aktualisierungen (Europäische Kommission). ISO-Länder- und Währungscodes ändern sich nur, wenn sich ein Land, eine Untergliederung oder eine Währung ändert.

• Neues ETIM-Release: Vergleiche deine übernommenen Klassen mit dem neuen Release, liste Klassen, die aufgeteilt, zusammengelegt oder ersetzt wurden, und mappe diese Produkte neu, bevor Partner gegen das neue Release validieren. Ein dynamisches Release enthält noch Klassen, die für die Löschung im nächsten offiziellen Release markiert sind; diese Markierungen sind deine Frühwarnung.
• Neues KN-Jahr: Prüfe jeden achtstelligen KN-Code im Katalog gegen die neue Liste, sobald sie veröffentlicht ist. Ein Code, den es nicht mehr gibt, wird in einer Zollanmeldung abgelehnt, und die Korrektur ist im Katalog günstiger als an der Grenze.
• Geänderter ISO-Code: Nimm den neuen Code in deine Liste auf, markiere den alten als inaktiv und verschiebe die betroffenen Produkte in einer Massenänderung, dann aktualisiere jedes Kanal-Mapping, das auf den alten Code zeigte.
• Deine eigenen Listen: Prüfe sie, wenn sich das Sortiment ändert, zum Beispiel vor einer Saison mit neuen Materialien oder einem neuen Größenlauf, statt die erste Lieferantendatei entscheiden zu lassen.

Die Referenzdaten in einem bestehenden Katalog prüfen

Die meisten Kataloge enthalten schon Referenzdaten, nur nicht als Listen. Ein erstes Audit dauert mit einem Export aller Produkte einen Nachmittag:

1. Liste jedes Feld auf, das eine Auswahl sein sollte. Farbe, Größe, Material, Ursprungsland, Einheit, Marke, Kategorie, Zertifizierung. Alles mit weniger unterschiedlichen Werten als Produkten ist ein Kandidat.
2. Zähle die unterschiedlichen Werte pro Feld. Hat ein Modekatalog, der 14 Farben verkauft, sagen wir 212 unterschiedliche Werte im Farbfeld, weißt du, wie viel Bereinigung vor dir liegt.
3. Gruppiere Schreibweisen desselben Werts. Groß- und Kleinschreibung, Leerzeichen und Satzzeichen erklären viele Dubletten; Synonyme (Dk Navy, Midnight) brauchen eine menschliche Entscheidung.
4. Prüfe externe Codes gegen den Standard. Das Ursprungsland sollte als Zwei-Buchstaben-Code vorliegen, Währungen als Drei-Buchstaben-Code, HS-Codes gültig für das aktuelle Jahr.
5. Lege für jede Liste eine verantwortliche Person und einen Code fest, dann stelle das Feld von Freitext auf ein Auswahlattribut um, das nur gelistete Werte akzeptiert.
6. Entscheide, was mit neuen Werten beim Import passiert: Produkt ablehnen, annehmen und zur Prüfung markieren oder bei Listen mit geringem Risiko automatisch annehmen.

Sieben Arten, wie schlechte Referenzdaten einen Katalog kaputt machen

1. Schreibvarianten eines Werts. Navy, navy und NAVY teilen eine Filteroption in drei, und jede enthält ein Drittel der Produkte.
2. Ländernamen statt Codes. Holland, Netherlands und Nederland im Ursprungsland scheitern alle an einem Feld, das NL erwartet.
3. Einheiten im Wert. 500g als Text lässt sich nicht mit 0,5 kg vergleichen; die Einheit gehört in ein eigenes, codiertes Feld.
4. Wiederverwendete Codes. Wer den Code red in coral umbenennt, ändert stillschweigend jedes Produkt, das rot war.
5. Veraltete Klassifikation. Produkte bleiben auf einer ETIM-Klasse oder einem HS-Code, die ein neueres Release aufgeteilt oder ersetzt hat, und Exporte an Partner fallen durch die Validierung.
6. Kanalwerte als Stammdaten gespeichert. Wer Googles Farbe ins Produkt tippt, statt sie zu mappen, macht aus jeder Änderung beim Kanal eine Massenbearbeitung.
7. Vermischte Identifikatoren. Wer SKU, GTIN und Artikelnummer des Lieferanten als ein Feld behandelt, macht jede Suche kaputt; siehe UPC vs. SKU.

Optionssets, Einheitencodesätze und Klassifikation in WISEPIM

WISEPIM hält interne Referenzdaten in Option sets (Optionssets): gemeinsame Listen erlaubter Werte für Auswahl- und Mehrfachauswahl-Attribute. Jeder Wert hat einen Code und ein Label pro Sprache, ein Set kann viele Attribute bedienen, und Werte lassen sich inaktiv setzen statt löschen. Jedes Set hat eine Regel für unbekannte Werte aus einem Import: Produkt überspringen, den Wert mit Prüfmarkierung hinzufügen oder ihn automatisch hinzufügen. CSV-Importe können Lieferantenwerte auf bestehende Optionen mappen, und die Seite Attribute values (Attributwerte) gruppiert Schreibweisen, die sich nur in Großbuchstaben, Leerzeichen oder Satzzeichen unterscheiden, damit du sie zusammenführen kannst (siehe Normalisierung von Attributwerten).

Ist das Workspace-Feature Classification (Klassifizierung) eingeschaltet, enthalten UOM code sets (Einheitencodesätze) Einheiten mit Code, Symbol, lokalisierten Namen und einem Umrechnungsfaktor auf eine Basiseinheit. Der Klassifizierungs-Workspace durchsucht außerdem ETIM-Klassen und GS1 GPC: Eine ETIM-Klasse lässt sich mit ihren Merkmalen als Produktfamilie übernehmen, eine Mapping-Prüfung schlägt Verknüpfungen zwischen deinen Familien und Attributen und ETIM vor, und GPC-Knoten lassen sich mit ihrem vollständigen Pfad als Kategorien importieren. Mehr auf der Seite zur Produktklassifizierung.

WISEPIM pflegt die externen Standards nicht für dich: Du wählst die ETIM- und GPC-Releases, und kanalspezifische Wert-Mappings für Farben oder Größen gehören weiterhin zur Einrichtung jedes Exports.