Microsoft Shopping Feed Pipeline

Die Herausforderung

Blender Networks Inc. betreibt ein großes Preisvergleichsportal, dessen komplette Monetarisierung exklusiv auf Microsoft Advertising Product Listing Ads (PLAs) basiert. Die bisherige In-House-Feed-Lösung war instabil und musste abgelöst werden.

Schwierig wurde es durch die heterogenen Drittanbieter-Quellen: Connexity liefert gezippte JSON-Bundles über einen API-Index, Shopping24 (S24) stellt eine CSV-Master-Datei plus Fragment-Updates per FTP bereit. Beide Formate mussten fehlerfrei in das streng definierte TSV-Schema des Microsoft Merchant Centers überführt werden. Jeder Formatfehler, jeder „Item Drop" = direkter Umsatzverlust.

Zusätzliche Härte: Die Connexity-Daten sprengen routinemäßig 2 GB pro Publisher-Account, der gemappte Output liegt im zweistelligen GB-Bereich, und der gesamte tägliche Upload ins Microsoft Merchant Center bewegt sich bei rund 200 GB. Naive In-Memory-Verarbeitung war keine Option, die Pipeline musste auch auf moderater Hardware OOM-sicher laufen.

Die Umsetzung

Drei heterogene Quellen, eine einheitliche Pipeline. Die Architektur folgt einem strikten Drei-Stage-Modell, Ingest → Map → Upload, in dem jedes Affiliate-Netzwerk hinter derselben Schnittstelle lebt, aber intern auf seinen eigenen Stack zugreift (siehe Pipeline-Diagramm unten).

• Streaming-First Ingestion. Eine Python-Pipeline mit ijson parst die gezippten JSON-Bundles item-by-item direkt aus dem Stream, statt das komplette Dokument in RAM zu deserialisieren. Der Speicherverbrauch bleibt konstant, unabhängig von der Feed-Größe.
• Disk-basierte Deduplizierung. Eine SQLite-Tabelle mit PRAGMA-Tuning übernimmt die Cross-Account-Deduplizierung auf Disk. Multi-Million-Item-Feeds bleiben sauber, ohne den Heap zu sprengen, der Dedup-State überlebt selbst bei Abbruch zur Inspektion.
• Strenges Mapping auf die MS-Spec. Jeder Source-Datensatz wird deterministisch auf das geforderte id/title/description/link/image_link/price/... Schema gemappt. Validierungslogik filtert unbrauchbare Brand-Strings (rein numerisch, zu lang, zu viele Wörter), prüft GTINs auf zulässige Längen (8/12/13/14) und setzt identifier_exists konsistent, keine „Partial Identifier"-Warnungen mehr.
• 15-GB-Chunking & Chunk-Aware Upload. Mapping-Outputs werden bei 15 GB automatisch in _0.txt, _1.txt, … geteilt, passend zum Microsoft-Upload-Limit. Der Uploader erkennt diese Chunks per Pattern-Matching und nummeriert sie remote korrekt durch (TipDigest_US_0.txt, TipDigest_US_1.txt, …).
• Hochgeschwindigkeits-SFTP via LFTP. Statt Python-SFTP-Libraries (paramiko) wird die System-LFTP-Binary mit vergrößertem TCP-Socket-Buffer und Reconnect-Strategie gefahren. Deutlich schneller und stabiler bei Multi-GB-Files als jede Python-Implementierung.
• Multi-Account-Orchestrierung. Mehrere Connexity-Publisher und mehrere Merchant-Center-Konten (US/DE) werden parallel durchgereicht; jeder Account liefert in seinen eigenen Output-Pfad und wird per Store-Mapping korrekt zugeordnet.
• Resilient Daily Sync. Cron-Lockfile schützt vor überlappenden Doppelläufen. Pipeline-Stages sind einzeln togglebar (--skip-ingest, --skip-map, --skip-upload) für gezielte Re-Runs nach Teilfehlern, ohne dass der gesamte 2-GB-Download neu gezogen werden muss.
• Proactive Error Handling & Diagnostics. Hybrid-Logging (Rich-Console mit Emojis für humans + RotatingFileHandler für die Maschine), pro-Stage Execution-Report-Tabelle, Per-Account-Isolation. Ein einzelner Truncated-JSON-Stream stoppt nicht den Gesamtlauf, Fehler werden lokalisiert geloggt und der Lauf läuft mit dem Rest weiter.
• Modulare Architektur. Jedes Affiliate-Netzwerk lebt in seinem eigenen Modul (ingest_*.py + mapper_*.py) hinter einer einheitlichen Pipeline-Schnittstelle. Eine dritte Quelle (Kelkoo) ließ sich anhängen, ohne Connexity oder S24 anzufassen, Beweis, dass die Abstraktion trägt.
• Acceptance Criterion. Die harte Abnahmebedingung (5+ Tage in Folge fehlerfreie Automation) wurde im ersten Anlauf bestanden, gesichert durch saubere Modulgrenzen und konsequentes Validation-Layering.

Das Diagramm zeigt den vollständigen Datenfluss: von den heterogenen Quellsystemen (gezippte JSON-Streams, REST-API, FTP-Dumps) durch die OOM-sichere Ingest-Schicht, das validations-getriebene Mapping mit 15-GB-Chunking bis hin zum chunk-aware LFTP-Upload in das Microsoft Merchant Center.

Das Ergebnis

• 100 % Feed-Compliance, keine Disapprovals mehr durch Formatfehler.
• Zero Errors im täglichen Sync, Akzeptanzkriterium first try bestanden.
• ROI geschützt, kein Umsatzverlust mehr durch defekte Feed-Updates.
• OOM-sicher bei Multi-GB-Feeds, Pipeline läuft auf moderater Hardware ohne Speicherstress.
• Modular erweiterbar, neue Affiliate-Netzwerke integrieren sich ohne Eingriff in den Kern.