Flatfile-Automatisierung: Produktangebote auf mehreren Amazon-Marktplätzen verwalten
Amazons Flatfile-System ist die vollständigste Schnittstelle zur Verwaltung großer Mengen von Produktangeboten in einem umfangreichen Katalog – und für den Betrieb auf mehreren Marktplätzen eine der am schlechtesten dokumentierten. Jeder Marktplatz verwendet eine andere Vorlagenversion, verlangt andere Felder und wendet andere Validierungsregeln an, oft für dasselbe Produkt in derselben Kategorie. Produktangebote für zehn Marktplätze aus einer einzigen Produktdatenquelle zu verwalten, erfordert einen systematischen Umgang mit Vorlagenunterschieden, Attributübersetzungen und dem Zyklus aus Hochladen, Validieren und Korrigieren.
Dieser Beitrag beschreibt unseren Flatfile-Workflow für die Katalogverwaltung auf mehreren Marktplätzen: wie sich Vorlagen unterscheiden, wo Automatisierung am meisten bringt und wo manuelle Eingriffe unvermeidbar bleiben.
Was Flatfiles sind
Eine Flatfile ist eine tabulatorgetrennte Vorlage für Produktangebote, mit der Amazon deren Erstellung und Aktualisierung in großen Mengen verarbeitet. Jede Zeile steht für ein Produkt, jede Spalte für ein Attribut. Die Vorlage wird im Bereich Catalog > Add Products via Upload von Seller Central heruntergeladen und legt fest, welche Spalten verpflichtend oder optional sind und welche Werte je Feld zulässig sind.
Das Flatfile-System ist älter als die SP-API Listings Items API und bleibt die wichtigste Schnittstelle für die Bearbeitung großer Datenmengen in Seller Central. Auf API-Seite hat Amazon Flatfile- und XML-Feeds für Produktangebote im März 2024 als veraltet eingestuft und ihre Abschaltung für den 30. Juni 2025 angekündigt. An ihre Stelle treten die JSON-basierte Listings Items API und JSON_LISTINGS_FEED; Flatfile-Uploads über Seller Central waren davon nicht betroffen. Für Verkäufer mit mehr als einigen Dutzend SKUs auf mehreren Marktplätzen ist ein Workflow zur Bearbeitung großer Datenmengen praktisch erforderlich, und in unserem System ist die Flatfile die wichtigste Schnittstelle zur Katalogverwaltung.
Amazons Flatfile-Dokumentation ist allerdings fragmentiert und häufig veraltet. Die aktuellste Spezifikation einer Vorlage ist die Vorlage selbst: frisch heruntergeladen für den konkreten Marktplatz und die betreffende Kategorie. Gespeicherte Vorlagen oder sechs Monate alte Dokumentation sind eine verlässliche Quelle für Upload-Fehler.
Unterschiede zwischen Marktplatzvorlagen
Die strukturellen Unterschiede zwischen Marktplatzvorlagen sind größer, als die meisten Verkäufer beim Einstieg erwarten. Es handelt sich nicht bloß um Übersetzungen derselben Felder.
Die US-Bekleidungsvorlage für eine bestimmte Kategorie kann fünfzig Attributspalten enthalten. Die entsprechende deutsche Vorlage kann sechzig enthalten, darunter Felder ohne US-Entsprechung: etwa bestimmte nach EU-Recht erforderliche Erklärungen zur Chemikalienkonformität oder Anforderungen an Energiekennzeichnungen für bestimmte Produkttypen. Die japanische Vorlage kann Größen- und Farbvarianten anders strukturieren und andere Namen für Variantenthemen verwenden, als die US-Version erkennt.
Auch bei gleichem Feldnamen unterscheiden sich zulässige Werte häufig je nach Marktplatz. Das Feld item_type_keyword akzeptiert auf .com andere Zeichenfolgen als auf .co.uk. Werte für color_name werden gegen eine marktplatzspezifische Liste geprüft. Ein in den USA gültiger Farbname kann in Deutschland oder Japan abgelehnt werden, weil er nicht zu den dort zugelassenen Werten gehört. Der Fehlerbericht erklärt das nicht immer deutlich: Statt eines Hinweises auf die fehlende Zulassung erhalten Sie einen allgemeinen Attributfehler.
Vorlagenversionen ändern sich ohne Ankündigung. Amazon veröffentlicht regelmäßig neue Versionen für Kategorien, ergänzt Pflichtfelder oder kündigt alte Felder ab. Bei einem Upload mit einer veralteten Vorlage kann das Hochladen gelingen, das Produktangebot aber nicht korrekt indiziert werden – oder bestimmte Attribute werden ohne Hinweis ignoriert. Zu Beginn jeder größeren Katalogaktualisierung laden wir neue Vorlagen herunter, statt gespeicherte Versionen erneut zu verwenden.
Größenumrechnung
Bei Bekleidung und Schuhen gehört die Umrechnung von Größensystemen zu den arbeitsintensivsten Teilen der Katalogverwaltung auf mehreren Marktplätzen. US-, EU-, britische und japanische Größensysteme entsprechen einander nicht direkt; auch die Umrechnungstabellen unterscheiden sich je nach Produkttyp.
Ein Damenschuh in US-Größe 8 entspricht auf gängigen Umrechnungstabellen in der Regel UK-Größe 6 und EU-Größe 39 (die Tabellen einzelner Marken können um eine halbe Größe abweichen). Ein Damenhemd in US-Größe Medium kann je nach Größenkonvention der Marke jedoch EU-Größe 38 oder 40 entsprechen. Es gibt keine universelle Zuordnungstabelle. Sinnvoll ist eine zentrale Größenzuordnung je Produkttyp und Marke, geprüft anhand der Größentabelle des jeweiligen Herstellers.
Die Amazon-Felder size_name und size_system müssen gemeinsam korrekt befüllt werden, damit das Produktangebot in den marktplatzspezifischen Größenfiltern richtig erscheint. Wird eine US-Größe im Feld size_name ohne Angabe von size_system hochgeladen, kann sie als unformatierte Zeichenfolge behandelt werden und unserer Erfahrung nach in nach Größe gefilterten Suchergebnissen fehlen. Die Upload-Bestätigung macht das nicht immer deutlich: Das Produktangebot wird erfolgreich erstellt, aber der Größenfilter funktioniert nicht.
Auf dem japanischen Marktplatz unterscheiden sich die Größensysteme vieler Produktkategorien sowohl von europäischen als auch von US-Konventionen. Japanische Bekleidungsgrößen verwenden ein eigenes Zahlensystem, Schuhgrößen ein zentimeterbasiertes System. Das Feld size_map_unit_of_measure war in den japanischen Vorlagen, mit denen wir gearbeitet haben, verpflichtend und fehlte in den US- und EU-Entsprechungen. Bei der marktübergreifenden Wiederverwendung von Vorlagen verursachte das fehlende Feld Verarbeitungsfehler ohne Fehlermeldung. Feldnamen unterscheiden sich je nach Produkttyp und Vorlagenversion; prüfen Sie daher die Spaltenüberschriften und zulässigen Werte in der Vorlage, die Sie tatsächlich herunterladen.
Grenzen für Backend-Keywords
Backend-Keywords – die nicht sichtbaren Suchbegriffe im Feld generic_keyword – unterliegen je nach Marktplatz unterschiedlichen Zeichenlimits. Auch die Art der Begrenzung unterscheidet sich.
Amazon.com begrenzt das kombinierte Feld generic_keyword auf 249 Byte. Auch Amazon.de verwendet ein Byte-Limit. Deutscher Text enthält jedoch mehr Mehrbytezeichen als englischer Text. Eine Keyword-Zeichenfolge, die auf Englisch innerhalb des US-Byte-Limits liegt, kann daher nach der Übersetzung das deutsche Byte-Limit überschreiten. Bei Amazon.co.jp wirken die Grenzen mit der japanischen Zeichenkodierung zusammen: Ein einzelnes Kanji-Zeichen benötigt in UTF-8 drei Byte. Die effektive Keyword-Kapazität für Japanisch ist daher erheblich geringer, als die Byte-Grenze bei einer Betrachtung in lateinischen Zeichen vermuten lässt.
Tatsächlich gehört das Keyword-Limit jedoch zu den weniger einflussreichen Faktoren für die Leistung von Produktangeboten auf mehreren Marktplätzen. Nach unserer Erfahrung bringt die Überoptimierung von Backend-Keywords – das exakte Ausschöpfen der Byte-Grenze – immer weniger zusätzlichen Nutzen gegenüber einer Optimierung von sichtbarem Titel, Aufzählungspunkten und Beschreibung für natürliches Suchverhalten. Die Byte-Grenzen sind eine einzuhaltende Rahmenbedingung, kein Leistungshebel, der maximiert werden sollte.
Praktisch ist ein marktplatzspezifischer Keyword-Satz je Produkt, der innerhalb der jeweiligen Grenzen bleibt. Die Byte-Anzahl sollte programmatisch statt nach Augenschein geprüft werden. Eine einfache Python-Funktion, die die Keyword-Zeichenfolge kodiert und ihre Byte-Länge mit der Marktplatzgrenze vergleicht, erkennt Kürzungsfehler vor dem Upload.
Der Automatisierungsworkflow
Die zentrale Erkenntnis der Flatfile-Automatisierung: Unterschiede zwischen Marktplätzen sind überwiegend strukturell, nicht inhaltlich. Das Produkt bleibt gleich – Maße, Materialien, Verwendungszweck und wesentliche Merkmale ändern sich nicht. Anders ist nur, wie diese Angaben im Vorlagenformat des jeweiligen Marktplatzes dargestellt werden müssen.
Wir pflegen ein zentrales Produktdatenblatt mit allen Attributen in neutralem Format: Maße metrisch, Größen im ursprünglichen System des Herstellers, Keywords in der Ausgangssprache und Kategorien nach einer neutralen internen Taxonomie. Daraus entstehen marktplatzspezifische Flatfiles über eine Transformationsschicht, die die strukturellen Unterschiede jedes Zielmarktes berücksichtigt.
Diese Transformationsschicht ist ein Skript – bei uns in Python –, das jedes zentrale Attribut der entsprechenden Flatfile-Spalte je Marktplatz zuordnet, Größen umrechnet, die Kategorietaxonomie auf die Kategorienknoten des Marktplatzes abbildet und jedes Feld vor der Dateierzeugung validiert. Felder mit manuellem Prüfbedarf – übersetzte Texte, marktplatzspezifische Compliance-Erklärungen und landesspezifische regulatorische Attribute – werden in der Ausgabe markiert statt automatisch befüllt.
Der Zyklus aus Herunterladen, Bearbeiten und Hochladen ist teilautomatisiert. Downloads erfolgen per Skript über die SP-API Reports API, die GET_FLAT_FILE_OPEN_LISTINGS_DATA und verwandte Berichtstypen bereitstellt. Die Verarbeitung des Downloads, der Abgleich mit dem zentralen Datenblatt und die Erstellung der Upload-Datei sind automatisiert. Der Upload selbst und die Prüfung des Verarbeitungsberichts erfolgen manuell. Automatisierung wäre möglich, aber Fehler bei einem umfangreichen Upload können so teuer sein, dass eine menschliche Prüfung vor der Übermittlung an Amazon angemessen ist.
Häufige Fehlerarten
Upload-Fehler lassen sich in drei Kategorien einteilen: Validierungsfehler, Verarbeitungsfehler und Fehler ohne Fehlermeldung.
Validierungsfehler sind am einfachsten zu erkennen: Der Upload-Bericht nennt ausdrücklich die betroffene Zeile und das fehlerhafte Feld. Häufige Ursachen sind ungültige Werte in Feldern mit festgelegtem Wertebestand (size_name, color_name, item_type_keyword), fehlende Pflichtfelder der jeweiligen Vorlagenversion und überschrittene Byte-Grenzen in Keyword- oder Beschreibungsfeldern.
Verarbeitungsfehler entstehen, wenn die Validierung erfolgreich ist, das Produktangebot aber nicht wie erwartet aktualisiert wird. Häufig sind Fehler in Variantenbeziehungen: eine untergeordnete ASIN ohne passende übergeordnete ASIN oder ein übergeordnetes Angebot mit einem Variantenthema, das nicht zu den Attributen der untergeordneten Variante passt. Auch Konflikte bei Kategorienknoten treten auf, wenn der übermittelte Knoten nicht zur bestehenden Einstufung einer bereits etablierten ASIN passt.
Fehler ohne Fehlermeldung sind am schwersten zu erkennen. Der Upload gelingt und der Verarbeitungsbericht zeigt keine Fehler, aber das Produktangebot funktioniert nicht korrekt: Eine Größe erscheint nicht in den Filtern, ein Suchbegriff wird nicht indiziert oder eine Variantenbeziehung ist im Backend sichtbar, wird in der Shop-Oberfläche jedoch falsch dargestellt. Dafür müssen die aktuellen Angebotsattribute über die Catalog Items API mit den übermittelten Werten verglichen werden; eine Sichtprüfung der Shop-Oberfläche reicht nicht aus.
Der praktische Schutz ist eine Prüfung nach dem Upload: Innerhalb von vierundzwanzig Stunden werden die aktuellen Angebotsdaten jeder betroffenen ASIN per API abgerufen, mit den übermittelten Werten verglichen und Abweichungen markiert. Dieser Schritt ist nicht komplex. Er unterscheidet jedoch eine zuverlässige Katalogverwaltung von einem Prozess, der ständige manuelle Kontrollen braucht, um unerklärte Änderungen zu finden, die kein Fehlerbericht gemeldet hat.
Weiterführende Beiträge
- Amazon FBA auf neue Marktplätze ausweiten: Ein datenbasiertes Bewertungsmodell – das Modell zur Marktauswahl vor Entscheidungen über die Angebotsverwaltung
- Ein Amazon Data Warehouse mit FastAPI und TimescaleDB aufbauen – wie wir Katalogdaten und Leistungsdaten von Produktangeboten speichern und abfragen, um Aktualisierungen zu planen