Produktdaten-Systeme, die wirklich funktionieren: Vom ERP zum Kanal

Das Produktdaten-Problem, über das keiner redet

Produktdaten sehen in einem Spreadsheet einfach aus. Name, Beschreibung, Preis, Bild. Dann kommt die Realität. Du hast 50.000 Produkte mit 200 Attributen, in 12 Sprachen, aus 3 Quellsystemen, verteilt auf 5 Ausgabekanäle, und die Datenqualität ist überall inkonsistent.

Das eigentliche Problem ist nicht das Speichern von Produktdaten. Das kann jede Datenbank. Das eigentliche Problem ist die Pipeline: wie Daten von Quellsystemen über Anreicherung zu Ausgabekanälen fließen, mit Validierung auf jeder Stufe und unterschiedlichen Formaten für jedes Ziel.

Wir haben Produktdaten-Systeme für B2B-Hersteller mit komplexen Klassifikationshierarchien, Multi-Locale-Content, ERP-Integration und Multi-Channel-Output (Web, Suche, Marktplatz, Export) entworfen. Dieser Artikel behandelt die Architekturmuster. Für PIM-spezifische Implementierung siehe unseren PIM-Implementierung Guide. Für Pimcore-Workflow-Muster siehe unseren Pimcore-Workflow Guide.

Die Pipeline: Quelle bis Kanal

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   QUELLEN     │     │   MASTER      │     │   KANÄLE      │
│               │     │               │     │               │
│  ERP/SAP     │────▶│  PIM-System   │────▶│  Website      │
│  Lieferanten │     │  (Pimcore,    │     │  Suchindex    │
│  Spreadsheets│     │   Akeneo)     │     │  Marktplatz   │
│  Manuelle    │     │               │     │  Print/PDF    │
│  Eingabe     │     │  Anreichern   │     │  Partner-API  │
│              │     │  Validieren   │     │  Daten-Feed   │
│              │     │  Freigeben    │     │               │
└──────────────┘     └──────────────┘     └──────────────┘

Quell-Schicht

Produkte gelangen aus verschiedenen Quellen ins System. Jede Quelle hat unterschiedliche Datenqualität, verschiedene Formate und andere Update-Frequenzen.

Die Import-Schicht muss Folgendes bewältigen: Feld-Mapping (der Lieferant nennt es "item_name", das ERP nennt es "MATNR"), Datentransformation (Preis in EUR zu Cent), Deduplizierung (dasselbe Produkt aus zwei Quellen) und Konfliktlösung (welche Quelle gewinnt für welches Feld).

Genau dieses Problem löst unser Vendure Data Hub Plugin mit 9 Extractors, 61 Transform-Operatoren und konfigurierbarem Feld-Mapping.

Master-Schicht (PIM)

Das PIM ist die Single Source of Truth für Produktdaten. Jedes Feld hat genau einen autoritativen Wert. Jede Änderung ist versioniert. Jedes Produkt durchläuft einen redaktionellen Workflow vor der Veröffentlichung.

Zentrale PIM-Aufgaben:

• Datenanreicherung: Beschreibungen, Bilder, Übersetzungen hinzufügen, die nicht aus dem ERP kommen
• Klassifikation: Produkte hierarchischen Kategorien mit typisierten Attributen zuordnen
• Validierung: Sicherstellen, dass Pflichtfelder vor der Veröffentlichung ausgefüllt sind
• Workflow: Redaktionelle Prüfung und Freigabe, bevor Daten die Ausgabekanäle erreichen
• Versionierung: Jede Änderung nachverfolgen, Draft-Bearbeitung ohne Auswirkung auf Live-Daten

Kanal-Schicht

Jeder Ausgabekanal braucht Produktdaten in einem anderen Format:

Dieselben Produktdaten, unterschiedlich transformiert für jeden Kanal. Das PIM speichert die Master-Daten. Die Distributionsschicht transformiert und liefert.

Klassifikationssysteme

Produkte haben Attribute. Ein Schuh hat Größe, Farbe, Material und Sohlentyp. Eine Armatur hat Durchflussrate, Anschlusstyp, Oberfläche und Zertifizierung. Ein Server hat CPU, RAM, Speicher und Höheneinheiten.

Flache Attribute vs Classification Store

Flache Attribute (Spalten auf der Produkttabelle) funktionieren für einfache Kataloge mit einheitlichen Produkten. Jedes Produkt hat die gleichen Felder.

Classification Stores (dynamisches Key-Value mit Gruppen) funktionieren für diverse Kataloge, bei denen verschiedene Produkttypen unterschiedliche Attribute haben.

Classification Store:
├── Gruppe: Abmessungen
│   ├── Key: width (float, Einheit: mm)
│   ├── Key: height (float, Einheit: mm)
│   └── Key: depth (float, Einheit: mm)
├── Gruppe: Technisch
│   ├── Key: flow_rate (float, Einheit: l/min)
│   ├── Key: pressure (float, Einheit: bar)
│   └── Key: connection_type (select: 3/8", 1/2", 3/4")
├── Gruppe: Zertifizierungen
│   ├── Key: ce_mark (boolean)
│   ├── Key: tuv (boolean)
│   └── Key: energy_label (select: A-G)

Classification Stores skalieren auf Tausende von Attributen ohne Schema-Änderungen. Neue Attribute sind Konfiguration, keine Migration. Aber sie sind schwieriger abzufragen (Key-Value-Lookups statt Spaltenzugriff) und schwieriger zu validieren (das Schema ist dynamisch).

In Pimcore bietet der Classification Store diese Fähigkeit out of the box, mit lokalisierten Werten, gruppenbasierter Organisation und Admin-UI-Integration.

Variantenmanagement

Produkte mit Varianten (Größe, Farbe, Konfiguration) sind die Hauptursache für Datenkomplexität.

Variantenarchitektur

Produkt (Elternobjekt)
├── name: "Running Shoe Pro"
├── description: "..."
├── brand: "..."
├── images: [hero.jpg, detail.jpg]
│
├── Variante: Größe 40, Schwarz
│   ├── sku: "RSP-40-BLK"
│   ├── price: 12900  (Cent)
│   ├── stock: 15
│   └── ean: "4012345678901"
│
├── Variante: Größe 40, Weiß
│   ├── sku: "RSP-40-WHT"
│   ├── price: 12900
│   ├── stock: 8
│   └── ean: "4012345678902"
│
└── Variante: Größe 42, Schwarz
    ├── sku: "RSP-42-BLK"
    ├── price: 12900
    ├── stock: 0  (ausverkauft)
    └── ean: "4012345678903"

Vererbte vs variantenspezifische Daten:

• Vererbt (vom Elternobjekt): Name, Beschreibung, Marke, Kategorie, gemeinsame Bilder
• Variantenspezifisch: SKU, Preis, Lagerbestand, EAN, Größe, Farbe, variantenspezifische Bilder

Das Vererbungsmodell reduziert Duplizierung. Ändere die Produktbeschreibung einmal, sie aktualisiert sich für alle Varianten. Aber variantenspezifische Überschreibungen müssen möglich sein (unterschiedlicher Preis pro Größe, unterschiedliches Bild pro Farbe).

Die kombinatorische Explosion

Ein Produkt mit 5 Größen und 8 Farben hat 40 Varianten. Füge 3 Materialien hinzu und du hast 120. Füge 2 Weiten hinzu und du hast 240. Die meisten dieser Kombinationen existieren nicht als echte Produkte.

Lösungen:

• Nur explizite Varianten: Erstelle nur die Kombinationen, die tatsächlich existieren. Keine Auto-Generierung.
• Verfügbarkeitsmatrix: Definiere welche Kombinationen gültig sind. Auto-generiere nur gültige.
• Virtuelle Varianten: Berechne zur Abfragezeit aus Attribut-Sets. Speichere keine einzelnen Datensätze.

Asset-Pipeline

Produktbilder, technische Zeichnungen, PDFs und 3D-Modelle brauchen ihre eigene Pipeline.

Upload/Import
  │
  ├── Formatvalidierung (Typ, Größe, Auflösung)
  ├── Metadaten-Extraktion (EXIF, Dimensionen)
  ├── Thumbnail-Generierung (mehrere Größen)
  ├── CDN-Distribution
  └── Zuordnung zu Produkt/Variante

Asset-Herausforderungen

Speziell für Pimcore haben wir einen Performance-Bug dokumentiert, bei dem Asset-Dimensionsabfragen bei jedem Seitenaufruf Remote-Storage-I/O auslösen. Der Fix ist in unserem Pimcore-Upgrade Guide beschrieben.

Multi-Channel-Distribution

Event-gesteuerte Distribution

Wenn ein Produkt im PIM veröffentlicht wird, lösen Events die Distribution an jeden Kanal aus:

// PIM veröffentlicht Produkt -> Events lösen Kanal-Updates aus
eventBus.on('product.published', async (product) => {
    await Promise.allSettled([
        searchIndexer.index(product),           // Suche aktualisieren
        feedGenerator.queue(product),            // Für Marktplatz-Feeds einreihen
        cacheInvalidator.invalidate(product.id), // Website-Cache invalidieren
        partnerApi.notify(product.id),           // Partner-Systeme benachrichtigen
    ]);
});

Jeder Kanal-Transformer konvertiert die Master-Daten ins kanalspezifische Format:

// Website: vollständige Daten mit SEO-Feldern
function toWebProduct(product: PimProduct): WebProduct {
    return {
        slug: product.slug,
        name: product.name,
        description: product.description,
        seoTitle: product.seoTitle || product.name,
        seoDescription: product.seoDescription || truncate(product.description, 160),
        images: product.images.map(img => ({
            url: cdn.getUrl(img, 'large'),
            alt: img.alt || product.name,
        })),
        variants: product.variants.filter(v => v.active),
        // ... vollständige Produktdaten
    };
}

// Marktplatz-Feed: plattformspezifisches Format
function toGoogleMerchantItem(product: PimProduct, variant: PimVariant): MerchantItem {
    return {
        id: variant.sku,
        title: `${product.name} - ${variant.size} ${variant.color}`,
        description: stripHtml(product.description),
        link: `https://shop.example.com/p/${product.slug}`,
        image_link: cdn.getUrl(product.images[0], 'large'),
        price: `${(variant.price / 100).toFixed(2)} EUR`,
        availability: variant.stock > 0 ? 'in_stock' : 'out_of_stock',
        brand: product.brand,
        gtin: variant.ean,
        condition: 'new',
    };
}

Datenqualität

Automatisierte Validierung

interface ValidationRule {
    field: string;
    check: (value: any, product: Product) => boolean;
    message: string;
    severity: 'error' | 'warning';
}

const VALIDATION_RULES: ValidationRule[] = [
    { field: 'name', check: (v) => v && v.length > 3, message: 'Name muss mindestens 3 Zeichen lang sein', severity: 'error' },
    { field: 'description', check: (v) => v && v.length > 50, message: 'Beschreibung sollte mindestens 50 Zeichen haben', severity: 'warning' },
    { field: 'images', check: (v) => v && v.length > 0, message: 'Mindestens ein Bild erforderlich', severity: 'error' },
    { field: 'price', check: (v) => v && v > 0, message: 'Preis muss positiv sein', severity: 'error' },
    { field: 'ean', check: (v) => !v || isValidEan(v), message: 'Ungültiges EAN-Format', severity: 'error' },
    { field: 'categories', check: (v) => v && v.length > 0, message: 'Mindestens eine Kategorie erforderlich', severity: 'error' },
];

Validierung vor der Veröffentlichung durchführen. Bei Fehlern die Veröffentlichung blockieren. Warnungen anzeigen, aber Veröffentlichung erlauben. Datenqualitäts-Scores pro Produkt, pro Kategorie und pro Lieferant tracken.

Häufige Fallstricke

1. Keine Single Source of Truth. Wenn dieselben Produktdaten im ERP, im PIM und im Commerce-System leben ohne klaren Master, sind Konflikte unvermeidlich.

2. ERP als PIM. ERPs speichern operative Daten (SKU, Preis, Lagerbestand). Sie können keinen Rich Content verwalten (Beschreibungen, Bilder, Übersetzungen). Versuch es gar nicht erst.

3. Keine Feld-Ownership. Ohne klare Regeln, welche Quelle welches Feld besitzt, überschreiben Imports die manuelle Anreicherung. Siehe unseren Pimcore-Workflow Guide für das Field-Ownership-Muster.

4. Gleiches Format für alle Kanäle. Jeder Kanal braucht andere Daten. Ein Google-Merchant-Feed und eine Website-API haben unterschiedliche Felder, Formate und Update-Frequenzen.

5. Keine Validierung vor Veröffentlichung. Produkte gehen mit fehlenden Bildern, leeren Beschreibungen oder ungültigen EANs live. Automatische Validierung verhindert das.

6. Variantenkomplexität ignorieren. Automatisches Generieren aller möglichen Kombinationen erzeugt Tausende von Phantomvarianten. Erstelle nur echte, verfügbare Kombinationen.

Zentrale Erkenntnisse

• Die Pipeline ist die Architektur. Quelle zu Master zu Kanal. Jede Stufe hat andere Verantwortlichkeiten, andere Datenformate und andere Qualitätsanforderungen.

• Das PIM ist die Single Source of Truth. Nicht das ERP, nicht das Commerce-System, nicht das Spreadsheet. Ein autoritativer Master mit Versionierung und Workflow.

• Classification Stores bewältigen Attribut-Vielfalt. Wenn verschiedene Produkttypen verschiedene Attribute haben, skaliert dynamisches Key-Value mit Gruppen besser als feste Spalten.

• Jeder Kanal bekommt seine eigene Transformation. Website, Suche, Marktplatz, Print und Partner-API brauchen alle unterschiedliche Formate aus denselben Master-Daten.

• Datenqualität ist ein System, kein Einzelschritt. Automatisierte Validierung, Qualitäts-Scores, Blockierregeln bei Veröffentlichung. Kontinuierlich, nicht einmalig.

Wir entwerfen Produktdaten-Systeme als Teil unserer E-Commerce- und Data-Engineering-Praxis. Wenn du Hilfe bei PIM-Architektur oder Produktdaten-Pipelines brauchst, sprich mit unserem Team oder fordere ein Angebot an.