Ein Händler möchte Produkte vieler Hersteller in einem gemeinsamen Shop anbieten. Fachlich klingt das nach einem einzigen Sortiment. Technisch treffen jedoch sehr unterschiedliche Datenwelten aufeinander.
Ein Hersteller liefert XML, ein anderer Excel, ein dritter eine API. Attribute heißen unterschiedlich, Einheiten werden anders geschrieben, Kategorien folgen internen Organisationsstrukturen und Variantenmodelle sind kaum vergleichbar. Bilder und Dokumente kommen über separate Downloadbereiche, Preise in einem anderen Rhythmus als Produktstammdaten.
Ein Händlerkatalog entsteht deshalb nicht durch das bloße Aneinanderhängen mehrerer Feeds. Er benötigt eine kontrollierte Verarbeitungsschicht, die aus heterogenen Quellen eine gemeinsam nutzbare Produktrealität erzeugt.
Jede Quelle besitzt einen eigenen Vertrag
Der erste Schritt ist kein allgemeiner Import, sondern eine explizite Beschreibung jeder Quelle.
Zu dokumentieren sind:
- technisches Format,
- Übertragungsweg,
- Authentifizierung,
- Aktualisierungsrhythmus,
- Voll- oder Delta-Lieferung,
- Produktidentifikatoren,
- Variantenmodell,
- Kategorie- und Attributstruktur,
- Einheiten und Werteformate,
- Medien- und Dokumentquellen,
- Preis- und Bestandsinformationen,
- Deaktivierungs- und Löschlogik,
- Qualitätsannahmen,
- Ansprechpartner beim Hersteller.
Diese Beschreibung wird zum Source Contract. Sie macht sichtbar, was die Pipeline erwarten darf und welche Abweichungen als Fehler gelten.
Rohdaten zuerst unverändert sichern
Vor jeder Transformation sollte die empfangene Lieferung in ihrem ursprünglichen Zustand gespeichert werden.
Das ermöglicht:
- spätere Fehleranalyse,
- erneute Verarbeitung mit verbesserten Regeln,
- Vergleich verschiedener Lieferstände,
- Nachweis, ob ein Fehler aus der Quelle oder der Transformation stammt,
- kontrollierte Rückverfolgung einzelner Werte.
Die Rohzone ist kein dauerhaftes Produktarchiv für jeden denkbaren Zweck. Sie ist die nachvollziehbare Eingangsschicht der Datenpipeline.
Ein gemeinsames Produktmodell entwickeln
Die Hersteller verwenden unterschiedliche Begriffe für ähnliche Dinge:
Hersteller A: Leistung_Nenn = "2,2 kW" Hersteller B: MotorPower = 2200 Hersteller C: Leistungsaufnahme = "2200 Watt"
Das gemeinsame Modell definiert beispielsweise:
Attribut: nominal_power Datentyp: decimal Einheit: watt Wert: 2200
Dafür werden benötigt:
- kanonische Attributnamen,
- Datentypen,
- Einheiten,
- Wertebereiche,
- Kategoriebezug,
- Pflicht- und optionale Felder,
- Übersetzungen,
- Herkunftsinformationen.
Das Modell sollte nicht alle Herstellerfelder zwanghaft vereinheitlichen. Manche Merkmale sind herstellerspezifisch und dürfen als solche erhalten bleiben. Entscheidend ist, welche Attribute für Suche, Vergleich, Filter, Darstellung und Verkauf gemeinsam benötigt werden.
Mapping ist mehr als Spaltenzuordnung
Ein Mapping kann einfache Felder direkt zuordnen. Häufig sind jedoch Transformationen erforderlich:
- Einheiten umrechnen,
- Werte aus Freitext extrahieren,
- mehrere Quellfelder zusammenführen,
- Codes in verständliche Werte übersetzen,
- Produktfamilien und Varianten erkennen,
- Kategorien zuordnen,
- Boolean-Werte aus unterschiedlichen Schreibweisen ableiten,
- ungültige Platzhalter wie „n. a." oder „0" behandeln.
Jede Regel sollte versioniert, testbar und einer Quelle zugeordnet sein. So kann ein Herstellerformat geändert werden, ohne die gesamte Plattform unkontrolliert zu beeinflussen.
Produktidentität und Dubletten
Händlerkataloge können dasselbe Produkt aus mehreren Quellen erhalten:
- direkt vom Hersteller,
- über einen Distributor,
- aus einem bestehenden internen Sortiment,
- aus einem Marktplatzfeed.
Mögliche Identifikatoren sind EAN, GTIN, Herstellerartikelnummer oder Kombinationen aus Marke und Modell. Sie sind nicht immer vollständig oder konsistent.
Ein Matching-Prozess kann deshalb mehrere Stufen verwenden:
- 1exakte, bestätigte Identifikatoren,
- 2bekannte Mappingtabellen,
- 3normalisierte Hersteller- und Modellwerte,
- 4regelbasierte Merkmalsvergleiche,
- 5KI-gestützte Ähnlichkeitsvorschläge,
- 6manuelle Prüfung unsicherer Fälle.
Unsichere Datensätze sollten nicht automatisch verschmolzen werden. Ein falscher Merge kann Preise, Dokumente oder technische Eigenschaften dem falschen Produkt zuordnen.
Kategorien aus Händlersicht
Jeder Hersteller besitzt seine eigene Taxonomie. Der Händler benötigt jedoch eine gemeinsame Navigation und Filterlogik.
Beispiel:
Hersteller A: Maschinen > Bohren > Akku Hersteller B: Elektrowerkzeuge > Mobile Geräte > Bohrschrauber Hersteller C: Produktgruppe 471 > Untergruppe 12
Im Händlerkatalog kann daraus werden:
Werkzeuge > Akkuschrauber
Die Zuordnung kann anhand von Quellkategorie, Produktmerkmalen, Herstellerregeln und KI-Vorschlägen erfolgen. Kritische oder neue Zuordnungen benötigen eine Freigabe.
Eine Kategoriezuordnung beeinflusst nicht nur Navigation. Sie bestimmt häufig auch:
- Pflichtattribute,
- Filter,
- Vergleichsmerkmale,
- Landingpages,
- rechtliche Hinweise,
- Dokumentanforderungen.
Wo KI sinnvoll unterstützt
KI eignet sich besonders für unscharfe und sprachliche Aufgaben:
- Attributnamen semantisch zuordnen,
- Werte aus Beschreibungen extrahieren,
- Produktkategorien vorschlagen,
- Beschreibungen strukturieren,
- fehlende Kurztexte erzeugen,
- mögliche Dubletten priorisieren,
- Herstellertexte vereinheitlichen,
- Übersetzungen vorbereiten.
Kritische Felder sollten jedoch kontrolliert bleiben:
- Produktidentität,
- Preise,
- Bestände,
- Freigaben,
- Gefahrgut- oder Compliance-Angaben,
- verbindliche technische Kennwerte.
Ein robustes System kombiniert KI-Vorschläge mit deterministischen Regeln, Konfidenzschwellen und menschlicher Prüfung.
Quelle, Aktualität und Priorität
Wenn mehrere Quellen denselben Wert liefern, muss geklärt werden, welcher übernommen wird.
Mögliche Regeln:
- direkter Hersteller vor Distributor,
- freigegebener Wert vor nicht freigegebenem,
- aktueller Wert vor älterem,
- vollständiger Wert vor leerem oder generischem,
- händlereigene redaktionelle Fassung vor automatisch generiertem Text,
- marktspezifischer Wert vor allgemeinem Wert.
Die Herkunft jedes übernommenen Werts bleibt gespeichert. Dadurch kann später erklärt werden, warum ein bestimmtes Attribut so dargestellt wird.
Voll- und Delta-Lieferungen
Hersteller liefern Daten auf unterschiedliche Weise:
- vollständiger Katalog täglich,
- nur Änderungen,
- separate Preisdatei,
- separate Bildpakete,
- unregelmäßige manuelle Exporte.
Die Plattform muss daraus einen konsistenten Zustand erzeugen.
Besonders wichtig:
- Wie wird erkannt, dass ein Produkt entfernt wurde?
- Darf ein fehlender Datensatz als Löschung interpretiert werden?
- Was passiert bei unvollständiger Lieferung?
- Wie werden verspätete Preisupdates behandelt?
- Wie werden Medienversionen synchronisiert?
Ein kompletter Katalog, der plötzlich nur halb so viele Produkte enthält, darf nicht automatisch die Hälfte des Sortiments deaktivieren. Mengen- und Plausibilitätsprüfungen schützen vor Quellfehlern.
Qualität für den Händler sichtbar machen
Nicht jeder Produktdatensatz erreicht sofort Veröffentlichungsqualität. Ein internes Quality Dashboard kann zeigen:
- Vollständigkeit je Kategorie,
- fehlende Pflichtattribute,
- ungeklärte Dubletten,
- Produkte ohne Bilder,
- veraltete Quellen,
- nicht zugeordnete Kategorien,
- auffällige Preisänderungen,
- fehlerhafte Dokumente,
- Anteil automatisch und manuell bestätigter Werte.
Dadurch wird Datenqualität zu einem steuerbaren Prozess statt zu einer unsichtbaren Importfrage.
Hersteller-Onboarding als wiederverwendbarer Prozess
Nach den ersten 15 Quellen kommt häufig die sechzehnte. Die Architektur sollte neue Hersteller nicht als individuelles Entwicklungsprojekt behandeln.
Ein standardisiertes Onboarding umfasst:
- 1Source Contract erfassen,
- 2Testdaten importieren,
- 3Mapping und Kategorien konfigurieren,
- 4Qualitätsregeln anwenden,
- 5Golden Dataset bestätigen,
- 6Delta- und Löschverhalten testen,
- 7Monitoring aktivieren,
- 8Quelle produktiv schalten.
Je mehr Regeln konfigurierbar und wiederverwendbar sind, desto schneller lassen sich weitere Sortimente integrieren.
Übertragbare Learnings
- 01Ein Herstellerfeed ist ein eigener Datenvertrag. Format, Rhythmus und Löschlogik müssen explizit beschrieben sein.
- 02Rohdaten sollten unverändert nachvollziehbar bleiben. Transformationen werden dadurch reproduzierbar.
- 03Ein gemeinsames Produktmodell bildet die Sprache des Händlers. Es ist nicht bloß die Summe aller Herstellerfelder.
- 04Mapping umfasst Semantik, Einheiten und Fachlogik. Spaltenzuordnung allein reicht nicht.
- 05Produktidentität benötigt mehrere Matching-Stufen. Unsichere Zusammenführungen gehören in die Prüfung.
- 06KI unterstützt unscharfe Aufgaben, kritische Felder bleiben kontrolliert. Beide Ansätze ergänzen sich.
- 07Quellenpriorität und Herkunft müssen pro Wert nachvollziehbar sein. Der Golden Record darf seine Geschichte nicht verlieren.
- 08Mengen- und Plausibilitätsprüfungen schützen vor fehlerhaften Lieferungen. Technisch erfolgreiche Feeds können fachlich unvollständig sein.
- 09Hersteller-Onboarding sollte ein Produktprozess werden. Die nächste Quelle darf nicht wieder bei null beginnen.