Product Feed: Zweck, Datenmodell, Schlüsselfelder und Richtlinien

1. Warum man überhaupt einen Product Feed braucht

Verglichen mit klassischem E‑Commerce ist der Product Feed eine Mischung aus:

• „Schaufenster“ der Produkte (Katalog mit Preisen, Verfügbarkeit, Links und Medien);
• und einem technischen Vertrag, der beschreibt, welche SKU der Merchant über ChatGPT anzeigen und/oder verkaufen möchte.

OpenAI sagt in seiner Spezifikation ausdrücklich, dass der Feed die Single Source of Truth für Produkte ist, auf die sich Suche, Empfehlungen und die Vorbereitung der Checkout‑Daten stützen.

In einem gewöhnlichen Online‑Shop navigiert der Nutzer selbst, blättert durch Kategorien, filtert usw. In AI‑Commerce ist es umgekehrt: Der Nutzer sagt dem Modell einfach „Finde mir ein digitales Geschenk bis 30 US‑Dollar für einen befreundeten Entwickler, der Brettspiele liebt“ – und ChatGPT entscheidet selbst, welche SKU aus Ihrem Product Feed passen, in welcher Reihenfolge sie gezeigt werden und wie das alles als Karten und anschließender Instant Checkout aufbereitet wird.

Deshalb löst der Product Feed mehrere Aufgaben auf einmal.

Erstens liefert er ChatGPT strukturierte Daten für die Suche. Das Modell stützt sich nicht nur auf Titel und Beschreibung, sondern auch auf Kategorien, Tags, Preis, Verfügbarkeit, Locale und Ländereinschränkungen.

Zweitens ist er die Datenquelle für den Checkout. Wenn ChatGPT beginnt, eine checkout_session vorzubereiten, werden genau aus dem Feed die SKU‑IDs, der Preis, die Währung, die seller URL und weitere kaufmännische Informationen entnommen.

Und schließlich ist der Product Feed ein formalisierter Vertrag zwischen Ihnen und der Plattform. Sie sagen explizit: „Hier ist die Liste der SKU; diese dürfen nur gesucht (Discovery) werden, jene dürfen zusätzlich über Instant Checkout abgewickelt werden.“

Um das zu veranschaulichen, zeichnen wir ein einfaches Schema.

flowchart TD
  A[GiftGenius DB] --> B[Feed Builder]
  B --> C["Product Feed (CSV/JSON/...)"]
  C --> D[OpenAI Ingestion]
  D --> E[Suchindex + Ranking]
  E --> F[ChatGPT/Agent wählt Geschenke aus]
  F --> G["Instant Checkout (ACP)"]

Links – Ihre interne Datenbank, in der der „echte“ Katalog bereits lebt. Rechts – ChatGPT, das dem Nutzer angezeigt wird. Dazwischen – der Product Feed sowie die Mechanismen zu dessen Übernahme und Indexierung. Alles, was wir in dieser Vorlesung tun, liegt genau zwischen A und D.

2. Formate und „Physik“ des Product Feed

Die OpenAI‑Spezifikation ist beim Dateiformat recht flexibel: TSV, CSV, XML und JSON werden unterstützt. Das ist Absicht, damit die meisten vorhandenen Systeme (von Eigenbau‑Monolithen bis Shopify) ohne Hokuspokus exportieren können.

Typischerweise gilt:

• Sie stellen eine Datei oder einen Endpoint mit dem Product Feed auf Ihrem HTTPS‑Server bereit;
• diese Adresse registrieren Sie im ChatGPT Merchants‑Portal;
• OpenAI holt den Feed regelmäßig ab, validiert und indexiert die Produkte.

Die Dokumentation betont, dass der Feed regelmäßig aktualisiert werden sollte (gern alle 10–15 Minuten), damit Nutzer aktuelle Preise und Verfügbarkeiten sehen – insbesondere zu Sales und in Peak‑Zeiten.

Im Lehrbeispiel mit GiftGenius arbeiten wir mit JSON, weil es TypeScript‑Entwicklern gut liegt. Wichtig ist aber: Auf Spezifikationsebene ist OpenAI nicht an JSON gebunden; es ist für uns nur bequemer.

Ein einfachster JSON‑Feed könnte so aussehen:

[
  {
    "id": "gg-coffee-sub-1m-usd",
    "title": "Kaffee-Abonnement für 1 Monat",
    "description": "Monatliche Box mit Bohnenkaffee für Entwickler.",
    "price": 2900,
    "currency": "usd",
    "availability": "in_stock",
    "link": "https://giftgenius.app/gifts/coffee-subscription-1m",
    "image_link": "https://cdn.giftgenius.app/images/coffee-1m.png",
    "enable_search": true,
    "enable_checkout": true
  }
]

In der Realität gibt es mehr Felder; einige sind verpflichtend, andere empfohlen oder optional. Wie das organisiert ist, sehen wir gleich.

3. Produkt vs. Variante (SKU): wie man das modelliert

Eine der häufigsten Fragen: „Wie bilde ich Größen, Bundles, Abodauern und andere Varianten eines Produkts im Product Feed ab?“

Die Product‑Feed‑Spezifikation arbeitet mit Zeilen/Records, von denen jeder eine verkaufbare Konfiguration beschreibt. Das in der Branche empfohlene Architektur‑Muster (und gut mit dem OpenAI‑Feed kompatibel) lautet: Jede Konfiguration (Größe, Abovariante, Tarif, Region) ist ein eigener Feed‑Record, also eine eigene SKU.

Das Basisprodukt lebt in Ihrem internen Modell, im Feed arbeiten Sie auf SKU‑Ebene.

Angenommen, Sie haben einen Dienst mit Abos für 1, 3 und 6 Monate. Aus Sicht des Product Feed sind das unterschiedliche SKU. Wenn ein Dienst unter 20 verschiedenen Bedingungen gekauft werden kann, sollten Sie 20 SKU im Product Feed haben.

In TypeScript könnte man das ungefähr so ausdrücken:

// Interne GiftGenius‑Modell
export interface GiftProduct {
  id: string;              // product_123
  name: string;
  description: string;
  baseImageUrl: string;
}

// SKU, das in den Product Feed geht
export interface GiftSkuFeedItem {
  id: string;              // product_123_usd_1m
  productId: string;       // Verweis auf GiftProduct.id
  title: string;
  description: string;
  price: number;           // in kleinsten Einheiten (Cent)
  currency: string;        // "usd"
}

In GiftGenius kann es eine 1:n‑Beziehung zwischen GiftProduct und GiftSkuFeedItem geben. Im Feed liefern Sie dann eine „flache“ Liste von SKU aus.

Damit ChatGPT erkennen kann, welche SKU zu einem Basisprodukt gehören (z. B. Abo über 1, 3 und 12 Monate), wird häufig ein Gruppierungsfeld wie item_group_id verwendet. Das ist jedoch ein Architektur‑Pattern und keine harte Vorgabe des Standards.

Zum Beispiel:

{
  "id": "gg-coffee-sub-1m-usd",                // SKU für ein 1‑Monats‑Abo
  "item_group_id": "gg-coffee-sub",            // Ihr Produkt
  "title": "Kaffee-Abo – 1 Monat",
  "price": 2900,
  "currency": "usd",
  "enable_search": true,
  "enable_checkout": true
}

Und für das 3‑Monats‑Abo:

{
  "id": "gg-coffee-sub-3m-usd",                // SKU für ein 3‑Monats‑Abo
  "item_group_id": "gg-coffee-sub",            // Dieselbe Produkt-ID
  "title": "Kaffee-Abo – 3 Monate",
  "price": 7900,
  "currency": "usd",
  "enable_search": true,
  "enable_checkout": true
}

Dieser Ansatz erleichtert sowohl dem Modell als auch Ihrem Backend die Auftragserzeugung: Die SKU‑ID ist der eindeutige Schlüssel, über den Sie stets die exakte Konfiguration finden, die der Nutzer gekauft hat.

4. Pflichtfelder des Product Feed und ihre Auswirkung auf die UX

In der OpenAI‑Spezifikation werden Felder grob in drei Gruppen unterteilt: verpflichtend (required), empfohlen (recommended) und optional (optional).

Die konkreten Bezeichnungen und Listen sollten Sie stets in der aktuellen Doku prüfen; für Lernzwecke kann man sich an folgendem „Minimalset“ orientieren.

id

title

description

price

currency

link

availability

enable_search

enable_checkout

Wichtiger Punkt: enable_search und enable_checkout trennen die Betriebsmodi logisch.

Wenn enable_search = true, enable_checkout = false ist, kann der Artikel in den Ergebnissen erscheinen, aber beim Kaufversuch wird der Nutzer über Ihren Link (link) auf Ihre Website geschickt – und nicht in den Instant Checkout innerhalb von ChatGPT (wo die Karte bereits hinterlegt ist).

Wenn hingegen enable_checkout = true ist, kann der Artikel – bei Erfüllung der übrigen Bedingungen (unterstützte Region, Währung, valides ACP‑Backend) – direkt in ChatGPT mit ein, zwei Klicks gekauft werden (was die Conversion deutlich erhöht).

Beispiel eines „minimal brauchbaren“ GiftGenius‑Objekts für den Checkout:

{
  "id": "gg-dev-notebook-plain-usd",
  "title": "Minimalistisches Notizbuch für Entwickler",
  "description": "Schwarz, ohne Linien, 120 Seiten. Für alle, die Spezifikationen von Hand schreiben.",
  "price": 1500,
  "currency": "usd",
  "availability": "in_stock",
  "link": "https://giftgenius.app/gifts/dev-notebook",
  "image_link": "https://cdn.giftgenius.app/images/dev-notebook.png",
  "enable_search": true,
  "enable_checkout": true
}

Beachten Sie: Selbst im Beispiel fügen wir ein Bild (image_link) hinzu – formal kann es ein empfohlenes statt ein Pflichtfeld sein, aber ohne Bild leidet die UX spürbar.

5. Empfohlene und optionale Felder: wie man den Feed „schmackhafter“ macht

Pflichtfelder sind „damit es überhaupt funktioniert“. Bleibt man nur dabei, erhält man etwas wie ein minimal valides CSV für die Buchhaltung – aber keine tolle KI‑Vitrine.

Empfohlene Felder umfassen typischerweise:

• Haupt‑ und zusätzliche Bild‑URLs;
• die Produktkategorie (oft auf Basis einer Taxonomie wie „gifts > experiences > online courses“);
• Marke/Merchant‑Name;
• Attribute wie Farbe, Größe, Material;
• Flags für Adult‑Content, Altersbeschränkungen usw.

Je reicher Sie den Artikel beschreiben, desto sinnvollere Antworten kann das Modell generieren. Wenn Sie z. B. explizit angeben, dass das Notizbuch aus recyceltem Papier besteht und „Entwickler unterstützt, die sich um den Planeten sorgen“, kann ChatGPT es gezielt Nutzern empfehlen, die umweltfreundliche Geschenke wünschen.

In GiftGenius könnten wir eine solche SKU wie folgt erweitern:

{
  "id": "gg-dev-notebook-plain-usd",
  "title": "Eco-Notizbuch für Entwickler",
  "description": "Minimalistisches Notizbuch ohne Lineatur, 120 Seiten aus recyceltem Papier.",
  "price": 1500,
  "currency": "usd",
  "availability": "in_stock",
  "link": "https://giftgenius.app/gifts/eco-dev-notebook",
  "image_link": "https://cdn.giftgenius.app/images/eco-dev-notebook.png",
  "category": "gifts > office > notebooks",
  "brand": "GiftGenius Originals",
  "enable_search": true,
  "enable_checkout": true
}

Zusätzliche Attribute wie category und brand verbessern nicht nur die Trefferqualität, sondern helfen auch in der Analytics: Sie sehen, welche Kategorien über ChatGPT besser konvertieren und welche schlechter.

Optionale Felder sind oft sehr szenariospezifisch (z. B. Geoparameter für Preise, über die wir separat sprechen, oder benutzerdefinierte Metadaten). Fügen Sie sie hinzu, wenn das Projekt reift – nicht nur „für den Haken“.

6. Kommerzielle Flags und Discovery‑only‑Modus

Lassen Sie uns die Logik von enable_search und enable_checkout noch einmal klar festhalten, denn sie ist die Brücke zu den nächsten Vorlesungen über ACP und Instant Checkout.

Stellen wir uns vor, Sie starten gerade als ChatGPT‑Merchant. Sie haben einen Geschenkekatalog, aber ACP‑Backend und Delegated Payment sind noch in Arbeit. Sie möchten, dass ChatGPT Ihre SKU bereits jetzt finden kann und Nutzer zur Bezahlung auf Ihre Website weiterleitet.

In diesem Fall:

• veröffentlichen Sie einen Product Feed mit enable_search = true für die gewünschten SKU;
• lassen Sie enable_checkout = false, bis Sie die ACP‑Integration gebaut und zertifiziert haben.

Dann kann ChatGPT Ihre Geschenke in Antworten aufnehmen, Karten anzeigen und einen Link „Zur GiftGenius‑Website wechseln“ anbieten, aber keinen internen Instant‑Checkout‑UI aufbauen.

Wenn Sie Agentic Checkout und Delegated Payment umgesetzt haben, können bestimmte Artikel in den Modus „bereit für Instant Checkout“ wechseln – indem Sie schlicht enable_checkout = true setzen und alle weiteren Datenanforderungen erfüllen (Preis, Währung, seller URL usw.).

Auf Spezifikationsebene werden die Felder aus dem Product Feed verwendet, um line_items und die Summe in der checkout_session zu befüllen.

So wird der Feed zum Feinsteuerungs‑Hebel: welche SKU ChatGPT in welcher Form überhaupt in Ihrem Namen verkaufen darf.

7. Locales, Währungen, Regionen und multiregionale Preise

Sie wissen: Die Welt endet nicht bei en-US und Dollar. In den Modulen zur Lokalisierung haben wir bereits besprochen, wie locale und userLocation die Geschäftslogik beeinflussen. Hier rückt das in den Vordergrund: Produkte können in Deutschland andere Preise haben als in den USA, und manche Geschenke dürfen in bestimmten Ländern gar nicht verkauft werden.

Die Product‑Feed‑Spezifikation berücksichtigt das über mehrere Mechanismen.

Erstens die Währung: currency muss ein gültiger ISO‑4217‑Code sein (z. B. usd, eur, gbp).

Zweitens können Felder verwendet werden, die geobasierte Preise und Verfügbarkeiten beschreiben. In der Dokumentation gibt es Beispiele für Attribute wie geo_price und zugehörige Regionscodes auf Basis von ISO 3166.

Es gibt zwei grundlegende Architekturansätze.

Ansatz eins: ein Feed pro Region.

• product-feed-us-en.json für die USA;
• product-feed-de-de.json für Deutschland;
• product-feed-br-pt.json für Brasilien.

In jedem Feed sind alle SKU bereits an Währung und Locale angepasst. Das ist für ChatGPT einfach, für Sie jedoch mehr Aufwand zur Pflege mehrerer Feeds.

Ansatz zwei: einheitlicher Feed mit Geo‑Feldern.

In jedem Record halten Sie entweder ein Preis‑Array oder zusätzliche Attribute:

{
  "id": "gg-dev-notebook-multi",
  "title": "Eco-Notizbuch für Entwickler",
  "description": "Unterstützt Ihre Liebe zu Clean Code und zum Planeten.",
  "prices": [
    { "region": "US", "currency": "usd", "price": 1500 },
    { "region": "DE", "currency": "eur", "price": 1400 }
  ],
  "availability_by_region": [
    { "region": "US", "availability": "in_stock" },
    { "region": "DE", "availability": "out_of_stock" }
  ],
  "enable_search": true,
  "enable_checkout": true
}

Die konkrete Struktur multiregionaler Felder hängt von der Spezifikationsversion ab, aber die Idee ist dieselbe: Der Feed muss der Plattform ermöglichen zu verstehen, in welchen Ländern eine SKU existiert und was sie dort kostet.

Aus GiftGenius‑Sicht ist es wichtig, ein Mapping zu durchdenken zwischen:

• locale und userLocation, die ChatGPT kennt;
• und dem Feed‑Teil, aus dem Preise und Texte zu entnehmen sind.

In kommerziellen Szenarien geben Sie häufig keine einzige „Welt‑SKU“ aus, sondern erstellen unterschiedliche SKU pro Land, um Steuern, Richtlinien und Produktsperren einfacher einzuhalten.

8. Datenqualität und Richtlinien: ohne das hebt Instant Checkout nicht ab

Der Product Feed betrifft nicht nur das Format, sondern auch die Datenqualität und die Einhaltung der OpenAI‑Richtlinien.

Zur Qualität verlangt OpenAI ausdrücklich:

• korrekte, stabile Bezeichner;
• valide HTTPS‑URLs mit HTTP‑Status 200;
• Konsistenz von Preis und Währung;
• aktuelle Verfügbarkeit (kein in_stock für Artikel, die faktisch bereits ausverkauft sind).

Außerdem gibt es Anforderungen an die Textlängen: title sollte nicht zu lang sein (hunderte Zeichen), description hat ein vernünftiges Limit (tausende Zeichen), damit Karten ordentlich aussehen und nicht zum Roman werden.

Ein eigener Block ist die Prohibited Products Policy. Das ist die Liste der Produkt‑ und Dienstkategorien, die über Instant Checkout und/oder generell über ChatGPT nicht verkauft werden dürfen: offensichtliche Dinge wie illegale Waren, Waffen, bestimmte medizinische Dienstleistungen usw. Prüfen Sie die Details stets in der aktuellen Richtlinie; wichtig ist: Der Product Feed wird nicht nur auf Format, sondern auch auf Zulässigkeit des Inhalts geprüft.

Wenn Ihr Katalog zweifelhafte Kategorien enthält (z. B. Alkohol, Glücksspiel oder Kinder‑Bezug), behandeln Sie diese Bereiche mit besonderer Sorgfalt. Oft ist es einfacher, sie im Modus enable_checkout = false zu belassen und ausschließlich über die eigene Website mit vollständiger juristischer Absicherung zu verkaufen.

9. Praxis: wir bauen einen minimalen Product Feed für GiftGenius

Wenden wir das nun praktisch an und bauen einen einfachen Feed für drei GiftGenius‑SKU. Angenommen, wir haben:

1. Eco‑Notizbuch für Entwickler.
2. Kaffee‑Abo für 1 Monat.
3. Geschenkgutschein für den Kurs „TypeScript für Erwachsene“.

Zuerst definieren wir den TypeScript‑Typ, den wir zur Feed‑Generierung verwenden:

export interface GiftGeniusFeedItem {
  id: string;
  title: string;
  description: string;
  price: number;         // in Cent
  currency: "usd" | "eur";
  availability: "in_stock" | "out_of_stock";
  link: string;
  image_link?: string;
  enable_search: boolean;
  enable_checkout: boolean;
}

Jetzt erstellen wir im Code ein Array mit einigen Einträgen und serialisieren es anschließend zu JSON:

export const giftGeniusFeed: GiftGeniusFeedItem[] = [
  {
    id: "gg-eco-notebook-usd",
    title: "Eco-Notizbuch für Entwickler",
    description: "Minimalistisches Notizbuch ohne Lineatur aus recyceltem Papier.",
    price: 1500,
    currency: "usd",
    availability: "in_stock",
    link: "https://giftgenius.app/gifts/eco-dev-notebook",
    image_link: "https://cdn.giftgenius.app/images/eco-dev-notebook.png",
    enable_search: true,
    enable_checkout: true
  },
  {
    id: "gg-coffee-sub-1m-usd",
    title: "Kaffee-Abo für Entwickler – 1 Monat",
    description: "Monatliche Box mit Bohnenkaffee. Kompatibel mit Deadlines.",
    price: 2900,
    currency: "usd",
    availability: "in_stock",
    link: "https://giftgenius.app/gifts/coffee-subscription-1m",
    image_link: "https://cdn.giftgenius.app/images/coffee-1m.png",
    enable_search: true,
    enable_checkout: true
  },
  {
    id: "gg-ts-course-gift-usd",
    title: "Geschenkgutschein für den TypeScript-Kurs",
    description: "Online-Kurs für Entwickler, die Generics endlich verstehen wollen.",
    price: 9900,
    currency: "usd",
    availability: "in_stock",
    link: "https://giftgenius.app/gifts/ts-course",
    image_link: "https://cdn.giftgenius.app/images/ts-course.png",
    enable_search: true,
    enable_checkout: false // vorerst nur Discovery
  }
];

Anschließend kann man ein einfaches Tool bauen, das alle N Minuten die Datei product-feed.json aus dieser Struktur generiert und auf Ihren HTTPS‑Server legt.

import { writeFile } from "node:fs/promises";
import { giftGeniusFeed } from "./feed-data";

// Ein einfachster JSON‑Feed‑Generator
async function buildProductFeed() {
  const json = JSON.stringify(giftGeniusFeed, null, 2);
  await writeFile("public/product-feed.json", json, "utf8");
}

buildProductFeed().catch(console.error);

Klar ist: Im realen Projekt werden Sie den gesamten Feed nicht im Code halten; stattdessen stammen die Daten aus der DB. Für den Anfang ist so ein Lehrbeispiel aber hilfreich, um die Pipeline zu testen: Generierung → Bereitstellung → Validierung.

10. Anti‑Beispiel: wie ein „schlechter“ Product Feed aussieht

Um Spezifikationsanforderungen und UX besser zu spüren, hilft ein Feed‑Beispiel, das formal fast funktioniert, in der Praxis aber zu Problemen führt:

{
  "id": "1",
  "title": "Geschenk",
  "description": "Tolles Geschenk",
  "price": 12.333333,
  "currency": "usdollars",
  "availability": "yes",
  "link": "http://giftgenius.local/gift/1",
  "enable_search": "true",
  "enable_checkout": "maybe"
}

Hier lassen sich gleich mehrere Probleme zählen.

Erstens ist id = "1" ein instabiler und wenig aussagekräftiger Bezeichner. Migrieren Sie irgendwann die DB oder führen Sharding ein, werden solche IDs fragil. Besser sind sinnvolle, ausreichend lange IDs, die innerhalb des Merchants eindeutig sind.

Zweitens ist price als Dezimalzahl mit endlosem Nachkommateil angegeben. Spezifikationen und Bezahlsysteme erwarten den Preis üblicherweise als Ganzzahl in kleinsten Einheiten (Cent), um Probleme mit Gleitkomma und Rundung zu vermeiden.

Drittens entsprechen currency = "usdollars" und availability = "yes" nicht den erwarteten Formaten (ISO‑4217 und die Liste zulässiger Statuswerte).

Viertens zeigt link auf http und eine lokale Domain – beides ist für echten Production‑Betrieb inakzeptabel; die Spezifikation fordert explizit HTTPS und öffentliche Erreichbarkeit.

Fünftens müssen die Flags enable_search und enable_checkout boolean sein, nicht Strings. Andernfalls lehnt der OpenAI‑Parser den Feed ab oder wendet Default‑Werte an, die Sie unangenehm überraschen können.

Solche Probleme können zu harter Validierungsfehlermeldung (Feed abgelehnt) führen oder zu einer unangenehmeren Situation: Der Feed wird formal akzeptiert, aber ein Teil der SKU wird ignoriert oder funktioniert anders als erwartet. Investieren Sie deshalb in interne Validierung – schon auf Ihrer Seite.

11. Typische Fehler beim Arbeiten mit dem Product Feed

Fehler Nr. 1: den Feed als „einmaliges CSV“ für den Import betrachten.
Manche Teams sehen den Product Feed als Datei, die sie einmal für die „Integration“ generieren und dann vergessen. Im AI‑Commerce ist das anders: Der Feed ist eine lebendige Quelle der Wahrheit und muss regelmäßig aktualisiert werden. Wenn Sie Preise ändern, Produkte auslisten, Promo‑Aktionen starten – all das muss zeitnah in den Feed. Sonst empfiehlt ChatGPT Dinge, die es nicht mehr gibt oder zum alten Preis, und Nutzer werden zu Recht verärgert.

Fehler Nr. 2: Produkt‑ und SKU‑Modell vermischen.
Ein verbreitetes Anti‑Pattern ist, ein Basisprodukt mit vielen Optionen in einem einzigen Feed‑Record mit zahllosen Feldern wie „size1/size2/size3“ oder „duration1/duration2“ abzubilden. Das Modell versteht dann nicht, was genau verkauft wird, und Ihr ACP‑Backend leidet beim Entpacken dieser Felder im Checkout. Viel einfacher und robuster: eine SKU – ein Feed‑Record, selbst wenn es nur eine Variante innerhalb eines Produkts ist.

Fehler Nr. 3: Locales und Regionen ignorieren.
Teams, die ein erstes MVP bauen, setzen oft currency = "usd" und enable_checkout = true für alles – ohne zu bedenken, dass Instant Checkout in Ihrer Region evtl. nicht verfügbar ist oder manche Produkte in bestimmten Ländern aus Richtlinien‑ oder Rechtsgründen nicht verkauft werden dürfen. Beim Markteintritt in neue Länder bricht dann vieles: Preise passen nicht, Steuern fehlen. Binden Sie SKU von Anfang an an Regionen und Währungen – auch wenn Sie zunächst nur einen Markt bedienen.

Fehler Nr. 4: Beschreibungen wie alte SEO‑Texte behandeln.
Einige Teams kopieren in den Product Feed alte Website‑Texte, teils für „Keywords“ und Bots verfasst. Für ChatGPT ist das eher schädlich als nützlich: Das Modell kann Texte selbst schreiben; ihm sind strukturierte, ehrliche und präzise Fakten wichtiger. Beschreiben Sie lieber kurz und knackig als description mit Marketing‑Wasser zu fluten.

Fehler Nr. 5: den Feed nicht selbst validieren.
Sich nur auf die OpenAI‑Validierung zu verlassen, führt zu schmerzhaften Nächten vor Deadlines. Bauen Sie einen einfachen Validator in Ihrem Backend oder CI, der Schemas, zulässige Werte sowie Formate von URL und Währung prüft. Das geht sogar in TypeScript, z. B. mit Zod oder eigenen Checks. So fangen Sie Probleme ab, bevor der Feed in Prod landet.

Fehler Nr. 6: „alles Mögliche“ in den Product Feed kippen.
Die Versuchung ist groß, gleich Tausende SKU einzustellen – „kann ja nicht schaden“. In der Praxis erschwert das Debugging, Analytics und Qualitätskontrolle. Starten Sie besser mit einem begrenzten Subset: nur die Kategorien und SKU, die Sie wirklich verkaufen möchten und im Blick behalten. Den Rest lassen Sie im Discovery‑Modus oder integrieren ihn gar nicht.

Fehler Nr. 7: Product Feed und ACP‑Backend nicht synchron halten.
Feed und ACP‑API sind zwei Seiten derselben Medaille. Wenn im Feed eine neue SKU auftaucht, Ihr Backend sie aber noch nicht verkaufen kann (oder umgekehrt: SKU aus dem Feed entfernt, aber das Backend glaubt, sie existiere), entstehen Desynchronisation, fiese Bugs und Support‑Tickets. Gute Praxis ist ein einheitliches Domänenmodell für den Katalog zu haben und es sowohl zur Feed‑Generierung als auch für die Checkout‑Verarbeitung zu verwenden.