Inhalte via Flat Files hochladen — der Massenweg, der die Einzelbearbeitungs-UI schlägt.

Episode 09 behandelte die vier Upload-Pfade, die Seller Central bietet, und die Beitragsregeln, die entscheiden, welche Version eines Feldes gewinnt. Von diesen vier Pfaden verdient sich der Inventar-Flat-File eine eigene Episode. Er ist der einzige Pfad, der Dutzende oder Hunderte von ASINs in einer einzigen Einreichung aktualisiert, der einzige Ort, an dem eine kleine Anzahl von Attributen überhaupt bearbeitet werden kann, und der einzige Upload-Modus, dessen Feed-Verarbeitungsreport dir Zeile für Zeile sagt, welche Zeile fehlgeschlagen ist und welche Spalte und Regel genau die Ursache war.

Der Flat File ist auch der Upload-Pfad, der bei falscher Anwendung am wahrscheinlichsten Schäden verursacht. Übermittle einen Full-Update-Feed mit leeren Zellen, wo Live-Werte existieren, und Amazon löscht pflichtbewusst jedes dieser Felder. Übermittle ihn ohne Kenntnis der erforderlichen Spalten des Kategorie-Templates und der gesamte Feed wird abgelehnt. Diese Episode ist das Sicherheitsgeländer, das den Flat File von einer Gefahrenquelle zum sichersten Massenweg in Seller Central macht.

Das richtige Template herunterladen — kategoriespezifisch, nicht generisch

Es gibt keinen einzigen „Flat File.“ Amazon veröffentlicht ein anderes Inventar-Template für jede Produktkategorie, und die Spalten unterscheiden sich — ein Shoes-Template hat Dutzende von Attributen, die ein Kitchen-Template nicht hat, und umgekehrt. Das falsche Template verwirft entweder deine Attributwerte stillschweigend (keine Spalte zum Eintragen) oder lehnt den Feed direkt beim Schema-Validierungsschritt ab.

Der Pfad in Seller Central: Catalog → Add Products via Upload → Download an Inventory File. Wähle den Marktplatz und navigiere dann den Kategorie- Baum bis zum Leaf Node, der zu deinem Produkt passt. Das Template, das auf die Festplatte kommt, ist eine Excel-Arbeitsmappe mit mehreren Arbeitsblättern:

• Instructions — einmal pro Kategorie lesen; hier dokumentiert Amazon Attributanforderungen, Byte-Limits und die Enum-Werte, die manche Felder erfordern.
• Data Definitions — jede Spalte, ihr Datentyp, ihre zulässigen Werte und ob sie erforderlich, bevorzugt oder optional ist. Dieses Arbeitsblatt ist die einzige Wahrheitsquelle, wenn ein Feed die Validierung nicht besteht.
• Valid Values — die Auswahllisten für jedes Enum-Feld (Item Type Keyword, Zielgeschlecht, Ursprungsland-Codes, Compliance-Flags). Freitext-Werte in einer Enum-Spalte lehnen die Zeile ab.
• Template — das Arbeitsblatt, das du tatsächlich ausfüllst. Die Kopfzeile ist fest; benenne, ordne oder lösche keine Spalten.

Speichere das Originaltemplate unverändert als Master- Kopie. Jeder Feed bekommt ein Duplikat, benannt mit Datum und Marktplatz.

Die vier Spalten, die jeden Feed entscheiden

Das Template-Arbeitsblatt hat Dutzende oder Hunderte von Spalten. Vier davon entscheiden, was der Feed tatsächlich bewirkt:

• SKU (item_sku) — deine interne Kennung. In jeder Zeile erforderlich. Das ist der Schlüssel, den Amazon verwendet, um das bestehende Listing in deinem Katalog zu finden und zu entscheiden, ob erstellt oder aktualisiert wird.
• Product ID + Product ID Type (external_product_id + external_product_id_type) — GTIN / EAN / UPC / ASIN und der passende Typ-Code. Erforderlich beim Erstellen eines neuen Angebots oder beim Zuordnen zu einer bestehenden ASIN. Optional bei einer reinen Inhaltsaktualisierung für eine SKU, die bereits existiert.
• Update / Delete (update_delete) — steuert die Absicht der Zeile. Update erstellt das Listing falls fehlend und überschreibt jedes in der Zeile vorhandene Feld. PartialUpdate berührt nur die Zellen, die du tatsächlich ausgefüllt hast — jede leere Zelle wird im Live-Listing unverändert gelassen. Delete entfernt dein Angebot von der ASIN. Die Standardeinstellung „Update“ ist die gefährlichste Voreinstellung in diesem gesamten Template; wechsle sie bewusst.
• Feed Product Type (feed_product_type) — die Kategorie-Leaf-Kennung. Bei Erstellungen erforderlich und bei Aktualisierungen, die durch das Kategorieschema gesperrte Attribute ändern. Falscher Wert hier lehnt die gesamte Zeile ab.

Update vs. PartialUpdate — die Zelle, die Katastrophen verhindert

Der Standardmodus eines Inventar-Feeds ist Update: jede Spalte, die das Template definiert, wird als maßgeblich behandelt, und jede leere Zelle in einer Zeile wird behandelt als „Amazon soll dieses Feld im Live-Listing löschen." Bei einer brandneuen SKU ist das in Ordnung — jedes Feld ist in der Zeile. Bei einer Inhaltsauffrischung eines 600- SKU-Portfolios ist es ein Weg, jedes Attribut, jeden Bullet, jeden Suchbegriff oder jeden Bild-Alt-Text zu löschen, den du nicht persönlich in jede Zeile erneut eingetippt hast.

PartialUpdate kehrt die Regel um. Der Feed berührt nur die Zellen, die du ausgefüllt hast; jede leere Zelle wird ignoriert. Verwende es für jeden Feed, der keine Clean-Room-SKU-Erstellung ist. Die Faustregel:

• Neuer SKU-Launch → Update. Jedes Feld ist in der Zeile, jede Zelle ist der neue Live-Wert.
• Auffrischung einer bestehenden SKU → PartialUpdate. Nur die Spalten, die du ändern möchtest, sind ausgefüllt. Alles andere bleibt so, wie es die Live-ASIN hatte.
• Einzel-Attribut-Korrektur über viele ASINs → PartialUpdate. Fülle die SKU, die eine zu korrigierende Spalte, und nichts anderes aus.
• Take-down → Delete. Der Feed- Verarbeitungsreport ist der Beleg.

Die Spaltengruppen, die du tatsächlich ausfüllst

Im Template fallen Spalten in erkennbare Gruppen. Der saubere Workflow ist, sie von oben nach unten auszufüllen statt von links nach rechts:

• Identität — SKU, externe Produkt-ID + Typ, Feed Product Type, Update/Delete-Modus, Markenname, Hersteller.
• Titel und Texte — item_name, bullet_point1..5, product_description, generic_keywords (das 250-Byte- Backend-Feld aus Episode 08).
• Kategorie-Attribute — die Dutzenden kategoriespezifischer Spalten, die der Leaf Node erfordert: Zielgeschlecht, Item Type Keyword, Größensystem, Stofftyp, Kapazität, Passform-Typ, Spannung. Das Data-Definitions-Arbeitsblatt listet, welche pro Kategorie erforderlich vs. bevorzugt sind.
• Bilder — main_image_url plus other_image_url1..8 / swatch_image_url. Vollständige HTTPS- URLs zu öffentlich zugänglichen JPGs, die Amazons Bildspezifikationen entsprechen.
• Preis & Inventar — Standardpreis, Aktionspreis, Aktionsbeginn/-ende, Menge, Fulfillment-Kanal. Oft in einem separaten Preis-/Inventar-Feed statt im Inhalts-Feed gehalten, damit die Verantwortlichkeiten nicht kollidieren.
• Compliance & Sicherheit — Ursprungsland, Gefahrstoff-Flags, Altersbeschränkung, Nachweise für regulierte Produkte. Bei Erstellungen in vielen Kategorien erforderlich; nach dem Setzen häufig editgesperrt.
• Parent / Variation — parent_sku, parent_child, relationship_type, variation_theme. Die Spalten, die die Variationsfamilie zusammenfügen, behandelt in Modul 5.

Den Feed einreichen und den Report lesen

Sobald die Arbeitsmappe ausgefüllt ist, speichere das Template-Arbeitsblatt als tabulatorgetrennte .txt-Datei. Upload über: Catalog → Add Products via Upload → Upload your Inventory File. Wähle den passenden Dateityp ("Inventory File for [Category]"). Einreichen.

Der Feed läuft asynchron. Die Verarbeitungszeit beträgt für kleine Feeds in der Regel 5–30 Minuten, bei großen Katalogen bis zu einigen Stunden. Der Beleg ist der Feed-Verarbeitungsreport, herunterladbar vom selben Bildschirm. Drei Zahlen darin sind relevant:

• Eingereichte Zeilen — Plausibilitätsprüfung, dass die von Amazon geparste Datei die erwartete Zeilenanzahl hat. Eine Abweichung bedeutet meist eine abschließende Leerzeile oder eine zusätzliche Kopfzeile.
• Erfolgreiche Zeilen — alles unter 100 % bedeutet, dass Zeilen entweder abgelehnt wurden (harter Fehler) oder mit einer Warnung akzeptiert wurden (weiches Problem, aber die Zeile wurde live gestellt).
• Fehler und Warnungen — jede abgelehnte Zeile erhält die SKU, die Spalte, den Fehlercode und eine menschenlesbare Meldung. Amazons Fehlercodes (z. B. Fehlercode 8541, 8016, 90106) sind stabil; derselbe Code für dieselbe Spalte bedeutet immer dasselbe.

Der Prüfschritt ist nicht verhandelbar: Jede Flat- File-Einreichung wird mit vollständig gelesenem Verarbeitungsreport als „erledigt“ betrachtet. Stille Teilfehler — 920 von 1.000 Zeilen erfolgreich, 80 abgelehnt — sind der häufigste Flat-File-Fehlermodus und am leichtesten zu übersehen, wenn niemand den Report öffnet.

Die Fallen, die der Report nicht erkennt

Ein „100 % erfolgreich“-Report ist nicht dasselbe wie „die Live-ASINs sehen richtig aus.“ Vier Fallen passieren die Validierung:

• Verlorenes Update bei einem beitragsgesperrten Feld. Der Feed wurde verarbeitet, das Feld hat sich nicht wirklich geändert, weil ein Beitragsberechtigter mit höherer Priorität (Brand Registry, Amazon Retail) es besitzt. Der Verarbeitungsreport zeigt Erfolg; die Live-ASIN zeigt den alten Wert. Erkenne mit einem Post-Upload- Diff gegen die Live-Detailseite.
• Leerzeilen-Löschung im Update-Modus. Jede erfolgreiche Zeile in einem Update-Modus-Feed hat die Spalten gelöscht, die du leer gelassen hast. Der Report nennt das einen Erfolg. Verhindere durch immer PartialUpdate bei Auffrischungs- Feeds — die Regel schlägt das Audit.
• Falscher Enum-Wert stillschweigend akzeptiert. Manche Enum-Spalten akzeptieren beliebige Strings und scheitern erst beim SERP-Filter-Schritt (das Listing ist live, bekommt aber nicht die Kategorie- Facette). Erkenne durch Querprüfung des Valid-Values- Blatts bei der Datenvorbereitung, nicht nach dem Upload.
• Bild-URLs, die nach dem Feed einen 404 liefern. Amazon ruft das Bild bei der Verarbeitung ab. Eine URL, die bei der Einreichung funktionierte und zehn Minuten später einen 404 lieferte, hinterlässt einen leeren Bildslot in der Live-ASIN. Hoste auf einem stabilen CDN, niemals auf einer temporären Asset-URL.

Wo der Flat File einzusetzen ist — und wo nicht

Setze den Flat File ein, wenn die Änderung breit ist: Dutzende von ASINs, dasselbe Attribut oder dieselbe Menge von Attributen, dasselbe Kategorie-Template. Eine einzeilige Inhaltsbearbeitung einer SKU gehört in die Einzelbearbeitungs-UI; eine kategorieweite Auffrischung von Bullets über 200 ASINs gehört in einen PartialUpdate-Feed. Der Übergang liegt bei etwa 5–10 ASINs — darunter ist die UI schneller und risikoärmer; darüber zahlt sich der Flat File für den Aufwand aus.

Verwende den Flat File nicht als Ersatz für die SP-API bei einem Feed, der täglich unbeaufsichtigt laufen soll. Wiederkehrende Preis-/Inventar-/Inhalts- Synchronisation ist die Aufgabe der SP-API — Flat Files sind der manuelle, geprüfte Pfad für geplante, menschengesteuerte Aktualisierungen.

Was diese Episode übergibt

Der geschriebene Text ist nun auf den ASINs im großen Maßstab live, mit einem Feed-Verarbeitungsreport auf Ablage und einem Post-Upload-Diff, der bestätigt, dass die Live-Detailseite dem Briefing entspricht. Modul 8 setzt von hier aus mit den A+ Content- Modulen fort — der Fläche, die die Beschreibung jeder ASIN ersetzt, die sie live hat — beginnend mit den Grundlagen, was A+ eigentlich ist und welche Amazon-Programme welches Modul-Set freischalten.