Produktdaten für KI-Shopping: Was Feeds liefern müssen

Ein KI-Shopping-Assistent empfiehlt kein Produkt, das er nicht eindeutig identifizieren, vergleichen und belastbar beschreiben kann. Wer fragt „Welche wasserdichte Laufjacke unter 150 Euro eignet sich für breite Schultern?“, bekommt keine Trefferliste, sondern eine Auswahl von zwei oder drei Artikeln. Was in diese Auswahl gelangt, entscheidet sich an der Datenlage: an Attributen, Kennungen, Preisen, Verfügbarkeit und an der Frage, ob Feed und Produktseite dasselbe sagen.

Dieser Beitrag beantwortet genau diese Frage: Welche Produktdaten brauchen Assistenten und Agenten, damit ein Shop überhaupt in Betracht kommt? Die Einrichtung eines Händlerkontos und die Feed-Übermittlung im Detail lassen wir bewusst beiseite. Es geht um den Inhalt der Daten, nicht um den Zugang zu einer bestimmten Plattform.

Warum Produktdaten für Assistenten anders wirken als für Suchergebnisse

Eine klassische Suchergebnisseite zeigt zehn Links und überlässt dem Menschen den Vergleich. Ein Assistent nimmt ihm diesen Schritt ab. Er muss aus einer Anfrage in natürlicher Sprache Kriterien ableiten, Kandidaten finden, sie gegeneinander abwägen und am Ende einen Vorschlag begründen. Jeder dieser Schritte stützt sich auf strukturierte Fakten, nicht auf Werbetext.

Daraus folgt eine unbequeme Verschiebung: Ein brillanter Produkttext hilft wenig, wenn die Eigenschaften, die er beschreibt, nirgends als Attribut stehen. Der Satz „Perfekt für lange Wandertage bei jedem Wetter“ lässt sich kaum filtern. Ein Attribut wie Wasserdichtigkeit, Material, Gewicht und Passform lässt sich filtern, vergleichen und zitieren. Assistenten greifen deshalb dort zu, wo Eigenschaften eindeutig benannt sind.

Hinzu kommt ein Vertrauensproblem. Ein Assistent, der einen falschen Preis oder einen nicht lieferbaren Artikel nennt, verliert das Vertrauen seiner Nutzer. Systeme, die Empfehlungen aussprechen, haben daher ein Eigeninteresse, Quellen zu bevorzugen, deren Angaben sich prüfen lassen: durch einen Abgleich zwischen Feed, Seite und markiertem Code. Niemand außerhalb der Anbieter kennt die genaue Gewichtung, und wer sie zu kennen behauptet, rät. Die Mechanik dahinter lässt sich aber beschreiben, und sie gibt die Prioritäten vor.

Identität zuerst: GTIN, Marke und MPN

Bevor ein System ein Produkt bewerten kann, muss es wissen, um welches Produkt es sich handelt. Die wichtigste Kennung dafür ist die GTIN, also die Nummer hinter dem Barcode: in Europa meist als 13-stellige EAN, daneben UPC, ISBN bei Büchern oder die kurze 8-stellige Variante. Sie verbindet dein Angebot mit demselben Artikel bei anderen Händlern, mit Bewertungen, Testberichten und Katalogeinträgen des Herstellers.

Ohne GTIN bleibt dein Angebot ein Einzelfall, den das System nur über Titel und Bild zuordnen kann. Das ist fehleranfällig. Mit GTIN wird dein Shop zu einem von mehreren Anbietern eines eindeutig bekannten Artikels, und genau dort setzen Preisvergleiche, Bewertungsaggregation und Empfehlungen an.

Ein Stolperstein ist die Qualität der Nummer selbst. Eine GTIN hat eine Prüfziffer; erfundene oder falsch abgetippte Nummern fallen bei der Validierung durch. Noch häufiger ist ein Fehler, der syntaktisch sauber aussieht: Die Nummer gehört zu einem anderen Produkt, etwa weil ein Hersteller sie für mehrere Varianten wiederverwendet hat oder weil ein Bündel dieselbe Nummer wie der Einzelartikel bekommen hat. Prüfe deshalb Stichproben gegen die Herstellerangaben, statt dem Stammdatensystem blind zu trauen.

Neben der GTIN zählen Marke und Herstellernummer (MPN). Die Marke muss als eigenes Feld stehen, nicht nur im Titel. Die MPN hilft bei Artikeln, die keine GTIN tragen, etwa bei Ersatzteilen, Industrie- und Handwerksware. Für Eigenmarken und handgefertigte Produkte ohne Barcode gibt es in den Feed-Spezifikationen meist eine Kennzeichnung, dass keine Kennung existiert. Nutze sie ehrlich, statt Nummern zu erfinden.

Die Attribute, nach denen Menschen tatsächlich fragen

Die Pflichtfelder eines Feeds reichen für ein Listing, aber selten für eine Empfehlung. Den Unterschied macht die Tiefe. Hilfreich ist eine einfache Übung: Sammle zwanzig Fragen, die Kunden vor dem Kauf stellen, im Support, im Chat, in Bewertungen, und prüfe, ob die Antwort jeweils als Attribut in deinen Daten steht.

Bei Laufjacken lauten die Antworten vielleicht: Material, Wassersäule, Gewicht, Geschlecht und Größensystem, Passform, Kapuze ja oder nein, Verpackungsmaß. Bei einem Wasserkocher: Fassungsvermögen, Leistung, Material des Innenraums, Abschaltautomatik. Bei Kosmetik: Inhaltsstoffe, Hauttyp, Volumen, Vegan-Kennzeichnung. Je klarer eine Antwort als Wert im Feld steht, desto eher kann ein Assistent sie in eine Empfehlung übersetzen.

Ein Beispiel zeigt den Unterschied. Ein Shop für Kaffeezubehör führt eine Handmühle mit dem Titel „Präzisions-Kaffeemühle Premium“. Im Feed steht nur der Preis. Ein Nutzer fragt den Assistenten nach einer Handmühle für Espresso unter 80 Euro, die sich für Reisen eignet. Der Assistent findet in den Daten weder den Mahlwerkstyp noch das Gewicht noch die Einstellbarkeit des Mahlgrads. Ein Wettbewerber hat Keramik- oder Stahlmahlwerk, 380 Gramm, stufenlose Einstellung und Fassungsvermögen sauber hinterlegt und wird genannt, obwohl sein Produkt nicht besser sein muss. Der Unterschied liegt allein darin, dass seine Eigenschaften lesbar sind.

Die Attribute, bei denen die meisten Shops Lücken lassen, sind meist dieselben:

• Farbe, Größe, Material und Geschlecht als getrennte Felder, nicht im Titel versteckt.
• Zielgruppe und Anwendungsfall, etwa Anfänger oder Profi, Innenraum oder Außenbereich.
• Maße, Gewicht und Kapazität mit Einheit, in einem einheitlichen Format.
• Kompatibilität: passt zu welchem Modell, welcher Marke, welcher Version.
• Mengen und Bündel: Stückzahl, Packungsgröße, enthaltenes Zubehör.
• Ein Produkttyp, der deine eigene Kategorie beschreibt, zusätzlich zur Einordnung in die Plattform-Taxonomie.

Titel und Beschreibung: eindeutig statt werblich

Der Titel ist kein Slogan, sondern eine Identifikation. Eine bewährte Reihenfolge lautet: Marke, Produktart, wichtigste Unterscheidungsmerkmale, Variante. „Nordwind Trail-Regenjacke Herren, wasserdicht, Schwarz, Größe L“ ist für Mensch und Maschine lesbar. „Der Bestseller für dein nächstes Abenteuer“ sagt beiden nichts.

In der Beschreibung ist Fließtext erlaubt, aber er sollte Fakten enthalten, die zu den Attributen passen, und keine Abweichungen einführen. Wenn im Feed „Polyester“ steht und der Text „100 % Baumwolle“ behauptet, hast du ein Konsistenzproblem, das im schlimmsten Fall zur Ablehnung des Artikels führt und im günstigsten Fall das Vertrauen in deine Daten senkt.

Vermeide Versprechen, die sich nicht belegen lassen, sowie Werbebegriffe in Großbuchstaben. Schreibe stattdessen, was das Produkt kann, woraus es besteht und wofür es gedacht ist. Ein Satz wie „geeignet für Hauttypen mit Neigung zu Trockenheit, ohne Parfüm“ liefert einem Assistenten Material, das er in einer Antwort wiederverwenden kann.

Strukturierte Daten auf der Produktseite: Schema.org sauber umsetzen

Der Feed ist nur eine Datenquelle. Die Produktseite ist die zweite, und sie ist diejenige, die jeder Crawler ohne Kontoanbindung sehen kann. Mit dem Schema.org-Typ Product im JSON-LD-Format beschreibst du dort dieselben Fakten maschinenlesbar. Mindestens gehören dazu Name, Bild, Beschreibung, Marke, SKU, GTIN in der passenden Schreibweise sowie ein Offer mit Preis, Währung und Verfügbarkeit.

Wichtiger als der Umfang ist die Übereinstimmung. Der Preis im Markup muss dem sichtbaren Preis auf der Seite entsprechen und dem im Feed. Die Verfügbarkeit muss stimmen, sobald ein Artikel ausverkauft ist. Wer Preise per JavaScript nachlädt oder Varianten erst nach einem Klick anzeigt, sollte prüfen, was ein Crawler im gerenderten Zustand tatsächlich sieht.

Für Shops mit Varianten lohnt sich das Modell ProductGroup mit den einzelnen Varianten darunter. Es verbindet zum Beispiel dieselbe Jacke in vier Farben und fünf Größen zu einer Produktfamilie und hält zugleich jede Variante mit eigener GTIN und eigenem Preis auseinander. Ohne diese Struktur behandeln Systeme jede Kombination schnell als eigenständiges Produkt oder werfen sie zusammen.

Ergänze die Angaben, die eine Kaufentscheidung tragen: Versandkosten und Lieferzeit über die Versanddetails am Angebot, Rückgaberegeln über eine Rückgaberichtlinie, Bewertungen als Gesamtwert samt Anzahl. Ein Assistent, der den Nutzer fragt, ob er das Produkt im Zweifel zurückschicken kann, braucht diese Antwort als Datum und nicht als Fließtext in den AGB.

Zwei Grenzen sollte man kennen. Erstens steigert Markup nicht automatisch die Reichweite; es macht Angaben lesbar und prüfbar, mehr nicht. Zweitens dürfen markierte Inhalte nicht erfunden oder versteckt sein. Bewertungen, die auf der Seite nicht erscheinen, sind ein Verstoß gegen die Richtlinien der Suchmaschinen und gefährden im Zweifel die gesamte Darstellung.

Feed-Qualität: Aktualität und Konsistenz vor Vollständigkeit

Bei Feeds entscheidet selten die Zahl der befüllten Felder, sondern ihre Verlässlichkeit. Drei Dinge gehören auf die tägliche Prüfliste.

Erstens die Aktualität. Preis und Bestand ändern sich schneller, als ein nächtlicher Export sie nachzieht. Wird ein Artikel empfohlen, der beim Klick nicht mehr lieferbar ist oder mehr kostet, ist das für den Assistenten ein Fehler, der auf ihn zurückfällt. Viele Plattformen bieten deshalb Wege für häufigere Aktualisierungen von Preis und Verfügbarkeit, als sie für den Vollabgleich vorsehen. Prüfe, was dein System unterstützt, und richte die Taktung nach der Volatilität deines Sortiments, nicht nach der Bequemlichkeit des Exports.

Zweitens die Konsistenz. Dasselbe Produkt sollte in Feed, Produktseite, Markup und Checkout dieselben Werte haben: Preis, Währung, Steuerangabe, Größe, Verfügbarkeit und Bilder. Abweichungen entstehen meist an Nahtstellen, etwa wenn ein Rabatt nur im Shop, nicht im Feed ankommt oder wenn die Seite Bruttopreise zeigt und der Feed Nettopreise liefert.

Drittens die Bildqualität. Ein Produktbild auf neutralem Grund, ausreichend groß, ohne Wasserzeichen und ohne Werbetext, ist nicht nur eine Richtlinienfrage. Visuelle Modelle lesen Bilder mit, und ein klares Hauptbild plus Varianten- und Anwendungsbilder liefern zusätzliche Hinweise auf Farbe, Form und Größe. Jede Variante braucht ihr eigenes Bild, sonst wird der Kontext falsch zugeordnet.

Zuletzt lohnt ein Blick auf Fehlerquellen bei Pflege und Verantwortung. Datenqualität scheitert selten an Technik, sondern daran, dass niemand zuständig ist: Der Einkauf pflegt Stammdaten, das Marketing den Feed, die Entwicklung das Markup, und jeder nimmt an, die anderen prüften den Rest. Benenne eine Person, die für die Übereinstimmung aller drei Quellen verantwortlich ist, und lege fest, wie Änderungen an Preisen, Varianten und Lieferbedingungen an alle Stellen gelangen. Eine einfache Regel hilft dabei: Jede Information hat genau eine führende Quelle, und alle anderen Ausgaben werden daraus erzeugt, nie von Hand nachgezogen.

Agentischer Checkout: Was über die Empfehlung hinaus gebraucht wird

Die nächste Stufe ist nicht mehr die Empfehlung, sondern der Kauf durch einen Agenten. Hier entstehen offene Protokolle, etwa das von OpenAI und Stripe entwickelte Agentic Commerce Protocol sowie Googles Agent Payments Protocol. Die Details ändern sich schnell und unterscheiden sich je Anbieter, weshalb du vor einer Umsetzung die aktuelle Dokumentation des jeweiligen Anbieters lesen solltest. Die Datenanforderungen folgen aber einer gemeinsamen Logik.

Ein Agent, der im Namen eines Nutzers kauft, muss ohne Rückfrage wissen, was genau im Warenkorb landet. Das heißt: eindeutige Variante mit eigener Kennung, verbindlicher Preis samt Steuer und Versandkosten, Lieferzeit, Bestand und Rückgabebedingungen. Jede Unschärfe wird zur Rückfrage oder zum Abbruch.

Drei Punkte verdienen besondere Aufmerksamkeit. Der erste ist die Variantenlogik: Wenn ein Agent Größe M in Schwarz bestellen soll, braucht er eine stabile Kennung genau dieser Kombination. Der zweite ist der Preis am Ende des Checkouts, der dem zuvor genannten entsprechen muss, einschließlich Versand. Der dritte sind Ausschlüsse: Artikel mit Altersbeschränkung, Gefahrgut, Lieferbeschränkungen nach Land oder Sonderanfertigungen sollten als solche gekennzeichnet sein, statt erst beim Bezahlen zu scheitern.

Wer sich mit diesen Protokollen beschäftigen will, tut gut daran, erst die Datenbasis zu bereinigen. Ein Protokoll überträgt nur, was vorhanden ist. Eine Schnittstelle mit unsauberen Varianten und abweichenden Preisen liefert die Fehler lediglich schneller aus.

Plane das Audit als wiederkehrende Aufgabe ein, etwa nach jedem größeren Sortimentswechsel und vor saisonalen Spitzen. Gerade bei Rabattaktionen geraten Preise in Feed, Seite und Markup auseinander, und ein Assistent, der einen veralteten Preis nennt, ist schwer zurückzugewinnen. Halte die Befunde in einer kurzen Liste fest, damit sichtbar wird, welche Fehlerarten wiederkehren und an welcher Stelle der Datenkette sie entstehen.

Ein Audit in einer Stunde: so prüfst du deine eigene Datenlage

Du brauchst keine Spezialwerkzeuge, um die größten Lücken zu finden. Wähle zehn Produkte aus: drei Bestseller, drei Artikel mit Varianten, zwei Randsortimente, zwei Produkte ohne Barcode. Vergleiche jeweils Feed-Eintrag, sichtbare Produktseite und das Markup im Quelltext.

Notiere bei jedem Produkt, ob die GTIN vorhanden und korrekt ist, ob Marke und MPN als eigene Felder stehen, ob Preis, Währung und Verfügbarkeit überall übereinstimmen, ob die Varianten sauber gruppiert sind und ob die zwanzig typischen Kundenfragen beantwortbar wären. Stelle danach die Anfragen probeweise an mehrere Assistenten und schau, welche Produkte genannt werden und welche Angaben dabei fehlen oder falsch sind. Das Ergebnis ist kein Ranking und keine Garantie, aber es zeigt, welche Fakten ein System aus deinen Daten tatsächlich ziehen kann.

Die häufigsten Befunde sind banal: Die GTIN fehlt bei einem Drittel der Varianten, die Farbe steht nur im Titel, der Sale-Preis erreicht den Feed nicht, und die Rückgabefrist steht nur in den AGB. Sie sind behebbar, meist an der Quelle im Warenwirtschafts- oder Shopsystem, und nicht in einzelnen Exporten. Wer nur den Feed nachbessert, aber die Stammdaten belässt, repariert jede Woche dasselbe.