Ein zentral gepflegtes Produkt ist nicht automatisch in jedem Vertriebskanal veröffentlichungsfähig. Jeder Shop, Marktplatz, Händler oder Datenempfänger erwartet eigene Feldnamen, Pflichtattribute, Kategorien, Werteformate und teilweise eigene Inhalte. Produktdatensyndizierung übersetzt deshalb einen kanonischen Produktdatensatz in die jeweils benötigte Kanalstruktur.
PIMSuite übernimmt diese Mapping-, Transformations- und Verteilungslogik.
Das kanonische Produktmodell
Shopify
↑
Amazon ← kanonisches Produkt → B2B-Portal
↓
Handelsfeed
Der zentrale Katalog sollte nicht zur Vereinigungsmenge aller nachgelagerten Schemata werden. Schlecht: amazon_bullet_1, amazon_bullet_2, shopify_vendor, partner_x_feld_93 direkt ins Kernmodell aufnehmen, für jeden neuen Kanal ein paar Felder mehr. Besser: ein sinnvolles kanonisches Modell pflegen und es nach außen abbilden. Das ist derselbe Grundsatz wie beim Produktkatalog: das Datenmodell folgt den Produkten, nicht den Kanälen.
Drei unterschiedliche Mapping-Probleme
Was oft als ein Problem behandelt wird, sind eigentlich drei:
1. Feldmapping - intern selling_price, im Kanal price.
2. Werttransformation - intern 29.99 EUR, im Kanal 2999.
3. Vokabularmapping - intern size = M, im Kanal medium.
Diese Unterscheidung macht klar, warum PIMSuite dafür drei getrennte Mechanismen anbietet, statt alles in einer Konfiguration zu vermischen.
Attributzuordnung
Für jeden Kanal definiert ihr, wie eure Stamm-Attribute dem Feldschema des Kanals zugeordnet werden. Eine Zuordnung verbindet euer internes Attribut (z. B. selling_price) mit dem Feld des Kanals (z. B. price) und einer optionalen Transformation.
Neun integrierte Transformationstypen decken die häufigsten Fälle ab:
- Groß-/Kleinbuchstaben - Textschreibweise normalisieren
- Preis in Cent - € 29,99 in 2999 umrechnen
- Preis mit Währung - Preis mit Währungssymbol oder -code formatieren
- Brutto zu Netto - Steuer aus einem Bruttopreis herausrechnen
- HTML-Entfernung - Formatierung für Klartextfelder entfernen
- Boolean JN - wahr/falsch in J/N umwandeln
- Boolean 1/0 - wahr/falsch in 1/0 umwandeln
- CDATA-Umhüllung - Inhalt für XML-Feeds umhüllen
Warum das wichtig ist: Ohne feste Regeln pflegt eine Person shopify_export.xlsx, eine andere baut amazon_final_v3.csv, ein Partner will products.xml - und jede Produktänderung bedeutet, drei Dateien von Hand neu zu bauen. Transformationen sollten wiederholbare Regeln sein, keine Tabellenaufräumarbeit nach jedem Export.
Benutzerdefinierte, formelbasierte Transformationen existieren heute für das Zuordnen von Lieferantenimporten, sind aber noch nicht in das Kanal-Export-Mapping eingebunden:
Aktuell verfügbar für Kanalexporte: die neun integrierten Transformationstypen oben.
Roadmap: beliebige formelbasierte Transformationen auch im Kanal-Export-Mapping.
Wertemapping
Euer internes Vokabular und das Vokabular des Kanals sind selten identisch. Ihr speichert Größen vielleicht als "S", "M", "L", während der Kanal "small", "medium", "large" erwartet. Ihr speichert einen Status vielleicht als "aktiv", während der Kanal "1" erwartet.
Wertemapping übernimmt diese Übersetzung pro Attribut und pro Kanal - ohne eure Stammdaten zu ändern.
Taxonomie
Feldschemata sind nur ein Teil der Marktplatz-Integration - Kategorien sind der andere. Ein interner Pfad wie "Schuhe > Laufschuhe" entspricht selten direkt der Kategoriestruktur eines Marktplatzes, etwa "Clothing, Shoes & Jewelry > Men > Athletic > Running" bei Amazon oder der Google-Produkttaxonomie.
PIMSuites KI-Funktionen können für jedes Produkt eine passende Google-Produkttaxonomiekategorie vorschlagen, die ihr bestätigt oder überschreibt. Taxonomiekategorie lässt sich außerdem als Bedingung für Produktkollektionen nutzen (siehe unten), um zu steuern, welche Produkte in welchen Kanal gehören. Eine dedizierte Mapping-Tabelle, die eine beliebige interne Taxonomie automatisch auf eine beliebige kanalspezifische Taxonomie überträgt, ist darüber hinaus heute keine eigenständige Funktion.
Produktkollektionen mit Regeln
Nicht jedes Produkt gehört in jeden Kanal: Marke A darf nicht auf Amazon verkauft werden, nur Produkte über 20 € gehen an Marktplatz X, der US-Shop bekommt nur Produkte mit englischem Inhalt, das Großhandelsportal schließt eingestellte Produkte aus, ein Handelspartner bekommt nur sein Eigenmarkensortiment.
PIMSuite definiert automatisch, welche Produkte zu welchem Kanal gehören, basierend auf Regelbedingungen:
- Marke, Status, Produktfamilie, Taxonomiekategorie
- Preisbereich, Attributwert
- EAN vorhanden/nicht vorhanden
- benutzerdefinierte Attributbedingungen
Kombiniert Bedingungen mit UND/ODER-Logik. Produkte, die die Regeln erfüllen, werden automatisch in den Exportpool des Kanals aufgenommen.
Kanalauswahl ist nicht dasselbe wie Kanalbereitschaft
Ein Produkt kann für Amazon ausgewählt sein, ohne für Amazon bereit zu sein:
Für Amazon ausgewählt: ja
Bereit:
✓ Titel
✓ Preis
✓ EAN
✗ erforderliches Größenattribut
✗ Marktplatz-Kategorie
Die Regelkollektionen oben lösen die Auswahlfrage. Die Bereitschaftsfrage ist etwas anderes: Erfüllt der Datensatz die Pflichtfelder genau dieses Kanals? PIMSuite verfolgt die Vollständigkeit heute pro Sprache über den gesamten Katalog, sodass ihr vor dem Export filtern könnt, was noch bearbeitet werden muss. Eine Vollständigkeitsbewertung, die speziell auf die Pflichtattribute eines einzelnen Kanals bezogen ist, ist für die Roadmap vorgesehen, aber noch nicht verfügbar.
Kanalspezifische Überschreibungen
Manche Kanäle brauchen einen anderen Produktnamen oder eine andere Beschreibung - keine Übersetzung, sondern eine wirklich andere Positionierung. Ein Beispiel:
Kanonischer Titel: "Bosch Professional GSR 18V-55 Akku-Bohrschrauber"
B2B-Portal: "GSR 18V-55, 18 V, solo"
Endkundenshop: "Bosch Professional GSR 18V-55 Akku-Bohrschrauber ohne Akku"
Marktplatz mit Zeichenlimit: "Bosch GSR 18V-55 18V Bohrschrauber"
Dasselbe Produkt, unterschiedlicher Kanalkontext. PIMSuite unterstützt kanalspezifische Überschreibungen für jedes Textattribut, sodass ihr anpassen könnt, ohne eure Stammdaten zu duplizieren. Das ist getrennt von der sprachspezifischen Lokalisierung - beides lässt sich kombinieren, es gibt aber heute kein formal dokumentiertes Rangfolgemodell, das beschreibt, wie kanonischer Wert, Sprachversion und Kanal-Override zusammen priorisiert werden, wenn mehrere gleichzeitig zutreffen könnten.
Multi-Channel vs. Omnichannel
Multi-Channel heißt: über mehrere Kanäle verkaufen bzw. veröffentlichen. Omnichannel heißt: das Kundenerlebnis und die Prozesse sind kanalübergreifend verbunden.
Ein PIM unterstützt vor allem das Erste, indem es konsistente Produktdaten liefert. Es kann Infrastruktur für Omnichannel sein, macht ein Geschäft aber nicht automatisch omnichannel-fähig.
Syndizierung vs. Integration
Syndizierung transformiert Produktdatensätze und verteilt sie an Zielsysteme. Integration ist oft breiter und bidirektional - Bestand, Bestellungen, Kunden, Preise, Statusrückmeldungen.
PIMSuites Shopify-Sync liegt näher an einer Integration als an einem statischen Export: Er läuft wiederkehrend und hält Shopify mit dem PIM-Datensatz synchron, statt einmalig eine Datei zu übergeben.
Push, Feed und API
Push - PIMSuite sendet Daten aktiv an ein Zielsystem, etwa Shopify.
Feed/Export - das Zielsystem liest periodisch eine bereitgestellte Datei (CSV/XML/JSON).
Pull/API - ein Partner ruft aktuelle Produktdaten selbst über die API ab.
PIMSuite deckt alle drei Modelle ab: Shopify-Sync als Push-artige Integration, Exportdateien als Feed, und die REST-API für Pull-Zugriff.
Vollsynchronisation vs. Delta-Sync
Statt bei jedem Abruf 100.000 Produkte neu herunterzuladen, liefert products:read mit Delta-Sync nur das, was sich seit einem Zeitstempel geändert hat - etwa 87 statt 100.000 Datensätze. Das reduziert Datenverkehr, Verarbeitungsaufwand und Last auf der empfangenden Seite erheblich, gerade bei häufigen Synchronisationszyklen.
Was eine belastbare Kanalanbindung zusätzlich braucht
Wenn ein Marktplatz 27 von 1.000 Produkten ablehnt, muss ein System im Prinzip beantworten können: Welche genau sind fehlgeschlagen? Warum? Automatisch erneut versuchen? Blockiert ein fehlerhaftes Produkt den gesamten Export? PIMSuites Exporthistorie hält die fünf letzten Exportläufe pro Kanal mit Zeitstempel und einem "Letzten Export herunterladen"-Link vor - eine detaillierte Fehlerrückmeldung pro Produkt, automatisches Retry oder das erneute Herunterladen älterer Exporte per ID sind heute nicht Teil der Funktion.
Exporthistorie als Nachvollziehbarkeit
Die eigentlich nützliche Frage lautet oft: Was genau haben wir diesem Händler gestern geschickt? Das ist unschätzbar wertvoll, wenn jemand meldet: "Euer Feed hat den Preis verändert." PIMSuites Exporthistorie mit Zeitstempel und Download-Link hilft dabei, den zuletzt gesendeten Stand zu rekonstruieren, auch wenn eine vollständige Diff- oder Wiederherstellungsfunktion für ältere Läufe noch nicht existiert.
Marktplatzanforderungen als Vertrag
Ein nützliches Denkmodell: Jedes Zielsystem hat einen Datenvertrag.
Erforderlich:
Titel
GTIN
Preis
Kategorie
Marke
Bedingt:
Batterietyp, wenn Batterie_enthalten = ja
Erlaubt:
Beschreibung <= X Zeichen
Die Mapping-Ebene ist dann ein Adapter zwischen eurem kanonischen Produktmodell und dem Vertrag jedes einzelnen Kanals.
Beispiel: ein Produkt, vier Kanäle
Ein Hersteller verkauft über den eigenen Shopify-Shop, Amazon, einen B2B-Distributoren-Feed und ein Partnerportal. Ein SKU hat einen kanonischen technischen Datensatz. Aber:
Shopify braucht einen Marketing-Titel und die volle Bildergalerie.
Amazon braucht die Marktplatz-Kategorie und Amazon-spezifische Bulletpoints.
Distributor braucht eine kurze Beschreibung, den Großhandelspreis und ein CSV-Format.
Partnerportal braucht sämtliche technischen Assets.
Genau dafür existieren Attributzuordnung, Werttransformation, kanalspezifische Überschreibungen und Kollektionsregeln zusammen.
Shopify-Integration
Shopify-Sync ist eingebaut: Ordnet eure PIMSuite-Attribute den Shopify-Feldern zu, definiert eure Kollektionsregeln und veröffentlicht. Produktupdates in PIMSuite werden im nächsten Synchronisierungszyklus in Shopify übernommen.
Öffentliche REST-API
Für Kanäle, die nicht durch integrierte Verbindungen abgedeckt sind, bietet PIMSuite eine öffentliche REST-API mit bereichsbezogenen Schlüsseln:
schema:read- Zugriff auf Attribut- und Familiendefinitionenproducts:read- Produktdaten mit Delta-Sync abfragen (Änderungen seit einem Zeitstempel)products:write- Produkte programmatisch erstellen oder aktualisieren
API-Schlüssel unterstützen Ablaufdaten für zeitlich begrenzten Partnerzugriff.
Wie PIMSuite das heute umsetzt
PIMSuite bildet ein kanonisches Produktmodell über Attributzuordnung, neun integrierte Werttransformationen und Vokabularmapping auf beliebige Kanalschemata ab. Regelbasierte Kollektionen entscheiden automatisch, welche Produkte in welchen Kanal gehören; kanalspezifische Überschreibungen erlauben abweichende Positionierung ohne Datenduplizierung. Shopify-Sync läuft als eingebaute Integration, weitere Kanäle lassen sich über die REST-API mit Delta-Sync anbinden. Was heute bewusst noch fehlt - formelbasierte Kanaltransformationen, kanalspezifische Bereitschaftsbewertung, detaillierte Export-Fehlerrückmeldung - ist oben ausdrücklich als Roadmap gekennzeichnet, nicht stillschweigend vorausgesetzt.