Oft als technische Revolution dargestellt, ist das Universal Commerce Protocol (UCP) tatsächlich primär eine Verschiebung der Infrastruktur. In diesem Artikel entmystifizieren wir das Protokoll, beleuchten den „Sneaker-Trugschluss“ (Sneaker Fallacy) und stellen die Reality-Matrix vor. Dies soll europäischen Führungskräften eine zusätzliche Perspektive bieten, um zwischen Erwartungen an dialogbasierte Systeme und operativer Realität differenzieren zu können.
Lesen Sie auch: Von der Technologie zur Web-Ökonomie: Entscheidungshoheit, Kontrollpunkte und warum Standards niemals neutral sind
Warum sich UCP unvermeidlich anfühlt – und warum der Schein trügen kann
Das Universal Commerce Protocol (UCP) ist mit bemerkenswerter Geschwindigkeit und hohem Marktdruck angetreten. Innerhalb kürzester Zeit wurde es als Grundlage für den sogenannten Agentic Commerce definiert: Eine Dynamik, in der KI-Agenten Produkte nicht mehr nur empfehlen, sondern den Kauf direkt im Namen des Kunden abschließen. Herkömmliche Benutzeroberflächen würden obsolet, Websites optional werden. Der Handel würde sich dadurch in die direkte Konversation verlagern.
Für viele Führungskräfte war die implizite Botschaft daher: Wer jetzt nicht UCP-ready ist, hat schon den Anschluss verloren.
Genau dieses Gefühl der Unausweichlichkeit erfordert jedoch eine kritische Betrachtung. UCP ist keine Marktrevolution, sondern eine Infrastruktur-Option in einem langfristigen Wettbewerb um den Zugang zu Kundennachfrage, Daten und digitaler Entscheidungshoheit. Wie viele Standards zuvor verspricht es Offenheit, stärkt aber letztlich vor allem die Marktposition jener Akteure, die technologisch und wirtschaftlich ohnehin am besten für dessen Nutzung aufgestellt sind.
Für eine pragmatische Diskussion greifen wir in diesem Artikel bewusst immer wieder auf ein einfaches Produkt zurück: ein Paar Marken-Sneaker. Die digitale Realität in Europa (von einer deutschen IP-Adresse) stellt sich, Stand Februar 2026, wie folgt dar: Sowohl der Google AI Mode als auch ChatGPT 5.2 identifizieren problemlos Kundenbedürfnisse über Agentic Discovery. Beide präsentieren auch eine Liste von Optionen, allerdings selten zu den besten Konditionen und oft aus unerwarteten Quellen.
Natürlich lässt sich derselbe Sneaker bei Amazon, Zalando oder Asos erwerben, ebenso wie bei großen Sportartikel-Filialisten wie JD Sports oder Snipes. Eventuell ist das Produkt auch bei spezialisierten europäischen Sneaker-Händlern mit stark kuratierten Katalogen gelistet, darunter Naked Copenhagen, BSTN, 43einhalb in Frankfurt, Sneakersnstuff in Stockholm oder The Broken Arm in Paris.
Die SKU bleibt dabei identisch, die wirtschaftlichen Rahmenbedingungen der einzelnen Anbieter sind es jedoch nicht. Das UCP hebt diese strukturellen Unterschiede nicht auf, sondern verschärft sie. Im Folgenden untersuchen wir im Detail, welche konkreten Effekte das Protokoll entfaltet und welche Relevanz es für Händler im europäischen Raum tatsächlich besitzt.
Die „Sneaker Fallacy“: Gleiches Produkt, andere Marktrealität
Wer UCP verstehen will, wird die Antwort nicht auf LinkedIn finden. Beginnen Sie mit der Entwicklerdokumentation oder dem GitHub Repository. Ein kurzer Blick in den UCP-Implementierungsleitfaden von Google verdeutlicht die Grenzen von UCP:
UCP standardisiert Prozesse, die Kaufabsichten (Commerce Intent) übermitteln und Funktionalitäten abgleichen. Es ersetzt nicht den Checkout – vor allem nicht in Bezug auf Zahlungsabwicklung, Risikomanagement, Retouren oder Kundenprofile.
Das ist deshalb so relevant, weil das oft genutzte Sneaker-Beispiel (s.o.) nur oberflächlich „einfach“ oder repräsentativ ist. Dasselbe Paar Schuhe (mit identischer SKU und GTIN) kann bei Zalando, auf adidas.com, oder in hunderten spezialisierten Sneaker-Boutiquen oder im örtlichen Schuhgeschäft um die Ecke gekauft werden. Während das Protokoll also völlig identisch ist, unterscheidet sich die dahinterliegende Wertschöpfungslogik fundamental. Diese Diskrepanz kann das UCP konstruktionsbedingt gar nicht neutralisieren.
Die UCP Reality Matrix
Um das Marketing von UCP von der operativen Realität abzugrenzen, kommt es auf zwei zentrale Fragen an:
- Ist der Agent überhaupt in der Lage, den Checkout eigenständig durchzuführen?
- Ist der Nutzer dem jeweiligen Händler bereits hinreichend bekannt?
Daraus ergeben sich vier mögliche Szenarien:
UCP-Szenarien-Matrix
Agent KANN Checkout ausführen
Agent KANN Checkout NICHT ausführen
Händlerseite: Nutzbare Kunden-ID / Konto beim Händler vorhanden?
JA, bestehendes Kundenkonto nutzbar
1. Vollständiger Agentic Checkout unter Nutzung bestehender Kontodaten
(SSO, Token)
3. Weiterleitung zum Händler: Login wird ausgelöst, Bestelldaten werden automatisch vorausgefüllt
NEIN, Agent Wallet = einzige ID
2. Agentic Guest Checkout via Agent Wallet ID
4. Weiterleitung, dann vollständiger klassischer Checkout beim Händler
Diese Matrix verdeutlicht, warum wir „Agentic Commerce“ als abstrakten Begriff von der tatsächlichen operativen Realität des „Agentic Checkout“ trennen sollten.
- Bekannter Nutzer + Agentic Checkout
Der Agent kann den Kauf abschließen, weil der Händler dies unterstützt und der Nutzer identifizierbar ist. Dies kommt der Vision eines „Zero-UI-Commerce“ am nächsten, bei dem die eigentliche Shop-Oberfläche für Kunden komplett in den Hintergrund tritt. - Unbekannter Nutzer + Agentic Checkout
Der Checkout funktioniert, aber nur als Gast- oder Wallet-basierter Prozess. Die Identität existiert primär aufseiten des Agenten; der Händler gewinnt zwar eine Transaktion, aber keine nachhaltige Kundenbeziehung. - Bekannter Nutzer + kein Agentic Checkout
Der Nutzer hat ein Konto, aber der Checkout findet auf der Website des Händlers statt. UCP verbessert hier die Auffindbarkeit (Discovery), nicht die Conversion-Mechanik. - Unbekannter Nutzer + kein Agentic Checkout
Der Agent kann das Angebot nur verlinken oder ignorieren. Hier dominiert die reine Vergleichbarkeit, jegliche Differenzierung ist nicht möglich. Die meisten Diskussionen um UCP setzen Variante 1 voraus: Der Nutzer ist bekannt, der Händler unterstützt den Agentic Checkout und der Agent kann den Kauf direkt im Flow abschließen. In der Praxis sehen wir jedoch eine Verteilung auf alle vier Szenarien, oft sogar innerhalb desselben Markenportfolios.
Was die Dokumentation Händlern tatsächlich abverlangt (und warum das iframe nie wirklich weg war)
An dieser Stelle fokussieren wir uns auf die Entwicklerdokumentation. Der Google-Leitfaden skizziert hier einen Integrationspfad, der mit sehr viel klassischem E-Commerce-Handwerk einhergeht.
Von Händlern wird erwartet:
- das Merchant Center vorzubereiten,
- strukturierte Produktdaten sauber bereitzustellen,
- ein Unternehmensprofil für die Discovery und das Abgleichen von technischen Fähigkeiten zu veröffentlichen und
- die Checkout-Interaktion über eine überschaubare Anzahl von Core-REST-Endpunkten abzubilden, um Sitzungen zu erstellen, zu aktualisieren und abzuschließen.
Dabei wird ein eingebetteter Web-Checkout (per iframe) explizit als optionaler Pfad aufgeführt, während ein Gast-Checkout (ebenfalls per iframe realisiert) den Standard darstellt. Auch die Identitätsverknüpfung über bestehende Kundenkonten über OAuth 2.0 wird als tiefergehende, optionale Ebene positioniert und eben nicht als Basis des Protokolls.
Kurz gesagt: UCP wird nicht zu Ihrem Checkout sondern leitet den Intent lediglich an einen Checkout-Mechanismus weiter, den Sie als Händler weiterhin besitzen und betreiben müssen. Dies beinhaltet den gesamten Bestell-Lebenszyklus, aber auch Zahlungskompatibilität und Risikosignale. Die folgende Grafik veranschaulicht diesen (exemplarisch für den US-Markt) wahrscheinlichsten Fall: den agentenbasierten Gast-Checkout aus Szenario 2.
Hier zeigt sich die funktionale Trennung des Protokolls: Das UCP standardisiert die Übermittlung der Kaufabsicht, greift jedoch nicht in die operativen Prozesse des Händlers ein.
Was nicht im Protokoll steht – und warum genau das entscheidend ist
UCP definiert nicht, wie man:
- Die Identität eines Nutzers verifiziert
- Mit Betrug (Fraud) und Haftung (Liability) umgeht
- Zahlungen über die unterstützten Wallet-Credentials hinaus ausführt
- Retouren, Service oder Post-Purchase-Sonderfälle abwickelt.
Die Hilfedokumentation des Merchant Centers wird hierzu sehr deutlich: Das aktuelle Modell für Zahlungsdaten im UCP-gestützten Google Checkout nutzt ausschließlich in Google Wallet hinterlegte Funding Credentials (mit künftiger Erweiterung). Händler benötigen daher in jedem Fall entsprechende Payment Service Provider (PSP) Capabilities, um diese Payment-Token akzeptieren und verarbeiten zu können.
Genau deshalb erweist sich die Gleichung „UCP = Checkout“ als Fehleinschätzung. Das Protokoll übernimmt lediglich die Standardisierung und das Routing der Kaufabsicht, während die operative Verantwortung und das wirtschaftliche Haftungsrisiko vollumfänglich beim Händler vebleiben. Das gilt selbst dann, wenn der Checkout für den Kunden scheinbar direkt auf der Plattform-Oberfläche stattfindet.
Das UCP sorgt somit keineswegs für faire Wettbewerbsbedingungen, sondern formalisiert nur die digitalen Schnittstellen, über die der Intent abfließt. Das bevorzugt naturgemäß jene Unternehmen, deren Mehrwert sich ohnehin rein über den Preis, die reine Verfügbarkeit und eine hocheffiziente Logistik definiert. Das Protokoll kann eine Kaufentscheidung also zwar beschleunigen, sie aber niemals strategisch begründen.
Deshalb sollten sich Entscheider in Europa auch nicht als erste strategische Frage überlegen, wie schnell sie das UCP implementieren können, sondern vielmehr: „In welchem digitalen Umfeld können wir uns noch eigenständig positionieren, ohne uns zu sehr von einem globalen System abhängig zu machen, das wir letztendlich nicht kontrollieren können?“
