E-Commerce Internet Marketing: Warum der Produktdatenfeed die eigentliche Steuerzentrale ist

Wer Marketing für einen Onlineshop plant, entscheidet in der Praxis selten über Kanäle. Er entscheidet über Daten. Welcher Artikel überhaupt ausgeliefert wird, mit welchem Preis, welcher Verfügbarkeit und welcher Kennzeichnung, steht nicht in einem Kampagnenplan, sondern im Produktdatensatz. Shopping-Anzeigen und feedbasierte Performance-Max-Kampagnen werden nicht aus einer Keywordliste heraus ausgeliefert, sondern aus den Produktdaten des Merchant Center. Damit ist die Feed-Qualität keine technische Vorstufe des Marketings, sondern sein Betriebssystem.

Daraus folgt eine zweite, ungewohntere Konsequenz: Gesteuert wird sinnvollerweise nicht pro Kanal, sondern pro Sortimentssegment. Ein Artikel mit dünnem Deckungsbeitrag, drei Wochen Lagerreichweite und hoher Retourenquote verdient in jedem Ausgabesystem dieselbe Zurückhaltung. Diese Entscheidung gehört in die Daten, nicht in sechs getrennte Kampagnenoberflächen, in denen sie sechsmal unterschiedlich getroffen wird.

Der Feed ist das Sortiment in Maschinenform

Ein Produktfeed wird häufig als Exportdatei behandelt, die Artikelnummer, Titel, Bild und Preis transportiert. Für den laufenden Betrieb ist das zu eng gedacht. Der Feed ist die standardisierte Übersetzung des Sortiments für Systeme, die das Sortiment nicht kennen. Er ist so gut wie die Quellen dahinter, und die liegen fast immer verteilt:

• Das Shopsystem kennt URL, Verkaufspreis und sichtbare Beschreibung.
• Die Warenwirtschaft liefert Bestand, Lieferstatus und Einkaufspreis.
• Ein PIM hält Varianten, Maße, Materialien und Merkmale.
• Das ERP kennt Beschaffung, Kostenstruktur und Lagerbewegung.
• Das Retourensystem weiß, welche Artikel überdurchschnittlich zurückkommen.
• Herstellerstammdaten oder ein Compliance-System liefern rechtliche Angaben.

Nützlich ist die Trennung in zwei Datenarten. Ausgabedaten beschreiben das Produkt nach außen: Titel, Bild, Preis, Verfügbarkeit, Kennzeichnung. Steuerungsdaten beantworten eine andere Frage, nämlich ob und mit welcher Priorität ein Artikel überhaupt beworben werden soll. Beide entstehen im selben Prozess, aber nur die erste Gruppe gehört vollständig nach draußen. Wer beides vermischt, überträgt entweder vertrauliche Kalkulation an Plattformen oder verliert die wirtschaftliche Steuerung ganz.

Pflichtfelder: das Minimum, das ohne Ausnahme stimmen muss

Welche Felder Pflicht sind, hängt von Zielsystem, Produktart und Verkaufsland ab. Für das Google Merchant Center gehören laut Produktdatenspezifikation unter anderem id, title, description, link, image_link, availability und price zu den grundlegenden Attributen. Diese Liste ist schnell abgehakt und genau deshalb trügerisch: Ein Feed kann alle Pflichtfelder befüllen und trotzdem unbrauchbar sein.

Entscheidend ist die Qualität hinter dem Feld. Die id muss über Exporte, Shop-Releases und Sortimentswechsel hinweg stabil bleiben, sonst verliert jeder Artikel seine Historie. Der Titel muss das Produkt benennen, nicht die interne Kurzbezeichnung aus dem Einkauf. Preis und Verfügbarkeit müssen mit der Landingpage übereinstimmen, und zwar nicht ungefähr: Weicht der Verfügbarkeitsstatus im Feed vom tatsächlichen Status auf der Produktseite ab, führt das zur Ablehnung des Artikels.

Eine Sonderstellung haben eindeutige Produktkennzeichnungen. Hat der Hersteller einem Produkt eine GTIN zugewiesen, ist deren Angabe im Produktdatensatz verpflichtend, und ein fehlender Wert kann die Ablehnung nach sich ziehen. Selbst erfundene Nummern sind keine Lösung, sondern erzeugen später Dubletten und falsche Produktzuordnungen. Für Artikel ohne zugewiesene GTIN, etwa Eigenfertigung oder Maßanfertigung, muss das korrekt kenntlich gemacht werden.

Je nach Sortiment kommen Marke, Zustand, Altersgruppe, Material, Versandgewicht oder Energiedaten hinzu. Pflegen Sie die Pflichtfeldlogik deshalb nicht als statische Checkliste, sondern als Regelwerk entlang von Produktkategorie, Zielland und Empfängersystem.

Datenqualität ist eine Betriebskennzahl, keine Projektaufgabe

Ein Feed kann fehlerfrei übertragen werden und inhaltlich falsch sein. Syntaktische Gültigkeit sagt nichts über Korrektheit aus. Messbar wird Qualität erst entlang mehrerer Dimensionen:

• Vollständigkeit: Sind alle benötigten Felder für alle relevanten Artikel gefüllt?
• Aktualität: Entsprechen Preis, Bestand und Lieferstatus dem aktuellen Shopzustand?
• Konsistenz: Stimmen Feed, Produktseite, Warenwirtschaft und Checkout überein?
• Eindeutigkeit: Sind IDs, GTINs und Variantenbeziehungen sauber gepflegt?
• Aussagekraft: Beschreiben Titel und Merkmale das konkrete Produkt verständlich?
• Regelkonformität: Erfüllen die Datensätze technische, rechtliche und plattformseitige Vorgaben?

Der typische Fehler ist, die Ablehnungsquote als Qualitätsmaß zu nehmen. Sie zeigt nur, was ein Empfänger zurückweist. Sie zeigt nicht den angenommenen Artikel mit nichtssagendem Titel, fehlendem Variantenmerkmal oder einem Bestand, der seit acht Wochen niemanden mehr interessiert.

Eine belastbare Übersicht erfasst deshalb zusätzlich Warnungen, fehlende Kernattribute, Preis- und Bestandsabweichungen gegen den Shop sowie das Alter der letzten erfolgreichen Verarbeitung je Quelle. Und sie gewichtet nach Umsatzpotenzial: Ein Fehler am Kernprodukt wiegt schwerer als hundert Fehler an dauerhaft nicht lieferbaren Randartikeln.

Aktualisierung nach Veränderungsrisiko, nicht nach Kalender

Google verlangt, dass Produktdaten im Merchant Center mindestens alle 30 Tage aktualisiert werden, sonst laufen die Artikel ab und werden nicht mehr ausgeliefert. Diese Frist ist eine technische Untergrenze, kein Rhythmus. Für einen aktiven Shop ist ein Monatsexport zu langsam, weil sich Preis und Bestand mehrmals täglich ändern können.

Der Takt gehört deshalb an das einzelne Feld, nicht an die Datei:

• Bestand, Verfügbarkeit und Verkaufspreis brauchen kurze Intervalle oder ereignisbasierte Aktualisierung.
• Aktionspreise müssen pünktlich starten und nach Aktionsende zuverlässig zurückgesetzt werden.
• Titel, Beschreibungen und Merkmale folgen Änderungen am Produktstamm.
• GTIN, Marke und Herstellerangaben ändern sich selten, müssen aber bei Erstanlage validiert werden.
• Deckungsbeitrag und Lagerreichweite werden so oft neu berechnet, wie Einkaufspreise und Absatz die Steuerung tatsächlich verschieben.

Robuste Setups kombinieren einen vollständigen Regelexport mit schnellen Teilaktualisierungen für volatile Felder. Überwachen Sie dabei nicht den Export, sondern die Quelle: Ein Job kann jede Stunde erfolgreich laufen und trotzdem seit gestern denselben veralteten Bestand ausliefern, weil die Warenwirtschaft nichts Neues geliefert hat. Ein Zeitstempel pro Quelle beantwortet diese Frage, ein grüner Job-Status nicht.

Segmente statt pauschaler Sortimentsbehandlung

Wenn die Auslieferung aus den Produktdaten kommt, verlagert sich die Steuerung in die Struktur des Sortiments. Vier kaufmännische Merkmale tragen diese Entscheidung.

Deckungsbeitrag. Umsatz sagt wenig über Vermarktungsfähigkeit. Ein hochpreisiger Artikel kann nach Wareneinsatz, Versand, Zahlungsgebühren und erwarteten Retourenkosten kaum Spielraum behalten. Der Deckungsbeitrag gehört deshalb als Steuerungsmerkmal in die Datenlogik, nach außen aber nur als Klasse: db_hoch, db_mittel, db_niedrig. So bleibt die Kalkulation im Haus und die Priorität trotzdem maschinenlesbar.

Lagerreichweite. Hoher Bestand ist kein Qualitätssignal. Maßgeblich ist das Verhältnis von Bestand zu erwarteter Absatzgeschwindigkeit, ergänzt um Wiederbeschaffungszeit und Mindestbestellmenge. Vier Zustände reichen meist aus: Restbestand, gesunder Bestand, drohender Ausverkauf, Überbestand. Jeder davon verlangt ein anderes Verhalten, und keiner davon steht im Feed, wenn ihn niemand berechnet.

Saisonalität. Saisonartikel brauchen Phasen statt eines Datums: Vorlauf, Hauptsaison, Abverkauf, Saisonende. Wichtig ist, dass dieser Kalender an einer Stelle gepflegt wird. Sobald mehrere Ausgabesysteme eigene Saisonlogiken führen, entstehen widersprüchliche Aktionen und verspätete Sortimentswechsel, die niemand mehr zuordnen kann.

Retourenquote. Eine hohe Quote mindert den realen Wert eines Verkaufs und ist zugleich ein Hinweis auf schlechte Produktdaten. Unklare Größenangaben, beschönigende Bilder oder fehlende Materialangaben erzeugen Erwartungen, die der Artikel nicht hält. Behandeln Sie die Quote deshalb nicht nur als Ausschlusskriterium, sondern als Auftrag an die Datenpflege, und werten Sie sie nach Retourengrund, Produktgruppe und ausreichender Fallzahl aus.

Aus der Kombination entstehen handhabbare Segmente, etwa margenstarke Kernartikel mit gesunder Reichweite oder Saisonware mit Überbestand und niedriger Retourenquote. Übergeben wird an die Ausgabesysteme nur das stabile Label. Die Geschäftsregel bleibt zentral, änderbar an einer Stelle, nachvollziehbar für alle.

Rechtliche Angaben sind Stammdaten, kein Textbaustein

Pflichtangaben gehören strukturiert in den Produktdatensatz, nicht als Freitext an das Ende der Produktbeschreibung. Sonst sind sie weder prüfbar noch über mehrere Ausgabekanäle hinweg konsistent.

Seit dem 13. Dezember 2024 gilt die EU-Produktsicherheitsverordnung (EU) 2023/988. Artikel 19 verpflichtet Online-Anbieter, bei jedem Angebot Herstellerangaben, Kontaktdaten der verantwortlichen Person, die Produktkennzeichnung sowie Sicherheitshinweise anzugeben. Das sind sechs bis acht zusätzliche Felder pro Artikel, die eine Quelle, einen Verantwortlichen und eine Prüfregel brauchen.

Auch Preisaktionen sind ein Datenthema. Nach Paragraf 11 der Preisangabenverordnung ist bei einer Preisermäßigung der niedrigste Gesamtpreis der letzten 30 Tage anzugeben. Ein Feld für den aktuellen Preis und eines für den Streichpreis genügen dafür nicht. Nötig ist eine Preishistorie, aus der der Referenzpreis regelkonform berechnet wird, statt ihn manuell zu setzen.

Datenpflichten gibt es außerdem auf dem Rückweg: Werbetreibende im EWR müssen seit März 2024 Consent Mode v2 implementiert haben, um Remarketing- und Zielgruppenfunktionen in Google Ads weiter zu nutzen. Der Produktdatenstrom nach außen und der Messdatenstrom zurück unterliegen also derselben Logik, nämlich gepflegter Herkunft und dokumentierter Regel.

Wer die Feed-Hygiene verantwortet

Feed-Pflege scheitert selten an Werkzeugen und fast immer an verteilter Zuständigkeit. Das Marketing sieht die Ablehnung, darf aber keine Stammdaten ändern. Der Einkauf kennt das Produkt, verantwortet aber nicht die Ausleitung. Die IT betreibt die Schnittstelle und beurteilt keine rechtlichen Inhalte.

Es braucht deshalb einen benannten Feed-Owner. Diese Rolle pflegt nicht alle Quelldaten selbst, verantwortet aber Qualitätsziele, Monitoring, Fehlerpriorisierung und Dokumentation. Darunter liegen klare Zuständigkeiten je Datenbereich: Produktmanagement für Stamm- und Herstellerdaten, Operations für Bestand und Lieferstatus, Pricing für Preise, Aktionen und Preishistorie, Legal für sicherheits- und preisrechtliche Vorgaben, Data Engineering für Schnittstellen und Transformationen, Marketing für die benötigten Sortimentssegmente und die Rückmeldung von Plattformfehlern.

Verbindlich wird das durch drei Dinge: automatische Prüfungen vor dem Versand, Alarme mit fester Bearbeitungsfrist für kritische Abweichungen und ein Protokoll, das zeigt, welche Quelle einen Wert geliefert und welche Transformation ihn verändert hat. Regeländerungen gehören vorher gegen eine Teilmenge getestet, nicht gegen den vollständigen Feed.

So wird E-Commerce Internet Marketing zu einem kontrollierbaren Datenprozess: Im Zentrum steht kein Kanal, sondern ein Produktdatenbestand, der technische Anforderungen, rechtliche Pflichten und wirtschaftliche Prioritäten an einer Stelle zusammenführt.