Geprüft anhand von Salesforce Help, dem Salesforce-Blog und den Trailhead-Modulen Data 360 Setup und Data Governance Strategies, September 2026. Data Cloud heißt inzwischen Data 360.
Die meisten Datenlecks sehen nicht aus wie ein Hackerangriff. Sie sehen aus wie ein normaler Arbeitstag: Der Außendienst öffnet ein Kundenprofil, jemand im Callcenter liest eine Nummer vor, das Marketing baut ein Segment. Niemand macht absichtlich etwas falsch. Die Daten landen einfach dort, wo keine Regel sie aufgehalten hat.
Dieser Artikel hat zwei Teile. Erstens: Was kann konkret schiefgehen? Dazu vier kurze Beispiele aus Pharma und Banking. Zweitens: Welche Regeln bietet Salesforce Data 360 dagegen – und welche Standardeinstellung erwischt viele Teams kalt?
Die Kurzfassung: dieselben Kundendaten, drei Mitarbeitende – und was jede Person sehen darf, sobald eine Data-360-Regel greift. Namen und Daten sind frei erfunden.
Was schiefgehen kann
1. Pharma: Der Außendienst sieht eine Nebenwirkungsmeldung
Eine Ärztin meldet dem Medical-Team, dass ein Patient nach der zweiten Dosis Schwindel hatte. Die Meldung landet im zusammengeführten Kundenprofil. Zwei Wochen später besucht der Außendienst dieselbe Ärztin und spricht sie darauf an.
Viele Pharmaunternehmen trennen Medical und Vertrieb bewusst. Sobald die Daten in einem gemeinsamen Profil liegen, gibt es diese Trennung nur noch, wenn eine Regel sie durchsetzt.
Kann das bei uns passieren? Welche Teams können heute das komplette Profil einer Ärztin öffnen – inklusive dessen, was Medical weiß?
2. Banking: Ein externer Mitarbeiter liest die volle IBAN vor
Eine Bank arbeitet mit einem externen Callcenter. Die Mitarbeitenden müssen den richtigen Kunden finden, brauchen aber nicht die volle Kontonummer. Ohne Regel sehen sie sie trotzdem – und einer liest sie in einem aufgezeichneten Gespräch vor.
Kann das bei uns passieren? Was sieht ein externer Mitarbeiter auf dem Bildschirm, wenn er einen Kunden öffnet?
3. Banking: Ein sensibles Feld landet in einer Kampagne
Jemand im Marketing baut ein Cross-Selling-Segment und filtert auf ein Feld „Inkasso-Status“, weil es eben da war. Die Kunden in diesem Segment bekommen ein Angebot, an dem sie merken, dass das Marketing der Bank von ihren Zahlungsrückständen weiß.
Kann das bei uns passieren? Welche Felder darf das Marketing für Segmente nutzen, und wer hat das entschieden?
4. Pharma: Eine Ärztin ohne Einwilligung bekommt eine E-Mail
Dieser Fall ist anders, und das ist wichtig. Hier geht es nicht darum, wer die Daten sehen darf, sondern ob das Unternehmen die Person überhaupt kontaktieren darf. Zugriffsregeln lösen das nicht. Dafür ist das Einwilligungsmanagement zuständig.
Kann das bei uns passieren? Wird die Einwilligung in dem Moment geprüft, in dem ein Segment versendet wird – oder nur beim Eingang der Daten?
Warum das passiert
Niemand hat die Daten als sensibel markiert. Ist ein Feld nicht als medizinisch oder finanziell gekennzeichnet, weiß keine Regel, dass es Schutz braucht.
Es gibt Regeln, aber eine Standardeinstellung hebelt sie aus. Dazu unten mehr – das ist die häufigste Überraschung.
Das zusammengeführte Profil übernimmt ein unmarkiertes Feld. Data 360 führt Daten aus mehreren Quellen zu einem Profil zusammen. Wurde ein sensibles Feld an der Quelle nie markiert, wandert es ungeschützt ins Profil.
Das Regelwerk in Salesforce Data 360
Dieser Teil ist für Admins und Architekten. Wer das Team leitet, dem reicht der Selbsttest am Ende.
Schritt 1: Sensible Daten mit Tags markieren
In Data 360 hängen Sie Tags an Felder, zum Beispiel E-Mail-Adresse oder Kreditkartennummer. Tags können einen übergeordneten Tag haben: Personenbezogene Daten → E-Mail-Adresse, Telefonnummer.
Diese Hierarchie erledigt die eigentliche Arbeit. Setzen Sie einen untergeordneten Tag auf ein Feld, wird der übergeordnete automatisch mitgesetzt. Jede Regel für Personenbezogene Daten schützt dieses Feld dann ohne zusätzlichen Aufwand.
Weitergabe (Propagation): Tags an einem Quellobjekt können auf verbundene, nachgelagerte Objekte übertragen werden, etwa auf das zusammengeführte Profil. Das schließt die Lücke aus Ursache 3.
KI-Vorschläge:Suggest Tags schlägt Tags vor. Die Funktion liest nur Metadaten – Feldnamen und Beschreibungen –, nicht die Inhalte der Felder. Ein Admin gibt jeden Vorschlag frei. Das ist die Antwort, wenn Compliance fragt, ob die KI Patientendaten sieht.
Nicht alles taggen. Beginnen Sie mit Daten, die Datenschutz, Compliance oder wichtige Entscheidungen betreffen. Alles zu taggen macht Arbeit, ohne mehr zu schützen.
Schritt 2: Festlegen, wer was sieht
Data 360 nutzt attributbasierte Zugriffskontrolle (ABAC). Eine Regel verbindet Merkmale der Person (Abteilung, Rolle) mit Merkmalen der Daten (ihren Tags). Sie formulieren die Absicht einmal, und sie gilt für jedes Feld mit diesem Tag – auch für Felder, die später dazukommen.
Was Sie brauchen
Policy-Art
Beispiel von oben
Bestimmte Personen dürfen es gar nicht sehen
Data Access Policy
Der Vertrieb hat keinen Zugriff auf Felder mit dem Tag Medizinische Informationen
Die Person braucht den Datensatz, aber nicht den vollen Wert
Dynamic Data Masking
Das externe Callcenter sieht DE89 •••• •••• •••• •••• 00
Jede Person soll nur ihren Ausschnitt sehen
Row-Level Security
Die Regionalleitung sieht nur ihre Region
Drei Policy-Arten, drei der vier Beispiele. Die Einwilligung (Beispiel 4) ist eine eigene Aufgabe.
Laut Salesforce werden Governance-Policies über alle Data-360-Funktionen hinweg durchgesetzt, auch in der Segmentierung. In der Praxis heißt das: Sperrt eine Policy ein Feld für jemanden im Marketing, steht es beim Segmentbau nicht zur Verfügung (Beispiel 3).
Deny schlägt Allow. Erlaubt eine Regel den Zugriff und verbietet ihn eine andere, wird er verweigert.
Einfach halten. Wenige, klare Regeln sind besser als viele, die sich überschneiden. Zu strenge Regeln verleiten dazu, sie zu umgehen.
Mit echten Rollen testen, bevor Sie für alle ausrollen.
Schritt 3: Die Standardregel „Allow All“ entfernen – mit Plan
Hier liegt der Haken. Jede Data-360-Org, ob neu oder bestehend, startet mit einer aktiven „Allow All“-Policy. Sie sorgt dafür, dass nichts kaputtgeht, während Sie Ihre Regeln entwerfen.
Die Folge: Solange Allow All aktiv ist, haben neue Allow-Regeln keine Wirkung – alle haben ohnehin Zugriff. Nur Deny-Regeln greifen. Ein Team kann also ein sauberes Regelwerk bauen und trotzdem komplett offen sein. Allow All ohne Plan zu löschen ist aber genauso schlecht: Dann verlieren womöglich alle Nutzer auf einen Schlag ihren Zugriff.
Trailhead beschreibt fünf Phasen:
Prüfen und entwerfen. Die Policy bleibt. Klären Sie, wer wirklich worauf Zugriff braucht.
Bauen und testen. Legen Sie die neuen Allow- und Deny-Regeln an, während Allow All noch aktiv ist.
Kommunizieren. Sagen Sie den Nutzern, was sich wann ändert. Planen Sie ein Wartungsfenster.
Umschalten. Löschen Sie in diesem Fenster Allow All und aktivieren Sie die neuen Regeln.
Prüfen und begleiten. Klären Sie mit den Nutzern, ob alle den Zugriff haben, den sie brauchen.
Hinweise zur Einrichtung, die später Ärger sparen
Home-Org vor dem Lizenzkauf festlegen. Wer mehrere Salesforce-Orgs hat, entscheidet vorher, mit welcher Data 360 verbunden wird – die Bereitstellung startet automatisch.
Datenresidenz: Müssen Daten in einer Region bleiben, planen Sie eine Data 360 pro Region.
Permission Sets: Starten Sie mit den Standard-Sets (Data Cloud Architect, Activation Manager, Activation Specialist, User). Ein neuer Nutzer bekommt seine Login-Mail, sobald das Permission Set gespeichert ist – das Konto sollte dann bereit sein.
Verbindung zur Marketing Cloud: Data 360 legt im Automation Studio eigene Automationen an, um Daten zu übertragen. Sagen Sie Ihren Marketing-Cloud-Nutzern, dass sie diese nicht bearbeiten sollen.
Selbsttest: Kann das bei uns passieren?
Fünf Fragen. Dafür braucht es kein Projekt, nur zehn Minuten mit Ihrem Admin.
Ist die „Allow All“-Policy in unserer Data-360-Org noch aktiv?
Welche Felder haben wir als sensibel markiert, und welche haben wir vergessen?
Wer kann das komplette zusammengeführte Kundenprofil sehen?
Was sieht ein externer Partner, wenn er einen Kunden öffnet?
Welche Felder darf das Marketing in Segmenten nutzen, und wird die Einwilligung vor dem Versand geprüft?
Wenn Sie eine davon nicht beantworten können, fangen Sie genau dort an.
Wie ich das gerade lerne
Ich arbeite gerade an der Zertifizierung zum Salesforce Data 360 Consultant. Die Inhalte stammen aus den Trailhead-Modulen Data 360 Setup und Data Governance Strategies. Wer tiefer einsteigen will, beginnt mit dem Trail „Prepare for your Salesforce Data 360 Consultant Certification“ und dem unten verlinkten Help-Artikel zur Data Governance in Data 360.
Ebenfalls lesenswert: MarTech unter der Haube, Teil 3 – die Adobe-Seite, auf der jede Data Usage Policy ausgeschaltet ausgeliefert wird.
Die Beispiele in diesem Artikel sind frei erfunden. Produktverhalten laut Salesforce-Dokumentation, Stand September 2026. Salesforce, Data 360 und Trailhead sind Marken der Salesforce, Inc. Dies ist eine unabhängige Analyse; es besteht keine Partnerschaft mit oder Empfehlung durch Salesforce.
Teil 3 · Sie sind hierSteuern · Messen · Warehouse · KI-Agenten
Der 30-Sekunden-Überblick
Durchsetzung, die Sie nie eingeschaltet haben, scheitert wie ein Graph: lautlos, und ohne Fehler zum Finden.
Steuern›Messen›Warehouse›KI-Agenten
AusAlle Data Usage Policies, auch Adobes eigene Core Policies, sind standardmäßig deaktiviert. Neu angelegte ebenfalls.
DreiEnterprise-Destinations in Adobes Katalog, in denen die Consent-Policy-Auswertung nicht läuft – und nicht einwilligende Profile im Export enthalten sind.
Keine IDsFederated Composition verbindet über einen Schlüssel, den Sie definieren. Daten, die im Warehouse bleiben, bekommen gar keine Identity Resolution.
30 Sekunden bis hierhin · 5 Minuten für die vier Abschnitte.
Teil 1 und 2 sind sieben Stationen abgegangen: ob die Daten ankommen, ob sie modelliert sind, ob sie sich zu einer Person auflösen, ob die Fragmente ein Profil werden, wie schnell eine Regel beantwortet werden kann, wo eine Entscheidung fallen kann und wie lange sie bis zu einem Kanal braucht. Sieben Stationen, die entscheiden, ob Sie handeln können.
Dieser Teil behandelt, ob Sie handeln dürfen – und ob hinterher irgendjemand sagen kann, was sich dadurch verändert hat. Jede Data Governance Policy wird ausgeschaltet ausgeliefert – auch Adobes eigene Core Policies – und Adobe dokumentiert das auf zwei verschiedenen Seiten. Dann zwei Fragen, die um die neun Stationen herum sitzen statt in ihnen: was es kostet, die Daten im Warehouse zu lassen, und was ein KI-Agent tatsächlich sieht.
Wie zuvor ist Adobe Experience Platform das durchgerechnete Beispiel, weil Adobe seine Grenzen öffentlich dokumentiert. Jede Zahl verlinkt auf ihre Quelle; alle Seiten wurden am 11. September 2026 abgerufen. Nichts davon ist eine rechtliche Einschätzung – das ist ein Gespräch für den Datenschutzbeauftragten, nicht für einen Architekturartikel.
Teil 3 · die letzten zwei Stationen und zwei Fragen darum herum1 / 4
Labels klassifizieren Daten, Policies beschreiben, was damit geschehen darf, Enforcement wendet sie an. Die Durchsetzung ist echt, wenn sie aktiv ist – ein Verstoß blockiert die Aktivierung und zeigt einen Lineage-Graph. Aber jede Policy, auch Adobes eigene Core Policies, ist standardmäßig deaktiviert und muss von Hand aktiviert werden. Eine nicht durchgesetzte Policy erzeugt keine Fehler und keine Warnungen: eingeschränkte Daten aktivieren genauso reibungslos wie nicht eingeschränkte.
Veröffentlicht ist, was das Abfragen betrifft: Ad-hoc-Queries bei 10 Minuten gedeckelt, die 100 Zeilen in der Oberfläche und bis zu 50.000 über einen Client zurückgeben; Batch-Queries bis zu 24 Stunden; vier gleichzeitige Slots auf dem beschleunigten Speicher. Was die Guardrails nicht beschreiben, ist die Schleife selbst – wie Engagement-Ergebnisse zu neuen Signalen werden, wie schnell, mit welcher Identität. Das muss entworfen werden, nicht konfiguriert.
Federated Audience Composition baut Zielgruppen aus Daten in einem externen Warehouse, ohne sie zu kopieren – die eigene FAQ sagt, dass nur Metadaten gespeichert werden und keine Kundendaten unterwegs sind. Der Handel steht in derselben FAQ statt in irgendeiner Vergleichstabelle: Federated Composition nutzt Identity Service nicht. Joins laufen über einen Schlüssel, den Sie definieren, diese Daten bekommen also kein Cross-Device-Stitching und keine Namespace-Priorität.
Der Adobe Experience Platform Agent Orchestrator schöpft aus strukturierten und unstrukturierten Quellen, beschrieben als Produktdokumentation, Kundenmetadaten über Geschäftsobjekte und Analysedaten. Lesen Sie diese Liste darauf, was nicht drinsteht: der Kundendatensatz. Ein Agent, der Ihnen beim Bauen einer Zielgruppe hilft, arbeitet auf der Beschreibung Ihrer Daten, nicht auf den Menschen darin.
Jedes Architekturdiagramm hat einen Governance-Kasten. Er ist meist als Band an der Seite oder unten gezeichnet, anders eingefärbt, beschriftet mit „Data Governance & Privacy“. Es ist der Kasten, auf den im Lenkungsausschuss alle zeigen und den niemand öffnet.
Öffnen wir ihn. Adobes Rahmenwerk hat drei Teile:
Labels klassifizieren Daten. Sie kommen in drei Kategorien: Contract mit den Codes C1 bis C12, Identity mit I1 und I2, und Sensitive mit S1 und S2 neben Labels für zulässige sensible personenbezogene Daten und regulierte Gesundheitsdaten.
Policies beschreiben, was mit gelabelten Daten geschehen darf.
Enforcement wendet diese Policies am Punkt der Aktivierung an.
08
Steuern
Entscheiden, was mit welchen Daten geschehen darf, und es durchsetzen.
Eingeschränkte Daten für Onsite-WerbungAdobe Core PolicyDeaktiviertAktiviert
Die Aktivierung läuft durch. Jedes Profil der Zielgruppe erreicht die Destination, auch die, deren Datensätze ein Restricted-Label tragen. Kein Fehler, keine Warnung, keine Warteschlange.
Die Aktivierung wird blockiert. Der Verstoß benennt die beteiligten Datensätze, Merge Policies, Zielgruppen und Destinations in einem Lineage-Graph.
In diesem Zustand ist eine neue Sandbox. Adobe: „All data usage policies (including core policies provided by Adobe) are disabled by default.“
Die Durchsetzung ist echt, sobald sie an ist. Sie ist auch ein Schalter, den jemand finden und umlegen muss – und nirgendwo meldet irgendetwas, dass er aus ist.
Das ist ein vertretbarer Entwurf – eine Durchsetzung, die Aktivierungen ab dem Moment blockiert, in dem man die Plattform einschaltet, würde jede Implementierung mit einem Ausfall beginnen lassen. Aber sie erzeugt einen spezifischen und gefährlichen Ausfallmodus: nichts scheitert. Eine nicht durchgesetzte Policy erzeugt keine Fehler, keine Warnungen, keine Warteschlange. Als eingeschränkt gelabelte Daten aktivieren genauso reibungslos wie nicht eingeschränkte. Das einzige Signal, dass Governance aus ist, ist das Fehlen eines Signals – und das ist das Schwerste, was eine Organisation bemerken kann.
Das einzige Signal, dass Governance aus ist, ist das Fehlen eines Signals.
Architektur-Check · Station 8 · Steuern
Eine brandneue Sandbox. Labels sind vergeben, Marketing Actions definiert, den Policy-Screen hat niemand angefasst. Was wird durchgesetzt?
Ihre Antwort
Was Adobe dokumentiert
Alle Data Usage Policies, auch die von Adobe bereitgestellten Core Policies, sind standardmäßig deaktiviert, und eine einzelne Policy muss von Hand aktiviert werden, um für die Durchsetzung berücksichtigt zu werden. Marketing Actions allein schränken nichts ein – sie „must be included in enabled data usage policies“, um zu wirken.
Warum das zählt
Ein Labeling-Projekt kann abgeschlossen, abgenommen und als erledigt gemeldet werden, ohne irgendetwas durchzusetzen. Das Artefakt sieht in beiden Fällen identisch aus: Labels vergeben, Actions definiert, Aktivierungen laufen. Nur der Policy-Screen sagt Ihnen, welcher der beiden Fälle vorliegt.
Was eine Data Governance Policy tatsächlich abdeckt
Drei weitere Tatsachen entscheiden, ob der Kasten, einmal geöffnet, das tut, was alle annehmen.
Marketing Actions allein schränken nichts ein. Sie „must be included in enabled data usage policies“, um zu wirken. Daten zu labeln und Marketing Actions zu definieren, ohne eine Policy zu aktivieren, erzeugt Dokumentation, keine Durchsetzung.
Consent Policies sind eine lizenzierte Fähigkeit, und sie haben eine dokumentierte Lücke. Sie sind nur mit Healthcare Shield oder Privacy & Security Shield verfügbar. Ihre Logik ist die Umkehrung der Governance Policies: Adobe beschreibt Consent Policies als „inclusive in nature“ – sie bestimmen, welche Profile einbezogen werden dürfen – während Governance Policies gelabelte Attribute von der Aktivierung ausschließen.
Drei Destinations in Adobes eigenem Katalog, alle drei in Unternehmensarchitekturen üblich, in denen die Consent-Prüfung nicht läuft. Adobe dokumentiert das offen. Das spricht für Adobe, und es macht die Seite nicht weniger lesenswert, bevor Sie eine davon anschließen.
Ihre Architektur streamt Profile an eine HTTP-API-Destination. Wessen Einwilligung wurde geprüft?
Ihre Antwort
Was Adobe dokumentiert
Die Consent-Policy-Auswertung wird in Exporten an Amazon Kinesis, Azure Event Hubs und die HTTP-API-Destination nicht unterstützt, und Adobe stellt fest, dass Profile, die dem Targeting nicht zugestimmt haben, in Exporten an diese drei enthalten sind. Consent Policies setzen außerdem eine Healthcare-Shield- oder Privacy-&-Security-Shield-Lizenz voraus, um überhaupt zu existieren.
Warum das zählt
Diese drei sind Unternehmens-Infrastruktur – die Destinations, zu denen ein Datenteam greift, wenn ein Kanal keinen nativen Connector hat. Der Durchsetzungspunkt, auf den Sie sich verlassen, hat eine dokumentierte Grenze, und zu wissen, wo er läuft, ist die Voraussetzung dafür, darum herum zu entwerfen. Was daraus folgt, ist eine Frage für den Datenschutzbeauftragten, nicht für einen Architekturartikel.
Einen Fall haben wir angeschaut (auf Englisch), in dem ein Label eine Paid-Social-Aktivierung aktiv blockiert – die Variante davon, die wie vorgesehen funktioniert.
CD
Was ich zuerst prüfe
Ich lasse mir einen Screenshot der Policy-Liste aus der Produktiv-Sandbox geben, gefiltert auf aktiviert, mit sichtbarem Datum. Nicht das Designdokument, nicht den Labeling-Plan – den Bildschirm. Dann liste ich jede Destination danach, ob für sie die Consent-Auswertung läuft. Beides dauert zwanzig Minuten, und es sind die zwei Fragen, die mir in einem ersten Workshop noch nie aus dem Gedächtnis beantwortet wurden.
Christopher Dettinger · MarTech- und Omnichannel-Architekt
Architektur-Checkpoint · Station 8 · was stimmen muss
Jemand kann heute benennen, welche Data Usage Policies in Ihrer Produktiv-Sandbox aktiviert sind.
Jemand weiß, welche Destinations Profile erhalten, deren Einwilligung nie ausgewertet wurde.
Das Team weiß, dass Governance Policies und Zugriffssteuerung zwei verschiedene Mechanismen mit zwei verschiedenen Lizenzen sind.
Station 9 – Messen
Der Rückweg ist die dünnste Station dieser Serie, weil er die dünnste in der Dokumentation ist. Das ist selbst schon der Befund.
09
Messen
Aus dem, was passiert ist, wieder ein Signal machen, das der Stack nutzen kann.
Sie geben 100 Zeilen in der Oberfläche und bis zu 50.000 über einen Client zurück.
Batch-Queries laufen bis zu 24 Stunden.
Der beschleunigte Speicher erlaubt vier gleichzeitige Query-Slots.
Data Distiller ist ein separates Paket mit einem Teil der Plattformfunktionalität.
Was die Guardrails nicht beschreiben, ist die Schleife selbst: wie Engagement-Ergebnisse zu neuen Signalen werden, wie schnell, mit welcher Identität. Das muss entworfen statt konfiguriert werden – und es ist der Teil der Architektur, der am häufigsten auf „Phase zwei“ verschoben wird, weshalb so viele Programme beschreiben können, was sie gesendet haben, aber nicht, was es verändert hat.
Sie können beschreiben, was sie gesendet haben. Nicht, was es verändert hat.
CD
Was ich vor der Freigabe verlange
Ich stelle im Design eine Frage und schreibe die Antwort ins Architekturdokument: welches Event, geschrieben von welchem System, mit welcher Identität, sagt diesem Stack, dass das, was wir gesendet haben, gewirkt hat. Gibt es keine Antwort, ist die Messschicht nicht spät dran – sie existiert nicht, und das Verschieben des Entwurfs ist genau das, was dafür sorgt, dass sie nie kommt. Sie später zu bauen ist in Ordnung. Sie später zu entwerfen nicht.
Christopher Dettinger · MarTech- und Omnichannel-Architekt
Architektur-Checkpoint · Station 9 · was stimmen muss
Der Messentwurf existiert vor dem Go-Live, auch wenn er danach gebaut wird.
Sie können das Event, das schreibende System und die Identität benennen, die die Schleife schließen.
Niemand hat „wir berichten über Sendungen“ mit „wir messen Ergebnisse“ verwechselt.
Wenn die Wahrheit im Warehouse liegt
In den meisten Unternehmen liegen die maßgeblichen Kundendaten nicht in einer Marketingplattform. Sie liegen in Snowflake, BigQuery, Databricks oder Redshift, verwaltet von einem Datenteam, das eine Meinung zu Kopien hat.
Für jeden, der ein Jahr damit verbracht hat, mit einem Security-Team eine Ausnahme für eine Datenkopie zu verhandeln, ist das eine erhebliche Fähigkeit. Aber es gibt einen Handel, und er steht in derselben FAQ statt in irgendeiner Vergleichstabelle.
Architektur-Check · Warehouse
Sie komponieren eine Zielgruppe föderiert gegen Snowflake. Welche Identity Resolution wird auf diese Daten angewandt?
Ihre Antwort
Was Adobe dokumentiert
Federated Audience Composition nutzt Identity Service nicht. Joins über Quellen hinweg laufen über einen Schlüssel, den Sie definieren, nicht über den aufgelösten Identity Graph – föderierte Daten bekommen also kein Cross-Device-Stitching und keine Namespace-Priorität. Sie bekommen genau die Trefferqualität des Schlüssels, den jemand gewählt hat.
Warum das zählt
Das ist der wahre Preis von „wir kopieren nichts“, und er wird fast nie besprochen. Die Frage ist nicht kopieren oder föderieren. Sie lautet: welche Daten brauchen aufgelöste Identität und welche nur einen verlässlichen Schlüssel – zwei Antworten, die auf zwei verschiedene Architekturen zeigen, und die meisten Unternehmen brauchen beide.
Ich teile das Quellenverzeichnis in zwei Spalten, bevor irgendjemand über Kopieren streitet: Daten, die eine aufgelöste Identität brauchen, und Daten, die nur einen verlässlichen Schlüssel brauchen. Dann prüfe ich, ob der Schlüssel aus der zweiten Spalte tatsächlich in beiden Systemen existiert, im selben Format und in derselben Groß-/Kleinschreibung. An dieser zweiten Prüfung verlieren föderierte Entwürfe still ihre Trefferquote, und sie ist jetzt billiger als nachdem die erste Zielgruppe halb so groß zurückkommt wie erwartet.
Christopher Dettinger · MarTech- und Omnichannel-Architekt
Architektur-Checkpoint · Warehouse · was stimmen muss
Sie wissen, welche Daten wirklich eine aufgelöste Identität brauchen und welche nur einen verlässlichen Schlüssel.
Der Join-Schlüssel existiert in beiden Systemen im selben Format und in derselben Groß-/Kleinschreibung.
Jemand hat den Standardverfall von 30 Tagen bei importierten föderierten Zielgruppen eingeplant.
Was KI-Agenten verändern
Jeder Hersteller liefert inzwischen Agenten aus, und die interessante Frage ist nicht, was sie tun können, sondern was sie sehen können.
Adobes agentische Schicht ist der Adobe Experience Platform Agent Orchestrator – ausgeschrieben; „AEP Agent Orchestrator“ ist nicht der Produktname. Er wird beschrieben als „the new agentic layer in Adobe Experience Platform“, der, in Adobes Worten, „with human oversight“ arbeitet. Zu den benannten Agenten gehören Audience Agent, Data Insights Agent, Experimentation Agent, Journey Agent, Product Support Agent und der Adobe Marketing Agent für Microsoft 365 Copilot.
Lesen Sie diese Liste noch einmal darauf, was nicht drinsteht. Die Wissensbasis besteht aus Dokumentation, Metadaten über Geschäftsobjekte und Analysedaten – nicht aus dem Kundendatensatz selbst. Ein Agent, der Ihnen beim Bauen einer Zielgruppe hilft, arbeitet auf der Beschreibung Ihrer Daten, nicht auf den Menschen darin.
Er arbeitet auf der Beschreibung Ihrer Daten. Nicht auf den Menschen darin.
In einer regulierten Umgebung ist das keine Einschränkung, um die man herum konstruiert. Es ist die Bedingung, unter der ein Agent überhaupt laufen darf – und es erklärt, warum ein Agent Ihnen sagen kann, wie Ihre Zielgruppen aufgebaut sind, aber nicht, wer darin ist.
Eine Namenskorrektur, weil sie falsch kursiert: Adobe Brand Concierge ist kein Experience-Platform-Agent. Es ist ein eigenes Produkt, das Experience-Platform-Daten konsumiert; der darin arbeitende Agent ist der Product Advisor Agent. Ihn zum Kreis des Agent Orchestrator zu zählen ist ein Kategorienfehler, der in vielen Zusammenfassungen aus zweiter Hand auftaucht.
CD
Was ich vor der Freigabe verlange
Für jeden Agenten, den ein Hersteller vorschlägt, lasse ich mir die dokumentierte Beschreibung seiner Wissensbasis geben und lese sie darauf, was fehlt, statt darauf, was gelistet ist. Dann frage ich, von welchen der neun Stationen der Agent abhängt, denn ein Agent, der über Metadaten schließt, erbt jede Lücke in diesen Metadaten. Ich prüfe das pro Hersteller und pro Agent – nichts davon verallgemeinert sich über Produkte hinweg, und die kursierenden Zusammenfassungen aus zweiter Hand sind oft genug falsch, um sie zu ignorieren.
Christopher Dettinger · MarTech- und Omnichannel-Architekt
Architektur-Checkpoint · KI-Agenten · was stimmen muss
Sie haben die dokumentierte Beschreibung dessen gelesen, was die Wissensbasis jedes Agenten enthält – und was nicht.
Sie wissen, von welchen der neun Stationen jeder Agent abhängt.
Niemand zählt den Agenten eines separaten Produkts zum Kreis der Plattform.
Der Bauplan: zwölf Fragen
Wenn Sie eine Sache aus dieser Serie in ein Meeting mitnehmen, dann diese. Eine pro Station, plus drei quer darüber.
Welcher Namespace ist Ihre Personenidentität – und ist er als eindeutig deklariert?
Wie viele Identitäten trägt Ihr durchschnittlicher Identity Graph heute?
Hat jemand die Normalisierung der E-Mail-Groß-/Kleinschreibung über jede schreibende Quelle geprüft?
Welche Ihrer Zielgruppenregeln greifen weiter zurück als 24 Stunden?
Wie viele Edge- und Streaming-Zielgruppen sind aktiv, gegen Adobes empfohlene 150 und 500?
Sind für jede zugesagte Echtzeitentscheidung die benötigten Daten an die Edge projizierbar?
Wie hoch ist die Aktivierungslatenz jedes Kanals in Ihrem aktuellen Kampagnenplan?
Welche Data Usage Policies sind in Ihrer Produktiv-Sandbox aktiviert – heute, nicht im Designdokument?
Welche Destinations erhalten Profile, deren Einwilligung nie ausgewertet wurde?
Wie hoch ist Ihr Event-Volumen pro Profil, gegen Adobes 5.000-Event-Guardrail für die Segmentierung?
Welche Daten brauchen wirklich aufgelöste Identität, und welche nur einen verlässlichen Schlüssel?
Wer hat die primäre Identität Ihrer profilaktivierten Schemas freigegeben, und wann?
Wenn acht der zwölf einen Verantwortlichen und eine Antwort haben, haben Sie eine Omnichannel-Architektur. Wenn vier es haben, haben Sie eine Omnichannel-Roadmap. Beides sind legitime Positionen. Das eine für das andere zu halten ist das, was den Stillstand nach achtzehn Monaten erzeugt.
Häufige Fragen
Was ist eine Data Governance Policy?
Eine Data Governance Policy ist eine Regel, die sagt, was mit Daten geschehen darf, die bestimmte Labels tragen – und sie wird am Punkt der Aktivierung durchgesetzt, nicht am Punkt des Zugriffs. In Adobe Experience Platform klassifizieren Labels die Daten, Policies beschreiben die erlaubte Nutzung, und die Durchsetzung blockiert eine verstoßende Aktivierung und zeigt die Lineage dahinter. Was Teams übersehen: jede Data Governance Policy, auch die von Adobe bereitgestellten Core Policies, ist standardmäßig deaktiviert und muss von Hand aktiviert werden.
Wo wird Einwilligung in einem MarTech-Stack durchgesetzt?
An mehreren Punkten, und nicht einheitlich. Einwilligung kann bei der Erfassung aufgenommen, im Profil gespeichert und bei der Aktivierung ausgewertet werden. Bei Adobe setzen Consent Policies eine Healthcare-Shield- oder Privacy-&-Security-Shield-Lizenz voraus, und Adobe dokumentiert, dass die Consent-Auswertung für Exporte an Amazon Kinesis, Azure Event Hubs oder die HTTP-API-Destination nicht läuft. Im Web SDK wird nur die Datenerfassungs-Berechtigung automatisch durchgesetzt. Alles andere muss von etwas durchgesetzt werden, das Sie selbst bauen.
Sehen KI-Agenten in einer Marketingplattform Kundendaten?
In Adobes dokumentierter Architektur wird die Wissensbasis des Agent Orchestrator als Produktdokumentation, Metadaten über Geschäftsobjekte und Analysedaten beschrieben – nicht als die Kundendatensätze selbst. Ein Agent kann beschreiben, wie Ihre Zielgruppen aufgebaut sind, ohne zu sehen, wer darin ist. Prüfen Sie das pro Hersteller und pro Agent, statt anzunehmen, dass es sich verallgemeinern lässt.
Wie arbeiten eine CDP und ein Data Warehouse zusammen?
Zwei Muster. Kopieren – die Daten in die CDP bewegen, wo sie vollständige Identity Resolution und Profilbehandlung bekommen. Oder föderieren – sie im Warehouse lassen und Zielgruppen dagegen komponieren, ohne zu kopieren, wie Adobes Federated Audience Composition es tut. Der Handel ist explizit: föderierte Daten werden über einen Schlüssel verbunden, den Sie definieren, statt über Identity Resolution, sie bekommen also kein Cross-Device-Stitching. Die meisten Unternehmen fahren am Ende beide Muster für verschiedene Daten.
Was ist der Unterschied zwischen einer Customer Data Platform und einem Data Warehouse?
Ein Warehouse speichert alles für die Analyse, optimiert auf große Scans über lange Historien. Eine CDP speichert ein Arbeitsprofil, optimiert auf Abruf in Millisekunden während einer laufenden Interaktion, mit eingebauter Identity Resolution und Aktivierung. Bei Adobe sind es buchstäblich verschiedene Technologien – Cosmos DB für den Profilspeicher, Azure Data Lake Storage für den Lake. Die meisten Unternehmen brauchen beides, verbunden, statt dass eines das andere ersetzt.
Steht das bei euch an?
Wenn die Durchsetzung in eurer Sandbox aus ist, lautet die nächste Frage, welche Policies ihr tatsächlich braucht – und das ist eine fachliche Entscheidung, bevor es eine technische ist. Das mit Marketing, Legal und IT an einem Tisch zu klären, ist genau meine Arbeit, für Teams in Pharma, Medical und Finance.
14 TageDas Profil, aus dem die Edge personalisiert, hält Attribute in einem rollierenden Fenster, nicht Ihre Historie. Es ist eine Projektion, nicht das Profil.
24 StundenStreaming-Segmentierung schaut einen Tag zurück. Eine Regel, die weiter greift, wird ohne jede Warnung zu einer Über-Nacht-Zielgruppe.
100Destinations pro Sandbox, systemseitig erzwungen. Die Aktivierungsschicht hat eine Decke, und sie liegt niedriger, als die meisten Integrations-Roadmaps annehmen.
30 Sekunden bis hierhin · 5 Minuten für die vier Stationen.
Teil 1 endete mit drei Stationen, die entscheiden, ob Sie überhaupt einen Kunden haben: ob die Daten ankommen, ob sie so modelliert sind, dass man sie nutzen kann, und ob die Fragmente sich zu einer Person auflösen. Nehmen wir an, alle drei funktionieren. Sie haben jetzt einen aufgelösten Identity Graph und keine Möglichkeit, darauf zu handeln.
Die nächsten vier Stationen sind die, an denen Handeln möglich wird – und an denen der Abstand zwischen dem, was eine Plattform kann, und dem, wofür Ihre Architektur tatsächlich konfiguriert ist, am größten wird. Die wiederkehrende Überraschung in dieser Hälfte der Kette ist, dass dieselbe Plattform dieselbe Frage in 350 Millisekunden, in fünf Minuten oder morgen früh beantwortet, und niemand wählt aus, welches davon. Die Form der Regel tut es. Das ist es, was Zielgruppen-Segmentierung in Echtzeit tatsächlich ist: keine Fähigkeit, die man einschaltet, sondern eine Stufe, für die sich Ihre Regel qualifiziert.
Wie in Teil 1 ist Adobe Experience Platform das durchgerechnete Beispiel, weil Adobe seine Grenzen öffentlich dokumentiert, jede Zahl auf die Seite verlinkt, aus der sie stammt, und alle Seiten am 11. September 2026 abgerufen wurden.
Teil 2 · die mittleren vier Stationen1 / 4
Aufgelöste Fragmente werden zu einer Union View, und eine Merge Policy entscheidet, welcher Wert gewinnt, wenn zwei Fragmente sich widersprechen. Die strukturelle Tatsache hinter jeder folgenden Grenze: Profilspeicher und Data Lake sind unterschiedliche Technologien für unterschiedliche Fragen. Das Profil ist auf Millisekunden-Lookups ausgelegt und bei 5.000 Experience Events pro Profil für die Segmentierung gedeckelt.
Dieselbe Regel kann auf drei Arten ausgewertet werden – an der Edge in bis zu 350 Millisekunden, als Streaming in bis zu fünf Minuten, als Batch alle 24 Stunden – und die Plattform wählt danach, wie die Regel geschrieben ist. Streaming-Segmentierung hat ein Rückblickfenster von einem Tag. Schreiben Sie eine Regel über die letzten 25 Stunden, wird sie ohne Warnung zu einer Über-Nacht-Zielgruppe.
Eine Entscheidung kann im Hub fallen, der die historischen Daten und den reichen Profilkontext hält, oder im Edge Network, das direkt neben dem Kunden sitzt. An der Edge liegen nur die Zielgruppen-Mitgliedschaften, Identitäten und Attribute, die für die Personalisierung nötig sind – in einem rollierenden 14-Tage-Fenster. Eine Entscheidung, die die vollständige Kaufhistorie braucht, kann an der Edge nicht laufen, weil die Historie dort nicht liegt.
Destinations sind bei 100 pro Sandbox gedeckelt, systemseitig erzwungen. Batch-Destinations exportieren einmal täglich oder alle 3, 6, 8 oder 12 Stunden, und Dateien werden bei 5 Millionen Zeilen automatisch geteilt. Adobe empfiehlt, die Startzeit der Aktivierung mindestens eine Stunde nach Fertigstellung des Flows zu setzen. Auf dem Batch-Weg misst sich der Abstand zwischen „die Zielgruppe ist fertig“ und „der Kanal hat sie“ in Stunden.
Sobald Identitäten aufgelöst sind, müssen die Fragmente zu einem Profil werden. Adobe nennt das Ergebnis eine Union View, ermöglicht durch ein Union Schema – „a merged view of all profile fragments for that entity across datasets“. Wo zwei Fragmente sich widersprechen, entscheidet eine Merge Policy, welches gewinnt – entweder nach Datensatz-Vorrang oder nach Zeitstempel. Sie bekommen fünf Merge Policies und genau eine Standard-Policy pro Klasse.
04
Vereinheitlichen
Fragmente aus mehreren Datensätzen werden zu einem lesbaren Profil.
Fünftausend Events. Adobes Performance-Guardrail liegt bei 5.000 Experience Events pro Profil für die Segmentierung; darüber hinaus werden nur die jüngsten 5.000 genutzt. Für eine monatliche Newsletter-Zielgruppe ist das ein Leben lang. Für eine App mit täglichen Sessions sind es ein paar Monate.
Größengrenzen, die Daten fallen lassen. Ein Profildatensatz über 100 KB und ein Event über 10 KB werden nicht gekürzt und nicht markiert – Adobes Formulierung ist, dass sie „will be dropped“. Die Ingestion läuft weiter. Der Datensatz kommt nicht an.
Architektur-Check · Station 4 · Vereinheitlichen
Ein Experience Event kommt mit 14 KB an. Was macht der Profilspeicher damit?
Ihre Antwort
Was Adobe dokumentiert
Events sind bei 10 KB gedeckelt, Profildatensätze bei 100 KB. Darüber sagt Adobes Guardrails-Seite, Datensätze „will be dropped“ – nicht gekürzt, nicht laut abgelehnt. Der Ingestion-Job läuft weiter und meldet Erfolg.
Warum das zählt
Reiche Event-Payloads wachsen über die Laufzeit eines Projekts: ein verschachteltes Objekt mehr pro Release, ein Produktarray mehr. An dem Tag, an dem ein Event-Typ 10 KB überschreitet, trägt er nichts mehr zum Profil bei, und das einzige sichtbare Symptom ist eine Zielgruppe, die ohne genannten Grund kleiner wird.
Das Profil ist kein Archiv. Es ist Arbeitsspeicher.
Diese Schlussfolgerung gehört klar ausgesprochen, weil sie dem widerspricht, wie das Profil üblicherweise verkauft wird. Die lange Historie liegt im Data Lake – anderer Speicher, andere Aufbewahrung (die Untergrenze im Lake liegt bei 30 Tagen, die Obergrenze bei zehn Jahren), andere Fragen. Dem Profil eine Fünf-Jahres-Frage zu stellen ist ein Kategorienfehler, kein Konfigurationsproblem.
CD
Was ich zuerst prüfe
Ich lasse mir die Event-Anzahl pro Profil im 95. Perzentil geben, nicht den Mittelwert, und zwar pro Event-Typ. Dann halte ich diese Zahl gegen den 5.000-Event-Guardrail und gegen die Reichweite, die die Zielgruppenregeln tatsächlich zurückgreifen. Die Diskrepanz zwischen beidem ist der Befund, und sie steckt meistens im Clickstream-Datensatz statt in dem, den alle beobachten.
Christopher Dettinger · MarTech- und Omnichannel-Architekt
Architektur-Checkpoint · Station 4 · was stimmen muss
Sie haben entschieden, was das Profil sich merken muss, um handeln zu können.
Alles darüber hinaus hat eine akzeptierte Heimat an einem langsameren Ort.
Ihr Event-Volumen pro Profil ist eine Zahl, die jemand tatsächlich ausgerechnet hat.
Station 5 – Segmentieren
Zielgruppen-Segmentierung ist die Stelle, an der „Echtzeit“ aufhört ein Marketingwort zu sein und zu einer Eigenschaft wird, die man prüfen kann.
Qualifiziere das Profil, wenn es die Preisseite gesehen hat in den letzten 23 Stundenin den letzten 25 Stunden
StreamingBatchBis zu fünf Minuten, um ein Profil zu qualifizieren.Alle 24 Stunden. Dieselbe Regel, eine Auswertungsstufe tiefer.
Innerhalb des Rückblickfensters. Streaming-Segmentierung berücksichtigt Events des letzten Tages.
Zwei Stunden weiter zurück, und die Regel ist still zu einer Über-Nacht-Zielgruppe geworden. Nichts wird rot, nichts wird abgelehnt, und die Zielgruppe funktioniert weiter – sie antwortet nur erst morgen früh.
Dieselbe Grenze taucht in der Liste der Ausschlüsse auf. Multi-Entity-Abfragen, Kombinationen eines einzelnen Events mit einer inSegment-Bedingung, Zeitbedingungen mit „ignore year“ und einzelne Events ganz ohne Zeitfenster sind nicht für Streaming geeignet. Die Edge-Auswertung ist noch enger.
Architektur-Check · Station 5 · Segmentieren
Sie ändern eine Zielgruppenregel von „in den letzten 23 Stunden“ auf „in den letzten 25 Stunden“. Was passiert?
Ihre Antwort
Was Adobe dokumentiert
Das Rückblickfenster der Streaming-Segmentierung ist bei der Zielgruppen-Segmentierung auf einen Tag begrenzt, und ältere Events „will be processed in the subsequent batch job“. Die Auswertungsmethode wird aus der Form der Regel gewählt, nicht aus einer Einstellung – die Änderung greift also, ohne dass sie jemand auswählt.
Warum das zählt
Die Kampagne auf dieser Zielgruppe ging von Unmittelbarkeit aus und läuft jetzt einen Tag zu spät. Niemand erfährt warum, denn aus Sicht der Plattform ist nichts schiefgegangen – es wurde eine Regel geschrieben und die richtige Auswertungsmethode darauf angewandt.
Echtzeit ist keine Eigenschaft Ihrer Plattform. Es ist eine Eigenschaft der Regel.
Drei weitere Zahlen, die Kampagnenpläne routinemäßig wegannehmen.
Eine neue Segment Definition braucht bis zu einer Stunde, bis sie verfügbar ist – für Streaming und Edge gleichermaßen. Sie können keine Zielgruppe schreiben und sie in denselben zehn Minuten aktivieren.
Ich nehme jede Zielgruppe, die das Business zeitkritisch nennt, und prüfe sie Zeile für Zeile gegen die Streaming-Eignungsliste – Rückblickfenster, Multi-Entity-Abfrage, verschachtelte Segmentbedingung, fehlendes Zeitfenster. Dann zähle ich, wie viele Edge- und Streaming-Zielgruppen live sind, gegen die empfohlenen 150 und 500. Beide Prüfungen dauern einen Nachmittag, und ich habe sie noch nie durchgeführt, ohne mindestens eine Zielgruppe zu finden, die einen Tag später antwortet, als das Briefing annimmt.
Christopher Dettinger · MarTech- und Omnichannel-Architekt
Architektur-Checkpoint · Station 5 · was stimmen muss
Jede Zielgruppe, die Sie für zeitkritisch halten, wurde gegen die Streaming-Eignungsliste geprüft.
Jemand verantwortet die Zahl der Edge- und Streaming-Zielgruppen in Ihrer Zielgruppen-Segmentierung gegen Adobes empfohlene 150 und 500.
Der Kampagnenkalender berücksichtigt die Stunde, die eine neue Segment Definition braucht, bevor sie verfügbar ist.
Station 6 – Entscheiden
Orchestrierung wird üblicherweise als Kapazitätsfrage diskutiert: wie viele Journeys, wie viele Nachrichten, wie schnell. Das ist die weniger interessante Frage. Die Grenze, die eine Decisioning-Architektur tatsächlich formt, ist nicht, wie viel sie kann. Es ist, was sie in dem Moment sehen kann, in dem sie entscheidet.
Adobes Architektur hat zwei Orte, an denen eine Entscheidung fallen kann. Der Hub ist das zentrale Rechenzentrum, das „contains all the historical data and rich profile context“. Das Edge Network ist die verteilte Schicht – sieben Regionen – die direkt neben dem Kunden sitzt.
06
Entscheiden
Die nächste Aktion wählen – mit dem, was an diesem Ort sichtbar ist.
Eine Next Best Action braucht drei Jahre Kaufhistorie und muss in 350 Millisekunden antworten. Wo liegt das Problem?
Ihre Antwort
Was Adobe dokumentiert
Die einzigen Daten im Edge Network sind Zielgruppen-Mitgliedschaften, Profilidentitäten und für die Personalisierung nötige Attribute, gehalten in einem rollierenden 14-Tage-Fenster. Die historischen Daten und der reiche Profilkontext liegen im Hub. Eine Entscheidung, die die Historie braucht, muss dort fallen, wo die Historie ist.
Warum das zählt
Eine 350-Millisekunden-Entscheidung und eine Entscheidung mit voller Historie sind nicht dieselbe Entscheidung in zwei Geschwindigkeiten. Es sind verschiedene Entscheidungen, an verschiedenen Orten, mit verschiedenen Informationen – und beides gleichzeitig zu verlangen ist ein Widerspruch, den man besser im Design-Workshop findet als im Performance-Review.
Zwei verschiedene Entscheidungen. Nicht eine in zwei Geschwindigkeiten.
Eine Next Best Action, die die vollständige Kaufhistorie braucht, kann nicht an der Edge laufen, weil die Kaufhistorie dort nicht liegt. Eine, die nur „ist diese Person in der High-Value-Zielgruppe“ braucht, kann es, weil genau diese Mitgliedschaft nach außen projiziert wird. Ein operatives Detail, das im Test überrascht: die Edge hat einen Kaltstart. Adobe merkt an, dass „the first few evaluation calls may result in a timeout“. Ein erster fehlschlagender Test ist nicht zwingend eine kaputte Konfiguration.
Für jede Echtzeitentscheidung, die jemand zugesagt hat, schreibe ich die Attribute auf, die sie liest, und prüfe jedes einzelne gegen das, was tatsächlich an die Edge projiziert wird – nicht gegen das, was im Profil existiert. Die beiden Listen sind verschieden, und der Unterschied ist die Stelle, an der die Demo funktioniert und die Produktion nicht. Hat ein Attribut auf dieser Liste keinen Projektionspfad, wird die Zusage umgeschrieben, bevor die Journey gebaut wird.
Christopher Dettinger · MarTech- und Omnichannel-Architekt
Architektur-Checkpoint · Station 6 · was stimmen muss
Für jede zugesagte Echtzeitentscheidung hat jemand bestätigt, dass die nötigen Daten an die Edge projizierbar sind.
„Im Profil vorhanden“ ist nicht derselbe Test wie „an die Edge projizierbar“, und der Unterschied ist aufgeschrieben.
Das Team weiß, dass ein erster Edge-Auswertungsaufruf konstruktionsbedingt in einen Timeout laufen kann.
Station 7 – Aktivieren
Aktivierung ist der Schritt, an dem ein aufgelöstes, vereinheitlichtes, segmentiertes Profil endlich einen Kanal erreicht. Es ist auch die Stelle, an der die Zeitannahmen aus Kampagnenplänen auf die dokumentierte Wirklichkeit treffen.
Die Zielgruppe zu dem Kanal bringen, der sie nutzen wird.
Destinations
100Destinations pro Sandbox · hart
Das Timing teilt sich nach Destination-Typ, und die Spanne ist groß.
Batch-, dateibasierte Destinations fahren einen vollständigen Export täglich oder inkrementelle Exporte alle 3, 6, 8 oder 12 Stunden. Dateien werden bei 5 Millionen Zeilen automatisch geteilt – gut zu wissen, bevor jemand einen Importjob schreibt, der eine einzelne Datei erwartet.
Streaming-Destinations haben keine dokumentierte Grenze für Nachrichten pro Sekunde an Partner-API-Endpunkte.
Enterprise-Destinations zielen auf unter 10 Minuten in 95 Prozent der Fälle, bei unter 10.000 Anfragen pro Sekunde und Instanz.
Das Briefing sagt: Zielgruppe heute Vormittag bauen, heute Nachmittag im dateibasierten Kanal live haben. Ist das realistisch?
Ihre Antwort
Was Adobe dokumentiert
Eine neue Segment Definition braucht bis zu einer Stunde, bis sie verfügbar ist. Adobe empfiehlt eine weitere Stunde zwischen Fertigstellung des Aktivierungsflows und der Startzeit. Batch-, dateibasierte Destinations exportieren einmal täglich oder in einem 3-, 6-, 8- oder 12-Stunden-Zyklus. Streaming- und Enterprise-Destinations sind eine andere Größenordnung – unter 10 Minuten in 95 Prozent der Fälle.
Warum das zählt
Welchen Weg ein Kanal nutzt, wird zur Integrationszeit entschieden, nicht zur Kampagnenzeit. In dem Moment, in dem jemand das Briefing schreibt, steht die Latenz dieses Kanals bereits fest – der Kalender muss also auf den Zahlen aufgebaut werden, nicht auf der Annahme von Unmittelbarkeit.
Fertig und ausgeliefert liegen Stunden auseinander.
Rechnen Sie es zusammen. Eine neue Segment Definition braucht bis zu einer Stunde, bis sie verfügbar ist. Adobe empfiehlt eine weitere Stunde, bevor eine Aktivierung startet. Eine Batch-Destination exportiert bestenfalls im Drei-Stunden-Zyklus. Der Abstand zwischen „die Zielgruppe ist fertig“ und „der Kanal hat sie“ misst sich auf dem Batch-Weg in Stunden und auf dem Streaming-Weg in Minuten – und welchen Weg ein Kanal nutzt, ist eine Entscheidung der Integrationszeit, nicht der Kampagnenzeit.
CD
Was ich zuerst prüfe
Ich baue eine Tabelle, bevor irgendeine Kampagnenplanung beginnt: jeder Kanal im Plan, sein Destination-Typ und seine dokumentierte Aktivierungslatenz. Dann zähle ich die aktiven Destinations gegen die Grenze von 100 pro Sandbox, weil diese Zahl hart ist und niemand sie verfolgt, bis eine Integration sich nicht mehr speichern lässt. Die Tabelle kostet eine Stunde und beendet Diskussionen, die sonst wochenlang laufen.
Christopher Dettinger · MarTech- und Omnichannel-Architekt
Architektur-Checkpoint · Station 7 · was stimmen muss
Jeder Kanal in Ihrem Plan hat eine bekannte Aktivierungslatenz.
Der Kampagnenkalender ist auf diesen Zahlen aufgebaut, nicht auf der Annahme von Unmittelbarkeit.
Jemand verfolgt die Zahl der aktiven Destinations gegen die Grenze von 100 pro Sandbox.
Was Teil 3 behandelt
Diese vier Stationen – vom vereinheitlichten Profil bis zur Zielgruppen-Segmentierung und Aktivierung – entscheiden, ob Sie handeln können und wie schnell. Was sie nicht entscheiden, ist, ob Sie dürfen – und ob hinterher irgendjemand sagen kann, was sich dadurch verändert hat.
Teil 3 nimmt die letzten beiden Stationen und die zwei Fragen darum herum: Steuern, wo der Kasten, den jedes Architekturdiagramm zeichnet, ausgeschaltet ausgeliefert wird; Messen, die dünnste Station der Dokumentation und die, die am häufigsten auf Phase zwei verschoben wird; die Warehouse-Frage, bei der Föderieren statt Kopieren Sie die Identity Resolution kostet; und was KI-Agenten tatsächlich sehen, wenn sie auf all dem laufen.
Häufige Fragen
Was ist Zielgruppen-Segmentierung in Echtzeit?
Zielgruppen-Segmentierung in Echtzeit ist eine Auswertung, die stattfindet, während die Interaktion noch läuft, statt in einem nächtlichen Batch. In Adobe Experience Platform ist sie keine Einstellung: die Plattform wählt Edge-, Streaming- oder Batch-Auswertung anhand der Form der Regel. Edge verarbeitet ein eingehendes Event in bis zu 350 Millisekunden, Streaming qualifiziert ein Profil in bis zu fünf Minuten, und Streaming hat ein Rückblickfenster von einem Tag – eine Regel, die weiter zurückgreift, wird still zu einer Batch-Zielgruppe.
Wie entsteht ein vereinheitlichtes Kundenprofil tatsächlich?
Daten kommen in mehreren Datensätzen als Profilfragmente an. Identity Resolution bestimmt, welche Fragmente zur selben Person gehören. Ein Union Schema führt sie zu einer Union View zusammen, und eine Merge Policy löst Konflikte auf – entweder über Datensatz-Vorrang oder über den jüngsten Zeitstempel. Das Ergebnis ist ein einzelnes Profil, das die Kanäle lesen können, mit harten Größengrenzen und einer empfohlenen Obergrenze für Events pro Profil.
Wann wird eine Zielgruppe in Echtzeit statt über Nacht ausgewertet?
Das hängt davon ab, wie die Regel geschrieben ist, nicht von einer Einstellung. Adobes Streaming-Segmentierung hat ein Rückblickfenster von einem Tag; Regeln, die auf Älteres verweisen, fallen auf den nächsten Batch-Job zurück. Multi-Entity-Abfragen, bestimmte verschachtelte Segmentbedingungen und Regeln ohne Zeitfenster sind ebenfalls nicht für Streaming geeignet. Die Edge-Auswertung, die schnellste Stufe mit bis zu 350 Millisekunden, ist noch enger.
Was ist der Unterschied zwischen Edge- und Hub-Decisioning?
Ort und Sichtbarkeit, nicht nur Geschwindigkeit. Der Hub hält die historischen Daten und den reichen Profilkontext. Das Edge Network hält nur Zielgruppen-Mitgliedschaften, Profilidentitäten und die für die Personalisierung nötigen Attribute, in einem rollierenden 14-Tage-Fenster. Eine Entscheidung, die die Historie braucht, muss im Hub fallen; eine, die nur ein Mitgliedschafts-Flag braucht, kann an der Edge in wenigen hundert Millisekunden laufen.
Was muss stimmen, damit Personalisierung kanalübergreifend funktioniert?
Fünf Dinge, in dieser Reihenfolge: Identitäten zu einem Graph aufgelöst; Fragmente zu einem Profil zusammengeführt; eine Zielgruppenregel, deren Auswertungsgeschwindigkeit zum Anwendungsfall passt; eine Destination, deren Aktivierungslatenz zum Moment passt; und tatsächlich aktivierte Governance-Policies. Ein Bruch an einer der fünf erzeugt Personalisierung, die falsch, zu spät oder außerhalb der Grenzen ist, die Sie für durchgesetzt hielten – statt Personalisierung, die sichtbar scheitert.
Steht das bei euch an?
Wenn die Zehn-Minuten-Prüfung eurer eigenen Audiences ein unangenehmes Ergebnis liefert, liegt die Lösung meistens in einer umgeschriebenen Regel, nicht in einer größeren Lizenz. Diese beiden auseinanderzuhalten, bevor die Vertragsverlängerung ansteht, ist genau meine Arbeit – für Teams in Pharma, Medical und Finance.
Zwischen dem, was eine Plattform kann, und dem, was Teams davon nutzen, liegt eine Lücke — auf beiden Seiten. Drei dokumentierte Werkzeuge schließen sie.
Dry run — läuft die Journey so, wie wir sie gebaut haben? Echte Zielgruppe, kein Versand, Mengen pro Knoten.
Simulation — was passiert mit einer einzelnen Person? Pfad-Trace und Coverage über alle Äste.
Holdout — hat die Kampagne etwas bewirkt? Eine Gruppe, die nichts bekommt.
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“.
Animation · Journey Dry run, Kapitel A
5.000 passende Profile. Trotzdem bleibt der E-Mail-Pfad leer.
Dieses Beispiel zeigt, wie eine fehlerhafte Bedingung die Zielgruppenverteilung verändert — und wie ein erneuter Prüflauf die Korrektur sichtbar macht.
Illustrative Demo mit synthetischen Daten. Geprüft wird die Pfadverteilung, nicht die tatsächliche Zustellung oder Kampagnenwirkung.
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.
Checkpoint · was Sie vor dem nächsten Versand wissen sollten
Wurde die aktuelle Journey jemals mit der echten Zielgruppe durchlaufen, ohne zu senden?
Ist Journey Dry run in Ihrer Instanz überhaupt freigeschaltet?
Weiß jemand, wie viele Profile an Knoten vier ankommen — oder wird geschätzt?
Gibt es eine Kontrollgruppe, oder ist die Öffnungsrate der einzige Wirkungsnachweis?
Wer schreibt diese Reihenfolge in den Kampagnenprozess?
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.
Steht das bei Ihnen an?
Wenn Sie wissen wollen, was Ihre Journey vor dem Versand tatsächlich ausgibt — und was Ihr Stack dabei kann und was nicht — schauen wir uns eine konkrete Kampagne an.
MarTech unter der Haube · eine Serie in drei Teilen
Teil 1 · Sie sind hierErfassen · Modellieren · Auflösen
Teil 2Vereinheitlichen · Segmentieren · Entscheiden · Aktivieren
Teil 3Steuern · Messen · Warehouse · KI-Agenten
Der 30-Sekunden-Überblick
Omnichannel ist keine Kanalstrategie. Es ist eine Frage zu einem Objekt: liest jeder Kanal dasselbe Kundenprofil?
Erfassen›Modellieren›Auflösen
7 TageDer Zwischenspeicher, über den alle ihre Dateien übergeben, löscht sie nach festem Plan. Er ist kein Speicher.
FixDie primäre Identität eines profilaktivierten Schemas lässt sich nach dem ersten Produktivladen nicht mehr ändern. Es ist die eine Entscheidung, die Sie nicht zurücknehmen können.
50Ein Identity Graph hält fünfzig Identitäten, dann löscht er die älteste, um Platz zu schaffen. Es wird kein Fehler ausgelöst, und das Profil fällt aus der Segmentierung.
30 Sekunden bis hierhin · 4 Minuten für die drei Stationen.
Jedes Omnichannel-Programm beginnt mit derselben Folie: der Kunde in der Mitte, die Kanäle drumherum angeordnet, Pfeile nach innen. Es ist eine gute Folie. Sie beschreibt ein Ergebnis, kein System – und genau in dieser Lücke bleiben die meisten Programme still stecken.
Hier ist der Test, der beides trennt. Multichannel und Omnichannel unterscheiden sich an genau einer Stelle: ob jeder Kanal dasselbe Profil liest, oder ob jeder Kanal seine eigene Liste führt. Alles andere – die Pfeile, das Wort „nahtlos“, der Kunde in der Mitte – folgt aus dieser einen architektonischen Tatsache. Wenn Ihre E-Mail-Plattform eine Liste hält, Ihre Web-Personalisierung eine zweite und Ihr Callcenter eine dritte, betreiben Sie Multichannel mit besserem Vokabular.
Alle Kanäle dasselbe Profil lesen zu lassen ist keine Beschaffungsentscheidung. Es sind neun davon, jede mit einer technischen Konsequenz, die achtzehn Monate später auftaucht. Diese Serie geht alle neun durch, mit Adobe Experience Platform als durchgerechnetem Beispiel – nicht weil die Antwort immer Adobe heißt, sondern weil Adobe seine Grenzen öffentlich dokumentiert, und dokumentierte Grenzen sind die einzige Möglichkeit, ehrlich darüber zu sprechen. Jede Zahl verlinkt auf die Seite, aus der sie stammt. Teil 1 nimmt die ersten drei – Erfassung, Datenmodell und Identity Resolution – die Stationen, die darüber entscheiden, ob Sie überhaupt einen Kunden haben, und den Identity Graph, an dem sie entweder halten oder still aufhören zu halten.
Batch-Ingestion bewegt Dateien, Streaming-Ingestion bewegt Events – und das sind nicht zwei Geschwindigkeiten derselben Sache. Sie landen in unterschiedlichen Speichern mit unterschiedlichen Grenzen: Streaming ins Profil ist bei 1.500 Anfragen pro Sekunde gedeckelt, in den Data Lake bei 4.000–5.000. Der schnellere Weg ist der schmalere. Und die Data Landing Zone, der Zwischenspeicher, über den die meisten Teams ihre Dateien übergeben, löscht alles nach sieben Tagen.
XDM setzt ein Schema aus einer Klasse plus Feldgruppen zusammen, und die Klasse entscheidet, ob die Daten Dinge beschreiben, wie sie sind, oder Dinge, wie sie passiert sind. Schema-Evolution ist rein additiv: Sie dürfen Felder hinzufügen, nie entfernen oder umbenennen. Ein Punkt auf der Verbotsliste wiegt schwerer als der Rest – die primäre Identität eines profilaktivierten Schemas zu ändern, sobald Daten geladen wurden.
Identity Service verknüpft die Identifikatoren eines Kunden zu einem Identity Graph. Der Graph hält fünfzig. Bei der einundfünfzigsten wird die älteste Identität gelöscht, first in, first out – Cookie-Identifikatoren vor dauerhaften – und ein Profil oberhalb der Grenze ist von Segmentierung, Exporten und Lookups ausgeschlossen. Namespace-Priorität schützt Sie nicht, und ein bereits kollabierter Graph wird erst repariert, wenn er das nächste Mal aktualisiert wird.
Die erste Verwechslung, die aus dem Weg muss, ist der Unterschied zwischen einer Plattform und einer darauf gebauten Anwendung.
Adobe führt als Anwendungen auf Experience Platform auf: Real-Time CDP, Real-Time CDP B2B Edition, Journey Optimizer, Customer Journey Analytics, Journey Orchestration und Mix Modeler. Die Plattform darunter übernimmt Ingestion, Datenmodell, Identität, Profil, Zielgruppen, Governance und Aktivierung. Die Anwendungen konsumieren das alles.
Das ist wichtig, weil Kaufentscheidungen intern anders beschrieben werden. „Wir haben Journey Optimizer gekauft“ beschreibt eine Anwendung. Es sagt nichts darüber, ob die Daten darunter modelliert, aufgelöst, gesteuert oder aktivierbar sind – und diese vier entscheiden, ob die Anwendung überhaupt etwas Brauchbares tut. Dieselbe Trennung gibt es in jedem Stack, unter anderen Namen und in anderer Anordnung.
Ein Begriff noch vor den Stationen, weil er an fast jeder wiederkehrt: die Sandbox. Sie ist die Isolationsgrenze – eine virtuelle Partition der Plattform mit eigenen Daten, eigener Konfiguration, eigenen Grenzen. Fast jede Zahl in diesem Artikel ist pro Sandbox definiert. Sie ist die folgenreichste unsichtbare Linie in der Architektur, und sie taucht auf keinem der Diagramme auf.
Station 1 – Erfassen
Daten kommen auf zwei Wegen an, und das sind nicht zwei Geschwindigkeiten derselben Sache. Es sind zwei Wege in zwei verschiedene Speicher mit zwei verschiedenen Sets von Grenzen.
Batch-Ingestion bewegt Dateien. Streaming-Ingestion bewegt Events. Die veröffentlichten Zeiten liegen weiter auseinander, als das Wort „Streaming“ vermuten lässt.
Streaming in den Data Lake. Derselbe Weg ist mit unter 60 Minuten dokumentiert.
Beachten Sie, was das bedeutet: die Sekundenangabe ist eine Beobachtung aus Adobes Troubleshooting-Leitfaden, keine veröffentlichte Latenz, während die Stunde in den analytischen Speicher dokumentiert ist. Zwei Antworten auf „haben wir diese Daten schon“, beide richtig, je nachdem wer fragt.
01
Erfassen
Was ankommt, und auf welchem der beiden Wege es reist.
Batch- und Streaming-Ingestion
7 TageData Landing Zone · hart
Die Durchsatzzahlen laufen in dieselbe Richtung. Adobes Performance-Guardrail für Streaming ins Profil und in die Streaming-Segmentierung liegt bei 1.500 Anfragen pro Sekunde; in den Data Lake bei 4.000–5.000. Der schnellere Weg ist der schmalere. Das ist kein Fehler, das ist der Handel – Echtzeitverarbeitung kostet Reserve.
Architektur-Check · Station 1 · Erfassen
Ihr Team nutzt die Data Landing Zone als Übergabepunkt zwischen zwei Systemen. Wie lange bleibt eine Datei dort liegen?
Ihre Antwort
Was Adobe dokumentiert
Sieben Tage, ohne Ausnahme: „Experience Platform enforces a strict seven-day expiration time on all files and folders uploaded to a Data Landing Zone container. All files and folders are deleted after seven days.“ Es ist ein Zwischenspeicher, kein Speicher – und dieser Unterschied hat schon mehr als einen Übergabeprozess lautlos beendet.
Warum das zählt
Jede Übergabe, die auf der Annahme beruht, eine Datei warte bis sie abgeholt wird, trägt eine Sieben-Tage-Frist, die niemand aufgeschrieben hat. Sie zeigt sich als Lücke in einem Report am achten Tag, nicht als Fehler in einem Ingestion-Log.
Der Zwischenspeicher. Die Data Landing Zone, die viele Teams als informellen Übergabepunkt zwischen Systemen nutzen, löscht alles nach sieben Tagen: „Experience Platform enforces a strict seven-day expiration time on all files and folders uploaded to a Data Landing Zone container.“
Ihr Zwischenspeicher ist kein Speicher.
Eine Anmerkung zu Adobes eigener Dokumentation an dieser Stelle, weil sie lehrreich ist. Die Guardrails-Seite nennt maximal 25.000 Dateien und 1 TB pro Batch. Die Übersichtsseite zur Batch-Ingestion nennt für dasselbe 1.500 Dateien und 100 GB. Beide sind aktuell. Wenn zwei Seiten eines Herstellers sich widersprechen, ist die praktische Antwort, deutlich innerhalb der kleineren Zahl zu entwerfen und gegen den eigenen Tenant zu prüfen statt gegen irgendeinen Artikel – auch diesen.
CD
Was ich zuerst prüfe
Bevor irgendjemand über Journeys spricht, lasse ich mir das Quellenverzeichnis mit zwei zusätzlichen Spalten geben: Batch oder Streaming, und der Name der Person, die das entschieden hat. Dann halte ich diese Spalte gegen die Latenz, die jeder nachgelagerte Anwendungsfall voraussetzt. Wo beide auseinandergehen, habe ich das Problem gefunden, bevor die erste Journey gebaut ist – und an dem Punkt ist es ein Nachmittag Arbeit statt einer Migration.
Christopher Dettinger · MarTech- und Omnichannel-Architekt
Architektur-Checkpoint · Station 1 · was stimmen muss
Sie wissen, welche Ihrer Quellen Batch sind und welche Streaming.
Diese Aufteilung wurde bewusst entschieden – nicht danach, welche Quelle sich am leichtesten anschließen ließ.
Alle, die Dateien über den Zwischenspeicher übergeben, wissen, dass er kein Speicher ist.
Station 2 – Modellieren
Das ist die Station, die Teams übereilen, und die einzige in der Kette, die faktisch unumkehrbar ist.
Adobes Datenmodell ist XDM – das Experience Data Model. Seine Kompositionsregel steht als Formel da: „Class + Schema Field Group* = XDM Schema“. Die Klasse entscheidet, ob ein Schema Dinge beschreibt, wie sie sind (Record-Daten – ein Kunde, ein Produkt, ein Konto) oder Dinge, wie sie passiert sind (Zeitreihendaten – ein Klick, ein Kauf, eine geöffnete E-Mail). Diese Wahl wird einmal getroffen, an der Klasse, und alles Nachgelagerte erbt sie.
02
Modellieren
Das Schema, dem jeder eingehende Datensatz entsprechen muss.
XDM · Experience Data Model
FixPrimäre Identität, nach dem ersten Laden
Schema-Evolution folgt dem, was Adobe ein rein additives Versionierungsprinzip nennt: Änderungen sind nur erlaubt, wenn sie nicht zerstörend sind. Sie dürfen Felder hinzufügen. Sie dürfen ein Pflichtfeld optional machen. Sie dürfen ein Feld nicht entfernen, umbenennen, verschieben, eine Werteinschränkung lockern, ein Schema löschen oder seine Teilnahme am Profil deaktivieren. Sobald echte Daten geladen wurden, werden „die Regeln der Schema-Evolution strikt durchgesetzt“, und Felder „werden in allen XDM-Schemas, in denen sie referenziert sind, nicht mehr editierbar“.
Architektur-Check · Station 2 · Modellieren
Was können Sie nach dem ersten Produktivladen noch ändern?
Ihre Antwort
Was Adobe dokumentiert
Nur Ergänzungen. Adobe setzt ein rein additives Versionierungsprinzip durch: Sie dürfen Felder hinzufügen und Pflichtfelder optional machen. Sie dürfen ein Feld nicht umbenennen, entfernen oder verschieben – und die Verbotsliste nennt ausdrücklich „changing primary identity on Profile-enabled schemas with ingested data“. Der Name eines Feldes ist noch früher fix, ab dem Speichern des Schemas.
Warum das zählt
Das ist die einzige Station der Kette, an der eine falsche Entscheidung nicht an Ort und Stelle korrigiert werden kann. Zielgruppen, Journeys und Destinations lassen sich neu bauen. Eine primäre Identität lässt sich nur migrieren – und die Migration berührt jedes Objekt, das von ihr abhängt.
Ein Punkt auf der Verbotsliste verdient es, zweimal gelesen zu werden: „Changing primary identity on Profile-enabled schemas with ingested data.“
Die primäre Identität ist das Feld, das sagt: diese Zeile ist eine Person, und zwar diese. Sie zu wählen ist eine Modellierungsentscheidung, die früh fällt, oft von der Person, die dem Quellsystem am nächsten ist, oft bevor irgendjemand darüber nachgedacht hat, wie die Identitätsstrategie in drei Jahren aussieht. Nach der ersten Zeile Produktivdaten ist sie fix.
Alles andere lässt sich neu bauen. Das Datenmodell muss migriert werden.
Alles andere in diesem Artikel lässt sich neu bauen. Zielgruppen lassen sich umschreiben, Destinations neu verbinden, Policies aktivieren, Journeys umbauen. Das Datenmodell nicht – nicht ohne eine Migration, die jedes nachgelagerte Objekt berührt. Es verdient einen entsprechenden Anteil der Projektaufmerksamkeit, was ungefähr das Gegenteil dessen ist, was es üblicherweise bekommt.
CD
Was ich vor der Freigabe verlange
Für jedes profilaktivierte Schema stelle ich zwei Fragen und schreibe die Antworten auf: wem gehört die primäre Identität, und an welchem Datum hat diese Person sie freigegeben. Nicht der Integrationsentwickler, nicht die Agentur – jemand, der in drei Jahren noch im Raum sitzt. Fehlt eine der beiden Antworten, stoppe ich das Schema-Review dort statt nach dem ersten Produktivladen, weil das der Punkt ist, hinter dem kein späteres Projekt es rückgängig macht.
Christopher Dettinger · MarTech- und Omnichannel-Architekt
Architektur-Checkpoint · Station 2 · was stimmen muss
Jedes profilaktivierte Schema hat einen benannten Verantwortlichen für seine primäre Identität.
Diese Person versteht sowohl die Quellsysteme als auch die Identitätsstrategie auf drei Jahre.
Die Freigabe liegt vor dem ersten Produktivladen vor, nicht danach.
Station 3 – Auflösen
Hier funktioniert Omnichannel entweder, oder es scheitert lautlos. Nicht laut. Lautlos.
Ein Kunde ist nicht ein Identifikator. Er ist ein Browser-Cookie auf einem Laptop, ein zweites auf einem Telefon, eine App-Installations-ID, eine gehashte E-Mail aus einem Newsletter, ein CRM-Datensatz, eine Kundennummer, ein zweiter Browser, nachdem er letzten Monat die Cookies gelöscht hat. Identity Resolution ist der Prozess, zu entscheiden, dass all das zu einer Person gehört.
03
Auflösen
Entscheiden, welche der vielen Identifikatoren eines Kunden eine Person sind.
Identity Service
50Identitäten pro Graph · hart
Adobes Identity Service tut das, indem er einen Identity Graph baut – die Menge der Identitäten, die einen Kunden repräsentieren. Jeder Identifikator sitzt in einem Identity Namespace: Email, Phone, CRMID, ECID und jeder eigene Namespace, den Sie definieren. Es gibt keine Grenze dafür, wie viele eigene Namespaces Sie anlegen können.
Es gibt allerdings eine Grenze für den Graph.
Architektur-Check · Station 3 · Auflösen
Ein Identity Graph läuft voll. Was passiert mit der einundfünfzigsten Identität?
Ihre Antwort
Was Adobe dokumentiert
Ein Graph hält maximal 50 Identitäten. Bei der einundfünfzigsten wendet Identity Service ein First-in-first-out-Verfahren an und löscht die älteste – Cookie-Identifikatoren vor dauerhaften. Es gibt keinen Fehler und keine Warnung, und ein Profil oberhalb der Grenze ist von Segmentierung, Exporten und Lookups ausgeschlossen.
Warum das zählt
Nichts in der Oberfläche ändert sich, wenn das passiert. Das Profil taucht in Segmentierung, Exporten und Lookups nicht mehr auf, und die Zahl im Kampagnenreport ist still niedriger als sie sein sollte. Der einzige Weg, es kommen zu sehen, ist die Verteilung der Identitäten pro Graph anzuschauen, bevor sie fünfzig erreicht.
Fünfzig klingt großzügig, bis man einen echten Haushalt zählt. Vier Personen. Drei Geräte pro Person. Zwei Browser pro Gerät. Cookie-Löschungen alle paar Wochen, jede erzeugt eine frische ECID. Ein gemeinsames Tablet, das die Identitäten zweier Familienmitglieder in einen Graph zieht. Ein Arbeitslaptop und ein privater. Dazu eine Servicebearbeitung, die eine Fall-ID als Namespace schreibt, und ein Kundenbindungsprogramm, das seine eigene schreibt.
Der Kipppunkt · der Identity Graph eines Profils495050 / 50
Cookie-IDGeräte-IDE-Mail · Telefon · CRMVerdrängt
Neunundvierzig Identitäten, die älteste links. Ein Haushalt, ein paar Cookie-Löschungen, ein gemeinsames Tablet, eine Kundennummer. Bisher ist nichts Ungewöhnliches passiert.
Fünfzig. Der Graph ist voll. Nichts in der Oberfläche sagt das.
Die einundfünfzigste ist nicht gescheitert. Identity Service hat die älteste Identität gelöscht – eine Cookie-ID – um Platz zu schaffen. Kein Fehler, keine Warteschlange, keine Warnung.
Die Verdrängung ist nicht zufällig. Sie priorisiert nach Identitätstyp – Cookie-ID zuerst, dann Geräte-ID, dann die dauerhaften Personenidentifikatoren, zusammengefasst als Cross-Device-ID, E-Mail und Telefon – und innerhalb eines Typs nach dem Zeitstempel der Identität. Der Entwurf ist sinnvoll: wirf die billigen Identifikatoren weg, bevor du die dauerhaften wegwirfst.
Beachten Sie aber die zwei Dinge, die er nicht tut. Er warnt Sie nicht. Und Namespace-Priorität schützt Sie nicht: Adobe stellt unmissverständlich fest, dass „namespace priority does not affect graph behavior when the limit of 50 identities per graph is reached“. Die Priorität, die Sie konfiguriert haben, regelt, welche Verknüpfungen einen Konflikt überleben. Sie regelt nicht, welche Identitäten die Obergrenze überleben.
Die kleinen Dinge, die einen Identity Graph zerlegen
Identity Service unterscheidet Groß- und Kleinschreibung. Adobes eigenes Beispiel: „abc@gmail.com and ABC@GMAIL.COM would be treated as two separate Email identities.“ Wenn ein Quellsystem E-Mail-Adressen in Großbuchstaben schreibt und ein anderes nicht, bauen Sie keinen Graph. Sie bauen zwei, und die werden nie zusammenfinden.
ECIDs haben ein Format.Genau 38 Zeichen, nur Ziffern. Datensätze, die das nicht erfüllen, werden bei der Ingestion übersprungen. Identitätswerte dürfen generell 1.024 Zeichen nicht überschreiten und nicht die Zeichenketten „null“, „anonymous“, „invalid“ oder leer sein.
Sie bekommen drei eindeutige Namespaces. Einen Namespace als eindeutig zu deklarieren bedeutet, dass ein Graph nur eine Identität in diesem Namespace halten kann – der Mechanismus, der verhindert, dass eine CRM-ID in eine andere kollabiert. Sie können maximal drei konfigurieren, und Änderungen brauchen bis zu 24 Stunden, bis sie greifen.
Die Reparaturregel
Wenn ein Graph kollabiert ist – wenn zwei Personen wegen eines gemeinsamen Geräts oder eines schlechten Schlüssels zu einem Profil verschmolzen sind – repariert eine geänderte Konfiguration das nicht rückwirkend:
Ein kollabierter Graph für einen Kunden, der seit der Korrektur nicht aktiv war, bleibt kollabiert. Ihre Konfiguration ist richtig. Ihr Dashboard ist grün. Das Profil ist weiterhin falsch, und es bleibt falsch, bis diese Person wiederkommt.
Der Graph scheitert nicht laut. Er scheitert lautlos.
Das ist, was „lautlos scheitern“ in der Praxis heißt. Es gibt keinen Fehlerzustand, keine Warteschlange abgelehnter Datensätze, keine Warnung. Es gibt ein Profil, das aufgehört hat ansprechbar zu sein, und eine Zahl in einem Report, die still niedriger ist als sie sein sollte.
CD
Was ich zuerst prüfe
Ich lasse mir die Verteilung der Identitäten pro Graph geben, nicht den Durchschnitt – ein Durchschnitt sagt nichts über eine Obergrenze. Was ich sehen will, ist der Rand: wie viele Profile bereits über vierzig liegen, denn das sind die, die sich dem Punkt nähern, an dem sie nicht mehr ansprechbar sind. Wenn niemand diese Zahl liefern kann, ist genau das der Befund, und er steht im Report vor allem anderen.
Christopher Dettinger · MarTech- und Omnichannel-Architekt
Eine Variante davon haben wir im Detail durchgespielt (auf Englisch) – ein authentifiziertes Portal, in dem ECID, CRM-Identität und der gestreamte Consent-Datensatz zusammenpassen müssen, bevor ein Arzt die richtige Seite sieht.
Architektur-Checkpoint · Station 3 · was stimmen muss
Sie wissen, welcher Namespace Ihre Personenidentität ist und ob er als eindeutig deklariert ist.
Sie wissen, wie viele Identitäten Ihre Graphen heute tragen – die Verteilung, nicht nur den Durchschnitt.
Die Normalisierung von Groß- und Kleinschreibung wurde über jede Quelle geprüft, die eine E-Mail-Adresse schreibt.
Was Teil 2 behandelt
Die drei Stationen in diesem Artikel entscheiden, ob Sie überhaupt einen Kunden haben: ob die Daten ankommen, ob sie so modelliert sind, dass man sie nutzen kann, und ob die Fragmente sich zu einer Person auflösen. Macht man die falsch, kann nichts Nachgelagertes das ausgleichen – eine Zielgruppe auf einem kollabierten Identity Graph ist falsch, egal wie gut die Kampagne ist.
Teil 2 nimmt die nächsten vier: Vereinheitlichen, wo aus Fragmenten ein Profil mit Verfallsdatum wird; Segmentieren, wo sich „Echtzeit“ als Eigenschaft der Regel statt der Plattform herausstellt; Entscheiden, wo die Grenze nicht die Kapazität ist, sondern was eine Entscheidung sehen kann; und Aktivieren, wo die Zeitannahmen aus Kampagnenplänen auf die dokumentierte Wirklichkeit treffen. Teil 3 schließt mit Governance, Messung, der Warehouse-Frage und dem, was KI-Agenten verändern.
Häufige Fragen
Was ist der technische Unterschied zwischen Multichannel und Omnichannel?
Ob jeder Kanal dasselbe Kundenprofil liest oder jeder seine eigene Liste führt. In einem Multichannel-Stack halten die E-Mail-Plattform, die Web-Personalisierung und das Contact Center jeweils ihre eigene Kopie der Zielgruppe. In einem Omnichannel-Stack lesen alle drei ein Profil, aufgelöst aus einem Identity Graph. Alles andere – konsistente Botschaften, wiedererkannte Kunden, durchgängige Journeys – ist eine Folge dieses einen strukturellen Unterschieds.
Wie funktioniert Identity Resolution in einer CDP?
Jeder Identifikator, den ein Kunde erzeugt – Cookie-IDs, Geräte-IDs, gehashte E-Mails, CRM-Datensätze – wird in einen Namespace gelegt und zu einem Identity Graph verknüpft, der eine Person repräsentiert. Verknüpfungen entstehen, wenn ein gemeinsames Signal zwei Identifikatoren verbindet, etwa ein Login, das ein Browser-Cookie an ein bekanntes Konto bindet. Die Qualität der Auflösung hängt vollständig von der Qualität und Konsistenz der Schlüssel ab, die Ihre Quellsysteme schreiben.
Was ist ein Identity Graph, und hat er eine Grenze?
Ein Identity Graph ist die Menge der Identitäten, die einen Kunden repräsentieren. Er hat eine dokumentierte Obergrenze: Adobe deckelt den Graph eines einzelnen Profils bei 50 Identitäten, und ein Profil darüber ist von Segmentierung, Exporten und Lookups ausgeschlossen. Wird ein voller Graph aktualisiert, wird zuerst die älteste Identität gelöscht – Cookie-Identifikatoren vor dauerhaften. Es wird kein Fehler ausgelöst.
Was braucht es tatsächlich, um Omnichannel-Marketing zu betreiben?
Neun Fähigkeiten, die in Reihe funktionieren müssen: Erfassung, ein Datenmodell, Identity Resolution, ein vereinheitlichtes Profil, Segmentierung, Decisioning, Aktivierung, Governance und Messung. Keine lässt sich überspringen und keine als fertiges Produkt kaufen – jede ist eine Reihe von Entscheidungen mit dokumentierten Grenzen daran. Die Plattform ist der einfache Teil. Die neun Entscheidungen sind die Arbeit.
Steht das bei euch an?
Ein Identity Graph scheitert selten zum Go-live. Er scheitert achtzehn Monate später, wenn eine Namespace-Entscheidung, die niemand dokumentiert hat, anfängt Profile zu verlieren. Wenn vorher jemand einen zweiten Blick darauf werfen soll – genau das mache ich, für Teams in Pharma, Medical und Finance.
Wir verwenden Cookies und ähnliche Technologien. Technisch notwendige Cookies sind für den Betrieb dieser Website erforderlich. Statistik-Cookies setzen wir nur mit Ihrer Einwilligung. Ihre Auswahl können Sie jederzeit ändern.
Notwendig
Immer aktiv
Die technische Speicherung oder der Zugriff ist unbedingt erforderlich, um die Nutzung eines von Ihnen ausdrücklich gewünschten Dienstes zu ermöglichen oder eine Nachricht über ein elektronisches Kommunikationsnetz zu übertragen.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistik
Die technische Speicherung oder der Zugriff erfolgt ausschließlich zu statistischen Zwecken – etwa zur Auswertung, wie diese Website genutzt wird.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
Die technische Speicherung oder der Zugriff dient dazu, Nutzerprofile für Werbung zu erstellen oder Nutzer über Websites hinweg zu vergleichbaren Marketingzwecken zu verfolgen.
