Du lädst den Katalogbericht, änderst 300 Titel, spielst die Datei zurück. Zwei Tage später fehlen Material, Zielgruppe und Maße — auch bei ASINs, die du nie angefasst hast.
Der Grund: Ein Feld, das im Export leer ist, ist im Katalog nicht leer. Der Bericht liefert nicht jedes gepflegte Attribut zurück. Wer die Datei unverändert hochlädt, schreibt jede Lieferlücke als Löschung.
Belegen lässt sich das an der Stelle, an der es jemand einmal falsch gemacht hat: Ein Abgleich, der zwischen „Feld ist leer" und „Feld wurde nicht geliefert" nicht unterscheidet, produziert bei jedem Durchlauf Löschungen. Deshalb ist die Unterscheidung in unserem eigenen Katalogabgleich eine feste Regel und keine Feinheit.
Der Hebel: Es trifft nie die Zeilen, die du bearbeitet hast — die prüfst du. Es trifft die anderen 2.700. Attribute steuern Filter, Varianten und die Zuordnung zu Suchanfragen; sie verschwinden ohne Fehlermeldung, und niemand sucht danach, weil der Upload als erfolgreich gemeldet wurde.
Du bekommst hier ein Modell mit drei Feldzuständen, eine Regel für sichere Uploads, einen Schnelltest für die fertige Datei und die Kennzahl, an der du einen Schaden nachträglich erkennst.
Die meisten Anleitungen zeigen, wie man eine Flatfile befüllt. Hier steht, was beim Zurückspielen mit den Feldern passiert, die du gar nicht befüllt hast.
- Ein Feld, das im Export leer ist, ist im Katalog nicht leer. Der Bericht liefert nicht jedes gepflegte Attribut zurück.
- Drei Feldzustände statt zwei: Wert vorhanden, nicht geliefert, ausdrücklich geleert. Eine Tabelle kann die letzten beiden nicht unterscheiden.
- Lade nie die Datei hoch, die du heruntergeladen hast. Nur Schlüsselspalten plus die Spalten, die du wirklich änderst.
- Teilaktualisierung statt „Datensatz ersetzen" — beim Ersetzen ist weg, was in der Datei fehlt.
- Prüfe nach dem Lauf die nicht geänderten Felder. Der Schaden liegt nie dort, wo du gearbeitet hast.
- Sichere vor jedem Lauf einen vollständigen Katalogbericht mit Datum. Eine lesbare Änderungshistorie gibt es nicht.
1. Die drei Zustände eines Feldes
Der Denkfehler steckt darin, dass eine Tabellenzelle nur zwei Zustände zu kennen scheint: gefüllt oder leer. Im Katalog sind es drei.
| Zustand | Was er bedeutet | Was beim Upload passieren soll |
|---|---|---|
| Wert vorhanden | Das Attribut ist gepflegt und wird ausgeliefert | Wert übernehmen |
| Nicht geliefert | Das Attribut existiert, steht aber nicht in dieser Datei | Bestehenden Wert behalten |
| Ausdrücklich geleert | Du willst das Attribut entfernen | Wert löschen |
Eine Tabelle kann Zustand zwei und drei nicht unterscheiden — beide sehen aus wie eine leere Zelle. Die Unterscheidung entsteht erst dadurch, welche Spalten du überhaupt mitschickst.
2. Warum der Export nicht der Katalog ist
Ein Katalogbericht ist eine Sicht auf deine Daten, keine Kopie davon. Welche Attribute er enthält, hängt vom Berichtstyp, von der Kategorie und vom Marktplatz ab. Kategoriespezifische Attribute fehlen regelmäßig in allgemeinen Berichten, und was in einer Kategorie eine eigene Spalte hat, existiert in einer anderen gar nicht.
Solange du den Bericht liest, ist das harmlos. Gefährlich wird es in dem Moment, in dem dieselbe Datei zur Eingabe wird.
Der Bericht kennt nur eine leere Zelle. Ob dahinter ein absichtlich geleertes Feld steht oder ein Attribut, das gar nicht mitgeliefert wurde, kann er nicht ausdrücken — und beim Hochladen entscheidet sich das zu deinen Ungunsten.
Wie sich dein Feedtyp bei Teilaktualisierungen verhält, legt Amazon fest und passt es an. Prüfe das vor dem ersten großen Lauf in Seller Central, nicht danach.
3. Sicher zurückspielen: nur die Spalten, die du änderst
Lade eine Datei hoch, die nur die Schlüsselspalten und die Spalten enthält, die du tatsächlich änderst. Was nicht in der Datei steht, kann auch nichts löschen.
| # | Schritt | Fertig, wenn |
|---|---|---|
| 1 | Schlüssel bestimmen — SKU und, je nach Feedtyp, die Produkt-ID | jede Zeile eindeutig zuzuordnen ist |
| 2 | Zielspalten festlegen, bevor du die Datei öffnest | die Liste der Attribute schriftlich vorliegt |
| 3 | Neue Datei bauen aus der Kategorievorlage: Schlüssel + Zielspalten, sonst nichts | die Spaltenzahl deiner Liste entspricht |
| 4 | Teilaktualisierung wählen statt Datensatz ersetzen | der Feedtyp bestehende Werte unangetastet lässt |
| 5 | Testlauf mit zehn SKUs, davon zwei mit vielen Kategorieattributen | der Lauf ohne Fehler durch ist |
| 6 | Die nicht geänderten Felder gegenprüfen | zwanzig Stichproben unverändert sind |
Schritt 6 ist der, den alle auslassen, und der einzige, der den Fehler findet.
Ein Sonderfall betrifft Variantenfamilien: Wenn dir die Child-SKUs gehören, die Parent-SKU aber nicht, fehlen die Zeilen schon im Bericht — nachzulesen in Varianten ohne eigene Parent-SKU.
4. Der Vorher-Stand, den du selbst anlegen musst
Es gibt keine für dich lesbare Änderungshistorie deiner Inhalte. Wenn Attribute verschwunden sind, kannst du nicht nachschlagen, was vorher dort stand — es sei denn, du hast es vorher gesichert.
Ein vollständiger Katalogbericht, gespeichert mit Datum, unmittelbar vor dem Lauf. Das kostet zwei Minuten und ist der Unterschied zwischen „wir spielen den Stand von Dienstag zurück" und „wir pflegen 2.700 Produkte neu".
Bei mehreren Marktplätzen gilt: je Marktplatz ein eigener Bericht, je Marktplatz eine eigene Datei. Ein gemeinsamer Lauf über DE, FR, IT und ES, dessen Zwischenstände nicht getrennt sind, liefert den späteren Ländern die Daten des ersten — und schreibt fremde SKUs unter falscher Landeskennung.
Was du nach dem Lauf misst und ab wann, hängt daran, wann die Änderung überhaupt auf der Detailseite steht — siehe warum eine angenommene Änderung nicht live ist.
5. Was ein gelöschtes Attribut wirklich kostet
Ein verschwundenes Attribut fühlt sich nach Datenpflege an. Es ist aber ein Eingriff in alle drei Größen, in denen du dein Geschäft misst — nur zeitversetzt und in dieser Reihenfolge:
| Größe | Wirkung | Weg und Verzögerung |
|---|---|---|
| Conversion | fällt zuerst | Fehlt Material, Größe oder Zielgruppe, fehlt dem Käufer die Entscheidungsgrundlage. Aus denselben Besuchern werden weniger Käufer — messbar innerhalb weniger Tage. |
| Best-Seller-Rank | fällt indirekt, über zwei Wege | Filterattribute entscheiden, ob dein Produkt in verfeinerten Suchen überhaupt erscheint. Weniger Sichtbarkeit plus langsamere Verkaufsgeschwindigkeit drücken die Position — mit ein bis zwei Wochen Verzug. |
| Umsatz | fällt zuletzt | Er ist die Summe der beiden darüber. Als Frühwarnung unbrauchbar: Wenn du ihn siehst, liegt die Ursache zwei Wochen zurück. |
Wichtig für die Erwartung: Hier geht es nie um mehr Umsatz, sondern um keinen Verlust. Das macht den Fehler so teuer — er produziert kein Alarmsignal, sondern eine Kurve, die einfach etwas flacher weiterläuft.
Wenn du Katalogpflege gar nicht mehr über Flatfiles machen willst: SELLRZ schreibt nur die Felder zurück, die du geändert hast, unterscheidet „leer" von „nicht geliefert" und legt zu jeder Änderung den Vorher-Stand ab.
6. Richtig und falsch, mit Schnelltest
| Falsch | Richtig | Warum |
|---|---|---|
| Export herunterladen, Titel ändern, dieselbe Datei hochladen | Neue Datei mit SKU + Titelspalte | Der Export enthält Spalten, deren Inhalt er nicht vollständig kennt |
| Alle Spalten mitschicken, „schadet ja nicht" | Nur Schlüssel- und Zielspalten | Jede mitgeschickte leere Spalte ist ein Löschkandidat |
| Vollständigen Datensatz ersetzen | Teilaktualisierung | Ersetzen heißt: was fehlt, ist weg |
| Nach dem Upload die geänderten Felder prüfen | Die nicht geänderten Felder prüfen | Der Schaden liegt nie dort, wo du gearbeitet hast |
| Ein Lauf über alle Marktplätze | Ein Lauf je Marktplatz | Kategoriespalten und Werte unterscheiden sich je Land |
Öffne deine Upload-Datei und zähle die Spalten. Sind es mehr als die Schlüsselspalten plus die Felder, die du bewusst ändern willst? Dann lade sie nicht hoch.
Was du nicht änderst, gehört nicht in die Datei.
Welche Attribute überhaupt auf eine Käuferfrage einzahlen und welche nur den Katalog füllen, entscheidet sich an derselben Stelle wie die Textarbeit — siehe welche Listing-Fläche zuerst dran ist.
7. Woran du einen Schaden erkennst
Weil die Kennzahlen aus Abschnitt 5 zeitversetzt reagieren, findest du den Fehler nicht über sie, sondern über eine Handprüfung. Die schnellste Spur ist die Angebotsqualität: Sie fällt bei einzelnen ASINs, ohne dass jemand am Text war, und sie misst genau das, was hier verloren geht — Vollständigkeit.
Wer erst auf den Umsatz schaut, findet die Ursache nicht mehr, weil in der Zwischenzeit zehn andere Dinge passiert sind. Nimm nach jedem größeren Lauf eine Stichprobe von zwanzig ASINs, die du nicht bearbeitet hast, und vergleiche ihre Attributvollständigkeit mit dem gesicherten Bericht von vorher.
Häufige Fragen
Warum löscht mein Flatfile-Upload Attribute?
Weil der Katalogbericht nicht jedes gepflegte Attribut zurückliefert. Lädst du dieselbe Datei wieder hoch, ist jede nicht gelieferte Spalte eine leere Zelle — und eine leere Zelle in einer mitgeschickten Spalte wird als Löschwunsch gelesen. Betroffen sind vor allem die Zeilen, die du nie angefasst hast.
Was ist der Unterschied zwischen Teilaktualisierung und Datensatz ersetzen?
Eine Teilaktualisierung ändert nur die Felder, die in der Datei stehen, und lässt den Rest unangetastet. „Datensatz ersetzen" schreibt den kompletten Datensatz neu — was in der Datei fehlt, ist danach weg. Wie sich dein Feedtyp verhält, legt Amazon fest; prüf das vor dem ersten großen Lauf.
Welche Spalten gehören in eine Upload-Datei?
Die Schlüsselspalten — SKU und je nach Feedtyp die Produkt-ID — plus genau die Spalten, die du ändern willst. Sonst nichts. Jede zusätzlich mitgeschickte Spalte ist ein Löschkandidat für die Zeilen, in denen sie leer ist. Bau die Datei aus der Kategorievorlage, nicht aus dem Export.
Wie mache ich einen Flatfile-Upload rückgängig?
Nur, wenn du vorher gesichert hast. Es gibt keine für dich lesbare Änderungshistorie deiner Inhalte — was gelöscht wurde, kannst du nicht nachschlagen. Deshalb gehört ein vollständiger Katalogbericht mit Datum unmittelbar vor jeden Lauf. Zwei Minuten Aufwand gegen die Neupflege tausender Produkte.
Woran erkenne ich, dass ein Lauf Daten gelöscht hat?
Nicht am Umsatz — der reagiert zu spät. Die schnellste Spur ist die Angebotsqualität einzelner ASINs: Sie fällt, ohne dass jemand am Text war. Nimm nach jedem Lauf zwanzig ASINs, die du nicht bearbeitet hast, und vergleiche ihre Attributvollständigkeit mit dem gesicherten Bericht.
Kann ich einen Lauf über mehrere Marktplätze machen?
Besser nicht. Kategoriespalten und zulässige Werte unterscheiden sich je Land, und ein gemeinsamer Lauf, dessen Zwischenstände nicht getrennt sind, liefert den späteren Ländern die Daten des ersten. Je Marktplatz ein eigener Bericht, je Marktplatz eine eigene Datei. Sonst schreibst du fremde SKUs unter falscher Landeskennung zurück.
Muss ich leere Zellen löschen oder ausfüllen?
Weder noch: Die Spalte gehört gar nicht erst in die Datei. Eine leere Zelle in einer mitgeschickten Spalte ist mehrdeutig, und die Mehrdeutigkeit löst sich zu deinen Ungunsten. Ausdrücklich leeren willst du nur Attribute, die tatsächlich weg sollen — und die stehen dann bewusst in der Datei.
Warum fehlen manche Varianten schon im Bericht?
Weil dir die Child-SKUs gehören können, die Parent-SKU aber nicht. Dann fehlt die Parent-Zeile im Export, und deine Gruppierung zählt Einzelprodukte statt einer Familie. Wie du diese Fälle findest, steht in Varianten ohne eigene Parent-SKU. Für den Käufer ist die Auswahl auf der Detailseite trotzdem vollständig.
Warum SELLRZ hier sinnvoll ist
SELLRZ pflegt Listings über einen eigenen Katalogabgleich, der zwischen „Feld ist leer" und „Feld wurde nicht geliefert" unterscheidet — ein nicht geliefertes Attribut wird nie als Löschung geschrieben. Jede Änderung entsteht als neue Version mit Vorher-Stand, und was nach Amazon zurückgeschrieben wird, wird gegen die live ausgelieferte Fassung verifiziert statt gegen die Rückmeldung des Uploads.
Quellen
- Amazon Seller Central — Hilfe zu Lagerbestandsdateien, Feedtypen und Teilaktualisierungen (Stand August 2026; Amazon ändert diese Vorgaben, vor jedem großen Lauf prüfen)
- Interne Betriebsregel aus dem SELLRZ-Katalogabgleich: ein nicht geliefertes Feld ist keine Änderung
Wachstumstweak: die Stichprobe der unberührten ASINs
Solange das der einzige Beleg ist, bleibt Massenpflege riskant. Wer das Risiko nicht messen kann, macht seltener Massenläufe — und lässt genau die Arbeit liegen, die bei großen Katalogen den größten Hebel hat.
Führe eine feste Stichprobe: zwanzig ASINs, die bei jedem Lauf ausdrücklich nicht bearbeitet werden, mit gesichertem Attributstand. Nach jedem Lauf werden genau diese zwanzig verglichen. Fünf Minuten Aufwand — und der Löschfehler fällt am selben Tag auf statt in drei Wochen.
SELLRZ macht genau diesen Vergleich zum Normalfall: Vorher-Stand je Version, Prüfung gegen die live ausgelieferte Fassung, Auswertung der Vollständigkeit über den gesamten Bestand statt über eine Handstichprobe. Wenn du das auch machen willst, nutze SELLRZ für dein Amazon-Wachstum. Trag dich für eine Demo ein.
