Universal Commerce Protocol (UCP): Was Händler in ihren Daten brauchen

Das Universal Commerce Protocol (UCP) ist ein Open-Source-Standard, mit dem AI-Agenten, Shopping-Plattformen, Händler und Zahlungsanbieter einen Kauf in einem gemeinsamen Format abwickeln: Produkte finden, einen Warenkorb zusammenstellen, bezahlen, das Konto des Käufers verknüpfen und die Bestellung verfolgen. Google hat es am 11. Januar 2026 angekündigt, gemeinsam entwickelt mit Shopify, Etsy, Wayfair, Target und Walmart und unterstützt von mehr als 20 Unternehmen, darunter Visa, Mastercard, Stripe, Adyen, Best Buy und Zalando. Statt für jede AI-Oberfläche eine eigene Integration zu bauen, veröffentlicht ein Unternehmen einmal, was es unterstützt, und jeder UCP-fähige Agent kann es nutzen.

Googles erste Umsetzung ist der Checkout im AI Mode der Google-Suche und in der Gemini-App, wobei der Händler der Merchant of Record bleibt. Um teilzunehmen, braucht ein Händler ein Merchant-Center-Konto mit freigegebenen Produkten, Rückgabe- und Support-Einstellungen, ein Checkout-Eignungsflag an jedem Produkt und saubere Produktdaten: stabile IDs, Varianten mit ihren Optionen, Barcodes, Preise, Verfügbarkeit und Kategorien. Dieser Beitrag erklärt, was UCP ist, wie es sich zu ACP, AP2 und MCP verhält und welche Produktfelder es genau braucht. Unser früherer Beitrag zu Googles Universal Cart behandelt die Seite der Käufer und die strategischen Argumente; dieser hier ist die technische Checkliste für deine Daten.

UCP-Zeitleiste: von der Ankündigung im Januar bis zur Spezifikation vom August 2026

UCP hat sich in den ersten neun Monaten schnell verändert. Die Meilensteine, die für Händler zählen:

Das Protokoll wird nach Datum versioniert, sodass sich ein Agent und ein Unternehmen beim Verbinden auf eine Version einigen. Rechne damit, dass deine Plattform oder dein Zahlungsanbieter den Großteil dieser Abstimmung für dich übernimmt.

So funktioniert UCP: das Profil unter /.well-known/ucp, Capabilities und Transports

Ein Unternehmen veröffentlicht ein JSON-Profil unter /.well-known/ucp auf seiner eigenen Domain. Das Profil listet die unterstützten Protokollversionen, die Service-Endpunkte, die angebotenen Capabilities und die Zahlungskonfiguration auf. Ein Agent liest zuerst diese Datei und weiß dann, was er mit diesem Shop tun kann, ohne fest programmierte Integration. Googles Walkthrough für Entwickler zeigt den kompletten Ablauf, vom Lesen des Profils bis zum Anwenden eines Rabattcodes im Checkout.

• Capabilities sind die Bausteine: Checkout, Cart, Catalog, Identity Linking und Order Management. Ein Unternehmen wählt die aus, die es unterstützt.
• Extensions fügen einer Capability Funktionen hinzu. Rabatte zum Beispiel erweitern Checkout und Cart.
• Transports: Dieselbe Capability kann als REST-API, über ein MCP-Binding oder über Agent2Agent (A2A) bereitgestellt werden. Eine Checkout-Capability kann zum Beispiel je nach Stack des Unternehmens ein REST-Binding oder ein MCP-Binding haben.
• Payments trennen das Zahlungsmittel (womit der Käufer bezahlt, etwa Google Pay) vom Handler (dem Zahlungsdienstleister, der die Zahlung annimmt), sodass UCP mit den Zahlungsanbietern funktioniert, die Händler bereits nutzen. UCP ist mit AP2 kompatibel, um nachzuweisen, dass der Käufer den Kauf autorisiert hat.
• Merchant of Record: Der Händler bleibt der Merchant of Record und behält seine eigene Geschäftslogik.

Für Googles Oberflächen kann ein Händler den nativen Checkout nutzen, der auf seiner eigenen Checkout-API aufbaut, oder eine eingebettete Variante, die ein komplett individuelles Checkout-Erlebnis innerhalb des Agenten beibehält.

UCP, ACP, AP2 und MCP: welches Protokoll was macht

Vier Abkürzungen tauchen in jedem Artikel über Agentic Commerce auf. Sie arbeiten auf unterschiedlichen Ebenen, und nur zwei davon konkurrieren:

ACP und UCP überschneiden sich am stärksten beim Checkout: Das eine ermöglicht Käufe in ChatGPT, das andere in Googles Oberflächen, und Stripe, Mitentwickler von ACP, kündigte im März 2026 an, auch UCP umzusetzen. Ein Händler entscheidet sich also nicht für immer für eines. Beide brauchen denselben Input: einen Produktkatalog, den eine Maschine ohne Raten lesen kann. Wenn dein Feed für das eine funktioniert, ist der Großteil der Arbeit für das andere schon erledigt. Unser Eintrag im E-Commerce-Lexikon zu Agentic Commerce erklärt den größeren Wandel.

Die Produktfelder in einer UCP-Katalogantwort

Die Catalog-Capability von UCP legt fest, wie ein Produkt aussieht, wenn ein Agent danach fragt. Die Schemas der Version 2026-08-25 sind eine praktische Checkliste, denn jedes Pflichtfeld muss aus deinen Produktdaten kommen und jedes optionale Feld ist eine Chance, die Frage des Käufers zu beantworten.

Produktebene. Pflicht: id, title, description, price_range und variants. Optional: handle, kanonische url, categories mit einer Taxonomie-Kennung, list_price_range für durchgestrichene Preise, media (Bilder, Video, 3D; das erste Element ist das Hauptbild), options wie Size und Color, rating, tags und vom Unternehmen definierte metadata.

Variantenebene. Pflicht: id, title (etwa „Blue / Large“), description und price. Optional: sku, barcodes (mit den Typen UPC, EAN, ISBN, GTIN oder JAN), list_price, unit_price für den Vergleich pro Kilo oder Liter, availability mit dem Status in_stock, backorder, preorder, out_of_stock oder discontinued, die options, die die Variante definieren, sowie eigene Medien, Kategorien und Verkäufer.

Zwei Details übersieht man leicht. Beschreibungen können als Klartext, HTML oder Markdown gesendet werden, und die Spezifikation weist Plattformen an, HTML zu bereinigen. Eine saubere Klartextbeschreibung ist daher die sicherste Version zum Pflegen. Und Kategorien tragen einen Taxonomienamen: google_product_category, shopify oder merchant. Wenn deine Produkte für Shopping bereits der Google-Produkttaxonomie zugeordnet sind, kannst du diese ID direkt durchreichen.

Praxisbeispiel: ein Wanderschuh in UCP-Begriffen

Nimm einen fiktiven, halbhohen, wasserdichten Wanderschuh in vier Größen und zwei Farben. Das braucht jedes UCP-Feld aus dem Katalog:

• Produkt-id und title: eine stabile ID, die sich nie ändert, wenn das Produkt umbenannt wird; Titel „Trailmark Ridge Mid GTX Hiking Boot, Men's“.
• Beschreibung: eine Klartextversion ohne HTML, die sagt, wofür der Schuh gedacht ist, welche Membran, welche Sohle und welche Passform er hat.
• Kategorien: Google-Produktkategorie 187 (Apparel & Accessories > Shoes) mit der Taxonomie google_product_category, dazu dein eigener Kategoriepfad mit der Taxonomie merchant.
• Optionen: Farbe (Slate, Olive) und Größe (EU 42, 43, 44, 45).
• Varianten: insgesamt acht, jede mit eigener ID, SKU (TRM-RDG-SLT-43), einem EAN-Barcode vom Typ EAN, price und list_price in EUR, Verfügbarkeitsstatus und den Werten für Color und Size. Der Variantentitel folgt den Optionswerten: „Slate / EU 43“.
• Medien: ein Hauptbild pro Farbe, danach Aufnahmen der Sohle und Detailfotos.
• Metadaten: Fakten, die die Standardfelder nicht abdecken, etwa Membran, Gewicht pro Schuh in Gramm und Leistenweite, aus deinem Attributset.

Jede Lücke in dieser Liste führt zu einer schwächeren Antwort. Eine Variante ohne Barcode lässt sich schwerer über Verkäufer hinweg zuordnen; eine Variante ohne Verfügbarkeitsstatus lässt sich nicht mit Sicherheit kaufen; ein Produkt ohne Optionen lässt sich nicht nach Größe filtern. Prüfe deine Kennungen mit unserem Leitfaden zu GTIN, UPC und EAN, wenn in deinem Katalog verschiedene Barcode-Typen gemischt sind.

Merchant-Center-Einstellungen und Feed-Attribute für den Checkout bei Google

Für Googles Umsetzung listet der Vorbereitungsleitfaden für das Merchant Center auf, was stehen muss, bevor du die API-Seite baust:

1. Ein Merchant-Center-Konto mit gutem Status und Produkten, die für kostenlose Einträge freigegeben sind.
2. Rückgaberichtlinien mit Rücksendekosten, Rückgabefrist und einem Link zur vollständigen Richtlinie, festgelegt in den Rückgabeeinstellungen des Kontos oder pro Produkt mit dem Attribut returns (return_policy_label beschränkt eine Richtlinie auf eine Teilmenge der Produkte). Erweiterte Konten konfigurieren das pro Unterkonto. Die Richtlinie wird im Checkout angezeigt.
3. Informationen zum Kundensupport, im Merchant Center hinterlegt und für den Link Contact Merchant (Händler kontaktieren) auf der Bestellbestätigungsseite genutzt.
4. native_commerce (checkout_eligibility): ein Wert true oder false pro Produkt. Fehlt er, gilt das Produkt als nicht berechtigt. Jedes Produkt, das du über Agentic Checkout verkaufen willst, muss ihn also ausdrücklich tragen.
5. consumer_notice: Pflicht für Produkte mit gesetzlichen Warnhinweisen, mit einem notice_type von legal_disclaimer, safety_warning oder prop_65 und einer notice_message von bis zu 1.000 Zeichen.
6. Übereinstimmende Produkt-IDs: Die id in deinem Feed muss zu der ID passen, die deine Checkout-API erwartet. Wenn nicht, ordnet das Attribut merchant_item_id sie einander zu und hat Vorrang.

Google empfiehlt, diese Attribute über eine ergänzende Datenquelle zu senden, statt den primären Feed zu bearbeiten, damit ein Formatierungsfehler nicht die normale Produktaufnahme stört. Manche Produkte sind unabhängig vom Flag ausgeschlossen: Abonnements und Ratenzahlungspläne, personalisierte Waren, gebrauchte, generalüberholte und vom Umtausch ausgeschlossene Artikel, Vorbestellungen, Produkte, die Speditions- oder anderen Sonderversand brauchen, altersbeschränkte Artikel, Dienstleistungen und Vermietungen. Setz native_commerce für diese auf false.

Unser Leitfaden zum Google-Shopping-Feed behandelt die Attribute des primären Feeds, die stimmen müssen, bevor irgendetwas davon greift.

Konversationelle Attribute: question_and_answer und related_product

Neben UCP hat Google neue optionale Merchant-Center-Felder für konversationelle Oberflächen wie AI Mode, Gemini und Business Agent angekündigt. Die Übersicht der konversationellen Attribute nennt sechs:

• question_and_answer: FAQ-Paare zum Produkt. Google weist darauf hin, dass du Details, die bereits in den Attributen für Beschreibung, Produkthighlights oder Produktdetails stehen, nicht wiederholen musst.
• related_product: Verweise auf Zubehör, benötigte Teile oder Artikel, die oft zusammen gekauft werden, mit den Unterattributen relationship_type, identifier_type und identifier.
• document_link: PDFs wie Anleitungen und Datenblätter.
• item_group_title und variant_option: ein Titel für die Produktfamilie und die Name-Wert-Paare (Size: 43, Color: Slate), die jede Variante definieren, genutzt zusammen mit item_group_id.
• popularity_rank: wie beliebt ein Produkt ist, als prozentuale Rangfolge innerhalb deines gesamten Sortiments.

Diese Felder ändern den Freigabestatus bestehender Produkte nicht und passen gut zu den UCP-Daten: variant_option spiegelt die UCP-Variantenoptionen, related_product spiegelt die Cross-Sell- und Zubehörverknüpfungen, die viele Kataloge ohnehin führen, und question_and_answer gibt einem Agenten die Antworten, die er sonst aus einem Marketingabsatz herauszulesen versuchen würde.

Neun Katalogkorrekturen, bevor der UCP-Checkout deinen Markt erreicht

Der Großteil der UCP-Integrationsarbeit liegt bei deiner Plattform, deinen Entwicklern oder deinem Zahlungsanbieter. Die Datenarbeit liegt bei dem, der den Katalog verantwortet, und sie kann jetzt beginnen:

Der UCP-Checkout ist in den USA gestartet, Kanada und Australien folgen als Nächstes und Großbritannien später. Händler in den Niederlanden und im übrigen Europa haben also Zeit. Diese Zeit steckst du am besten in diese Liste, denn dieselben Felder verbessern schon heute Shopping-Einträge, Marktplatz-Feeds und AI-Antworten. Wenn du allgemeiner entscheidest, was du AI-Agenten zeigst, behandelt unser Beitrag zu llms.txt für E-Commerce die Seite der Indexdatei und warum sie weniger zählt als die Daten.

WISEPIM verwaltet die Katalogebene, auf der diese Checkliste aufbaut: AI füllt fehlende Attribute, Beschreibungen und Google-Kategorien, Quality Guard prüft Produkte gegen Kanalregeln, und die Google-Merchant-Center-Anbindung überträgt das Ergebnis. Teams, die eigene Agent-Integrationen bauen, können Produktdaten im Pro-Tarif über die öffentliche API von WISEPIM lesen. Die Feature-Seite zu Agentic Commerce zeigt, wie die Teile zusammenpassen.