Bankdaten in die Public Cloud – und durch das Audit
Ein Institut im Konsumentenkreditgeschäft, Teil einer internationalen Bankengruppe, löst sein E-Mail-System durch Adobe Journey Optimizer ab. Die Einführung des Tools war der kleinere Teil. Der harte Teil war die Freigabe interner Kundendaten für eine Cloud, die dem Institut nicht gehört.
Ein E-Mail-System, das Listen verschickt
Was vorher lief – und warum es nicht mehr trug.
Listen statt Profile. Versand auf Basis exportierter Empfängerlisten. Kein durchgängiges Kundenprofil, keine Reaktion auf Ereignisse.
Daten in Silos. Warehouse, Kernsysteme und Drittanbieter lieferten getrennt. Die Zusammenführung passierte manuell, kurz vor dem Versand.
Ein Kanal. E-Mail allein. SMS und Push existierten nicht als orchestrierte Kanäle, sondern bestenfalls als Einzellösungen.
Was Adobe Journey Optimizer ist – und warum eine Bank es wählt
Adobe Journey Optimizer ist die Orchestrierungs-Anwendung der Adobe Experience Cloud. Kein E-Mail-Tool mit angeschlossener Datenbank, sondern eine Anwendung auf der Adobe Experience Platform: Jede Journey liest dasselbe Kundenprofil, das auch Segmentierung, Governance und Customer Journey Analytics nutzen.
Für das Institut hieß das eine Entscheidung, die alles andere trägt: Welche Daten verlassen das Haus – und welche nicht. Das Warehouse blieb führendes System. Die Plattform bekam einen definierten Ausschnitt, im Batch-Zyklus geladen, mit Löschfristen je Datensatz.
Ein Profil statt Listen. Jeder Versand las vorher eine exportierte Empfängerliste. Im Real-Time Customer Profile gibt es einen Datensatz pro Kunde, den Segmentierung, Journey und Reporting teilen – wer widerruft, ist überall widerrufen.
Ereignisse statt Versandtermine. Kontoeröffnung, Antrag, Ablauf einer Frist: Die Journey reagiert auf das, was passiert, mit Wartezeiten und Bedingungen in einer Logik statt in drei Tools.
Neue Kanäle ohne neue Systeme. SMS und Push sind Ausgänge derselben Journey wie E-Mail. Consent, Frequenz und Löschfristen gelten einmal – für alle Kanäle. Das war die Voraussetzung, um Omnichannel überhaupt zu beginnen.
Das führende System bleibt im Haus. Die Plattform bekommt genau so viel, wie sie zur Aktivierung braucht.
Kundendaten verlassen das Haus – unter welchen Bedingungen?
Bei einer Bank ist nicht die Frage, ob eine Marketing-Plattform technisch funktioniert. Die Frage ist, welche Kundendaten sie überhaupt sehen darf, wie lange sie sie behalten darf und wie belegt wird, dass sie wieder verschwinden. Diese Freigabe war der längste und härteste Teil des Projekts – nicht die Konfiguration.
Die tragende Architekturentscheidung: Das interne Data Warehouse blieb die eigentliche Kundendatenplattform. Journey Optimizer bekam nicht den Kundenbestand, sondern gezielt die Merkmale, Ereignisse und Kennzeichen, die zur Aktivierung nötig sind – in eigenen Datasets, mit definierter Lebensdauer.
Konkret: ein striktes TTL-Konzept je Dataset, eigene Datasets statt gemeinsamer Ablage, Löschlogik über die Data Hygiene API und ein belastbarer Rückweg ins Warehouse. Dazu der Nachweisweg für die Cyber-Security-Audits: Zertifikate, Serverstandorte, Datenflüsse, Protokolle, Einsicht ins Tool.
Teil davon war das Preference Center: Zeitstempel und Logiken wurden mit Legal und Data Privacy abgestimmt, und Abmeldungen laufen im 24-Stunden-Zyklus mit Error Handling zurück ins Warehouse – damit ein Widerruf dort ankommt, wo die Daten führend gehalten werden, und nicht nur in der Plattform.
Nicht das Rohfeld in die Cloud, sondern das abgeleitete Merkmal. Was die Plattform nicht braucht, bekommt sie nicht.
Vom Produkt zur Datenanforderung: der Attributskatalog
„Welche Daten braucht ihr?“ ist die falsche erste Frage. Die richtige lautet: Welche Entscheidung soll die Journey treffen – und welche Information ist dafür das Minimum?
Bevor ein einziges Feld gemappt wurde, entstand ein Katalog. Für jedes Produkt und jeden Anwendungsfall des Instituts wurde rückwärts gearbeitet: von der Nachricht, die am Ende beim Kunden ankommen soll, über die Entscheidung, die dafür in der Journey fallen muss, bis zum Datenpunkt, der diese Entscheidung trägt. Erst dann folgte die technische Seite – Ereignis oder Attribut, XDM-Feld, Quellsystem, Ladeweg.
Jede Zeile bekam zwei Spalten, die in Marketing-Projekten oft fehlen und in einer Bank über die Freigabe entscheiden: Zweck und Löschfrist. Genau diese Tabelle war später die Grundlage der Gespräche mit Legal und Data Privacy – und das Dokument, das in den Audits auf dem Tisch lag.
| Anwendungsfall | Entscheidung in der Journey | Datenpunkt | Typ | Zweck & Frist |
|---|---|---|---|---|
| Willkommensstrecke | Ist der Vertrag aktiv – und seit wann? | Vertragsstatus | Attribut | Vertragskommunikation · Laufzeit + gesetzliche Frist |
| Reaktion auf einen Antrag | Wurde ein Antrag gestellt, und ist er offen? | Antrag eingegangen | Event | Servicekommunikation · kurze Frist nach Abschluss |
| Regionale Aussteuerung | Welche Region – ohne die Adresse zu übertragen? | Region, abgeleitet | abgeleitet | Regionale Angebote · an den Vertrag gebunden |
| Kanalwahl | Darf per Push kontaktiert werden? | Consent je Kanal | Attribut | Einwilligungsnachweis · bis Widerruf + Nachweisfrist |
| Angebotslogik | Über welchen Vertriebsweg kam der Kunde? | Herkunftskennzeichen | Attribut + Gültigkeit | Angebotssteuerung · Laufzeit des Programms |
Beispielzeilen, anonymisiert und auf das Muster reduziert. Der reale Katalog umfasste die Produktpalette des Instituts und wurde je Zeile freigegeben.
Die dritte Zeile zeigt das Prinzip, das den Katalog von einer Wunschliste unterscheidet: Die Plattform bekommt nicht die Adresse, sondern die Region. Für die Entscheidung „welches regionale Angebot“ reicht das abgeleitete Merkmal – und ein Feld, das nie übertragen wird, muss auch nicht gelöscht, geschützt und im Audit erklärt werden. Datenminimierung ist hier kein Compliance-Zugeständnis, sondern spart Arbeit an drei Stellen gleichzeitig.
Herkunft ist eine Entscheidungsgrundlage, kein Verwaltungsdatum
Ein Kunde erreicht das Institut nicht nur direkt. Ein Teil des Geschäfts läuft über Vertriebspartner – und was ein Kunde danach angeboten bekommen darf, hängt davon ab, woher er kam. Für die Orchestrierung ist das kein Randfall, sondern eine eigene Klasse von Anforderungen: Die Herkunft braucht ein eigenes Attribut, eine Gültigkeitsdauer, eine Vorrangregel für den Fall, dass mehrere Programme zutreffen – und sie muss in dem Moment gelesen werden, in dem die Nachricht gebaut wird, nicht beim nächtlichen Import.
Damit war klar, warum eine Empfängerliste nicht mehr trägt: Dieselbe Kampagne muss für zwei Kunden zwei verschiedene Inhalte erzeugen, weil ihre Herkunft verschieden ist. Das ist Personalisierung als Regelwerk, nicht als Textbaustein.
// Eintritt: in der Audience, seit 7 Tagen nicht kontaktiertinAudience("Aktivkunden – Kreditkarte") and not inLastDays(#{Profile.lastContact.timestamp}, 7)// Angebotslogik: Herkunft prüfen, solange das Programm giltnot isEmpty(#{Profile.origin.programId}) and nowWithDelta(0, "days") < toDateTime(#{Profile.origin.validUntil})// Kanal: Push nur mit Consent und Gerät, sonst E-MailisEmpty(#{Profile.pushToken}) or #{Profile.consents.push.val} != "y"Funktionen inAudience, inLastDays, isEmpty, nowWithDelta, toDateTime aus der AJO-Funktionsreferenz; Feldpfade sind Platzhalter.
Vom Katalog zum Schema: wie ein XDM-Baum entsteht
Der Attributskatalog sagt, welche Information gebraucht wird. Das Schema sagt, wie sie in der Plattform aussieht. Adobe formuliert das als Gleichung: Klasse + Feldgruppen = XDM-Schema.
Ein Schema ist „ein Satz von Regeln, der Struktur und Format der Daten abbildet und validiert“. Die Klasse bestimmt das Verhalten der Daten – zustandsbeschreibend oder zeitbasiert – und damit, welche Feldgruppen überhaupt zulässig sind. Eine Feldgruppe ist eine wiederverwendbare Komponente, die zusammengehörige Felder definiert. Der Datensatz ist am Ende die Tabelle, in die eingelesen wird; alle Daten müssen einem vorher definierten Schema entsprechen.
Für ein Marketing-Datenmodell zählt vor allem eine Unterscheidung: XDM Individual Profile ist zustandsbeschreibend und bildet die Attribute einer Person ab – veränderlich. XDM ExperienceEvent ist zeitbasiert und hält den Zustand fest, als etwas passiert ist – unveränderlich. Vertragsstatus ist ein Profil-Attribut. „Antrag eingegangen“ ist ein Event. Diese Zuordnung entscheidet später darüber, ob eine Journey auf ein Ereignis reagieren kann oder nur eine Bedingung prüft.
Genau deshalb steht in Adobes Best Practices ein Schritt vor dem Modellieren: „Sort your data tables into profile, lookup, and event categories before constructing your schemas.“ Im Projekt war das die Brücke vom Katalog zum Schema – jede Zeile bekam vorab eine dieser drei Kategorien.
Schema „Kunde – Aktivierung" ├─ Klasse XDM Individual Profile zustandsbeschreibend ├─ Feldgruppe Demographic Details Standard ├─ Feldgruppe Personal Contact Details Standard └─ Feldgruppe _{TENANT_ID}.aktivierung eigen ├─ vertragsstatus string ├─ regionAbgeleitet string ├─ herkunft │ ├─ programId string │ └─ validUntil date-time └─ consents · email · sms · push object Schema „Antrag – Ereignis" └─ Klasse XDM ExperienceEvent zeitbasiert, unveränderlich identityMap CRMID (primär) · email · ECID
TENANT_ID to avoid collisions with other field groups or fields.“ Genau ein primäres Identitätsmerkmal ist Pflicht, damit das Schema für das Real-Time Customer Profile aktiviert werden kann.Über die Schema Registry API sieht dieselbe Struktur so aus – die Klasse wird über allOf referenziert, eigene Felder liegen im Tenant-Namespace:
// Klasse referenzieren – die "Basisklasse" des Schemas{ "title": "Kunde – Aktivierung", "allOf": [ { "$ref": "https://ns.adobe.com/xdm/context/profile" } ]}// Eigene Feldgruppe: alles unter dem Tenant-Namespace"_{TENANT_ID}": { "aktivierung": { "herkunft": { "programId": { "type": "string" }, "validUntil": { "type": "string", "format": "date-time" } } }}// Identitäten – genau eine primäre je Schema"identityMap": { "CRMID": [ { "id": "2e33192000007456-...", "primary": true } ], "email": [ { "id": "...", "primary": false } ]}Struktur und identityMap nach der Adobe-Dokumentation (Schema Composition, Schema Registry API); Feld- und Tenant-Namen sind Platzhalter aus dem Projektmuster. Adobe akzeptiert bei der Aufnahme weder null noch leere Werte in Pflichtfeldern.
Zwei Regeln aus derselben Dokumentation waren im Bankkontext mehr als Stilfragen. „Keep schemas as simple as possible. Add new fields only when necessary.“ Und: „If you are not sure whether a particular field is necessary to include in a schema, the best practice is to leave it out.“ Was der Katalog nicht begründen konnte, kam nicht ins Schema – und musste damit auch im Audit nicht verteidigt werden. Dass Schema-Änderungen additiv sind und Breaking Changes nicht unterstützt werden, macht diese Disziplin zur Notwendigkeit: Ein Feld, das einmal drin ist, verschwindet nicht mehr geräuschlos.
Der Unterschied zwischen Profil und Event hat noch eine Konsequenz für die Löschfristen: Events tragen laut Adobe ein höheres Risiko, automatisch abzulaufen und aus dem Profilspeicher entfernt zu werden. Wer eine Journey auf ein Ereignis stützt, muss wissen, wie lange dieses Ereignis überhaupt lesbar ist – eine Frage, die im Katalog neben der Löschfrist steht.
Personalisierung ist ein Regelwerk, kein Textbaustein
Ein Datenmodell allein verschickt nichts. Zwischen Profil und Postfach liegt die Ebene, an der ein Kampagnenteam täglich arbeitet: Templates, wiederverwendbare Fragmente und die Ausdrücke, die aus einem Feld einen Satz machen.
Der Message Designer greift auf dieselben Profilfelder zu wie die Journey-Bedingung. Zwei Schreibweisen stehen zur Verfügung: Handlebars {{…}} für Profilattribute und Schleifen, und die Profile Query Language {%= … %} für Funktionen und Bedingungen. In einer Bank ist dabei ein Detail wichtiger als jede Gestaltungsfrage: Was passiert, wenn ein Feld leer ist? Ein optionales Attribut darf leer sein – die Anrede darf es nicht.
// Fallback, wenn das Attribut leer oder null istHallo {%= profile.person.name.firstName ?: "zusammen" %},// Inhalt nach Vertragslage – ein Template, zwei Aussagen{%#if profile.contract.status = "aktiv" %} … Inhalt für Bestandskunden{%else%} … neutraler Inhalt ohne Produktbezug{%/if%}Syntax nach der AJO-Personalisierungsdokumentation: ?: ist der Default-Fallback-Helper, Vergleiche in PQL nutzen ein einfaches =, nicht ==. Feldpfade sind Platzhalter.
Der zweite Baustein sind Fragmente – „wiederverwendbare Komponenten, die in einer oder mehreren E-Mails referenziert werden können“. Für ein reguliertes Haus ist das kein Komfort, sondern Governance: Pflichtangaben, Impressum, Widerrufshinweis und Abmeldelink liegen einmal zentral. Wenn Legal eine Formulierung ändert, ändert sie sich überall – laut Dokumentation werden Änderungen „automatisch an alle Inhalte weitergegeben, die das Fragment nutzen, einschließlich laufender Journeys und Kampagnen“, solange die Vererbung nicht gebrochen wurde.
Eine Grenze davon gehört ins Betriebshandbuch, weil sie sonst im Livebetrieb auffällt: Neue personalisierte Attribute nachträglich in ein aktives Fragment einzubauen, wird nicht unterstützt. Wer eine Personalisierung ergänzen will, plant sie vorher ein – oder baut eine neue Version.
Dazu kamen Content-Templates als Startpunkte für wiederkehrende Strecken und das Event-Tagging, damit Reaktionen als Ereignisse zurück ins Profil laufen und die nächste Journey darauf reagieren kann. Erst mit dieser Ebene wird aus dem Datenmodell etwas, das ein Team ohne Entwickler bedienen kann – und genau das war Ziel der Übergabe.
Drei Ebenen, die zusammen tragen müssen
Datenfundament
Schemas und Datasets nach dem Attributskatalog, Mapping aus dem Warehouse über Data Prep – inklusive Transformationen und berechneter Felder, damit abgeleitete Merkmale beim Import entstehen und nicht im Quellsystem. Dazu Identitäten und Merge-Regeln, Löschfristen je Dataset und Sandboxes für Entwicklung, Test und Produktion, damit eine Änderung nicht im Livebetrieb geprüft wird.
Kanäle
E-Mail als Ablösung des Altsystems, dazu SMS und Push als orchestrierte Kanäle derselben Journey. Consent und Frequenz gelten je Kunde, nicht je Kampagne. Custom Actions binden Systeme an, die keinen eigenen Kanal haben.
Betriebsfähigkeit
SSO über SAML, ein Rollenmodell für Kampagnen-Engineering, Administration und Freigabe, Aufgaben und Abhängigkeiten in Jira, Dry-Runs vor jedem Schritt und die Übergabe an das interne Team mit eigenen Zugängen.
Die Freigabe lief nicht am Ende, sondern parallel ab dem Datenfundament – jede neue Datenkategorie brachte eine neue Prüfrunde.
Was ein Audit sehen will – und was es nicht akzeptiert
Die Freigabe fiel nicht in einem Termin. Sie war eine Reihe von Reviews mit den Architekten des Instituts, mit Cyber-Security und mit Data Privacy – jede mit eigenen Fragen und eigenen Nachweisen.
Geliefert wurde nicht eine Präsentation, sondern eine Beweiskette:
- Datenflüsse je Datenkategorie – von der Quelle über Ingestion und Profil bis zum Kanal und zur Löschung, als Diagramm und als Beschreibung.
- Serverstandorte und Zertifikate des Anbieters, zugeordnet zu den tatsächlich genutzten Diensten.
- Löschkonzept mit Nachweis – TTL je Dataset, Data Hygiene API, und die Antwort auf die Frage, woran man erkennt, dass gelöscht wurde.
- Rollen- und Rechtekonzept – wer darf welche Daten sehen, wer darf versenden, wer darf freigeben, angebunden über SSO.
- Widerrufsweg – Preference Center, Zeitstempel, Rückfluss ins Warehouse im 24-Stunden-Zyklus mit Fehlerbehandlung.
- Der Attributskatalog – jede Zeile mit Zweck und Frist, freigegeben statt behauptet.
Und die Gegenprobe, weil sie in solchen Projekten die meiste Zeit kostet: Ein Audit akzeptiert kein „wir nutzen nur, was nötig ist“ ohne Feldliste. Keine Löschung ohne Nachweis, wie sie belegt wird. Keine Rolle, die niemand namentlich verantwortet. Und keine Architekturskizze, die nicht zeigt, wo die Daten liegen.
Wer diese sechs Punkte vor dem ersten Audit vorbereitet, verkürzt die Freigabe erheblich. Wer sie danach nachliefert, verhandelt jedes Mal neu.
Was übergeben wurde, damit es ohne mich weiterläuft
Eine Plattform, die nur der Berater bedienen kann, ist kein Ergebnis. Die Übergabe war deshalb kein Termin am Ende, sondern ein eigener Arbeitsstrang – parallel zum Aufbau.
Drei Workshop-Tage fanden vor Ort statt, dazu liefen Remote-Sessions für Accounts, Sandbox-Freigaben und offene Fragen aus dem Tagesgeschäft. Geschult wurden mehr als zehn Personen, vom Kampagnenteam bis ins Management – nicht dieselben Inhalte für alle: Wer Journeys baut, braucht Bedingungen und Fragmente; wer freigibt, braucht das Rollenmodell und den Freigabeweg; wer Budget verantwortet, braucht die Architektur in einem Bild.
Blueprints und Templates für die wiederkehrenden Strecken, damit das Team nicht bei jeder Kampagne neu entscheidet, sondern anpasst.
Dokumentation des Datenmodells – der Attributskatalog mit Zweck und Frist, die Schemas, die Mapping-Regeln aus dem Warehouse.
Rollen- und Freigabemodell mit eigenen Zugängen über SSO: Kampagnen-Engineering, Administration, Freigabe getrennt statt ein Sammelkonto.
Backlog und Abhängigkeiten in Jira, damit offene Punkte nach der Übergabe nicht in einer Mailkette leben.
Dry-Runs vor jedem Schritt – dokumentiert, samt der Fehler, die sie gefunden haben. Das ist der Teil, der beim nächsten Release Zeit spart.
Am Ende standen Datenmodell, Pipelines, Löschlogiken, SSO, Rollen, Kanäle und Freigabeprozesse aufgesetzt und dokumentiert. Die Security-Audits waren mit Zertifikaten, Datenflüssen und Serverstandorten belegt. Das interne Team hatte eigene Zugänge – und die Produktion war einsatzbereit, die erste Testmail erfolgreich zugestellt.
Wie dieser Enablement-Teil aufgebaut ist, steht im Detail unter Enablement.
Wohin der Weg führen sollte
Der Batch-Zyklus war eine bewusste Entscheidung, keine Einschränkung: Solange das Warehouse führend ist, gibt es keinen Grund, Daten schneller zu bewegen, als sie gebraucht werden. Die geplante Ausbaustufe nach dem Rollout war die Near-Real-Time-Synchronisation über das Edge Network und die Real-Time CDP – damit ein Ereignis eine Journey in Sekunden auslöst statt im Tageszyklus.
Aus E-Mail-Versand wird so Customer Journey Orchestration: SMS und Push waren angebunden, Decisioning und In-App vorbereitet. Und weil jede Journey auf demselben Profil läuft, werden Entscheidungen messbar – wer welche Nachricht wann bekommen hat, was daraufhin passierte, wo die Strecke abbricht. Für Campaign Engineers und Architekten liegt genau hier der Hebel: nicht mehr Mails versenden, sondern datengestützte Entscheidungen im Unternehmen sichtbar machen.
Dasselbe Muster, andere Prüfinstanz
Die Aufgabe wiederholt sich in jeder regulierten Branche: Ein Marketing-Tool wird eingeführt, aber die eigentliche Arbeit liegt darunter – im Datenmodell, in den Löschfristen, im Nachweis gegenüber der Revision.
In Pharma heißt die Prüfinstanz MLR statt Cyber-Security, das HCP-Profil ersetzt das Kundenprofil, und statt Kontostatus entscheidet die Freigabe eines Claims. Die Struktur des Problems bleibt dieselbe: Das führende System bleibt im Haus, die Plattform bekommt genau so viel, wie sie zur Aktivierung braucht – und der Attributskatalog entscheidet, wie lange die Freigabe dauert. Wie sich das je Branche unterscheidet, steht unter Branchen. Warum ein solches Vorhaben nur trägt, wenn Marketing, Analyse, Leitung und Architektur dieselbe Diskussion führen, steht im Grundlagenartikel Was Omnichannel wirklich bedeutet.
Adobe Experience Cloud im DetailWas Entscheider vor so einem Projekt fragen
Bleibt unser Data Warehouse das führende System?
Was verlangt ein Security-Audit konkret?
Wie lange dauert die Freigabe der Daten?
Was passiert mit Abmeldungen und Widersprüchen?
Braucht es dafür Echtzeit?
Quellen: Adobe Experience Platform Blueprints, XDM Schema Composition, Best Practices for data modeling, Schema Registry API sowie die AJO-Personalisierungs- und Funktionsreferenz (Experience League, abgerufen 02.09.2026). Eigene Darstellungen. Projektdetails anonymisiert; beschrieben ist die gelieferte Arbeit – keine Kundendaten, keine Betriebskennzahlen.