Der Katalog unter der Haube: warum deine Änderung zurückspringt

Der Katalog kennt keine „Bulletpoints" und keine „Beschreibung" als freie Textfelder. Er kennt Produkttypen (zum Beispiel KITCHEN oder SHOES) und je Produkttyp ein Attribut-Schema: eine maschinenlesbare Liste aller erlaubten Felder mit Datentyp, Wertebereich, Pflicht-Kennzeichen und erlaubten Aufzählungswerten.

Diese Schemas sind öffentlich beschrieben: Amazons Product Type Definitions liefern je Produkttyp und je Marktplatz ein JSON-Schema mit den anwendbaren Attributen und Beschränkungen (Belegstufe: Amazon, Entwickler-Dokumentation der Selling Partner API). Das ist die eigentliche Sprache des Katalogs. Alles, was du sonst benutzt, ist eine Übersetzung davon:

Der praktische Schluss, den kaum jemand zieht: Wenn ein Feld in deinem Formular fehlt, ist es nicht „nicht vorhanden" — es ist nur nicht in dieser Ansicht. Bevor du glaubst, dein Produkttyp könne etwas nicht, sieh in der aktuellen Vorlage nach. In sehr vielen Fällen liegt das gesuchte Attribut dort, nur unter einem technischen Namen, den niemand erraten würde. Und ebenso oft ist der Produkttyp schlicht falsch gewählt — dann fehlen die Attribute wirklich, aber die Lösung heißt Produkttyp korrigieren, nicht Feld suchen. Welche Attribute in deiner Kategorie überhaupt Wirkung entfalten, steht in Listing-Lektion 13.

„Meine Änderung ist weg" ist eine Beobachtung, keine Diagnose. Es gibt vier Ursachen, und sie brauchen vier verschiedene Behandlungen. Wer sie nicht trennt, eröffnet Fälle, die niemand lösen kann.

Ursache 4 ist die häufigste und die peinlichste: Kein Wettbewerber, keine Amazon-Automatik, sondern das eigene Warenwirtschaftssystem, das nachts brav den Stand von vorgestern zurückschreibt. Prüfe das immer zuerst, bevor du irgendwo einen Fall eröffnest.

Profis ändern nicht anders als andere, sie protokollieren anders. Der Unterschied zeigt sich erst im Streitfall — dann aber vollständig:

1. Vorher sichern. Detailseite als vollständige Kopie (Bildschirmfoto reicht) mit Datum und Uhrzeit.
2. Eine Änderung pro Zyklus. Wer Titel, Bilder und Attribute gleichzeitig ändert, kann hinterher keiner Wirkung eine Ursache zuordnen — weder bei Erfolg noch bei Ablehnung.
3. Über den führenden Kanal senden, mit Bericht. Bericht speichern, nicht nur ansehen.
4. Warten. Wie lange, sagt Amazon öffentlich nicht; kursierende Fristen sind nicht belastbar (siehe Listing L16, Abschnitt „Zahlen ohne Quelle"). Praxisregel: erst am Folgetag urteilen, bei Bildern eher später.
5. Nachher sichern und mit dem Vorher-Stand vergleichen — attributweise, nicht nach Gefühl.
6. Register führen. Datum, Attribut, alter Wert, neuer Wert, Kanal, Ergebnis. Das ist die Tabelle, die einen Support-Fall in Minuten statt Wochen löst.

Vier Fälle, die jeder Profi einmal hat, und ihre nüchterne Bewertung:

• Dublette selbst angelegt (dasselbe Produkt zweimal, weil beim ersten Versuch ein Attribut fehlte): Die schwächere ASIN schließen, nicht beide bewerben. Verkäufe und Bewertungen ziehen nicht automatisch um.
• Falscher Produkttyp gewählt: Attribute und Filterzugehörigkeit hängen daran (Listing L13). Korrektur ist möglich, kann aber Attribute leeren — vorher exportieren.
• Fremde ASIN mit falschen Daten, auf der du mitverkaufst: Du kannst Korrekturen beisteuern, aber du gewinnst nicht automatisch. Ohne Markenrecht ist deine Verhandlungsposition schwach.
• Zusammengeführte oder getrennte ASINs: Solche Eingriffe wirken auf Bewertungen und Verkaufshistorie. Sie sind kein Werkzeug für Reichweite, sondern eine Katalog-Korrektur — Missbrauch fällt unter Katalog-Manipulation, und die Regeln zu Variationen (Lektion 4) gelten sinngemäß.

Der teuerste Katalog-Fehler großer Konten hat einen Namen: zwei Quellen der Wahrheit. Sobald zwei Systeme dieselbe ASIN pflegen dürfen — die Weboberfläche und ein Warenwirtschaftssystem, oder zwei Dienstleister mit je eigenem Feed —, entsteht eine Schleife, die von außen wie Amazon-Willkür aussieht und in Wahrheit ein Datenmodell-Problem ist.

Die Schleife hat eine typische Signatur, an der du sie erkennst, ohne irgendetwas zu wissen:

• Regelmäßigkeit: Der Rücksprung passiert immer zur selben Tageszeit — Automatiken laufen nach Zeitplan, Amazon-Entscheidungen nicht.
• Selektivität: Genau die Attribute springen zurück, die das andere System kennt. Felder, die es nicht führt, bleiben stehen. Das ist der deutlichste Fingerabdruck.
• Wiederholgenauigkeit: Es kehrt exakt derselbe alte Wert zurück, nicht ein normierter. Amazons Automatik normiert, ein Feed kopiert.

Die Gegenmaßnahme ist organisatorisch, nicht technisch: Je Attributgruppe genau eine schreibende Quelle. Preise und Bestand aus der Warenwirtschaft, Inhalte (Titel, Bullets, Bilder, A+) aus einem einzigen Content-Kanal. In der Praxis heißt das, im anderen System die Content-Felder wirklich abzuschalten — leere Felder im Feed reichen NICHT sicher: Je nach Konfiguration ist „leer" ein Wert und löscht. Wer das nicht abstellen kann, sendet Content-Felder gar nicht erst mit, statt sie leer zu senden.

Zwei Ergänzungen, die den Unterschied zwischen „aufgeräumt" und „belastbar" ausmachen. Erstens: Der Katalog vergisst nicht, was du nie geschrieben hast. Ein Attribut, das du einmal gefüllt und danach nie wieder mitgesendet hast, bleibt oft stehen — auch wenn es längst falsch ist. Deshalb gehört zu jeder Sortimentsbereinigung ein Export ALLER Attribute, nicht nur der gepflegten. Zweitens: Verarbeitungsberichte sind Beweismittel mit Verfallsdatum. Sie stehen nicht ewig zum Abruf bereit. Wer sie erst sucht, wenn der Streit da ist, hat sie oft nicht mehr — sie gehören am Tag der Änderung in den eigenen Ordner, nicht in die Absicht, sie später zu holen.