OpenAI Agentic Commerce Protocol: Was Händler jetzt über ChatGPT-Shopping wissen sollten

Warum OpenAI Commerce für Händler strategisch relevant ist

OpenAI beschreibt den Agentic Commerce Protocol-Bereich als Infrastruktur zwischen Händlern und Käufern in ChatGPT. Die Grundidee ist nicht nur ein weiterer Shopping-Feed. ACP soll strukturierte Katalogdaten aufnehmen, Händlerbestand verstehen und passende Produkte im Kontext einer ChatGPT-Nutzung anzeigen können.

Für Händler ist das relevant, weil Produktsuche damit stärker in dialogische und agentische Umgebungen wandert. Ein Nutzer sucht nicht mehr nur nach einer SKU, einer Kategorie oder einem Keyword. Er beschreibt ein Problem, einen Anlass, ein Budget, eine Größe, eine Farbe, eine Einschränkung oder einen Vergleich. Damit ein System wie ChatGPT daraus eine belastbare Produktauswahl bilden kann, braucht es mehr als klassische SEO-Texte. Es braucht strukturierte Daten über Produkte, Varianten, Preise, Verfügbarkeit, Bilder, Kategorien, Seller-Kontext und teilweise Promotions.

Die wichtige Einordnung lautet: OpenAI verspricht in der Dokumentation keinen allgemeinen Sofortzugang für jeden Shop. Das Onboarding von Produktfeeds in ChatGPT ist laut Get-started-Dokumentation derzeit für genehmigte Partner verfügbar. Für Unternehmen ist das trotzdem ein sinnvoller Zeitpunkt, die eigene Commerce-Datenqualität zu prüfen. Wer Produktdaten heute schon sauber, stabil und automatisiert ausspielen kann, ist besser vorbereitet, wenn weitere agentische Commerce-Kanäle entstehen.

Was der Agentic Commerce Protocol laut OpenAI leisten soll

OpenAI nennt ACP einen offenen Standard, der als Verbindungsschicht zwischen Händlern und ChatGPT-Nutzern dienen soll. Praktisch bedeutet das: Der Händler liefert strukturierte Katalogdaten. ChatGPT kann diese Daten indexieren, Produktattribute verstehen und relevante Produkte in Shopping-Erlebnissen kontextbezogen darstellen. Der Schwerpunkt liegt also zunächst nicht auf kreativen Produkttexten, sondern auf Datenklarheit.

Der wichtigste Startpunkt ist ein strukturierter Produktfeed. OpenAI schreibt, dass Product Feeds ChatGPT die Katalogdaten geben, die nötig sind, um Produkte zu indexieren, Kernattribute zu verstehen und korrekte Produktinformationen in Shopping-Erlebnissen zu präsentieren. Händler sollen mit Feeds beginnen, wenn sie ihren Katalog für ChatGPT verständlich machen, aktuelle Daten zu Titel, Beschreibung, Bildern, Preis und Verfügbarkeit teilen und einen dokumentierten Integrationsweg nutzen wollen.

Das ist eine sehr technische Definition von Commerce-Sichtbarkeit. Es reicht nicht, dass eine Produktseite hübsch aussieht. Die Maschine muss wissen, welches Produkt stabil gemeint ist, welche Variante kaufbar ist, welcher Preis gilt, ob ein Artikel verfügbar ist, welches Bild zur Variante gehört und welche Policy-Seiten zum Verkäufer gehören. ACP verschiebt damit einen Teil der Commerce-Arbeit von der Landingpage in die Datenpipeline.

Der empfohlene Integrationsweg: Snapshot plus API-Updates

Im Get-started-Leitfaden beschreibt OpenAI eine klare Reihenfolge: Integrationsmethode wählen, Spezifikation prüfen, Pflichtfelder validieren, Feed hochladen und den Feed aktuell halten. Händler können zwischen File Upload und API wählen.

OpenAI empfiehlt im Allgemeinen, den vollständigen Feed einmal täglich per File Upload bereitzustellen und Updates im Tagesverlauf über die API zu senden. Kleine Feeds können vollständig über API geliefert und regelmäßig aktualisiert werden. Promotions sind eine wichtige Ausnahme: Promotionsdaten können laut OpenAI nur über die API bereitgestellt werden.

Das ist für deutsche E-Commerce-Teams eine vertraute Architektur. Ein nächtlicher oder regelmäßiger Full Snapshot ist die Quelle der Wahrheit. Er korrigiert Drift, entfernt alte Produkte und stellt sicher, dass ChatGPT nicht auf veralteten Zuständen bleibt. Die API ist danach der schnellere Kanal für Änderungen: Preisänderungen, Verfügbarkeit, neue Varianten, korrigierte Produktdaten oder Promotions. Wer heute schon ERP, PIM, Shop-System und Feed-Management getrennt betreibt, sollte ACP deshalb nicht als manuelles Exportprojekt sehen, sondern als zusätzlichen Ausgabekanal der bestehenden Produktdatenarchitektur.

File Upload: SFTP, stabile Dateinamen und volle Snapshots

Die File-Upload-Spezifikation beschreibt einen strukturierten Produktfeed, der per SFTP an OpenAI geliefert wird. Unterstützt wird ein Full Snapshot Feed, also ein vollständiger Katalogexport, der als Quelle der Wahrheit behandelt wird. OpenAI empfiehlt mindestens tägliche Aktualisierung.

Bei den Formaten bevorzugt OpenAI Parquet, idealerweise mit zstd-Kompression. Unterstützt werden außerdem jsonl.gz, csv.gz und tsv.gz. Die Codierung soll UTF-8 sein. Für den Betrieb sind stabile Dateinamen wichtig: Händler sollen denselben Dateinamen bei jeder Aktualisierung wiederverwenden und die aktuelle Datei überschreiben, statt bei jedem Lauf neue Namen zu erzeugen. Bei Shards soll das Shard-Set stabil bleiben; OpenAI nennt bis zu 500.000 Items pro Shard als Empfehlung und Zielgrößen unter ungefähr 500 MB.

Typische Fehler sind laut Dokumentation fehlende Pflichtfelder, veraltete oder nicht spezifikationskonforme Feldnamen und fehlerhafte Werte. Entfernen kann man Produkte entweder, indem man sie in der nächsten Full-Snapshot-Datei nicht mehr mitliefert, oder indem man `is_eligible_search=false` setzt. Für operative Teams ist das wichtig: Löschen, Deaktivieren und Nicht-mehr-sichtbar-sein sind unterschiedliche Prozesszustände, die sauber aus dem PIM oder Shop-System kommen müssen.

API: Feeds, Products und Promotions als drei Oberflächen

Die API-Übersicht teilt die Commerce-API in drei Oberflächen: Feeds, Products und Promotions. Feeds erstellen Produktfeeds und liefern Metadaten. Products ruft Produkte ab und spielt partielle Produktänderungen ein. Promotions ruft Aktionen ab und aktualisiert Promotion-Änderungen.

Für Feeds gibt es Endpunkte wie `GET /product_feeds/{id}` für Feed-Metadaten und `POST /product_feeds` zum Erstellen eines Feeds. Bei Products gibt es `GET /product_feeds/{id}/products` und `PATCH /product_feeds/{id}/products`. PATCH spielt partielle Änderungen ein; Produkte werden über `id` gematcht, und nicht enthaltene Produkte bleiben unverändert. Das ist ein wichtiger Unterschied zum Full Snapshot: Ein API-Patch ist keine vollständige Wahrheit über den Katalog, sondern ein gezieltes Update.

Promotions funktionieren ähnlich: `GET /product_feeds/{id}/promotions` ruft Promotiondaten ab, `PATCH /product_feeds/{id}/promotions` upsertet Promotions anhand der `id`. Promotions, die nicht im Request enthalten sind, bleiben bestehen. Die API nutzt gemeinsame Header wie Authorization, Accept-Language, User-Agent, Idempotency-Key, Request-Id, Content-Type, Timestamp und API-Version. Für produktive Integrationen sind Idempotency und Request-Ids besonders wichtig, weil sie Wiederholungen, Nachvollziehbarkeit und Fehleranalyse ermöglichen.

Das Produktschema: stabile IDs, Varianten und kaufbare Zustände

Die Produktspezifikation macht deutlich, dass OpenAI zwischen Produkt und Variante unterscheidet. Das Produkt ist der kanonische Datensatz, Varianten sind kaufbare Konfigurationen wie Farbe, Größe oder Material.

Für das Produkt ist `id` der stabile globale Identifier und muss über die Zeit stabil bleiben. Titel, Beschreibung, URL und Medien können auf Produktebene angegeben werden. Entscheidend ist aber: `variants` ist erforderlich. Jede Variante hat wiederum eine eigene stabile `id` und einen erforderlichen Titel. Optional können Variantendescription, Variant-URL, Barcodes, Preis, Listenpreis, Unit Price, Verfügbarkeit, Kategorien, Zustand, Variant Options, Medien und Seller-Daten folgen.

Dieses Modell ist sehr nah an der Realität guter Commerce-Systeme. Ein Schuh ist nicht nur ein Produkt, sondern ein Set aus Größen, Farben und Lagerzuständen. OpenAI empfiehlt in den Best Practices, Varianten auf Zeilenebene zu modellieren: stabile Produkt-ID für das Parent-Produkt, einzigartige Variant-ID für jede kaufbare Option und variantenspezifische Werte für Titel, URL, Beschreibung, Medien, Verfügbarkeit und Preis, wenn diese sich unterscheiden. Wer Varianten nur als Text im Beschreibungstext versteckt, macht es agentischen Systemen schwerer, eine konkrete kaufbare Option zu empfehlen.

Preis, Verfügbarkeit, Medien und Policies sind keine Nebensache

OpenAI definiert Preise als Geldbeträge in Minor Units mit ISO-4217-Währung. Ein Preis von 79,99 USD würde also als `amount: 7999` mit `currency: USD` modelliert. Verfügbarkeit kann über `available` und Statuswerte wie `in_stock`, `backorder`, `preorder`, `out_of_stock` oder `discontinued` beschrieben werden. Das wirkt technisch, entscheidet aber direkt darüber, ob eine Empfehlung brauchbar ist.

Medien können als Produkt- oder Variantenmedien geliefert werden. Bei Variantenmedien wird der erste Eintrag als primär behandelt. Die Spezifikation sieht neben URL und Typ auch Alt-Text, Breite und Höhe vor. Für Shops ist das ein Hinweis: Bilder sollten nicht nur hübsch sein, sondern sauber adressiert, stabil erreichbar und zur jeweiligen Variante passend sein. Ein roter Pullover mit blauem Variantenbild ist für eine dialogische Empfehlung besonders schädlich.

Auch Seller-Links gehören in das Modell. Unterstützt werden Link-Typen wie privacy_policy, terms_of_service, refund_policy, shipping_policy und faq. In einem klassischen Shop sucht der Nutzer solche Informationen vielleicht über Footer oder Checkout. In einem agentischen Commerce-Kontext muss das System sie strukturiert finden können. Rückgabe, Versand, Datenschutz und FAQ sind Vertrauens- und Entscheidungssignale, nicht nur juristische Pflichtseiten.

Best Practices: faktisch schreiben, Optionen bewusst nutzen

Die OpenAI-Best Practices sind bemerkenswert nüchtern. Produktbeschreibungen sollen knapp, faktisch und hilfreich sein. Plain Text und Bullet-Style-Text sind beide akzeptabel. Optionale Felder wie `description.html`, `description.markdown`, `categories.taxonomy` und `seller.links` können die Antwortqualität verbessern, sind aber nicht zwingend für die Ingestion.

Wichtig ist der pragmatische Zusatz: Wenn optionale Felder nur mit brüchigen Transformationen gefüllt werden können, sollte man sie weglassen, bis die Datenqualität stabil ist. Das ist für Teams mit gewachsenen PIM-Systemen ein sehr sinnvoller Rat. Schlechte strukturierte Daten sind nicht automatisch besser als fehlende strukturierte Daten. Ein optionales Feld, das bei 20 Prozent der Produkte falsche Taxonomien oder kaputte HTML-Fragmente enthält, kann mehr Schaden anrichten als Nutzen bringen.

OpenAI betont außerdem gültige und korrekt encodete URLs. `url`, `media.url` und Seller-Link-URLs sollen valide sein; Leerzeichen und unsichere Zeichen müssen encodet werden. Für Attribution empfiehlt OpenAI Feed-Attributionsparameter wie `utm_medium=feed`, wenn Händler feed-spezifische Klickmessung brauchen. Das ist ein klarer Hinweis: Agentic Commerce braucht nicht nur Datenlieferung, sondern auch Messbarkeit nach dem Launch.

Update vom 6. Mai 2026: ChatGPT Ads wird zur zweiten Commerce-Schicht

Am 6. Mai 2026 ist die neue OpenAI-Ads-Dokumentation öffentlich sichtbar. Sie positioniert ChatGPT Ads nicht als klassische Keyword-Anzeigen, sondern als Werbung in Momenten, in denen Nutzer Optionen erkunden, Alternativen vergleichen, Kompromisse abwägen und Entscheidungen vorbereiten. Das passt direkt zum Agentic-Commerce-Thema: ACP macht Produktdaten für ChatGPT verständlich, Ads schaffen zusätzlich einen bezahlten Zugang zu kaufnahen Gesprächssituationen.

Für Händler ist das eine wichtige Verschiebung. Bisher stand im Vordergrund, wie ein Katalog technisch in ChatGPT Shopping auftauchen kann: Feed, API, Varianten, Preise, Bestand, Policies. Mit ChatGPT Ads kommt eine zweite Frage dazu: Wie wird Sichtbarkeit gesteuert, budgetiert und gemessen, wenn der Nutzer nicht mehr eine Suchergebnisseite scannt, sondern mit einem Assistenten spricht? OpenAI beschreibt auf der Landingpage drei operative Schritte: Kampagne anlegen, Anzeigendetails ergänzen und danach Ergebnisse messen, Kampagnen bearbeiten und optimieren.

Die Konsequenz ist strategisch: Commerce-Teams sollten ACP nicht isoliert als Produktdatenkanal behandeln. Sie brauchen ein Modell, das Produktdaten, Paid-Media-Setup und Conversion-Messung verbindet. Ein Feed kann dafür sorgen, dass ein Produkt korrekt verstanden wird. Eine Anzeige kann dafür sorgen, dass eine Marke in relevanten Entscheidungsphasen sichtbar wird. Die Messschicht entscheidet anschließend, ob aus dieser Sichtbarkeit Warenkorb, Lead, Registrierung oder Kauf entstanden ist. Wer diese Ebenen getrennt plant, verliert genau dort Kontext, wo ChatGPT Ads ihren Unterschied zu klassischer Suche behaupten: bei reicheren Gesprächssignalen statt nur bei Keywords.

Was die Ads-Landingpage über OpenAIs Richtung verrät

OpenAI spricht auf der neuen Seite von Anzeigen, die sich natürlich in die ChatGPT-Erfahrung einfügen und klar gekennzeichnet bleiben sollen. Gleichzeitig betont OpenAI, dass Anzeigen von den eigentlichen Antworten getrennt bleiben und Nutzer Kontrolle über die Datennutzung für Werbung behalten sollen. Diese Formulierungen sind für Marken wichtig, weil Vertrauen in einer Chat-Oberfläche empfindlicher ist als in einer klassischen Anzeigenfläche. Eine schlecht passende Anzeige kann nicht nur ignoriert werden, sondern die wahrgenommene Qualität des gesamten Assistenten stören.

Für deutsche Händler entsteht daraus ein anderes Briefing an Marketing und Legal. Es reicht nicht, bestehende Google- oder Meta-Assets zu kopieren. ChatGPT Ads müssen zur Gesprächssituation passen: klare Nutzenargumente, belastbare Produktversprechen, keine überzogenen Claims, keine manipulative Verknappung und keine Zielseiten, die Produktdaten, Preis oder Verfügbarkeit anders darstellen als Feed und Anzeige. Je stärker ChatGPT als Entscheidungsbegleiter genutzt wird, desto stärker fallen Brüche zwischen Anzeige, Produktdaten und Landingpage auf.

SEO Südwest ordnet die neue Landingpage ebenfalls als Signal ein, dass OpenAI ChatGPT Ads konkreter öffnet: Neben Registrierung und Ads Manager verweist der Beitrag auf Reporting, direkte Conversion-Messung, UTM-Parameter und die Conversions API. Diese Einordnung ist kein Ersatz für die OpenAI-Dokumentation, aber sie zeigt, dass das Thema jetzt aus der Spekulationsphase in operative Marketing- und Analytics-Fragen rutscht.

Conversion-Messung: Pixel, Server-Events und UTM-Disziplin

Die neue OpenAI-Ads-Dokumentation nennt drei Bausteine: JavaScript Pixel, Conversions API und Advertiser API. Der JavaScript Pixel misst Website-Events nach einem Klick auf eine Anzeige in ChatGPT. OpenAI beschreibt dafür eine Browser-SDK-Integration mit Pixel-ID und Event-Aufruf über `oaiq("measure", ...)`. Unterstützt werden Standard-Events und Custom Events; für Commerce-Flows nennt die Dokumentation unter anderem `items_added`, `checkout_started` und `order_created`.

Das ist für Shops nur auf den ersten Blick Standard-Tracking. In einem ChatGPT-Kontext sollte das Event-Design dieselben Produkt- und Varianten-IDs verwenden, die auch im ACP-Feed auftauchen. Wenn der Feed eine Variante als `variant_123_blue_m` kennt, der Pixel aber eine interne Shop-ID, eine GA4-ID oder nur einen Produktnamen sendet, wird spätere Attribution unnötig schwer. Händler sollten deshalb früh eine ID-Matrix festlegen: Feed-ID, Variant-ID, Shop-SKU, Analytics-Item-ID und Warenwirtschafts-ID müssen zusammenführbar bleiben.

Die Conversions API ist die serverseitige Ergänzung. OpenAI beschreibt sie als zuverlässigere Quelle als den Pixel allein und empfiehlt ihre Nutzung, wenn möglich. Events werden serverseitig an OpenAI gesendet, Batches können bis zu 1.000 Events enthalten, und jedes Event braucht eine eindeutige ID, einen Typ und einen Zeitstempel. Wichtig ist auch Deduplication: Wenn Pixel und Conversions API dieselbe Conversion senden, sollen Pixel-`event_id` und API-`id` übereinstimmen.

Für deutsche Unternehmen ist das zugleich ein Datenschutz- und Governance-Thema. Vor dem Livegang müssen Consent-Management, Datenschutzerklärung, Auftrags- und Rechtsgrundlagenprüfung, Opt-out-Logik und Datenminimierung sauber bewertet werden. OpenAI nennt optionale User-Felder zur Verbesserung der Attribution, aber optional heißt nicht automatisch sinnvoll. Wer ChatGPT Ads testet, sollte mit einem minimalen, rechtlich geprüften Event-Set starten: Page View, Content View, Add to Cart, Checkout Start, Purchase oder Lead. Erst wenn diese Events sauber laufen, lohnt sich ein breiteres Custom-Event-Modell.

Advertiser API: Kampagnen werden programmierbar

Neben der Messung dokumentiert OpenAI eine Advertiser API. Laut Quickstart können Kampagnen programmatisch erstellt und Ergebnisse überwacht werden. Die Struktur ist vertraut: Ads liegen in Ad Groups, Ad Groups liegen in Campaigns. Kampagnen und Ad Groups definieren Budget und Targeting, während Ads Titel, Beschreibung und Bilder tragen.

Für große Händler ist das relevanter als eine manuelle Oberfläche. Wenn Produktdaten, Preise und Verfügbarkeit dynamisch sind, werden auch Anzeigen-Assets und Kampagnenlogik dynamischer. Denkbar sind Feeds, die nicht nur Produkte an ACP liefern, sondern zusätzlich Creative- und Kampagnenbausteine für Ads vorbereiten: Produktgruppen, saisonale Aktionen, Bestseller, Margencluster, Lagerdruck oder regionale Verfügbarkeit. Trotzdem sollte man hier vorsichtig bleiben. Nur weil eine API Kampagnen programmatisch ermöglicht, sollte nicht jede Produktänderung automatisch eine Anzeigenänderung auslösen.

Die sinnvolle Governance ähnelt Performance-Marketing-Automation in anderen Kanälen: klare Freigabegrenzen, Budget-Limits, Namenskonventionen, Creative-Qualitätsregeln, UTM-Standards, Reporting-Owner und Monitoring. Besonders wichtig ist die Trennung von Produktwahrheit und Werbeversprechen. Der ACP-Feed sollte den belastbaren Zustand abbilden. Die Anzeige darf diesen Zustand verdichten, aber nicht überdehnen. Wenn Bestand, Lieferzeit oder Promotion nur eingeschränkt gelten, muss das in Zielseite, Feed und Kampagne konsistent sein.

Was sich für die Vorbereitung deutscher Commerce-Teams ändert

Die neue Ads-Schicht verändert die Prioritäten nicht vollständig, aber sie schärft sie. Bisher konnte ein Händler sagen: Wir bereiten Produktdaten vor und warten ab, bis ChatGPT Shopping breiter verfügbar wird. Jetzt kommt hinzu: Wir müssen auch entscheiden, ob ChatGPT als Paid-Kanal getestet werden soll und welche Messlogik dafür nötig ist. Das betrifft nicht nur Performance Marketing, sondern auch Data Engineering, Consent Management, CRM, BI und Shop-Operations.

Ein pragmatischer Startpunkt ist ein gemeinsames Readiness-Dokument. Darin sollten Teams festhalten, welche Produktgruppen für ACP geeignet wären, welche Kategorien aufgrund von Policy, Alter, Regulierung oder Margenlogik ausgeschlossen werden, welche IDs in Feed, Shop und Analytics genutzt werden, welche Events gemessen werden dürfen und welche Zielseiten für ChatGPT-Traffic geeignet sind. Gerade bei deutschen Shops lohnt sich außerdem ein Blick auf Sprache, Lieferland, Retourenbedingungen, Bruttopreise, Versandkosten und Widerrufsinformationen. Ein ChatGPT-Nutzer stellt häufig konkrete Vergleichsfragen; unklare Nebenkosten oder unvollständige Policy-Seiten sind dann nicht nur rechtlich unschön, sondern auch conversion-schädlich.

Für SEO- und Content-Teams bedeutet das: klassische Produktdetailseiten bleiben wichtig, aber sie sind nicht mehr der einzige Ort, an dem Relevanz entsteht. Produktdaten, Anzeigenkontext, Messdaten und Landingpage-Erfahrung bilden einen gemeinsamen Entscheidungsraum. Wer in ChatGPT sichtbar sein will, sollte nicht nur Texte für Rankings optimieren, sondern maschinenlesbare Produktwahrheit, klare Angebotslogik und messbare Nutzerpfade aufbauen.

Policy-Grenzen: nicht jeder Katalog passt in ChatGPT

OpenAI nennt im Get-started-Leitfaden eine Prohibited-Products-Policy. ChatGPT soll laut Dokumentation ein sicherer Ort bleiben; erlaubt sind nur Produkte und Dienstleistungen, die legal, sicher und für ein allgemeines Publikum geeignet sind. Nicht zugelassen sind unter anderem Adult Content, altersbeschränkte Produkte wie Alkohol, Nikotin oder Glücksspiel, gefährliche Materialien, Waffen, verschreibungspflichtige Medikamente, nicht lizenzierte Finanzprodukte, gesetzlich eingeschränkte Güter, illegale Aktivitäten und täuschende Praktiken.

Händler bleiben verantwortlich dafür, dass Produkte und Inhalte diese Einschränkungen und geltendes Recht einhalten. OpenAI kann laut Dokumentation Korrekturmaßnahmen ergreifen, zum Beispiel Produkte entfernen oder Verkäufer aus ChatGPT-Oberflächen ausschließen, wenn Policies verletzt werden. Für deutsche Unternehmen heißt das: ACP-Onboarding ist nicht nur ein IT-Projekt. Legal, Compliance, Category Management und Marketplace Operations müssen früh eingebunden werden.

Besonders wichtig ist die Grenzziehung bei Sortimenten mit Mischkatalogen. Ein Händler kann harmlose und problematische Kategorien nebeneinander führen. Dann reicht es nicht, einen vollständigen Shop-Export blind in einen Feed zu kippen. Es braucht Eligibility-Regeln, Category-Filter, Prüfprozesse und eine saubere Dokumentation, warum bestimmte Produkte an ChatGPT geliefert oder ausgeschlossen werden.

Was deutsche Händler jetzt konkret vorbereiten sollten

Der erste Schritt ist kein API-Projekt, sondern ein Datenqualitätsaudit. Gibt es stabile Produkt- und Varianten-IDs? Sind Parent-Produkte und kaufbare Varianten sauber getrennt? Sind Preise in allen Märkten korrekt modelliert? Ist Verfügbarkeit aktuell? Haben Produkt- und Variantenbilder stabile URLs? Sind Policy-Seiten öffentlich erreichbar und langlebig? Gibt es eine klare Regel für gelöschte, ausgelaufene oder nicht eligible Produkte?

Der zweite Schritt ist eine Feed-Architektur. Große Händler sollten einen vollständigen Snapshot aufbauen, der mindestens täglich erzeugt werden kann. Danach braucht es einen Delta- oder Event-Kanal für API-Updates: Preis, Bestand, Promotion, Variantendaten, Bilder und Seller-Links. Diese Architektur sollte mit Monitoring, Validierung, Fehlerreports, Request-Ids und Replays geplant werden. Sonst entsteht schnell ein Kanal, der zwar funktioniert, aber nicht zuverlässig betrieben werden kann.

Der dritte Schritt ist Governance. Commerce, SEO, Data Engineering, Recht, Datenschutz und Analytics müssen denselben Begriff von Produktwahrheit haben. ACP ist kein Ersatz für PIM, Shop, ERP oder Feed-Management. Es ist ein weiterer Ausgabekanal für agentische Einkaufssituationen. Wer ihn ernst nimmt, muss ihn wie einen produktiven Marktplatzkanal behandeln: mit Owner, SLA, Datenqualitäts-KPIs, Policy-Filtern, Tracking und regelmäßiger Prüfung.