Produktdaten für Maschinen: einen MedusaJS-Katalog für KI-Einkaufsagenten strukturieren

Ein Käufer, der auf einer Produktseite landet, füllt die Lücken selbst. Er liest das Foto, schließt von der Marke auf das Material, nimmt an, dass die Lieferzeitangabe für seine Postleitzahl gilt, und fragt nach, wenn er unsicher ist.

Ein Agent, der im Auftrag dieses Käufers einkauft, tut nichts davon. Er liest, was Sie in strukturierter Form veröffentlicht haben, und alles, was fehlt, ist für ihn schlicht nicht wahr. Wenn Ihr Attribut für das Material bei 40 % der SKUs gefüllt ist, sind Sie bei 60 % der nach Material gefilterten Abfragen unsichtbar. Wenn Lieferzeiten als Fließtext dastehen, lassen sie sich nicht vergleichen.

Wer MedusaJS betreibt, ist damit in einer günstigen Lage: Sie steuern Datenmodell und API-Oberfläche direkt, statt mit den Vorgaben einer Plattform zu verhandeln. So nutzen Sie das.

Attribute sind jetzt das Produkt

In einem Medusa-Katalog ist die Versuchung groß, die Storefront Bedeutung tragen zu lassen, die in den Daten nicht steckt — eine hübsch gestaltete Spezifikationstabelle, zusammengesetzt aus einem Beschreibungstext. Für Menschen funktioniert das, für Maschinen nicht.

Die Disziplin dahinter:

• Modellieren Sie Attribute als typisierte Daten erster Klasse, nicht als Freitext in einer Beschreibung. Alles, wonach ein Kunde filtern, was er vergleichen oder wonach er fragen könnte, braucht ein eigenes Feld.
• Verwenden Sie ein kontrolliertes Vokabular. Dreitausend verschiedene Freitext-Farbwerte gruppieren sich zu nichts. Vierundzwanzig definierte Optionen ergeben einen brauchbaren Filter und ein vergleichbares Attribut.
• Füllen Sie die Identifikatoren. Über GTIN, MPN und Marke wird Ihr Produkt demselben Produkt anderswo zugeordnet. Fehlen sie, kann ein Agent nicht bestätigen, dass er wirklich das vor sich hat, was er zu sehen glaubt.
• Geben Sie Einheiten explizit an. 2.5 ist keine Länge. 2.5 m schon.
• Seien Sie ehrlich bei Varianten. Wenn Größe und Farbe wirklich unabhängig voneinander sind, modellieren Sie sie auch unabhängig und nicht als flache Liste vorkombinierter Optionen.

Das meiste davon ist dieselbe Katalogarbeit, die Onsite-Suche und Facettennavigation verbessert — das ist der beruhigende Teil: Sie zahlt sich aus, ob in Ihrer Kategorie je Traffic von Agenten entsteht oder nicht. Die Anreicherungs-Pipeline selbst beschreiben wir in einen großen Katalog per KI bereinigen; die Beispielplattform ist eine andere, die Methode nicht.

Verfügbarkeit muss wahr sein, nicht optimistisch

Hier bestrafen Agentenkanäle Shops, denen Menschen verzeihen. Wer etwas bestellt, das als auf Lager ausgewiesen ist, und dann eine E-Mail über eine Verzögerung bekommt, ärgert sich mäßig. Ein Agent, der auf dieser Grundlage gekauft hat, ist im Namen eines Kunden eine Verpflichtung eingegangen — mit Informationen, die Sie als Tatsache veröffentlicht haben.

• Geben Sie den echten Bestand aus, pro Standort, wenn Sie von mehreren aus liefern — das Inventory-Modul von Medusa unterstützt das sauber, nutzen Sie es also, statt alles auf eine einzige Zahl zu reduzieren.
• Veröffentlichen Sie eine Lieferzusage, hinter der Sie stehen, berechnet aus Standort und Lagerbestand statt als statisches Versprechen in einem CMS-Block.
• Unterscheiden Sie ausverkauft von ausgelaufen. Beides verlangt von einem Agenten völlig unterschiedliches Verhalten.
• Halten Sie die Daten frisch. Ein gecachter Verfügbarkeitswert, der eine Stunde alt ist, ist eine falsche Antwort, überzeugt vorgetragen.

Richtlinien müssen Daten sein, keine PDFs

Rückgabefristen, Garantiebedingungen, Versandgrenzen und Einschränkungen stehen meist als Fließtext auf einer Seite, geschrieben von jemandem aus der Rechtsabteilung. Ein Agent, dem die Frage kann mein Kunde das zurückgeben gestellt wird, braucht eine strukturierte Antwort.

Machen Sie mindestens das hier maschinenlesbar: die Rückgabefrist in Tagen, wer die Rücksendung bezahlt, welche Kategorien ausgeschlossen sind, die Garantiedauer, die Schwelle für kostenlosen Versand und alle Ziele, in die Sie nicht liefern. Veröffentlichen Sie das als strukturierte Felder, die Ihre API zurückgeben kann, und — davon getrennt — als schema.org-Markup in der Storefront, damit beide Kanäle dasselbe sagen.

Der kommerzielle Grund ist schlicht: Vergleicht ein Agent zwei Produkte, von denen eines eine Rückgabefrist von 30 Tagen veröffentlicht und das andere gar nichts, bevorzugt er das, über das er argumentieren kann.

Die API-Oberfläche, die ein Agent braucht

Medusas Store API ist ressourcenorientiert — richtig für eine Storefront, falsch für einen Agenten. Ein Agent will aufgabenorientierte Operationen: finde mir Produkte, die zu dieser Beschreibung passen, sag mir, ob das in dieser Größe an diese Postleitzahl lieferbar ist, wie ist die Rückgaberegelung dafür.

Bauen Sie eine dünne Schicht über Ihren Medusa-Modulen, die genau diese Operationen bereitstellt, und behandeln Sie diese Schicht als eigenes Produkt mit eigenen Gestaltungsstandards. Wie man sie entwirft — einschließlich dessen, was niemals freigegeben werden darf — beschreiben wir in Ihr Produkt braucht einen MCP-Server.

Zwei Medusa-spezifische Hinweise. Erstens macht das Modulsystem die Sache wirklich angenehm: Die agentenseitige Schicht ist ein Konsument Ihrer Module für Produkte, Bestand und Preise, kein Fork davon. Zweitens: Halten Sie sie von der API der Storefront getrennt — Zugriffsmuster, Rate Limits und Berechtigungsmodell unterscheiden sich, und beide zusammenzulegen macht beide schlechter.

Gefunden werden versus bei Ihnen gekauft werden

Das sind zwei verschiedene Projekte, und Teams werfen sie regelmäßig zusammen.

• Gefunden werden — ein Assistent empfiehlt Ihr Produkt in einer Antwort. Getrieben von crawlbaren, strukturierten Storefront-Daten: schema.org-Markup, sauberen Produktseiten, echten Inhalten und einer Crawler-Richtlinie, die den richtigen Agenten Zugang gibt. Größtenteils eine SEO-nahe Disziplin.
• Bei Ihnen gekauft werden — ein Agent schließt einen Kauf gegen Ihre Systeme ab. Getrieben von API-Design, Authentifizierung, Zahlungsabwicklung und den entstehenden Protokollen.

Das Erste steht heute jedem Shop offen und bringt den klareren kurzfristigen Ertrag; wir behandeln es in Ihre Produkte von ChatGPT und Perplexity empfehlen lassen. Beim Zweiten bewegen sich die Standards noch. Fangen Sie in jedem Fall mit dem Ersten an.

Eine sinnvolle Reihenfolge der Arbeit

1. Prüfen Sie die Vollständigkeit der Attribute über den gesamten Katalog und ordnen Sie die Attribute danach, ob Suche, Filter oder Vergleich sie tatsächlich nutzen.
2. Bringen Sie die kontrollierten Vokabulare in Ordnung, bevor Sie irgendetwas anreichern — sonst fügen Sie einer inkonsistenten Taxonomie nur weitere Zeilen hinzu.
3. Füllen Sie die Lücken und prüfen Sie das Ergebnis stichprobenartig, statt ihm blind zu vertrauen.
4. Strukturieren Sie die Richtlinien und veröffentlichen Sie sie sowohl als API-Felder als auch als Markup in der Storefront.
5. Überprüfen Sie die Genauigkeit der Verfügbarkeit einen Monat lang gegen die Realität. Wenn sie für Menschen falsch ist, wird sie für Maschinen schneller und sichtbarer falsch sein.
6. Bauen Sie dann die agentenseitige API-Schicht, und erst danach kümmern Sie sich darum, welches Protokoll Sie sprechen.

Die Schritte eins bis fünf lohnen sich unabhängig davon, ob Agenten-Commerce in Ihrer Kategorie relevant wird — und genau das macht sie zu einer sicheren Investition in einem Feld, in dem sonst nichts feststeht.

Unsere Arbeit mit MedusaJS und unser Medusa-Entwicklungsteam bauen solche Kataloge und die Schnittstellen darüber, unser KI-Engineering-Team übernimmt die modellseitige Arbeit, und unsere breitere Arbeit zur KI-Integration beantwortet, wo das in eine kommerzielle Strategie gehört.

Beginnen Sie mit dem Attribut-Audit

Schicken Sie uns die Befüllungsgrade der Attribute in Ihrem Medusa-Katalog, und wir sagen Ihnen, was ein Agent derzeit sieht und was nicht. Es ist meist weniger, als Teams erwarten. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.