Commerce Velocity: Die Falle im gemeinsamen Mirakl-Backend

Alle Wege führen nach Rom – das war schon im Römischen Reich eine Frage der Infrastruktur, nicht der Sprache. Wer ankam, musste trotzdem lesen können, was vor Ort galt: andere Bezeichnung, andere Einheiten, andere Regeln. Die Straße war gemeinsam. Die Karte nicht.

Im E-Commerce heißt diese Straße heute oft Mirakl. Bauhaus, OBI, Galeria, MediaMarkt/Saturn, Fressnapf, Hornbach, Decathlon, home24 – ein gutes Dutzend der bekanntesten Marktplätze in Deutschland läuft technisch über dieselbe Plattform. Wer das weiß, zieht schnell den falschen Schluss: ein Anschluss, viele Kanäle, Skalierung fast geschenkt.

Das ist die Versprechung hinter dem, was zuletzt als Commerce Velocity gefeiert wurde: Geschwindigkeit als neue Währung, gemessen daran, wie schnell ein Sortiment neue Vertriebskanäle erreicht. Nur beschreibt dieses Bild bestenfalls die halbe Wahrheit.

Ein gemeinsames Backend ist keine gemeinsame Sprache.

Und genau an dieser Stelle liegt die Falle, in die Händler regelmäßig laufen, ohne es beim Start des nächsten Marktplatzes zu merken.

Ein Motor, zwölf Attributmodelle

Mirakl ist die technische Plattform hinter vielen der genannten Marktplätze – nicht selbst ein Marktplatz, sondern die Infrastruktur, auf der Bauhaus, OBI, Galeria oder MediaMarkt/Saturn ihre jeweiligen Marktplatzmodelle betreiben. Das ist ein echter Effizienzgewinn: Ein Händler muss nicht für jeden dieser Marktplätze eine komplett neue technische Anbindung bauen.

Was Mirakl nicht standardisiert, ist das Attributmodell dahinter. Jeder Betreiber definiert seine eigenen Pflichtfelder, eigene Kategoriebäume, eigene Bezeichnungen für praktisch identische Eigenschaften. Eines Akkuschraubers Voltzahl heißt bei dem einen Marktplatz "Spannung", beim nächsten "Nennspannung", beim dritten steckt sie in einem Freitextfeld namens "technische Daten". Das Backend ist geteilt. Die Taxonomie ist es nicht.

Für den Handel bedeutet das: Jeder neue Mirakl-Marktplatz sieht auf dem Papier aus wie eine kleine technische Übung – Zugangsdaten, Katalog-Feed, fertig. In der Praxis beginnt an dieser Stelle wieder die gleiche Arbeit, die beim ersten Marktplatz schon einmal gemacht wurde: Attribute von Hand zuordnen, Freitexte interpretieren, Ausnahmen dokumentieren.

Die Mapping-Steuer

Nennen wir dieses wiederkehrende Problem die Mapping-Steuer: den Aufwand, der bei jedem neuen Kanal erneut fällig wird, unabhängig davon, wie viel technische Infrastruktur bereits geteilt wird. Sie taucht in keiner Roadmap auf, weil sie kein Projekt ist, sondern eine Nebenkosten-Position, die sich bei jedem "schnell noch einen Marktplatz aufschalten" wiederholt.

Das eigentliche Problem an der Mapping-Steuer ist nicht ihre Höhe im Einzelfall, sondern ihre Unsichtbarkeit in der Planung. Wer "Time to Market" als Kennzahl für einen neuen Kanal nennt, rechnet meist die Vertragsunterzeichnung, die technische Anbindung und den ersten Testupload. Die Wochen, die ein Produktdatenteam braucht, um 8.000 SKUs in ein neues Attributschema zu pressen, tauchen in dieser Rechnung selten auf – sie laufen "nebenbei", parallel zum Tagesgeschäft, meist manuell in Excel.

Ein Beispiel: 12.000 Artikel, vier Marktplätze, vier Regelwerke

Ein Baumarktsortiment mit 12.000 aktiven Artikeln, das parallel auf OBI, Bauhaus, Hornbach und Amazon gelistet ist, bewegt sich technisch über zwei Backends: Mirakl für die ersten drei, eine eigene Anbindung für Amazon. Vier Marktplätze, vier Attributlogiken – trotz der geteilten Infrastruktur bei drei von ihnen.

Kommt ein fünfter Marktplatz hinzu, etwa Hagebau oder ein neuer Mirakl-Partner, ändert sich an dieser Grundrechnung nichts. Ein Produktdatenteam, das bereits an der Kapazitätsgrenze arbeitet, bekommt keine "schnelle Erweiterung", sondern ein weiteres Regelwerk, das gegen dieselben 12.000 Artikel gemappt werden muss – Attribut für Attribut, Kategorie für Kategorie. Genau in diesem Moment kippt "Speed to Market" in Verzug: Der neue Kanal geht später live als geplant, oder er geht mit unvollständigen Daten live, was in der Regel schlechtere Sichtbarkeit und mehr Rückfragen von der Marktplatzseite bedeutet.

Commerce Velocity lässt sich fälschen – aber nicht erzwingen

Hier liegt die eigentliche Pointe: Ein Handelsunternehmen kann Commerce Velocity kurzfristig simulieren, ohne das zugrunde liegende Mapping-Problem zu lösen. Ein neuer Marktplatz lässt sich technisch anbinden, ein erster Katalog lässt sich hochladen, eine Pressemitteilung lässt sich schreiben – "jetzt auch auf X gelistet". Auf dem Papier zählt das als Geschwindigkeit.

Was diese Momentaufnahme nicht zeigt: wie viele der gelisteten Artikel tatsächlich vollständig, korrekt attribuiert und damit auffindbar sind. Ein Sortiment, das mit halbfertigen Attributen auf einem neuen Marktplatz startet, gewinnt keine Geschwindigkeit – es verschiebt die Mapping-Steuer nur in die Zukunft, wo sie als Reklamationen, Deranking oder manuelle Nacharbeit unter Zeitdruck wieder auftaucht. Velocity, die auf einem manuellen Mapping-Rückstand aufbaut, ist geliehene Zeit, keine gewonnene.

Die eigentliche Kennzahl ist deshalb nicht, wie schnell ein Marktplatz technisch angebunden ist, sondern wie schnell ein vollständiges, kanalkonformes Sortiment darauf live geht. Das ist ein Mapping-Problem, kein Anbindungsproblem – und Mapping-Probleme lassen sich nicht durch mehr manuelle Arbeitsstunden dauerhaft lösen, sondern nur durch weniger davon.

Ainavio als Agentic PIM: Der Mapping Agent übernimmt die Übersetzung

Genau an dieser Stelle setzt ainavio als agentischer Workspace für Produktdaten an. Statt jeden neuen Marktplatz erneut von Hand gegen das eigene Attributmodell abzugleichen, übernimmt der Mapping Agent die Übertragung von Kategorien und Attributen auf das jeweilige Zielsystem automatisch – ohne dass ein Team manuell Mapping-Regeln pflegen muss.

Das funktioniert, weil ainavio Produktdaten nicht kanalspezifisch verwaltet, sondern zentral im PIM: ein Golden Record pro Produkt, aus dem heraus jeder angebundene Kanal – ob Mirakl-Marktplatz wie Bauhaus oder OBI, oder eine eigenständige Anbindung wie Amazon oder Shopify – automatisch mit den für ihn richtigen Attributen, Bezeichnungen und Pflichtfeldern beliefert wird. Vor jedem Export prüft das System Vollständigkeit, Konsistenz und Kanalkonformität, sodass unvollständige Daten erst gar nicht live gehen.

Der Effekt lässt sich an der eigentlichen Kennzahl ablesen, nicht an der Zahl der angebundenen Kanäle: Kunden, die ihr Produktdaten-Onboarding auf diese Weise automatisieren, berichten von bis zu zehnfach schnellerem Onboarding neuer Sortimente. Der zwölfte Marktplatz kostet damit nicht mehr Aufwand als der erste – weil die Übersetzungsarbeit nicht mehr bei Menschen liegt, sondern beim Agenten.

Zurück zur Karte

Alle Wege führen weiterhin nach Rom, und ein gemeinsames Backend wie Mirakl bleibt ein echter Vorteil – nur eben kein Ersatz für die Übersetzungsarbeit, die an jedem Ziel neu anfällt. Der Unterschied zwischen einem Händler, der bei jedem neuen Marktplatz wieder bei null anfängt, und einem, der einfach den nächsten Kanal freischaltet, liegt nicht in der Anzahl der Straßen. Er liegt darin, wer die Karte liest – ein Team, das jedes Mal neu übersetzt, oder ein Agent, der es längst kann.

Commerce Velocity ist kein Versprechen der Infrastruktur. Sie ist das Ergebnis dessen, was mit den Daten passiert, bevor sie die Straße überhaupt erreichen.