Content-Datenqualität bei Amazon: Der Bericht, den viele übersehen
Gute Bullet Points und ansprechende Bilder reichen nicht aus, wenn im Hintergrund die Content-Daten nicht stimmen. Amazon führt dazu einen eigenen Bericht im Seller Central, der Datenqualitätsprobleme auf ASIN-Ebene sichtbar macht, lange bevor daraus eine Suppression oder eine sinkende Sichtbarkeit wird. Die wenigsten Verkäufer/innen schauen regelmäßig hinein, dabei liegt genau dort die Arbeit, die den Unterschied macht, gerade bei größeren Katalogen mit vielen Varianten.
Was der Content-Datenqualitätsbericht zeigt
Der Bericht listet ASIN für ASIN auf, wo Pflichtattribute fehlen, Bilder abgelehnt wurden oder Varianten nicht sauber verknüpft sind. Anders als eine Sperrmeldung erscheint hier kein Alarm im Konto, das Problem bleibt im Hintergrund, bis es sich in Suchergebnissen oder im Bestsellerrang bemerkbar macht.
Wer den Bericht routinemäßig auswertet, findet Lücken, bevor sie zur Umsatzfrage werden. Das gilt besonders für Kataloge, die über Monate gewachsen sind und bei denen sich Attribut-Anforderungen zwischenzeitlich geändert haben, ohne dass ältere Listings entsprechend nachgezogen wurden.
Warum gute Listings trotzdem schlecht performen
Ein Listing kann für das menschliche Auge vollständig wirken und trotzdem strukturell unvollständig sein, weil ein Backend-Attribut fehlt, das gar nicht auf der Produktseite sichtbar ist. Amazons System bewertet Content stärker nach diesen strukturierten Daten als nach dem Eindruck, den ein Mensch beim Durchklicken bekommt.
Genau diese Lücke zwischen gefühlter und tatsächlicher Content-Qualität sorgt dafür, dass augenscheinlich gute Listings in der Suche schlechter abschneiden, als das Team erwartet. Wer nur auf das Erscheinungsbild schaut, findet die eigentliche Ursache oft nicht, weil sie sich nicht auf der Produktseite selbst zeigt, sondern nur im Datenqualitätsbericht.
Keyword-Recherche ist Teil der Content-Qualität
Backend-Suchbegriffe werden oft als Pflichtübung am Ende der Content-Erstellung behandelt, dabei gehören sie strategisch an den Anfang. Eine saubere Keyword-Recherche auf Produkt- und Kategorieebene zeigt, welche Suchbegriffe tatsächlich Volumen haben und wo die eigene Kategorie Begriffe verwendet, die sich von naheliegenden Synonymen unterscheiden.
Ohne diese Grundlage bleibt Content-Qualität eine Frage des Bauchgefühls statt einer messbaren Arbeit. Ich gleiche Titel, Bullet Points und Backend-Suchbegriffe deshalb regelmäßig gegen aktuelle Suchbegriffsdaten ab, statt sie einmal beim Launch festzulegen und danach unangetastet zu lassen.
A+ Content und Brand Store als nächster Schritt
Erst wenn die Basisdaten sauber sind, lohnt sich die Investition in A+ Content, Premium A+ Content oder den Brand Store, weil diese Elemente auf einem bereits funktionierenden Fundament aufbauen. Wird diese Reihenfolge umgedreht, entsteht ein optisch starkes Listing mit denselben strukturellen Lücken darunter, die weiterhin die Sichtbarkeit begrenzen.
Auch A/B-Tests über Manage Experiments bringen erst dann belastbare Ergebnisse, wenn die Grunddaten stimmen, sonst testet man Varianten eines Listings, das ohnehin nicht vollständig ausgespielt wird.
Wie oft sich ein Blick in den Bericht lohnt
Bei größeren Katalogen prüfe ich den Content-Datenqualitätsbericht monatlich, unabhängig davon, ob sich am Sortiment etwas verändert hat, weil sich Anforderungen an Attribute und Kennzeichnungen auch ohne eigenes Zutun ändern können. Kommt eine neue Pflichtangabe hinzu, etwa zu einer Produktkategorie oder einer neuen regulatorischen Vorgabe, betrifft das oft den gesamten Bestand auf einen Schlag, nicht nur einzelne Neuanlagen.
Bei kleineren Katalogen reicht häufig ein quartalsweiser Rhythmus, dafür lohnt sich dort ein zusätzlicher Blick immer dann, wenn eine größere Flatfile-Aktualisierung ansteht, damit sich neue und alte Fehler nicht in derselben Korrekturrunde vermischen.
Wie ich die Nacharbeit organisiere
Ich priorisiere Korrekturen nach Umsatzrelevanz, nicht nach Reihenfolge im Bericht: ASINs mit hohem Traffic oder wichtiger Kategorieposition zuerst, kleinere Nebenprodukte später. Die eigentliche Korrektur läuft über Flatfiles in Batches, damit sich wiederkehrende Fehler wie ein fehlendes Pflichtattribut nicht Produkt für Produkt einzeln beheben lassen müssen.
So wird aus einem unübersichtlichen Bericht eine planbare Aufgabe mit klarem Ende, statt eines Dauerprojekts ohne sichtbaren Fortschritt. Und der Bericht bleibt Teil der laufenden Arbeit, nicht nur einer einmaligen Aufräumaktion nach dem Launch.