Das Meiste, was Ihre Plattform kann, hat Ihnen nie jemand gezeigt

Der Konsens — und wo er aufhört

Auf der DigIT Pharma in Berlin, Anfang September, lief eine Linie durch fast alle Gespräche: Omnichannel sei selten ein Technologie-, sondern vor allem ein Organisationsproblem. Der BCG-Report Cracking the Omnichannel Code zitiert einen Befragten mit demselben Befund: „The biggest challenge is never technical. It is change management.“

Dem ist nichts entgegenzusetzen. Es stimmt. Nur: „organisatorisch“ klingt nach Alignment und Change-Kommunikation. Und dort bleibt die Diskussion stehen. Dabei hat das Problem eine sehr konkrete Form.

Was im Workshop tatsächlich passiert

Ein neues System ist eingeführt. Es gibt einen Workshop. Marketing beschreibt, was es braucht — und beschreibt dabei, was es kennt: eine Zielgruppe, ein Asset, ein Versandzeitpunkt, ein Report hinterher. Die Systemseite hört zu und sagt: machbar.

Man einigt sich auf einen Standard. E-Mail-Deployment, ein Workflow, vielleicht zwei Varianten. Haken dran.

Und damit ist der Rahmen für die nächsten drei Jahre gesetzt. Nicht durch eine Entscheidung, sondern durch die Abwesenheit einer.

In meinen Workshops zeigt sich das immer wieder: Teams formulieren Anforderungen entlang der Funktionen, die sie bereits kennen. Möglichkeiten außerhalb dieses Rahmens werden selten konkret geprüft — die Business Unit kennt die Verschränkungen nicht, und die Systemseite schlägt nichts vor, wonach niemand gefragt hat.

Drei Gründe halten das stabil. Niemand hat es je vorgeführt — eine Release-Notiz leistet das nicht. Die Daten dafür wurden nie vorbereitet — viele Funktionen brauchen Felder, Ereignisse oder Zeitstempel, die nie definiert wurden. Man kann dabei Fehler machen — und ein Fehler in einer HCP-Kommunikation ist teuer.

Der dritte Grund ist der interessanteste, weil er der einzige ist, für den die Plattformen bereits eine Antwort mitliefern.

Zwei Fragen vor dem Versand. Eine danach.

Die Antwort besteht aus drei Werkzeugen. Zwei beantworten, was passieren wird. Das dritte beantwortet, ob es etwas gebracht hat — und das geht erst nach dem Start. In meinen Projekten ist mir keines der drei bisher als fester Bestandteil eines Kampagnenprozesses begegnet.

Frage 1 · Läuft die Journey so, wie wir sie gebaut haben?

Adobe Journey Optimizer hat dafür den Journey Dry run. Die Journey läuft mit echten Produktionsprofilen, aber: „Profiles in Dry run mode are not contacted, ensuring no risk of sending communications or impacting live data.“ Kanal-Knoten für E-Mail, SMS und Push werden nicht ausgeführt, Custom Actions sind deaktiviert.

Was ein Kampagnenteam dadurch vor dem Go-Live sieht: wie viele Profile an welchem Knoten ankommen, welche Verzweigung tatsächlich greift, an welcher Stelle die Zielgruppe versickert. Die Zahlen stehen direkt im Journey-Canvas, an den Knoten, wo die Entscheidungen fallen.

Das ist der Unterschied zwischen „wir gehen davon aus, dass etwa 5.000 Profile den E-Mail-Pfad nehmen“ und „wir haben nachgesehen“.

Was in den rund 70 Sekunden passiert: Eine abweichende Schreibweise in der Kanalregel — EMAIL im Profil, E-MAIL in der Abfrage — schiebt 5.000 passende Profile in den Default-Pfad. Technisch schlägt nichts fehl; der Inspector zeigt die Ursache direkt am Knoten. Nach der Korrektur bestätigt Prüflauf B die erwartete Verteilung. 1.000 Profile bleiben ohne passenden Kanal — ein eigener Prüfpunkt, keine Panne.

Eine Content-Freigabe findet diesen Fehler nicht — sie prüft die Nachricht, nicht die Bedingung. Der Versandreport danach meldet ihn auch nicht: Er zeigt, was rausging, nicht was hätte rausgehen sollen. Sichtbar wird die Lücke erst im Vergleich zwischen erwarteter und tatsächlicher Pfadverteilung — also genau dort, wo der Dry run hinsieht.

Die eine Grenze, die man dazusagen muss: Journey Dry run ist laut Adobe-Dokumentation derzeit ein Limited-Availability-Feature, „being rolled out globally over time“. Es ist dokumentiert, aber nicht automatisch in jeder Instanz verfügbar.

Weitere Grenzen: Nach 14 Tagen fällt die Journey zurück auf Draft. Die Profile zählen auf das Engageable-Profiles-Kontingent, die Journey auf das Live-Journey-Kontingent. Die Reporting-Werte verschwinden beim Stoppen. Wait-Aktivitäten sind standardmäßig deaktiviert und lassen sich einschalten — das macht den Dry run aber nicht zu einer vollständigen Prüfung des Zeitverhaltens: Bei geplanter Read-Audience-Aktivität verankert Adobe den Zeitplan am Moment der Dry-run-Aktivierung, nicht an der konfigurierten Uhrzeit.

Frage 2 · Was passiert mit einer einzelnen Person?

Der Dry run liefert Mengen. Er sagt nicht, warum genau dieser Arzt in genau diesem Ast gelandet ist.

Dafür gibt es die Journey Simulation: temporäre simulierte Nutzer, deren Weg Schritt für Schritt protokolliert wird — mit Zeitstempel, Verzweigungsentscheidung und Fehlern. Und, für mich der unterschätzte Teil: eine Coverage-Ansicht, die zeigt, welche Pfade der Durchlauf überhaupt abgedeckt hat.

Diese Frage höre ich in Kampagnenteams selten: Haben wir jeden Ast unserer Journey jemals durchlaufen — oder nur den, an den wir gedacht haben?

Adobe hat die Auswahl zwischen den drei Validierungsmethoden inzwischen dokumentiert:

Methode	Daten	Sendet echte Nachrichten?	Wofür
Journey Simulation	temporäre simulierte Nutzer	ja — an die Execution Addresses der simulierten Nutzer	schnelles Iterieren an neuen Ästen
Journey Test mode	persistente AEP-Testprofile	ja — an die echten Postfächer der Testprofile	Branch- und Message-Logik manuell prüfen
Journey Dry run Limited Availability	echte Produktionszielgruppe	nein, Aktionen werden übersprungen	Reichweite und Verzweigung in echter Größe

Der Satz, der die häufigste Sorge ausräumt, steht wörtlich in der Doku: „None of these methods contact real customers.“ Zwei der drei senden zwar Nachrichten — aber an Adressen, die man selbst eingetragen hat.

Adobes eigene Empfehlung: Simulation während des Bauens, Dry run direkt vor dem Publish. Test mode dann, wenn man mit echten, dauerhaften Testprofilen manuell durchgehen will.

Frage 3 · Hat die Kampagne etwas bewirkt?

Die ersten beiden Fragen betreffen die Ausführung. Diese hier betrifft den Nutzen — und sie lässt sich erst nach dem Start beantworten.

Ein Kampagnenreport meldet 3.900 zugestellt und 31 Prozent Öffnungsrate. Was er nicht sagt: Wie viele von diesen Ärzten hätten den Termin ohnehin gebucht?

Die Antwort liefert kein Report, sondern ein Vergleich. In Journey Builder geht das über die Random-Split-Aktivität: „Contacts are grouped in up to 10 configurable paths that you create.“ Einer dieser Pfade bleibt leer. Wer dort landet, bekommt nichts.

Unter geeigneten Bedingungen — zufällige Zuteilung, stabile Gruppenzugehörigkeit über die Laufzeit, gleiche Messung auf beiden Seiten — ist der Unterschied zwischen beiden Gruppen eine Schätzung des zusätzlichen Effekts der Kampagne. Keine exakte Zahl, aber eine mit einer Unsicherheit, die man beziffern kann.

Zwei Grenzen: „Each path is populated randomly, so its distribution of contacts often doesn’t match the configured percentage exactly.“ Wer bei 800 Ärzten fünf Prozent konfiguriert, bekommt nicht 40. Und fünf Prozent sind keine allgemeingültige Größe — wie groß die Kontrollgruppe sein muss, hängt davon ab, welchen Effekt man überhaupt noch erkennen können will.

Was die Stacks dabei leisten — und wo einer aufhört

Wer in beiden Welten arbeitet, sollte den Vergleich kennen, bevor er einem Team etwas verspricht.

Ebene 1 · Rendert der Inhalt richtig für diese Person?
Subscriber Preview and Test Send rendert die E-Mail mit den Daten eines ausgewählten Abonnenten. Der Testversand geht ausschließlich an die Adressen im Recipients-Tab. Grenzen: Testsendungen zählen auf das gekaufte Sendekontingent, und bei Status unsubscribed, bounced oder held wird nicht zugestellt.

Ebene 2 · Nimmt ein Kontakt den richtigen Pfad?
Journey Testing in Journey Builder, mit einer Data Extension als Entry Source: „configure a test to simulate a journey with real contacts“, und zwar „without sending messages to them or affecting tracking or reporting“.

Wichtig für die Erwartungshaltung: Der Testversand ist standardmäßig abgeschaltet — „The test is set to Do Not Send Messages by default“ — man kann ihn aber mit Send Only Test Messages und einer hinterlegten Adresse einschalten. Also derselbe Gedanke wie bei Adobe, nur mit umgekehrter Voreinstellung.

Grenzen: bis zu zehn Kontakte pro Test. „Test mode simulates random and decision split activities, but ignores wait times and contact entry settings.“ Custom Activities werden übersprungen. Für Single-Send-Journeys steht das Verfahren nicht zur Verfügung.

Ebene 3 · Wie viele erreichen welchen Knoten, in echter Größe?
Hier gibt es kein dokumentiertes Pendant. Journey Builder kennt keinen Modus, der die vollständige Produktionszielgruppe durchlaufen lässt und Knotenzahlen meldet, ohne zu senden.

Was man stattdessen tut: die Entry-Data-Extension auszählen, die Abzweigungen an den Consent-, Frequenz- und Freigabefeldern per Query nachbilden und die Mengen von Hand modellieren. Das geht — es ist nur Arbeit statt Knopfdruck, und es setzt voraus, dass jemand weiß, welche Felder die Verzweigung bestimmen.

Frage	Adobe Journey Optimizer	Salesforce Marketing Cloud
Rendert der Inhalt richtig?	Journey Test mode	Subscriber Preview and Test Send
Nimmt der Kontakt den richtigen Pfad?	Journey Simulation · Test mode	Journey Testing, bis zu 10 Kontakte
Versand im Test	sendet an eigene Testadressen	standardmäßig aus, zuschaltbar
Wie viele erreichen welchen Knoten, in echter Größe?	Journey Dry run (LA)	kein Pendant — Handarbeit auf der Datenschicht
Wird der Takt mitgeprüft?	teilweise, mit aktivierten Wait-Aktivitäten	nein, Wartezeiten werden ignoriert

Diese Tabelle ist für eine Systementscheidung zu klein, und so ist sie auch nicht gemeint. Sie ist für die Frage gemeint, wie viel Sicherheit ein Team im jeweiligen Stack überhaupt haben kann, bevor es auf Senden drückt.

Und zwei Fragen an die Datenschicht

Welche Ereignisse liegen bei uns überhaupt als auslösbares Event vor — und mit welcher Verzögerung? Was in die Kundendatenplattform einläuft, ist nicht automatisch als Auslöser verfügbar. Zwischen „das Ereignis wird erfasst“ und „die Journey kann darauf reagieren“ liegen Schema, Ingestion-Art und Takt.

Was wird beim Portal-Login tatsächlich verfügbar? Meldet sich ein HCP in einem Portal an, kann aus einem pseudonymen Besucher ein bekanntes Profil werden. Welches Verhalten anschließend mit dem CRM-Datensatz zusammengeführt wird, entscheidet sich am Identitätsmodell, an der Integration und an der zulässigen Datennutzung — automatisch passiert davon nichts. Welche Attribute damit nutzbar werden, ist eine Architekturfrage. Es ist aber vor allem eine Marketingfrage, denn daran hängt, welche Personalisierung möglich ist.

Keines dieser fünf Dinge ist exotisch. Drei sind dokumentierte Funktionen, eine davon mit eingeschränkter Verfügbarkeit. Zwei sind Fragen, für die es kein Projekt braucht. In den Workshop-Protokollen, die ich gesehen habe, stand keines davon.

Was die Zahlen dazu sagen

Der BCG-Report beruht auf einer Benchmark-Studie mit mehr als 100 Senior Omnichannel Leaders aus Biopharma und Medtech. Zwei Zeilen daraus passen zu dem Muster: 60 Prozent sind mit ihrer Next-Best-Action-Engine nicht zufrieden, und 90 Prozent folgen deren Empfehlungen in weniger als 60 Prozent der Fälle. Dazu: 97 Prozent halten Omnichannel für geschäftskritisch, 90 Prozent kämpfen mit Datensilos, 95 Prozent können den Omnichannel-ROI nicht klar messen.

Meine Erklärung dazu — und es ist eine Erklärung, kein Beweis: Eine Engine entscheidet auf Daten, die oft nie für diesen Zweck vorbereitet wurden, und ihre Vorschläge lassen sich schwer überprüfen, solange die Prüfwerkzeuge nicht im Prozess stehen. Die Zahlen zeigen das Muster. Sie belegen die Ursache nicht.

Der Einwand, den man sich selbst machen muss

Man kann all das auch anders lesen: Vielleicht sind die Empfehlungen einfach schlecht, und das Team hat recht, sie zu ignorieren. Das wäre kein Wissens-, sondern ein Qualitätsproblem.

Der Einwand ist berechtigt. Er verschiebt die Frage nur um eine Ebene: Warum sind sie schlecht? Wenn das Profil unvollständig ist und die Regel nie mit echten Daten durchgespielt wurde, produziert sie zuverlässig schwache Vorschläge. Aus den Zahlen beweisen lässt sich das nicht. Prüfen schon — an einer einzigen konkreten Journey.

Was die Ebene darunter leisten kann

Sichtbar machen. Nicht als Feature-Liste, sondern am eigenen Anwendungsfall, mit den eigenen Daten, in einer Sitzung, in der das Marketingteam selbst sieht, was herauskommt. Ein Dry run auf der eigenen Zielgruppe überzeugt anders als ein Screenshot aus einer Demo-Umgebung.

Kontrolliert erproben. Der häufigste Grund, warum eine Idee nicht ausprobiert wird, ist die Angst vor dem Fehler. Dafür gibt es diese Werkzeuge — aber jedes mit eigenen Grenzen. Die Aufgabe ist, die passende Methode zu wählen und ihre Grenze im Kampagnenprozess mitzuschreiben.

Die Voraussetzungen schaffen, bevor jemand fragt. Die interessanten Funktionen scheitern fast immer an derselben Stelle: ein Feld, ein Zeitstempel oder ein Ereignis, das in der Schnittstelle nie definiert wurde. Und wo ein Werkzeug fehlt, wie das Dry-run-Pendant in Marketing Cloud, besteht die Aufgabe darin, es auf der Datenschicht nachzubauen — statt dem Team zu sagen, das ginge eben nicht.

Die Frage zum Mitnehmen

Nicht: Haben wir die richtige Plattform? Sondern: Wer bei Ihnen zeigt den Business Units eigentlich, was das System kann — und wer sorgt dafür, dass sie es kontrolliert ausprobieren können?

Wenn die Antwort niemand ist, erklärt das mehr als jede Technologiebewertung. Und es erklärt auch, warum nach drei Jahren immer noch dasselbe E-Mail-Deployment läuft.

Quellen: Adobe Experience League zu Journey Dry run und zur Wahl der Validierungsmethode; Salesforce Help zu Journey Testing und Random Split; alle abgerufen 09/2026. Boston Consulting Group, „How Biopharma and Medtech Leaders Can Get Omnichannel Right“, Juni 2025, Benchmark-Studie mit mehr als 100 Senior Omnichannel Leaders. DigIT Pharma 2026, Berlin, 9.–10. September 2026.

Was Omnichannel für Marketing, Analyse, Leitung und Architektur jeweils bedeutet, steht im Grundlagenartikel → Was Omnichannel wirklich bedeutet