MCP entwickelt sich zunehmend zum Standardprotokoll für die Verbindung von KI-Agenten mit MarTech-Systemen. Im Fokus stehen diesen Monat vor allem Neuerungen rund um Adobe Target – insbesondere technische Änderungen, die für Experimentation, Personalisierung und Performance-Workflows relevant sind.
Der MCP-Server selbst ist dabei nur ein Teil der Entwicklung. Viel wichtiger ist: MCP setzt Anbieter unter Druck, ihre APIs besser, vollständiger und nutzerfreundlicher zu gestalten. Denn KI-gestützte Workflows funktionieren nur zuverlässig, wenn Systeme sauber miteinander kommunizieren können.
Auch die weiteren Entwicklungen dieses Monats – von Edge-Decisioning über Zero-Copy-Architekturen bis hin zur nativen Erfassung von KI-Traffic in GA4 – zeigen, wie eng KI, Daten und Marketing-Technologien inzwischen zusammenwachsen. Die wichtigsten Updates haben wir für Sie im Folgenden zusammengefasst.
Inhaltsverzeichnis – Mai 2026
Adobe Target MCP Server - Allgemeine Verfügbarkeit
Der MCP-Server von Adobe Target ist ab sofort unter targetmcp.adobe.io verfügbar [1].
Er bietet eine kontrollierte, schreibgeschützte Schnittstelle, über die KI-Agenten die bestehende Target-Infrastruktur analysieren können: darunter aktive und pausierte Kampagnen, Konfigurationen, Angebote, Audiences, Mboxes, Properties, Tokens sowie at.js-Einstellungen. Zusätzlich lassen sich Performance-Metriken wie Conversions, Umsatz oder Bestellungen für A/B-, XT- und AP-Aktivitäten abrufen.
Wichtig dabei: Der Server dient aktuell ausschließlich der Analyse und Einsicht. Schreibzugriffe, Empfehlungen oder automatische Optimierungen sind derzeit nicht möglich. Stattdessen handelt es sich um eine sichere Inspektionsschicht, die sich beispielsweise mit Claude, ChatGPT oder Cursor verbinden lässt, um Experimentation-Setups per natürlicher Sprache abzufragen. Schreibzugriffe dürften voraussichtlich zu einem späteren Zeitpunkt folgen.
CDN Experimentation SDK - Version 1.0.0
Das @adobe/target-cdn-experimentation-akamai-sdk ermöglicht lokales A/B-Test-Decisioning innerhalb von Akamai EdgeWorkers. Dadurch entfällt der zusätzliche Netzwerkaufruf zu Adobe Edge im kritischen Ladepfad. Die Decisioning-Latenz für Experimente sinkt bei performancekritischen Seiten damit von rund 500 ms auf etwa 5 ms – also um den Faktor 100.
Das SDK ist dabei als Ergänzung zu verstehen [2]. Funktionen wie Besucherprofile, AEP-/AAM-Segmente oder ML-basierte Aktivitäten wie Auto-Target laufen weiterhin über die Server-Infrastruktur von Adobe.
Besonders interessant ist der Einsatz für Seiten mit hohem Traffic und sehr strengen Performance-Anforderungen – etwa Checkout-Prozesse, Landingpages oder generell Bereiche, bei denen Core Web Vitals eine zentrale Rolle spielen und zusätzliche Latenz kaum tolerierbar ist.
Flicker Manager v2 - Verwaltetes Pre-Hide
Mit Flicker Manager v2 ersetzt Adobe die bisherige manuelle Pre-Hide-Lösung für VEC-Aktivitäten [3]. Bislang waren bei neuen Aktivitäten häufig individuelle Anpassungen am Seitencode notwendig.
Die neue Version blendet nur noch die Bereiche einer Seite aus, die tatsächlich von aktiven VEC-Aktivitäten betroffen sind. Personalisierte Inhalte werden angezeigt, sobald sie geladen sind, während Consent-Banner und nicht betroffene Inhalte ganz normal gerendert werden. Die Implementierung erfolgt dabei über ein einziges Script-Tag, während Adobe die Regel-Updates zentral über das CDN verwaltet. Zusätzlicher Wartungsaufwand pro Aktivität entfällt damit weitgehend.
Gemessenes Ergebnis: 12–20 % Verbesserung bei LCP, FCP und Speed Index. Für Kunden mit mehr als 20 parallelen VEC-Aktivitäten reduziert dies sowohl Wartungsaufwand als auch Performance-Kosten erheblich.
Anwendungsfall: Sub-10-ms-Personalisierung ohne Flicker
Ausgangssituation waren stark frequentierte Seiten auf Akamai-Hosting mit sehr hohen Anforderungen an die Core Web Vitals. Ziel war es, umfangreiche Experimentation und Personalisierung umzusetzen, ohne dabei Ladezeiten zu verschlechtern oder sichtbares Flickering auf der Seite zu erzeugen.
Architekturentscheidung: Die Lösung bestand in der Kombination aus CDN Experimentation SDK (Latenz) und Flicker Manager v2 (Rendering). Das CDN SDK übernimmt das Decisioning am Edge – rules.json wird beim Start des EdgeWorkers im Speicher gecacht, die Besucheridentität kommt aus dem ECID-Cookie oder wird lokal generiert, Murmur3-Hashing übernimmt die Experience-Zuweisung (identische Logik wie serverseitiges Target), sendNotification erfolgt asynchron fürs Reporting.
Der Flicker Manager v2 übernimmt parallel die Darstellung im Browser. Dabei werden nur die tatsächlich betroffenen Bereiche kurzfristig ausgeblendet und sofort angezeigt, sobald personalisierte Inhalte bereitstehen. Zusätzliche Codeanpassungen pro neuer Aktivität sind nicht mehr notwendig.
Der technische Implementierungsaufwand bleibt vergleichsweise gering: erforderlich sind im Wesentlichen die EdgeWorker-Konfiguration, ein Flicker-Manager-Script-Tag sowie die Anbindung an die Consent- bzw. Cookie-API. Laufender Wartungsaufwand pro Aktivität entfällt weitgehend.
Gesamtergebnis: Teams können auch auf performancekritischen Seiten umfangreiche Personalisierungs- und Experimentation-Programme umsetzen, ohne den klassischen Zielkonflikt zwischen Seitenperformance und Testumfang eingehen zu müssen.
Adobe Analytics 1.4 API — Abschaltung am 12. August 2026
Adobe stellt die Analytics 1.4 API am 12. August 2026 endgültig ein. Ab diesem Zeitpunkt sind die entsprechenden Endpunkte nicht mehr erreichbar – ausgenommen ist lediglich die Data Insertion API.
Unternehmen sollten daher frühzeitig prüfen, ob interne Tools, Dashboards oder externe Dienstleister noch auf die 1.4 API angewiesen sind. Sinnvoll ist außerdem ein Blick in die Server-Logs, um bestehende API-Aufrufe und potenzielle Abhängigkeiten sichtbar zu machen.
Wichtig dabei: Die Migration auf die 2.0 API ist kein einfacher technischer Austausch. Die neue API basiert auf JSON statt XML, verwendet eine andere Pagination und setzt auf OAuth-Authentifizierung. Entsprechend müssen viele Integrationen nicht nur angepasst, sondern teilweise grundlegend überarbeitet werden. Wer betroffen ist, sollte daher möglichst früh mit der Umstellung beginnen.
Optimizely Opal: Memory, MCP und neue Agents
Optimizely erweitert Opal um neue Funktionen, die den Einsatz im Alltag deutlich praktischer machen [4]. Künftig kann Opal Informationen über einzelne Sessions hinweg speichern – etwa Präferenzen, frühere Interaktionen oder den Kontext laufender Experimentreihen. Dadurch reduziert sich der Aufwand für wiederholtes Prompting insbesondere bei langfristigen Experimentation-Programmen spürbar.
Neu ist außerdem die Unterstützung von Remote MCPs. Damit lässt sich Opal direkt mit externen Tools wie Notion, Contentsquare, Contentful oder eigenen Experimentation-Systemen verbinden und in bestehende Workflows integrieren.
Zusätzlich führt Optimizely vier spezialisierte Agents ein:
- Idea Builder erstellt Testhypothesen auf Basis bisheriger Experimentergebnisse
- Variation Generation generiert komplette Varianten aus einer bestehenden Hypothese
- Experiment Conflict Checker prüft neue Tests auf mögliche Überschneidungen mit laufenden Experimenten
- Page Performance Evaluation kombiniert Lighthouse-Audits, Screenshot-Analysen und konkrete Optimierungsvorschläge
Damit entwickelt sich Opal zunehmend von einem klassischen KI-Assistenten hin zu einem dauerhaft nutzbaren Kollaborationspartner mit Zugriff auf die bestehende Toollandschaft. Ergänzend dazu soll der neue Enrichment-Modus deutlich tiefere und kontextreichere Antworten liefern als der bisherige Fast-Modus.
Braze: Zero-Copy-Architektur
Braze setzt künftig auf eine sogenannte Zero-Copy-Architektur [5]. Dadurch kann die Plattform für Segmentierung und Personalisierung direkt auf Kundendaten in angebundenen Cloud-Data-Warehouses wie Snowflake, BigQuery oder Redshift zugreifen – ohne die Daten zuvor physisch in Braze zu übertragen [6].
Der Vorteil: Kampagnen können nahezu in Echtzeit auf aktuelle Transaktions- oder Kundendaten reagieren, ohne auf klassische ETL- oder Synchronisationsprozesse warten zu müssen. Gleichzeitig bleiben Segmente immer so aktuell wie die Daten im jeweiligen Warehouse. Zusätzlich sinken Speicher- und Infrastrukturkosten, da Daten nicht mehr mehrfach gespeichert werden müssen. Auch potenzielle Fehlerquellen durch komplexe Ingestion- oder ETL-Pipelines werden dadurch reduziert.
Gerade für Teams, die bislang mit veralteten Segmentdaten, zeitverzögerten Synchronisierungen oder instabilen Datenpipelines gearbeitet haben, ist dieser Ansatz ein deutlicher Schritt in Richtung moderner Echtzeit-Personalisierung.
GA4: Native Erkennung von KI-Assistenten-Traffic
Google Analytics 4 erkennt künftig automatisch Zugriffe über KI-Assistenten wie ChatGPT, Gemini oder Claude. Wird ein entsprechender Referrer erkannt, ordnet GA4 den Traffic automatisch dem Medium ai-assistant zu und führt ihn in den Standard-Channel-Reports unter „AI Assistant“ auf [7].
Dadurch entfallen viele der bisherigen Workarounds wie eigene Channel-Gruppen, Regex-Filter oder manuelle UTM-Konstruktionen, die bislang notwendig waren, um KI-generierten Traffic sauber auszuwerten.
Für viele Teams schließt GA4 damit eine wichtige Messlücke, die seit dem zunehmenden Traffic über KI-Assistenten Anfang 2024 bestand. Gleichzeitig wird es deutlich einfacher, Zugriffe aus KI-Systemen direkt mit klassischen Kanälen wie Organic Search oder Referral-Traffic zu vergleichen und deren Einfluss besser zu bewerten.
Fazit
Die Entwicklungen dieses Monats zeigen deutlich, wohin sich der Markt bewegt: KI wird zunehmend Teil der operativen Infrastruktur und nicht mehr nur ein zusätzliches Feature innerhalb einzelner Tools.
Dabei stehen weniger neue „KI-Funktionen“ im Mittelpunkt, sondern vielmehr die Frage, wie Systeme, Daten und Workflows miteinander verbunden werden. MCP, Edge-Decisioning, Zero-Copy-Architekturen oder native AI-Tracking-Funktionen verfolgen letztlich alle dasselbe Ziel: weniger Reibung zwischen Daten, Entscheidungen und Ausspielung.
Egal ob Experimentation, Personalisierung, Analytics, Tracking oder KI-gestützte Workflows: Wenn Sie sich zu einzelnen Entwicklungen, möglichen Auswirkungen auf Ihre Systemlandschaft oder konkreten Einsatzmöglichkeiten austauschen möchten, unterstützen wir Sie dabei gern. Nehmen Sie Kontakt auf.
Als Principal Martech & AI bei Up Reply verknüpft Benedikt APIs, automatisiert Prozesse und bringt KI in datengetriebene Marketing-Setups.