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.
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.
Vergleich
OpenAI-Commerce-Bausteine im Überblick
Praxisfälle
Drei typische Vorbereitungsprojekte
PIM- und Feed-Audit
Prüfen, ob Produkt-IDs, Varianten-IDs, Preise, Verfügbarkeit, Kategorien, Medien und Seller-Links stabil genug sind, um als agentischer Commerce-Feed genutzt zu werden.
Snapshot-plus-Delta-Architektur
Täglichen Full Snapshot per Batch planen und API-Updates für Preise, Bestand, Produktkorrekturen und Promotions als getrennten Echtzeitkanal aufsetzen.
Policy- und Eligibility-Regeln
Kategorien, Länder, Altersbeschränkungen, rechtliche Grenzen und nicht geeignete Produkte vor dem Export filtern, statt Kataloge ungeprüft weiterzugeben.
FAQ
Häufige Fragen
Was ist das Agentic Commerce Protocol?
OpenAI beschreibt ACP als offenen Standard und Verbindungsschicht zwischen Händlern und ChatGPT-Nutzern. Ziel ist, strukturierte Produktdaten so bereitzustellen, dass ChatGPT Kataloge, Attribute, Bestand und relevante Produkte in Shopping-Kontexten verstehen kann.
Kann jeder Händler sofort einen Feed in ChatGPT onboarden?
Laut OpenAI-Dokumentation ist das Onboarding von Produktfeeds in ChatGPT aktuell für genehmigte Partner verfügbar. Händler können sich vorbereiten, sollten aber keinen allgemeinen Sofortzugang voraussetzen.
Sollte man File Upload oder API nutzen?
OpenAI empfiehlt im Allgemeinen den vollständigen Feed einmal täglich per File Upload und Updates im Tagesverlauf per API. Kleine Feeds können auch vollständig über API laufen. Promotions können laut Dokumentation nur per API geliefert werden.
Welche Produktdaten sind besonders wichtig?
Stabile Produkt- und Varianten-IDs, Titel, Beschreibungen, gültige URLs, Medien, Preis, Listenpreis, Verfügbarkeit, Kategorien, Variant Options, Seller-Daten und Policy-Links sind zentrale Bausteine.
Warum sind Varianten so wichtig?
Varianten repräsentieren kaufbare Optionen wie Größe, Farbe oder Material. OpenAI empfiehlt, Varianten mit eigener stabiler ID und variantenspezifischen Werten zu modellieren, wenn Preis, Bild, Beschreibung oder Verfügbarkeit abweichen.
Welche Produkte sind ausgeschlossen?
OpenAI nennt unter anderem Adult Content, altersbeschränkte Produkte, gefährliche Materialien, Waffen, verschreibungspflichtige Medikamente, unlizenzierte Finanzprodukte, gesetzlich eingeschränkte Güter, illegale Aktivitäten und täuschende Praktiken als problematische Kategorien.
Quellen und Herstellerseiten
Weiterführende Quellen
- OpenAI Developers: Agentic Commerce Protocol
- OpenAI Developers: ACP Get Started
- OpenAI Developers: ACP Best Practices
- OpenAI Developers: File Upload Overview
- OpenAI Developers: Product Feed Specification
- OpenAI Developers: Commerce API Overview
- OpenAI Developers: Products API
- OpenAI Developers: Promotions API