Datenextraktion aus Amazon Seller Central automatisieren: CLI als Ausgangspunkt
Amazon Seller Central stellt einen erheblichen Teil seiner Daten über die SP-API bereit. Ein kleinerer, betrieblich jedoch wichtiger Teil ist ausschließlich über die Oberfläche von Seller Central zugänglich: Berichte, die im Browser angefordert werden müssen, Zeit zur Erstellung benötigen und anschließend separat heruntergeladen werden. Diese Schritte zuverlässig zu automatisieren, ist anspruchsvoller, als es zunächst erscheint. Die meisten Ansätze, die in einer Vorführung funktionieren, scheitern im Produktivbetrieb innerhalb weniger Tage.
Die Herausforderung ist nicht in erster Linie technischer Natur. Browser-Automatisierung ist ausgereift, die Berichts-Endpunkte sind dokumentiert und die Datenformate gut bekannt. Die Schwierigkeit liegt im Betrieb: Amazons Oberfläche ändert sich ohne Ankündigung, die Aufruflimits sind streng, und die Verfügbarkeit von Berichten hängt vom Marktplatz und Kontotyp ab. Zudem verliert der Sitzungszustand, auf den die Browser-Automatisierung angewiesen ist, auf schwer erkennbare Weise seine Gültigkeit, bis eine Pipeline unbemerkt keine Daten mehr liefert.
API oder Browser: Eine ehrliche Abwägung
Die SP-API deckt die meisten Berichtstypen ab, die für operative Daten wichtig sind: Bestellungen, Bestände, Abrechnungen, FBA-Fulfillment und Katalogleistung. Hier ist ein reiner API-Ansatz klar vorzuziehen: Er ist schneller, zuverlässiger und unabhängig von Änderungen der Benutzeroberfläche. Die Investition in eine korrekt umgesetzte SP-API-Authentifizierung mit LWA-Zugangsdaten, Token-Erneuerung und Drosselung der Anfragen zahlt sich schnell aus.
Bestimmte Berichtskategorien sind allerdings überhaupt nicht über die SP-API verfügbar. Werbeberichte, die über das Angebot der Advertising API hinausgehen, einige Compliance-Dokumente und mehrere Formate für Finanzübersichten erfordern Interaktionen im Browser. Browser-Automatisierung sollte nur zurückhaltend und genau für diese Fälle eingesetzt werden, im vollen Bewusstsein der damit verbundenen Betriebskosten.
Bei selten benötigten Berichten ist die Alternative – bei Bedarf manuell zu exportieren – durchaus vernünftig. Entscheidend ist, ob der Automatisierungsaufwand für die Pflege von Browsersitzungen, Anmeldeabläufen, CAPTCHAs und MFA über den relevanten Zeitraum tatsächlich geringer ist als der manuelle Aufwand. Für tägliche operative Daten gewinnt die Automatisierung klar. Bei monatlichen Compliance-Berichten ist die Rechnung weniger eindeutig.
Deterministische Dateibenennung als Grundlage
Die folgenreichste Designentscheidung in einer Datenextraktionspipeline betrifft nicht den Extraktionsmechanismus, sondern die Benennung und Ablage der extrahierten Dateien. Pipelines mit zeitstempelbasierten oder fortlaufenden Dateinamen erzeugen Betriebsprobleme, die sich mit der Zeit verstärken: Der erwartete Berichtszeitraum ist nicht auf einen Blick erkennbar, die Deduplizierung wird unzuverlässig, und nachgelagerte Prozesse mit Abhängigkeiten von bestimmten Dateien müssen bei jeder Änderung der Namenskonvention angepasst werden.
Eine deterministische Namenskonvention bildet die wesentlichen Eigenschaften jedes Berichts direkt im Dateinamen ab: Berichtstyp, Marktplatzkennung, Zeitraum und einen Hash des Inhalts zur Deduplizierung. Ein Abrechnungsbericht für den EU-Marktplatz und einen bestimmten Zeitraum sollte denselben Dateinamen erhalten, unabhängig davon, wann er angefordert oder heruntergeladen wurde. Diese Eigenschaft – Idempotenz im Dateisystem – beseitigt eine ganze Klasse von Pipeline-Fehlern und macht das Datenverzeichnis selbsterklärend.
Dafür müssen die Schlüsseleigenschaften jedes Berichts vor dem Schreiben der Datei in eine kanonische Form gebracht werden. Bei den meisten Berichtstypen ist das einfach. Schwieriger sind Berichte, deren Dateien nicht alle relevanten Metadaten von Amazon enthalten. In solchen Fällen muss die Namenskonvention die Metadaten aus dem Anfragekontext ableiten, der deshalb bis zum Download mitgeführt werden muss.
YAML-Zustandsverfolgung
Ein unbeaufsichtigt laufendes CLI-Werkzeug zur Datenextraktion benötigt einen persistenten Zustand: Welche Berichte wurden angefordert, welche stehen aus, welche wurden erfolgreich heruntergeladen und welche sind mit welchem Fehler gescheitert? Eine datenbankgestützte Zustandsverwaltung liegt nahe, führt aber eine zusätzliche Abhängigkeit ein, die das Deployment erschwert und unverhältnismäßigen Betriebsaufwand verursacht.
YAML-Dateien je Berichtstyp – oder bei mehreren Marktplätzen je Marktplatz – liefern den Großteil der benötigten Funktionen mit minimaler Infrastruktur. Die Zustandsdatei dokumentiert jede Berichtsanforderung mit Parametern, Anfragezeitpunkt, erwartetem Verfügbarkeitszeitpunkt, Downloadstatus und aufgetretenen Fehlern. Das reicht für fortsetzbare Pipelines, die beim letzten erfolgreichen Zustand wieder einsteigen, für nachvollziehbare Protokolle darüber, welche Daten wann erhoben wurden, und für die Erkennung fehlender Zeiträume.
Die praktische Grenze von YAML als Zustandsspeicher ist der gleichzeitige Zugriff: Läuft die Pipeline in mehreren Prozessen oder auf mehreren Rechnern, entstehen bei dateibasiertem Zustand Race Conditions, also Fehler durch konkurrierende Zugriffe. Auf einem einzelnen Rechner mit sequenzieller Ausführung ist das kein Problem. Für verteilte Systeme ist eine schlanke Datenbank die richtige Wahl. Die YAML-Struktur lässt sich bei einer später erforderlichen Migration gut in ein Datenbankschema überführen.
Der Workflow mit zwei Durchläufen für Berichte über Nacht
Mehrere Amazon-Berichtstypen werden asynchron erzeugt: Sie fordern einen Bericht an, Amazon stellt ihn in eine Warteschlange, und nach einigen Minuten bis Stunden wird er verfügbar. Das zuverlässigste Muster dafür ist ein Workflow mit zwei Durchläufen: Einer übermittelt alle ausstehenden Berichtsanforderungen, der andere lädt die seit der letzten Prüfung verfügbar gewordenen Berichte herunter.
Der Anforderungsdurchlauf läuft zu einer festgelegten Zeit, typischerweise am späten Abend, und fordert alle Berichtstypen für den zuletzt abgeschlossenen Zeitraum an. Die YAML-Zustandsdatei erfasst jede Anfrage-ID und den Übermittlungszeitpunkt. Am nächsten Morgen fragt der Downloaddurchlauf den Status aller ausstehenden Anforderungen ab, lädt die fertigen Berichte herunter und markiert sie in der Zustandsdatei als abgeschlossen. Noch nicht verfügbare Berichte bleiben ausstehend und werden im nächsten Downloaddurchlauf erneut geprüft.
Diese Trennung hat eine wichtige betriebliche Eigenschaft: Sie entkoppelt die Erstellungsdauer der Berichte von den Verfügbarkeitszielen der Pipeline. Statt auf die Verfügbarkeit zu warten und dadurch variable Verzögerungen und komplexe Zeitüberschreitungen einzuführen, strebt die Pipeline für vor einem Annahmeschluss angeforderte Berichte ein festgelegtes Zeitfenster am Folgetag an; Berichte, die Amazon bis dahin nicht fertiggestellt hat, bleiben für den nächsten Durchlauf ausstehend. Der genaue Zeitpunkt innerhalb dieses Fensters hängt von Amazons Warteschlange ab, nicht vom Verhalten der Pipeline.
Zwei Fehlerfälle müssen berücksichtigt werden: abgelaufene Berichte und doppelte Anforderungen. Die Reports API hält Berichte maximal 90 Tage vor, weshalb verspätete Downloads erkannt werden müssen. Doppelte Anforderungen für denselben Zeitraum erzeugen redundante Dateien und verbrauchen API-Kontingente. Die YAML-Zustandsdatei behandelt beides: Sie erfasst, für welche Zeiträume aktive Anforderungen bestehen, und verhindert neue Anforderungen, bis die bestehende abläuft oder endgültig scheitert.
Was im Produktivbetrieb scheitert
Das häufigste Fehlermuster im Produktivbetrieb betrifft nicht die Berichtsextraktion selbst, sondern die Verwaltung der Zugangsdaten. Die SP-API verwendet LWA-Zugriffstoken (Login With Amazon), die nach einer Stunde ablaufen und mit einem Refresh-Token erneuert werden müssen, dessen Lebensdauer länger, aber ebenfalls begrenzt ist. Pipelines, die diese Erneuerung in der Entwicklung korrekt behandeln, scheitern im Produktivbetrieb oft nach längeren unbeaufsichtigten Laufzeiten, wenn das Refresh-Token ohne Erneuerung abläuft.
Browserbasierte Extraktion hat andere Fehlerquellen: Sitzungscookies laufen ab, Amazon führt neue Verifikationsschritte ein, und Änderungen der Oberfläche machen CSS-Selektoren oder Navigationsabläufe unbrauchbar. Diese Fehler bleiben unbemerkt, wenn die Pipeline nur prüft, ob eine Datei heruntergeladen wurde, statt ausdrücklich deren erwartete Datenstruktur zu validieren.
Die meisten Ausfälle im Produktivbetrieb lassen sich durch Validierung bei jedem Schritt verhindern. Prüfen Sie vor dem Start der Pipeline, ob die Zugangsdaten gültig sind. Prüfen Sie, ob jeder angeforderte Bericht das erwartete Schema liefert. Prüfen Sie, ob die Zeiträume in den heruntergeladenen Dateien den angeforderten Zeiträumen entsprechen. Pipelines mit konsequenter Validierung scheitern sofort und sichtbar. Pipelines, die ihren Eingaben vertrauen, scheitern unbemerkt und teuer.
Weiterführende Beiträge
- Datenpipelines für mehrere Marktplätze: Verkäuferkonten über Regionen hinweg verwalten – die Extraktion für einen einzelnen Marktplatz auf US, JP und DE erweitern, mit eigener Konfiguration und YAML-Zustand je Marktplatz.
- Produktionsreife Dateninfrastruktur für Amazon-Verkäufer aufbauen – die Architektur hinter tva-fetch und die zugrunde liegenden SP-API-Integrationsmuster.
- Ein Amazon-Data-Warehouse mit FastAPI und TimescaleDB aufbauen – wie sich extrahierte Daten nach der Speicherung auf dem Datenträger nutzen lassen.