Ein Produkt, 40 Kanäle, 40 Wahrheiten: Das Konsistenzproblem der Produktdaten-Distribution

Ein Produkt verlässt euer System of Record ein einziges Mal, aber es landet in Dutzenden Ausprägungen: im eigenen Onlineshop, im Marktplatz-Feed, im Preisvergleicher, in der App, im Newsletter-Modul, in der Social-Commerce-Anzeige. Jeder dieser Kanäle hat eigene Pflichtfelder, eigene Längenlimits für Titel und Beschreibung, einen eigenen Kategoriebaum und eigene Anforderungen an Bildformate. Wer die Abweichungen einmal prüfen musste, kennt das Muster: der Titel ist im Marktplatz abgeschnitten, der Preis im Feed ist einen Tag alt, die Verfügbarkeit widerspricht sich zwischen App und Shop, und niemand im Team kann mit Sicherheit sagen, welche Version gerade die richtige ist. Das ist kein Zufall und kein Einzelfall schlechter Datenpflege, sondern eine strukturelle Folge davon, wie Kanal-Ausleitung heute meist gebaut wird. In diesem zweiten Beitrag unseres Clusters zur Kanal-Distribution von Produktdaten schauen wir uns die konkreten Drift-Mechanismen an und warum die Lösung nicht in noch mehr Feed-Tools liegt, sondern in einem Orchestrierungs-Layer, der die kanalabhängige Ableitung übernimmt, statt sie 40-fach zu kopieren.

Warum Konsistenz mit jedem Kanal schwieriger wird

Am Anfang, mit zwei oder drei Kanälen, wirkt das Problem beherrschbar. Ein Team pflegt den Onlineshop, ein zweites kümmert sich um den Marktplatz-Feed, gelegentliche Abweichungen fallen kaum auf. Sobald aber ein zehnter, zwanzigster oder vierzigster Kanal dazukommt, kippt die Rechnung. Jeder neue Kanal bringt eigene Validierungsregeln mit: Amazon verlangt andere Titel-Längen als Google Shopping, ein Preisvergleicher erwartet andere Kategorie-Codes als ein B2B-Marktplatz, eine App-Kachel braucht ein quadratisches Bildformat, während der Onlineshop mit 16:9 arbeitet. Die Zahl der möglichen Abweichungen wächst nicht linear mit der Anzahl der Kanäle, sondern mit der Anzahl der Kombinationen aus Kanal und Feld. Das ist der eigentliche Grund, warum Konsistenz mit wachsender Kanalzahl nicht schwieriger wird, weil einzelne Teams schlechter arbeiten, sondern weil die Kombinatorik gegen jede manuelle Pflege arbeitet.

Hinzu kommt ein zweiter Effekt: Kanäle werden selten synchron eingeführt und synchron gepflegt. Ein Marktplatz wird im ersten Quartal angebunden, ein weiterer im dritten, ein regionaler Preisvergleicher kommt spontan dazu, weil ein Vertriebspartner danach fragt. Jede dieser Anbindungen bringt ihre eigene, oft handgestrickte Integration mit, die zum Zeitpunkt der Einführung Sinn ergab, aber selten mit den anderen Integrationen abgestimmt ist. Das Ergebnis ist eine gewachsene Landschaft aus Punkt-zu-Punkt-Verbindungen, in der jede einzelne für sich funktioniert, aber niemand einen Überblick hat, welche Transformationsregel in welchem Kanal gerade aktiv ist.

Die konkreten Mechanismen, durch die Daten auseinanderdriften

Der häufigste und zugleich unauffälligste Drift-Mechanismus ist der manuelle Kanal-Override. Ein Category Manager stellt fest, dass ein Titel im Marktplatz nicht zieht, und ändert ihn direkt im Marktplatz-Backend, weil das am schnellsten geht. Die Änderung ist lokal sinnvoll, aber sie existiert ab diesem Moment nur noch in einem System: im Kanal-Tool, nicht in der Quelle. Beim nächsten Sync überschreibt entweder der automatisierte Feed den manuellen Override wieder, oder der Override bleibt bestehen und der Kanal driftet dauerhaft von der Quelle ab. Beide Ausgänge sind unbefriedigend, weil in keinem von beiden jemand bewusst entschieden hat, welche Version die gültige ist.

Ein zweiter Mechanismus sind unterschiedliche Sync-Frequenzen. Der Onlineshop synchronisiert Preise und Bestand nahezu in Echtzeit, ein Marktplatz-Feed läuft alle sechs Stunden, ein Preisvergleicher wird einmal täglich per Batch aktualisiert. Wenn sich ein Preis oder eine Verfügbarkeit zwischen diesen Zyklen ändert, existieren für Stunden mehrere gleichzeitig gültige, aber widersprüchliche Zustände des gleichen Produkts im Netz. Niemand hat hier einen Fehler gemacht, die Systeme arbeiten wie konfiguriert, aber die Konfiguration selbst erzeugt Inkonsistenz als Nebenprodukt.

Rundungs- und Währungslogik ist ein dritter, oft unterschätzter Mechanismus. Ein Preis wird in der Quelle mit drei Nachkommastellen geführt, ein Kanal rundet auf zwei, ein anderer rechnet zusätzlich eine Währungskonvertierung mit eigenem Kurs-Stichtag durch. Zwei Kanäle, die denselben Ausgangspreis anzeigen sollen, zeigen am Ende unterschiedliche Beträge, weil die Rundungsregel nicht zentral definiert, sondern an vierzig Stellen implizit im jeweiligen Feed-Mapping vergraben ist.

Kategorie-Mappings verstärken das Problem, weil jeder Kanal einen eigenen Kategoriebaum erzwingt. Ein Produkt, das intern eindeutig kategorisiert ist, muss für jeden Kanal auf dessen eigene Taxonomie abgebildet werden, oft über Übersetzungstabellen, die getrennt vom Produktdatensatz gepflegt werden und bei Sortimentsänderungen veralten, ohne dass es jemand bemerkt. Abgeschnittene Titel, wenn ein Kanal ein Längenlimit erzwingt und die Kürzung nicht kontrolliert, sondern automatisch am Zeichenlimit passiert, sowie Bild- und Sprachvarianten, die pro Kanal unterschiedlich gepflegt werden, runden das Bild ab: es handelt sich nicht um einen einzelnen Fehler, sondern um ein Bündel struktureller Ursachen, die sich gegenseitig verstärken.

Warum das Problem im Feed-Tool nicht lösbar ist

Die naheliegende Reaktion auf Datendrift ist, in noch bessere Feed-Management-Software zu investieren: mehr Validierungsregeln, mehr Mapping-Tabellen, mehr manuelle Override-Möglichkeiten pro Kanal. Das lindert Symptome, verschiebt das Problem aber nur. Ein Feed-Tool kennt per Definition nur die Ausgangsseite, es weiß, wie ein Kanal Daten erwartet, aber es hat keine belastbare Vorstellung davon, was die eine gültige Wahrheit für ein Produkt gerade ist, weil jeder Override direkt im Feed-Tool selbst neue, konkurrierende Wahrheiten erzeugt. Je mehr Logik in das Feed-Tool wandert, desto mehr wird es selbst zur Quelle, obwohl es dafür nie gedacht war.

Das strukturelle Problem liegt eine Ebene tiefer: Die Transformation von einer Quelle in vierzig kanalspezifische Ausprägungen braucht Kontext, den ein reines Feed-Tool nicht hat. Es braucht Wissen über Locale, über Content-Struktur, über den Rendering-Kontext, in dem ein Titel oder ein Bild am Ende erscheint. Genau dieses Wissen liegt im Frontend-Layer, weil er bereits entscheidet, wie ein Produkt in welchem Markt, in welcher Sprache und auf welcher Fläche dargestellt wird. Ein Frontend-Layer, der ohnehin Locale-Logik, Content-Modelle und Rendering-Kontexte verwaltet, ist der natürliche Ort, an dem auch die kanalabhängige Transformation von Produktdaten stattfinden sollte, nicht als weitere Insellösung neben dem Feed-Tool, sondern als integraler Bestandteil derselben Schicht.

Die Wahrheit gehört in den Orchestrierungs-Layer

Der Ausweg aus dem Konsistenzproblem ist nicht, noch eine weitere Kopie zu erzeugen, sondern die Anzahl der Kopien auf eins zu reduzieren. Statt vierzig gepflegter Varianten braucht es eine einzige, klar verantwortete Quelle und darüber einen Orchestrierungs-Layer, der jede Kanalausprägung als ableitbare Sicht auf diese Quelle berechnet. Ein Titel für den Marktplatz ist dann keine eigene, manuell gepflegte Zeichenkette mehr, sondern das Ergebnis einer definierten Regel, die aus dem Quelltitel plus Kanalvorgabe automatisch abgeleitet wird. Ändert sich der Quelltitel, ändert sich die Ableitung mit, ohne dass irgendwo eine veraltete Kopie liegen bleibt.

Das setzt voraus, dass Transformationsregeln nicht mehr implizit in vierzig einzelnen Integrationen verstreut sind, sondern explizit an einer Stelle modelliert werden: Längenlimits, Rundungslogik, Kategorie-Mappings, Bildvarianten und Sprachfallbacks werden zu deklarierten Regeln, die pro Kanal einmal definiert und danach konsistent angewendet werden. Der Unterschied ist entscheidend: Statt vierzig Mal zu fragen "wie soll dieser Titel für diesen Kanal aussehen", stellt man sich einmal die Frage "nach welcher Regel wird ein Titel für einen Kanal mit diesen Eigenschaften abgeleitet", und wendet die Antwort auf beliebig viele Kanäle an.

Manuelle Eingriffe verschwinden dabei nicht vollständig, das wäre weder realistisch noch wünschenswert, denn es gibt legitime Gründe für kanalspezifische Anpassungen. Der Unterschied liegt darin, wo diese Eingriffe sichtbar werden. Statt eines stillen Overrides im Kanal-Backend braucht es eine Ausnahme, die im Orchestrierungs-Layer selbst dokumentiert und nachvollziehbar ist, damit klar bleibt, welche Abweichung bewusst gewählt wurde und welche schlicht Drift ist.

Was ein Orchestrierungs-Layer nicht ist

Es ist an dieser Stelle wichtig, eine Erwartung sauber abzugrenzen: Ein Orchestrierungs-Layer für die kanalabhängige Ausleitung von Produktdaten ersetzt kein Product Information Management System und will kein neues System of Record werden. Das PIM bleibt der Ort, an dem Produktdaten strukturell gepflegt, angereichert und freigegeben werden. Der Orchestrierungs-Layer setzt eine Ebene darüber an: Er nimmt die freigegebene Quelle aus dem PIM entgegen und übernimmt die kanalabhängige Ableitung, die Transformation in vierzig verschiedene Darstellungsformen, ohne selbst Eigentümer der Produktwahrheit zu werden.

Diese Abgrenzung ist mehr als eine Formalie, sie bestimmt, wie Teams zusammenarbeiten. Product Owner und Category Manager pflegen weiterhin im PIM, weil dort die fachliche Verantwortung liegt. Entwicklerinnen und Architekten modellieren die Transformationsregeln im Frontend-Layer, weil dort das technische Wissen über Rendering-Kontexte und Locale-Handling zusammenläuft. Beide Seiten arbeiten an derselben Quelle, aber jede an dem Teil, für den sie tatsächlich die Kompetenz hat. Wer diese Trennung verwischt und versucht, Transformationslogik zurück ins PIM zu ziehen oder Produktstammdaten im Frontend-Layer zu duplizieren, handelt sich am Ende genau die Kopien-Problematik wieder ein, die eigentlich gelöst werden sollte.

Einordnung: Wann sich der Umbau lohnt

Nicht jedes Unternehmen mit zwei oder drei Kanälen braucht sofort einen dedizierten Orchestrierungs-Layer, dafür lohnt sich der Aufwand nicht in jedem Fall. Der Punkt, an dem sich die Investition rechnet, ist meist dort erreicht, wo die Anzahl der Kanäle beginnt, stärker zu wachsen als die Kapazität des Teams, jede Abweichung manuell zu prüfen, oder wo bereits mehrfach unklar war, welche Version eines Produkts gerade die verbindliche war. Das ist ein qualitativer, kein exakt bezifferbarer Schwellenwert, aber er lässt sich im eigenen Betrieb leicht beobachten: Wie oft in der letzten Woche musste jemand manuell nachschauen, welcher Preis, welcher Titel oder welche Verfügbarkeit gerade "stimmt"?

Wer diese Frage häufiger stellen muss, sollte prüfen, ob die eigene Systemlandschaft überhaupt in der Lage ist, kanalabhängige Ableitung als Regel zu modellieren, statt sie als vierzig einzelne Integrationen zu pflegen. Genau hier setzt unser nächster Beitrag im Cluster an: Wie eine solche Modellierung konkret aussieht, welche Content-Strukturen sie braucht und wie ein composabler Frontend-Layer Kanaleigenschaften als deklarierte Eigenschaften statt als verstreuten Custom-Code abbildet, haben wir bereits im ersten Teil dieser Reihe skizziert. Wer die Grundlagen der Kanal-Distribution von Produktdaten und den Frontend-Layer als natürlichen Ort dieser Logik nachlesen möchte, findet das im Beitrag zur Rolle des Frontend-Layers bei der Kanal-Distribution von Produktdaten.

Mehr zu unserem Ansatz für Content-Modellierung als Grundlage konsistenter Datenableitung findet Ihr unter Content Management bei Laioutr, zur technischen Architektur composabler Frontends unter Composable Headless Frontend, und zu unserem Ansatz für Multichannel-Handel speziell im Handelskontext unter Growth Kit Multichannel Retail. Wer parallel mehrere Marken oder Märkte über denselben Produktdaten-Kern ausspielt, findet zusätzlichen Kontext unter Multi-Brand, Multi-Market.