UCP vs ACP vs MCP vs AP2: Was ein Shop tatsächlich implementieren muss

Dokumentierte Analyse zu UCP, ACP, MCP und AP2: Risiken, Verantwortlichkeiten und praktische Schritte für einen vernetzten, aber unabhängigen Ecommerce.

Veröffentlicht am 11. September 202614 Minuten

Redaktionelle Illustration zu UCP, ACP, MCP und AP2 und der Kontrolle der Ecommerce-Infrastruktur — Ein Kanal kann den Verkauf beschleunigen, ohne zum zentralen System des Shops zu werden.

Die direkte Antwort

Ein Shop kann Distribution gewinnen und gleichzeitig den kommerziellen Kontext verlieren. Das Thema UCP, ACP, MCP und AP2 zeigt genau, wo diese beiden Effekte getrennt werden müssen. Das konkrete Risiko ist, dass die Protokolle unterschiedliche Ebenen abdecken und nicht als Synonyme behandelt werden dürfen. Die praktische Empfehlung ist einfach: Starte von der Business-Fähigkeit und implementiere nur den notwendigen Adapter. Das erfordert keinen Rückzug aus Google. Es verlangt, dass Google ein angebundener Kanal zu einer kommerziellen Infrastruktur bleibt, die der Shop auch ohne ihn betreiben kann.

Was UCP ist und was es nicht löst

Universal Commerce Protocol ist eine offene Spezifikation für den Austausch kommerzieller Fähigkeiten zwischen Agenten, Distributionsoberflächen, Händlern und Zahlungsanbietern. Die öffentliche Dokumentation beschreibt Capability Discovery, checkout und Bestellmanagement. UCP ist jedoch weder ein Versprechen für Traffic, noch eine Garantie für Eligibility und auch keine automatische Übertragung der Beziehung zum Kunden. Technische Implementierung und der Zugang zu einer Google-Oberfläche sind getrennte Entscheidungen. Ein rumänischer Shop kann den Vertrag studieren und seine Architektur vorbereiten, auch wenn das kommerzielle Produkt lokal nicht verfügbar ist. Genau diese Trennung verhindert Investitionen auf Basis einer Schlagzeile.

Die Verantwortlichkeitskarte

Ebene	Kontrollfrage	Minimaler Nachweis
Katalog	Wer definiert Produkt, Variante und Verfügbarkeit?	Stabile ID, Version und readback
Angebot	Wer berechnet den Gesamtbetrag und die Geschäftsregeln?	datierter Snapshot und Ablauf
checkout	Wo bestätigt der Kunde und was sieht er vorher?	an das Angebot geknüpftes Einverständnis
Bestellung	Wer akzeptiert, lehnt ab und gleicht ab?	idempotency und auditierbarer Status
Beziehung	Wer kann den Kunden bedienen und zurückgewinnen?	CRM, Präferenzen und direkter Kanal

Im Fall von UCP, ACP, MCP und AP2 muss die Tabelle mit Systemnamen, Eigentümern und Wiederherstellungszeiten ergänzt werden, nicht mit Marketingformulierungen.

Der Katalog muss die Quelle des Händlers bleiben

Agenten und Feeds brauchen strukturierte Daten, aber die Source of Truth sollte nicht in einen Export verlagert werden. Der interne Katalog bewahrt die Produktidentität, Varianten, Einheiten, Einschränkungen und Verpackungsregeln; der Adapter transformiert diese Daten für den Kanal. Im Thema UCP, ACP, MCP und AP2 ermöglicht diese Disziplin, die Integration zu stoppen oder zu ersetzen, ohne das Business neu aufzubauen. Die Validierung umfasst Preis, Währung, Verfügbarkeit, Steuern, Lieferung und Ablauf. Wenn Feed und internes System voneinander abweichen, muss der Vorfall erkannt werden, bevor ein Kunde oder Agent eine Bestellung auf einem unmöglichen Angebot anlegt.

1. Die Margen-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Wenn wir UCP, ACP, MCP und AP2 analysieren, zeigt die Frage nach der Marge, ob der Vorteil beim Händler bleibt, nachdem Sitzung und Kampagne beendet sind. In einem Workshop prüft der Prozessverantwortliche den normalen Ablauf, dann einen Timeout, eine Bestandsabweichung und die Entziehung des Zugriffs auf den Kanal. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Das Exit-Kriterium tritt ein, wenn die Protokolle unterschiedliche Ebenen abdecken und nicht als Synonyme behandelt werden dürfen. In diesem Moment improvisieren wir keine Migration, sondern wenden die dokumentierte Entscheidung an: Starte von der Business-Fähigkeit und implementiere nur den notwendigen Adapter.

2. Die Portabilitäts-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Im Fall von UCP, ACP, MCP und AP2 verschiebt das Fehlen einer Definition für Portabilität die Diskussion in den Bereich der Eindrücke und verdeckt, wer die Ausnahme, den Verlust oder die Regeländerung trägt. Im Architekturregister werden Quelle, Adapter, Ziel und die verfügbare Alternative versioniert, falls der Vermittler nicht antwortet. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Hier ist das Risiko konkret: Die Protokolle decken unterschiedliche Ebenen ab und dürfen nicht als Synonyme behandelt werden. Deshalb kann die Messgröße nicht nur die Anzahl der Bestellungen sein. Wir ergänzen Einverständnis, Wiederherstellungszeit und den Prozentsatz der Fälle, die ohne manuellen Export gelöst werden.

3. Die Identitäts-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Durch die Identitäts-Linse betrachtet, ist das Thema UCP, ACP, MCP und AP2 keine isolierte Funktion mehr, sondern eine Entscheidung darüber, wie Wert zwischen Shop, Kunde und Vermittler zirkuliert. Der Pilot grenzt die Wirkung auf Conversion, operative Kosten und die Fähigkeit, die direkte Beziehung wieder aufzunehmen, separat ein. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Die kommerzielle Konsequenz des Szenarios ist, dass die Protokolle unterschiedliche Ebenen abdecken und nicht als Synonyme behandelt werden dürfen. Die überprüfbare Antwort bleibt: Starte von der Business-Fähigkeit und implementiere nur den notwendigen Adapter. Die Akzeptanzschwelle wird vor dem Test geschrieben, nicht nachdem die Ergebnisse bekannt sind.

4. Die Einverständnis-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Für UCP, ACP, MCP und AP2 muss Einverständnis vor der Integration beschrieben werden; andernfalls wird das Team einen funktionierenden Flow mit einem Business verwechseln, das es kontrollieren kann. Der technische Vertrag isoliert die Pflichtfelder, Zwischenzustände und den Nachweis, der verwendet wird, wenn zwei Systeme sich nicht einig sind. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Wenn wir feststellen, dass die Protokolle unterschiedliche Ebenen abdecken und nicht als Synonyme behandelt werden dürfen, kehrt der Pilot zum direkten Pfad zurück. Das Team muss von der Business-Fähigkeit ausgehen und nur den notwendigen Adapter implementieren, dann den Test mit denselben Produkten, Märkten und Regeln wiederholen.

5. Die Resilienz-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Der Resilienztest geht von der realen Operation aus, die mit UCP, ACP, MCP und AP2 verbunden ist, nicht von der kommerziellen Präsentation des Protokolls oder der Plattform. Das Team gleicht das System ab, das die Information erzeugt, das Ereignis, das sie bestätigt, und die Person, die einen Fehler korrigieren kann. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Dieser Blickwinkel beweist nicht, dass der Vermittler unnötig ist; er beweist, dass die Protokolle unterschiedliche Ebenen abdecken und nicht als Synonyme behandelt werden dürfen. Für ein Gleichgewicht lautet die Empfehlung, von der Business-Fähigkeit auszugehen und nur den notwendigen Adapter zu implementieren und den Kanal nur so lange zu behalten, wie er inkrementell bleibt.

6. Die Kontinuitäts-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Wenn wir UCP, ACP, MCP und AP2 analysieren, zeigt die Frage nach der Kontinuität, ob der Vorteil beim Händler bleibt, nachdem Sitzung und Kampagne beendet sind. In einem Workshop misst der Prozessverantwortliche den normalen Ablauf, dann einen Timeout, eine Bestandsabweichung und die Entziehung des Zugriffs auf den Kanal. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Das Exit-Kriterium tritt ein, wenn die Protokolle unterschiedliche Ebenen abdecken und nicht als Synonyme behandelt werden dürfen. In diesem Moment improvisieren wir keine Migration, sondern wenden die dokumentierte Entscheidung an: Starte von der Business-Fähigkeit und implementiere nur den notwendigen Adapter.

7. Die Observability-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Im Fall von UCP, ACP, MCP und AP2 verschiebt das Fehlen einer Definition für Observability die Diskussion in den Bereich der Eindrücke und verdeckt, wer die Ausnahme, den Verlust oder die Regeländerung trägt. Im Architekturregister werden Quelle, Adapter, Ziel und die verfügbare Alternative verglichen, falls der Vermittler nicht antwortet. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Hier ist das Risiko konkret: Die Protokolle decken unterschiedliche Ebenen ab und dürfen nicht als Synonyme behandelt werden. Deshalb kann die Messgröße nicht nur die Anzahl der Bestellungen sein. Wir ergänzen Einverständnis, Wiederherstellungszeit und den Prozentsatz der Fälle, die ohne manuellen Export gelöst werden.

8. Die Attribution-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Durch die Attribution-Linse betrachtet, ist das Thema UCP, ACP, MCP und AP2 keine isolierte Funktion mehr, sondern eine Entscheidung darüber, wie Wert zwischen Shop, Kunde und Vermittler zirkuliert. Der Pilot dokumentiert separat die Wirkung auf Conversion, operative Kosten und die Fähigkeit, die direkte Beziehung wieder aufzunehmen. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Die kommerzielle Konsequenz des Szenarios ist, dass die Protokolle unterschiedliche Ebenen abdecken und nicht als Synonyme behandelt werden dürfen. Die überprüfbare Antwort bleibt: Starte von der Business-Fähigkeit und implementiere nur den notwendigen Adapter. Die Akzeptanzschwelle wird vor dem Test geschrieben, nicht nachdem die Ergebnisse bekannt sind.

9. Die Kontroll-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Für UCP, ACP, MCP und AP2 muss control vor der Integration beschrieben werden; andernfalls wird das Team einen funktionierenden Flow mit einem Business verwechseln, das es kontrollieren kann. Der technische Vertrag prüft die Pflichtfelder, Zwischenzustände und den Nachweis, der verwendet wird, wenn zwei Systeme sich nicht einig sind. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Wenn wir feststellen, dass die Protokolle unterschiedliche Ebenen abdecken und nicht als Synonyme behandelt werden dürfen, kehrt der Pilot zum direkten Pfad zurück. Das Team muss von der Business-Fähigkeit ausgehen und nur den notwendigen Adapter implementieren, dann den Test mit denselben Produkten, Märkten und Regeln wiederholen.

10. Die Reconciliation-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Der Reconciliation-Test geht von der realen Operation aus, die mit UCP, ACP, MCP und AP2 verbunden ist, nicht von der kommerziellen Präsentation des Protokolls oder der Plattform. Das Team versioniert das System, das die Information erzeugt, das Ereignis, das sie bestätigt, und die Person, die einen Fehler korrigieren kann. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Dieser Blickwinkel beweist nicht, dass der Vermittler unnötig ist; er beweist, dass die Protokolle unterschiedliche Ebenen abdecken und nicht als Synonyme behandelt werden dürfen. Für ein Gleichgewicht lautet die Empfehlung, von der Business-Fähigkeit auszugehen und nur den notwendigen Adapter zu implementieren und den Kanal nur so lange zu behalten, wie er inkrementell bleibt.

11. Die Margen-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Wenn wir UCP, ACP, MCP und AP2 analysieren, zeigt die Frage nach der Marge, ob der Vorteil beim Händler bleibt, nachdem Sitzung und Kampagne beendet sind. In einem Workshop grenzt der Prozessverantwortliche den normalen Ablauf ab, dann einen Timeout, eine Bestandsabweichung und die Entziehung des Zugriffs auf den Kanal. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Das Exit-Kriterium tritt ein, wenn die Protokolle unterschiedliche Ebenen abdecken und nicht als Synonyme behandelt werden dürfen. In diesem Moment improvisieren wir keine Migration, sondern wenden die dokumentierte Entscheidung an: Starte von der Business-Fähigkeit und implementiere nur den notwendigen Adapter.

12. Die Portabilitäts-Linse: die Entscheidung für UCP, ACP, MCP und AP2

Im Fall von UCP, ACP, MCP und AP2 verschiebt das Fehlen einer Definition für Portabilität die Diskussion in den Bereich der Eindrücke und verdeckt, wer die Ausnahme, den Verlust oder die Regeländerung trägt. Im Architekturregister werden Quelle, Adapter, Ziel und die verfügbare Alternative isoliert, falls der Vermittler nicht antwortet. Es werden Eigentümer, Prüfungsfrequenz, Mindestdaten und das, was nicht aus dem Dashboard abgeleitet werden kann, notiert. Ein günstiges Ergebnis an einem Tag ersetzt keine Kohortenprüfung, und ein einzelner Vorfall rechtfertigt nicht die Entfernung des Kanals. Hier ist das Risiko konkret: Die Protokolle decken unterschiedliche Ebenen ab und dürfen nicht als Synonyme behandelt werden. Deshalb kann die Messgröße nicht nur die Anzahl der Bestellungen sein. Wir ergänzen Einverständnis, Wiederherstellungszeit und den Prozentsatz der Fälle, die ohne manuellen Export gelöst werden.

Sicherheit und Minimierung des Zugriffs

Der Adapter erhält keinen allgemeinen Zugriff nur, weil er als „Agent“ bezeichnet wird. Jede Operation hat Zweck, Identität, Berechtigungen, Ablauf und Protokoll. Tokens werden auf die notwendige Ressource und Dauer begrenzt, und Secrets gelangen nicht in Feeds, Prompts oder Logs. Für UCP, ACP, MCP und AP2 umfasst das Threat Model Agenten-Fälschung, Replay, Preismanipulation, Bestandsenumeration, Missbrauch von Promotionen und Datenexfiltration. Sensible Aktionen erfordern Bestätigung oder explizite Richtlinien. Der Bot-Schutz wird nicht global deaktiviert; legitimer Traffic wird authentifiziert und auf kontrollierten kommerziellen Routen begrenzt.

Vier Szenarien, die nicht verwechselt werden dürfen

Das erste Szenario ist Discovery: die Plattform zeigt das Produkt, und der Shop behält die gesamte Transaktion. Das zweite ist der kontextuelle Redirect, bei dem Warenkorb oder Auswahl übertragen werden, die Bestätigung aber auf der Website bleibt. Das dritte ist das eingebettete checkout, bei dem ein Teil der Händleroberfläche in der Oberfläche des Vermittlers erscheint. Das vierte ist das native checkout, bei dem der Nutzer abschließt, ohne sichtbar in den Shop zurückzukehren. Für UCP, ACP, MCP und AP2 hat jedes Szenario eine andere Attribution, ein anderes Fehlerset und ein anderes Maß an Kundenzugriff. Das Team muss sie getrennt berichten. Wenn sie unter dem Label „Verkäufe aus AI“ vermischt werden, lässt sich nicht mehr feststellen, ob das Ergebnis aus Empfehlung, Rabatt, checkout-Erlebnis oder aus Kunden stammt, die ohnehin gekauft hätten. Auch der Begriff „direkt“ reicht nicht aus: Direkt für den Nutzer kann für den Händler vermittelt bedeuten. Die interne Dokumentation wird den Daten- und Verantwortungsweg tatsächlich zeichnen, von der Antwort bis zur Rücksendung.

Was wir messen

Das Minimal-Dashboard trennt Distribution von der Gesundheit des Business. Für Distribution: Impressionen, berechtigte Anzeigen, Sitzungen und Bestellungen über den Kanal. Für die Wirtschaftlichkeit: Nettoumsatz, Marge nach Rabatten und operative Kosten, Stornierungen, Rücksendungen und Support. Für die Beziehung: identifizierte Kunden, gültige Einverständnisse, direkte Wiederkehr und Wert pro Kohorte. Für die Resilienz: Prozentsatz des portablen Katalogs, abgeglichene Bestellungen, Erkennungszeit und Zeit zum Ersetzen des Adapters. Im Thema UCP, ACP, MCP und AP2 kann eine einzelne Conversion-Rate nicht all diese Effekte abdecken.

Häufig gestellte Fragen

Was ändern UCP, ACP, MCP und AP2 konkret?

Sie ändern den Ort, an dem einige kommerzielle Entscheidungen getroffen oder ausgeführt werden; sie verlagern nicht automatisch alle Verantwortlichkeiten und garantieren keine Distribution.

Was ist in diesem Fall das Haupt-Risiko?

Die Protokolle decken unterschiedliche Ebenen ab und dürfen nicht als Synonyme behandelt werden. Das Risiko wird in Verträgen, Daten und Flows geprüft, nicht aus dem Produktnamen abgeleitet.

Eliminiert ein offener Standard die Abhängigkeit?

Nicht automatisch. Die Spezifikation kann offen sein, während Eligibility und die Oberfläche von einem Distributor kontrolliert werden.

Können wir den Shop vor der Eligibility vorbereiten?

Ja: eigener Katalog, deterministisches Angebot, checkout, idempotency und Adapter. Die Vorbereitung sollte nicht als Live-Zugang dargestellt werden.

Welche Entscheidung empfiehlt die Analyse?

Von der Business-Fähigkeit auszugehen und nur den notwendigen Adapter zu implementieren, mit vor dem Pilot geschriebenen Erfolgs- und Abbruchschwellen.

Muss Google aufgegeben werden?

Nein. Google kann ein profitabler Kanal bleiben; das Ziel ist, dass es nicht zur einzigen kommerziellen Infrastruktur wird.

Fazit

UCP vs ACP vs MCP vs AP2: Was ein Shop tatsächlich implementieren muss, ist keine Einladung zur Isolation. Es ist eine Einladung, Kontrolle korrekt zu bilanzieren. Wenn die Protokolle unterschiedliche Ebenen abdecken und nicht als Synonyme behandelt werden dürfen, muss der kurzfristige Vorteil mit Portabilität, direkter Beziehung und Exit-Kosten verglichen werden. Die gesunde Entscheidung ist, von der Business-Fähigkeit auszugehen und nur den notwendigen Adapter zu implementieren. Notiere die Annahmen vor dem Pilot, lege die Stoppschwellen fest und wiederhole die Bewertung, wenn sich Länder, Oberflächen oder Verträge ändern. Eine gute Integration sollte sowohl dem technischen Team als auch Vertrieb, Support und Management erklärt werden können. Für ein Audit der Sichtbarkeit und Abhängigkeiten kannst du mit AYSA sprechen; für Katalog, checkout, CRM und Adapter kannst du Softwareentwicklung ansehen oder ein direktes Gespräch beginnen.

Quellen und Verifikationsdatum

Quellen geprüft am 24. August 2026. Eligibility, Länder und kommerzielle Funktionen können sich ändern; die Prüfung muss vor der Implementierung wiederholt werden. Die Analyse trennt öffentliche Dokumentation von redaktionellen Empfehlungen.