10 Praxistipps für Open Data mit Industrie-Produktdaten

Geben Sie einen Ihrer Produktnamen in einen KI-Assistenten ein und lesen Sie die zurückgegebene Spezifikation. Nennt er einen Messbereich, den Sie vor zwei Jahren geändert haben, liegt kein Suchproblem vor — Sie sehen Ihre eigenen Daten, kopiert von einem Händler, veraltet, und jetzt als massgeblich behandelt, weil es die einzige maschinenlesbare Fassung war.

Open Data ist die bewusste Antwort darauf: einen kontrollierten Ausschnitt Ihres Katalogs als strukturierte, öffentliche, maschinenlesbare Daten bereitstellen, damit die Kopie, die Maschinen lesen, Ihre eigene ist. Zehn Punkte entscheiden darüber, ob diese Veröffentlichung nützlich ist oder nur vorhanden.

1. Klären Sie «öffentlich», bevor Sie klären, was veröffentlicht wird

Öffentlich ist eine Governance-Frage, keine technische. Vor jeder Formatdiskussion braucht es eine schriftliche Antwort auf: welche Produkte, welche Attribute, welche Sprachen — und wer freigibt.

Konkret: Erstellen Sie ein einseitiges Open-Data-Profil. Produktumfang nach Kategorie und Lebenszyklusstatus, eine explizite Attribut-Allowlist, die Sprachen, die verantwortliche Person. Alles, was nicht auf der Liste steht, bleibt berechtigt. Standard ist privat — nichts wird öffentlich, nur weil es im PIM existiert.

2. Formulieren Sie den Umfang als Regel, nicht als Liste

Eine handverlesene Liste mit 6'000 SKU stimmt am Tag ihrer Erstellung und ist mit der nächsten Produkteinführung falsch. Regeln überleben den Katalog.

Konkret: Schreiben Sie die Selektion als Bedingungen über Attribute, die Sie ohnehin pflegen — category IN [Druck, Temperatur, Füllstand], lifecycle = active AND market IN [DE, AT, CH], attribute.visibility = internal → ausschliessen. Prüfen Sie vor der Veröffentlichung die resultierende Anzahl Datensätze. Verschiebt eine Regeländerung die Zahl um Tausende, haben Sie ein Attribut gefunden, das niemand pflegt.

3. Arbeiten Sie mit einer Allowlist, nie mit einer Sperrliste

Eine Sperrliste versagt beim ersten neuen internen Feld. Die Liste dessen, was man auszuschliessen vergessen hat, wächst unbemerkt; die Liste dessen, was man bewusst aufgenommen hat, nicht.

Konkret: Zählen Sie die öffentlichen Felder positiv auf. In einem typischen Industriekatalog: Bezeichnung, Beschreibung, Kategorie, Masse, technische Bereiche, Werkstoffe, GTIN, Bilder, Datenblatt. Und benennen Sie ebenso ausdrücklich, was nie hinausgeht — Listen- und Kundenpreise, Bestände, Kosten, interne Notizen, Lieferantendaten, nicht freigegebene Produkte.

4. Einheiten als Codes, nicht als Zeichenkette

«10 bar» ist eine Zeichenkette, die eine Maschine raten muss. minValue: 0, maxValue: 10, unitCode: "BAR" ist ein Fakt, den sie vergleichen, umrechnen und filtern kann.

Konkret: Bilden Sie jedes numerische Attribut auf Wert, Einheitencode (UN/CEFACT im schema.org-Kontext) und — wo zutreffend — Min und Max ab, statt auf einen ausformulierten Bereich. Einmal im kanonischen Modell gemacht, erbt es jede Ausgabe. Steht in Ihrem PIM «0-10 bar» in einem Textfeld, ist das Ihr erstes Datenqualitäts-Ticket — und es zahlt sich bei ETIM und beim Digitalen Produktpass erneut aus.

5. Jedes Produkt braucht einen stabilen, auflösbaren Identifikator

Maschinen gleichen Datensätze über Identifikatoren ab. Ändert sich Ihre öffentliche URI, weil ein Produkt die Kategorie wechselt, hält jeder Consumer, der sie zwischengespeichert hat, eine Waise.

Konkret: Veröffentlichen Sie sku, mpn und gtin13, soweit vorhanden, und vergeben Sie eine stabile @id-URI, die den Kategoriepfad nicht enthält. Halten Sie sie über Umbenennungen und Umkategorisierungen hinweg stabil. Wo GTINs existieren, ist die GS1-Digital-Link-Syntax (/01/{GTIN}) die Form, die Handels- und Scansysteme erwarten; sie ist für das Modul geplant, nicht heute verfügbar — Ihre Identifikatoren jetzt so zu entwerfen, dass sie später ergänzt werden kann, kostet allerdings nichts.

6. schema.org/Product als Vokabular, additionalProperty für die technische Wahrheit

schema.org ist das etablierte Vokabular, mit dem Suchmaschinen Produktseiten lesen. Die Kernfelder decken kaufmännische Fakten ab; industrielle Spezifikationen gehören in additionalProperty.

Konkret: Erzeugen Sie ein JSON-LD-Dokument pro Produkt, eingebettet in Ihre eigene Produktseite (Script-Tag oder serverseitig) und über einen Endpunkt abrufbar. Legen Sie jedes technische Attribut als PropertyValue in ein additionalProperty-Array, mit name, value oder minValue/maxValue, unitCode und unitText. Hängen Sie das Datenblatt als subjectOf vom Typ DigitalDocument mit encodingFormat und URL an — so ist das PDF als Dokument zum Produkt erkennbar und nicht bloss ein unbeschrifteter Link.

7. Vor der Veröffentlichung validieren und Fehlerhaftes zurückhalten

Öffentliche Daten werden Ihnen zitiert. Ein Datensatz mit fehlender Einheit oder abgeschnittener Beschreibung ist öffentlich schlimmer als gar keiner, weil er gespiegelt wird.

Konkret: Definieren Sie Vollständigkeitsregeln eigens für das Open-Data-Profil — strenger als Ihr internes Minimum. Was durchfällt, wird zurückgehalten, nicht lückenhaft veröffentlicht. Sehen Sie sich diese Menge wöchentlich an: Sie ist der ehrlichste Datenqualitäts-Rückstand, den Sie bekommen, denn jeder Eintrag darin wäre einem Kunden aufgefallen.

8. Jede Veröffentlichung versionieren und ein Änderungsprotokoll führen

«Der Feed wird nächtlich aktualisiert» sagt einem Consumer nichts, woraus er handeln könnte. Eine Versionsnummer und eine Änderungsübersicht sagen ihm, ob er neu einlesen muss.

Konkret: Nummerieren Sie jeden Veröffentlichungslauf, publizieren Sie Zähler für hinzugefügt / geändert / zurückgezogen mit Datensatz-IDs und Zeitstempeln und halten Sie frühere Versionen für eine angegebene Aufbewahrungsdauer abrufbar. Liefern Sie Voll- und Delta-Feed nebeneinander — Marktplätze und Grosshändler mit grossen Katalogen nehmen den Delta-Feed und lesen nicht mehr eine Million Datensätze neu ein, um 112 Änderungen zu finden. Delta-Sync auf Feldebene macht das günstig: rund 95 % kleinere Payloads als Vollexporte.

9. Produkte ausdrücklich zurückziehen, nie stillschweigend löschen

Ein Datensatz, der verschwindet, ist von einem fehlgeschlagenen Abruf nicht zu unterscheiden. Consumer behelfen sich, indem sie die letzte gesehene Kopie behalten — also genau die veraltete Spezifikation, die Sie beseitigen wollen.

Konkret: Kennzeichnen Sie ausgelaufene Produkte im Feed als zurückgezogen, mit Datum, und halten Sie sie für eine definierte Frist unter ihrer URI auflösbar. Gibt es einen Nachfolger, verweisen Sie darauf. Für den KI-Fall ist das die billigste wirksame Massnahme: Ein Assistent, der «zurückgezogen» sieht, sagt es auch.

10. Lizenz angeben — und maschinenlesbar

Open Data ohne Lizenz sind Daten, die keine Rechtsabteilung freigibt. Marktplätze und Partner müssen wissen, was sie damit dürfen und wen sie nennen müssen.

Konkret: Legen Sie eine Lizenz pro Datensatz fest — eine offene Lizenz wie CC BY 4.0 oder Ihre eigenen Nutzungsbedingungen — und führen Sie sie im Feed-Manifest und im Endpunkt-Index mit, nicht nur im Footer. Nehmen Sie die Namensnennung auf. Die Wahl treffen Sie mit Ihrer Rechtsabteilung; die Anforderung ist, dass sie ausdrücklich und abrufbar ist.

Ein KI-Assistent nennt einen Messbereich, den wir vor zwei Jahren geändert haben — aus der Datenkopie eines Händlers.

Wie das im Betrieb aussieht

Open Data sollte keine zweite Exportstrecke sein. Es ist eine veröffentlichte Sicht auf dieselben validierten Daten, die Ihre Portale und APIs bereits liefern, gefiltert nach den Regeln aus Tipp 2. Eine Spezifikationsänderung erreicht damit Ihr Kundenportal, Ihre API-Consumer und den öffentlichen Feed aus einer einzigen Korrektur, in einem Lauf.

Einige Betriebspunkte, die jedes Mal aufkommen:

• Öffentliche Antworten zwischenspeichern und bei Veröffentlichung invalidieren, damit Crawler und Partner nie Ihre Quellsysteme erreichen.
• Read-only, mit Rate Limits. Ein öffentlicher Endpunkt kennt GET und sonst nichts.
• Regeländerungen protokollieren, mit Nutzer und Zeitstempel. Die Frage «wer hat das öffentlich gemacht» wird irgendwann gestellt.
• Produktdaten-Sitemap veröffentlichen — ein maschinenlesbarer Index öffentlicher Produkt-URLs mit Datum der letzten Änderung —, damit Crawler Ihren Katalog nicht erraten müssen.

Das Open-Data-Modul ist für 2026 geplant; GS1-Digital-Link-Auflösung und ein Agenten-Manifest im Stil von llms.txt sind darüber hinaus geplant. Keiner der zehn Tipps hängt jedoch vom Modul ab. Einheiten als Codes, stabile Identifikatoren, eine Attribut-Allowlist und ein schriftliches Profil sind Arbeit an Ihrem eigenen Datenmodell — und der Teil, der am längsten dauert.

Key takeaways

• Beginnen Sie mit einem schriftlichen Open-Data-Profil — Umfang, Attribut-Allowlist, Sprachen, Verantwortung — und setzen Sie alles Übrige auf privat.
• Formulieren Sie den Umfang als Regel über gepflegte Attribute statt als handverlesene SKU-Liste, und prüfen Sie vor jedem Lauf die Anzahl Datensätze.
• Zahlen brauchen Einheitencodes und Min/Max statt ausformulierter Zeichenketten; diese eine Änderung zahlt sich bei ETIM und DPP erneut aus.
• Versionieren Sie jede Veröffentlichung, liefern Sie Voll- und Delta-Feed, führen Sie ein Änderungsprotokoll und ziehen Sie Produkte markiert zurück, statt sie zu löschen.
• Führen Sie Lizenz und Namensnennung im Feed-Manifest selbst mit, damit Consumer ohne Rechtsanfrage handeln können.
• Validieren Sie öffentliche Daten gegen ein strengeres Profil und halten Sie Fehlerhaftes zurück — diese Menge ist Ihr ehrlichster Qualitätsrückstand.