Wenn Teams zum ersten Mal auf Salesforce Data Cloud treffen, greifen sie zu einer Analogie. „Das ist eine CDP.” „Das ist Salesforce-typisches Segment.” „Das ist ein In-Platform-Data-Lake.” Jeder Vergleich bringt Sie ein Stück weit und führt Sie dann an einen teuren Ort.
Data Cloud ist keines dieser Dinge. Sie ist eine Salesforce-geformte Datenplattform, gebaut um DMOs, Harmonisierungs-Regeln und Identity Resolution. Die architektonischen Entscheidungen, die im CDP-Modell sinnvoll erscheinen, sind in Data Cloud fast immer die, die das Ergebnis teuer, brüchig und schwer weiterzuentwickeln machen.
Das CDP-Modell scheitert auf drei Achsen
Identität. Die Aufgabe einer CDP ist es, ein vereinheitlichtes Profil aus rohen Events und Merkmalen zusammenzusetzen. Die Identity-Resolution-Engine von Data Cloud tut dem Namen nach dasselbe, ihre Designziele sind aber andere. CDPs optimieren typischerweise auf Reichweite (so viele anonyme Events wie möglich auf bekannte Profile abbilden). Data Cloud sitzt auf einem CRM, in dem Profil-Korrektheit wichtiger ist als Reichweite und in dem die Reihenfolge der Match-Regeln weiterreichende Konsequenzen über Sales, Service und Marketing Cloud hinweg hat. Wer Identity in Data Cloud mit CDP-Defaults gestaltet, bekommt einen Graphen, der zu nachgiebig ist, wo er strikt sein müsste, und merkt es erst nach drei Quartalen.
Modellierung. Eine CDP belohnt ein flaches, event-stream-orientiertes Schema: Merkmale und Events, das vereinheitlichte Profil zur Query-Zeit zusammengesetzt. Data Cloud belohnt ein strukturiertes DMO-Modell mit expliziten Harmonisierungs-Regeln und einem kanonischen Modell, auf das sich andere Teile des Salesforce-Ökosystems verlassen können. Wer es wie eine CDP baut, landet bei tausenden Attributen, mehrdeutigen Ableitungen und einem Modell, gegen das kein nachgelagerter Konsument planen kann.
Aktivierung. CDP-Aktivierungen sind tendenziell event-getrieben, häufig in Werbenetzwerke. Aktivierungen aus Data Cloud sind CRM-geformt: Sie aktualisieren Objekte, treiben Marketing-Cloud-Audiences, lösen Flow-Trigger aus und versorgen Agentforce-Topics. Jeder Pfad hat seinen eigenen Takt, seine eigene Verantwortung und seinen eigenen Aktualisierungs-Rhythmus. Wer alles als „diese Segmente an jene Ziele schicken” modelliert, übersieht, dass die Ziele eigene Empfindlichkeiten, Governance und SLAs haben.
Was stattdessen funktioniert
Behandeln Sie Data Cloud als produktive Datenplattform, die zufällig innerhalb von Salesforce lebt.
Das heißt: ein bewusst kleiner DMO-Katalog, gegen die tatsächliche Kardinalität Ihrer Quellen entworfen. Match-Regeln mit expliziter Reihenfolge, schriftlich festgehalten. Calculated Insights, die isoliert testbar sind. Aktivierungs-Pfade mit benannten Verantwortlichen und beobachtbaren Nebenwirkungen. Und eine Kultur, in der Sie das Modell wie einen API-Vertrag versionieren, denn das ist es, nur ein API-Vertrag, den andere Teams in der Plattform konsumieren.
Die Teams, die das richtig machen, liefern Data-Cloud-Projekte, die ihren zweiten Geburtstag erleben. Die Teams, die das nicht tun, verhandeln das Verbrauchs-Pricing nach, während das Modell unter ihnen verfault.
Ein Test, den Sie sofort machen können
Nehmen Sie das meistgenutzte Attribut Ihres aktuellen Unified-Profile. Stellen Sie drei Fragen:
- Wo kommt dieser Wert her? Kann jemand in unter fünf Minuten zur Quellregel zurückverfolgen?
- Was passiert, wenn die Quelle widerspricht? Ist die Reihenfolge schriftlich festgehalten oder implizit aus der Reihenfolge der Anlage entstanden?
- Wer hängt davon ab? Aktivierungen, Agentforce-Topics, Marketing-Cloud-Audiences, sehen alle dieselbe Antwort?
Wenn eine dieser Fragen unscharf ist, betreiben Sie CDP-Modellierung auf einer CRM-Plattform. Die Sanierung ist real, aber sie lohnt sich, bevor die Verbrauchsabrechnung kommt.