Customer 360: Das gemeinsame Datenmodell für Kundenanalysen
Wie Customer 360 Identität, Profil, Verhalten und Kontext in einem Datenmodell verbindet und welche Rolle Identity Resolution und Governance dabei spielen.
Die Kernaussagen auf einen Blick.
- Customer 360 ist ein gemeinsames Datenmodell für Identität, Profil, Verhalten und Kontext und nicht lediglich ein Dashboard.
- Unternehmen müssen entscheiden, ob das Kundenprofil in einer CDP, im Lakehouse oder in einer hybriden Architektur geführt wird.
- Verantwortlichkeiten für Identitätsauflösung, Masterdaten und abgeleitete Features sollten klar geregelt sein. Zusätzlich braucht es verbindliche Regeln für Berechtigungen, Lineage, Consent und Löschung.
- Ein Customer-360-Modell entfaltet erst dann Nutzen, wenn CRM, Marketing, Service oder ML-Anwendungen darauf zugreifen.
Inhaltsverzeichnis
Warum jede Abteilung einen anderen Kunden sieht
Eine scheinbar einfache Frage nach der Zahl aktiver Kunden kann je nach System unterschiedlich beantwortet werden. Marketing zählt möglicherweise alle erreichbaren Kontakte. Der Vertrieb betrachtet dagegen aktive Accounts im CRM. Finance zählt ausschließlich zahlende Kunden. Customer Success orientiert sich an tatsächlicher Nutzung oder Logins. Jede Zahl kann innerhalb ihrer eigenen Definition korrekt sein. Ohne gemeinsamen Kundenbegriff lassen sich daraus jedoch nur schwer einheitliche Entscheidungen ableiten.
In fast jeder wachsenden Datenlandschaft entsteht ein ähnliches Bild. Jede Abteilung definiert Kunden anhand des Systems und der Prozesse, mit denen sie arbeitet. Gemeinsame Reports benötigen dadurch regelmäßig manuelle Abstimmung und Datenabgleiche. Segmentierung, Churn-Modell und Kampagnen können dadurch mit unterschiedlichen Kunden-IDs und Profilständen arbeiten und kommen zu unterschiedlichen Aussagen über denselben Account.
Customer 360 wird häufig als Produkt- oder Dashboardfrage behandelt. Dabei wird oft zuerst über CDP, CRM-Suite oder Visualisierung gesprochen. Der eigentliche Ausgangspunkt ist jedoch die gemeinsame Definition des Kundenobjekts. Customer 360 beschreibt, wie Kundendaten systemübergreifend modelliert, zusammengeführt und bereitgestellt werden, als Grundlage für die gesamte Customer-Intelligence-Kette: Segmentierung, Customer Lifetime Value, Churn, Next Best Action.
Was ist Customer 360: und was ist es nicht?
Customer 360 definiert das Kundenobjekt über operative und analytische Systeme hinweg. Dazu gehören Identitätsmerkmale, Stammdaten, Interaktionen und abgeleitete Informationen. CRM, Marketing, Service, Analytics und ML-Anwendungen können dadurch auf dieselbe Grundstruktur zurückgreifen. Ziel ist ein verbindliches Kundenprofil, dessen Definition zentral gepflegt wird.
Davon abzugrenzen sind drei verwandte Begriffe. Ein CRM fokussiert Vertriebs- und Serviceprozesse und bildet nicht automatisch alle relevanten Kundendaten ab. Eine Customer Data Platform (CDP) ist typischerweise auf Profilbildung, Segmentierung und Aktivierung im Marketing ausgerichtet. Das Customer-360-Modell definiert unabhängig vom konsumierenden System, wie ein Kunde fachlich und technisch dargestellt wird. CRM, CDP, BI und ML werden auf dieser Basis mit denselben Profilen versorgt. Wird Customer 360 vollständig einem einzelnen Produkt überlassen, übernimmt das Unternehmen zugleich dessen Datenmodell und technische Grenzen.
Eine Visualisierung kann Customer-360-Daten darstellen, ersetzt aber nicht das zugrunde liegende Modell. Eine breit gefüllte Kundenübersicht ist noch keine systemübergreifend konsistente Kundendefinition. Das Ergebnis ist häufig ein Dashboard auf weiterhin fragmentierten Datenquellen.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Aus welchen vier Bereichen besteht ein Customer-360-Modell?
Ein belastbares Customer-360-Modell trennt vier fachlich unterschiedliche Bereiche, die jeweils eine andere Frage beantworten und unterschiedliche Aktualisierungsraten haben.
Identität
Beantwortet, welche Datensätze zu welchem Kunden oder Account gehören.
Profil
Enthält vergleichsweise stabile Stammdaten, Hierarchien und Consent-Informationen.
Verhalten
Beschreibt Käufe, Nutzung, Interaktionen, Supportfälle und weitere Ereignisse.
Kontext
Umfasst berechnete Größen wie Segment, CLV, Churn-Score, Intent oder Next Best Action.
| Bereich | Inhalt | Beispiele | Typische Quellen | Update-Frequenz |
|---|---|---|---|---|
| Identität | Auflösung auf das Kundenobjekt | Customer-ID, Account-ID, Match-Keys, Hierarchie | CRM, ERP, Auth, Stewardship | bei Änderung |
| Profil | stabile Attribute des Kunden | Stammdaten, Branche, Größe, Region, Consent | CRM, MDM, Third-Party | täglich/wöchentlich |
| Verhalten | Aktionen und Transaktionen | Käufe, Logins, Tickets, Klicks, Nutzung | Shop, App, Telemetrie, Service | Stream/Batch |
| Kontext | abgeleitete Größen und Signale | CLV, Churn-Score, Segment, NBA, Intent | Feature Store, ML-Modelle, Intent-Provider | Modell-Lauf |
Die Trennung erleichtert unterschiedliche Aktualisierungszyklen, Ownership und Governance. Identitäts- und Stammdaten verändern sich meist seltener als Interaktions- und Nutzungsdaten. Abgeleitete Signale werden typischerweise durch Regeln oder Modelle berechnet. Eine einzige sehr breite Tabelle für Stammdaten, Events und Scores erhöht das Risiko inkonsistenter Aktualisierungen, unklarer Ownership und instabiler Schemas. Eine Medallion-Architektur kann die Trennung zwischen Rohdaten, konsolidierten Profilen und aktivierungsfertigen Sichten unterstützen. Die Bronze-Schicht übernimmt Quelldaten möglichst unverändert. In Silver werden Daten bereinigt, vereinheitlicht und zu Kundenobjekten zusammengeführt. Gold stellt fachliche Profile, Segmente und Scores für konkrete Anwendungsfälle bereit.
Im B2B steht hinter dem Kunden häufig eine Unternehmens- oder Accountstruktur. Zu einem Account gehören verschiedene Ansprechpartner, Nutzer, Vertragsparteien und Organisationseinheiten. Je nach Geschäftsmodell können Muttergesellschaft, Billing Entity, Business Unit, Supportorganisation und Nutzergruppen unterschieden werden, eine B2B-Identity-Resolution bildet bis zu sechs Hierarchieebenen ab. Werden diese Beziehungen nicht abgebildet, können Signale aus Tochtergesellschaften, Verträgen oder Nutzergruppen falsch zugeordnet oder übersehen werden.
Identity Resolution als Engpass
Die Zusammenführung unterschiedlicher Identitäten ist häufig der aufwendigste Teil eines Customer-360-Programms. Web, Marketing, ERP, CRM und Service verwenden jeweils eigene Identifier: Cookie-ID, E-Mail-Hash, SAP-Kundennummer, Salesforce-Account, Telefonnummer. Erst durch ein gemeinsames Identitätsmodell lassen sich die Datensätze konsistent einem Kunden oder Account zuordnen. Fehlende Regeln, Datenqualität und Ownership führen an dieser Stelle häufig zu Verzögerungen.
Exakte Treffer auf verifizierte Identifier
Fuzzy-Logik und ML-Modelle für unsichere Treffer
Auflösung verschiedener Identifier auf ein gemeinsames Kundenobjekt
Zwei Strategien stehen zur Verfügung. Deterministisches Matching verbindet Datensätze über eindeutige und verifizierte Schlüssel (E-Mail, Telefon, Customer-ID). Die Treffer sind gut nachvollziehbar, sofern die zugrunde liegenden Identifier verlässlich sind. Die Methode greift jedoch nur, wenn gemeinsame Identifikatoren tatsächlich vorhanden sind. Probabilistisches Matching bewertet Ähnlichkeiten über mehrere Merkmale wie Name, Adresse, Telefonnummer, Domain oder weitere Kontextsignale. Das Ergebnis ist eine Wahrscheinlichkeit oder ein Matchscore statt einer eindeutigen Zuordnung. In der Praxis werden exakte Regeln häufig mit probabilistischen Verfahren und manueller Prüfung ergänzt; die zulässige Konfidenz sollte vom Risiko des jeweiligen Anwendungsfalls abhängen.
Identity Resolution gilt im CX-Markt als das schwierigste DatenproblemFür Konfliktfälle muss festgelegt sein, welche Quelle Vorrang hat und wer Ausnahmen entscheidet. Survivorship-Regeln bestimmen zusätzlich, welches Attribut als aktuell oder führend gilt: welche Telefonnummer, welche Adresse, welcher Account die führende Hierarchie hat.
Master-Profile vs. Use-Case-Features
Nach der Identitätsauflösung muss entschieden werden, welche Daten Teil des kanonischen Kundenprofils sind.
Das Master-Profile, in der MDM-Welt auch Golden Record genannt, enthält Identität, Hierarchie, Stammdaten, Mappings und Consent. Nachgelagerte Systeme sollten diese Informationen nicht jeweils neu definieren. Use-Case-Features wie Scores, Segmente, Rankings und Verhaltensaggregate werden häufiger neu berechnet. Solche Größen sollten in spezialisierten Feature- oder Use-Case-Tabellen verwaltet werden. Das kanonische Profil sollte nicht bei jeder Modelliteration sein Schema ändern.
Die Trennung verhindert einen typischen Anti-Pattern: das überladene Kundenobjekt. In Reviews finden sich regelmäßig sehr breite Kundentabellen mit Stammdaten, Aggregaten, Scores und experimentellen Features. Solche Objekte werden mit der Zeit schwer wartbar und unklar in ihrer Verantwortung. Neue Modelle oder Featureversionen können regelmäßig neue Spalten und Abhängigkeiten erzeugen. Jede Stewardship-Entscheidung muss zwischen Identität und Score abwägen, jeder Downstream-Konsument muss vorsichtig wählen, welche Spalten er ziehen darf. Mehrere spezialisierte Tabellen erhöhen zwar die Zahl der Verknüpfungen, erleichtern aber Versionierung, Ownership und den gezielten Zugriff auf relevante Daten.
Governance für das gemeinsame Kundenprofil
Ein Customer-360-Modell bündelt zahlreiche sensible und personenbezogene Informationen. Dadurch ist es besonders relevant für Auskunft, Berichtigung, Löschung und Audit.
Ein Lakehouse-Setup verankert diese Governance im Katalog. Auf Databricks kann Unity Catalog Zugriffssteuerung, Tags, Lineage und Auditinformationen zentral unterstützen: Berechtigungen auf Spalten- und Zeilenebene, Lineage von Quelle bis Aktivierung, Audit-Logs über Zugriffe. Welche Policies tatsächlich automatisch wirken, hängt von Konfiguration, Zugriffspfad und unterstützten Objekten ab. Bei vollständigen Metadaten und Logs lassen sich viele Zugriffs- und Herkunftsfragen nachvollziehbar beantworten, etwa „Wo liegt das Profil von Kunde X, wer hat es in den letzten 90 Tagen gelesen, in welche Modelle ist es eingeflossen?" Fehlt eine konsistente Datenherkunft, müssen abhängige Tabellen und Systeme bei Löschanfragen häufig manuell identifiziert werden.
Zwei Themen verdienen besondere Aufmerksamkeit. Erstens sollte Consent mit Kanal, Zweck, Gültigkeitszeitraum und Quelle dokumentiert werden. Zweitens erzeugt jede Aktivierung in einem weiteren System zusätzliche Kopien oder Verarbeitungspfade personenbezogener Daten. Mit jedem zusätzlichen CRM-, Marketing- oder Serviceziel steigt der Aufwand für Löschung, Zugriffskontrolle und Nachweis. Modulare Architekturen benötigen deshalb ein klares Verzeichnis aller aktiven Datenflüsse und Zielsysteme.
Eigene 360 oder CDP: welcher Weg passt?
Für Customer 360 gibt es drei verbreitete Architekturansätze, mit klar unterschiedlichen Trade-offs.
| Variante | Stärke | Schwäche | Wann sinnvoll |
|---|---|---|---|
| Lakehouse-360 (eigene Schicht) | Kontrolle über Datenmodell, Governance in Unity Catalog, ML-Integration | Für operative Kanäle werden zusätzliche Connectoren, APIs oder Reverse-ETL-Werkzeuge benötigt | Plattform-zentrierte Organisationen, viele ML-Use-Cases, klare Plattform-Verantwortung |
| Packaged CDP (Segment, mParticle, Adobe RT-CDP) | schnell verfügbare Profile, Fachanwenderfunktionen und Aktivierungsconnectoren | zusätzliche Anbieterabhängigkeit, Datenkopien, Grenzen bei eigenen ML-Prozessen | Marketing-getriebene Organisationen mit hohem Aktivierungsbedarf, niedrige Latenz-Anforderungen |
| Hybrid (Lakehouse + CDP) | analytisches Profil im Lakehouse, Aktivierung in der CDP | ohne klare Verantwortungsgrenzen können wieder parallele Profile und Matchregeln entstehen | Enterprise-Setups mit getrennten Analytics- und Marketing-Teams, hohe Anforderungen an beides |
- Volle Datenkontrolle
- Unity Catalog Governance
- Reverse ETL für Aktivierung
- Analytisch im Lakehouse
- Operativ in der CDP
- Echtzeit-Profile
- Connector-Sets nativ
Die Detailabwägung CDP vs. Lakehouse mit Reverse ETL vertiefen wir an anderer Stelle. Hier reicht die strukturelle Beobachtung: Die zentrale Frage lautet, welches System das führende Profil verwaltet. Davon getrennt sollte festgelegt werden, welche Systeme Segmente und Scores konsumieren. Ein einzelnes System für Datenhoheit und Aktivierung kann Prozesse vereinfachen, führt aber je nach Wahl zu stärkerer Anbieterabhängigkeit oder höherem Eigenentwicklungsaufwand.
Unsicher, ob Lakehouse, CDP oder Hybrid zu eurer Architektur passt?
Wie landet das 360-Profil in CRM und Marketing?
Ein Kundenprofil erzeugt erst dann Geschäftswert, wenn es in operativen Prozessen genutzt wird. Drei Patterns haben sich etabliert.
Reverse ETL
Überträgt ausgewählte Profile, Segmente oder Scores aus dem Lakehouse in CRM- und Marketing-Systeme, etwa über Hightouch. Das führende Profil bleibt in der eigenen Datenplattform, dafür sind Aktualisierung und Zielsystemverarbeitung häufig nicht vollständig echtzeitfähig.
Operative CDP-Aktivierung
Eine CDP übernimmt zeitkritische Profile, Trigger und Personalisierung, etwa Cart-Abandonment oder In-App-Personalisierung. Konkrete Latenzen hängen von Produkt, Region, Integration und Last ab.
API-First
Eine API-basierte Architektur stellt ausgewählte Profilinformationen direkt für Anwendungen bereit. Für niedrige Latenzen braucht es meist einen zusätzlichen Online Store oder Cache neben dem analytischen Lakehouse.
Der passende Aktivierungsweg hängt von Aktualität, Kanal, Last und Governance ab. Für nächtliche oder stündliche Aktivierung kann Reverse ETL ausreichen. Für interaktive Personalisierung oder Entscheidungen im Request-Pfad wird meist eine latenzarme Serving-Komponente benötigt. Ein Customer-360-Modell ohne definierte Konsumenten erzeugt vor allem Betriebs- und Pflegeaufwand.
Warum Customer 360 oft an Datenqualität, Silos und fehlender Nutzung scheitert
Drei Muster treten in laufenden Customer-360-Programmen häufig auf.
Das 360-Cockpit als Projektziel
Ein Dashboard wird zum sichtbaren Projektziel, obwohl die zugrunde liegenden Kundenbegriffe weiterhin uneinheitlich sind. Die Oberfläche bündelt Informationen, löst aber keine Identitäts- oder Ownershipfragen.
Identity Resolution als Tool-Kauf
Ein MDM- oder Matching-Werkzeug wird eingeführt, bevor Matchregeln und Stewardship geklärt sind. Die Qualität der Ergebnisse hängt weiterhin von fachlichen Regeln und Konfliktentscheidungen ab, primär eine Business-Regel, sekundär eine technische Frage.
Die Über-360-Tabelle
Alle Kundendaten, Events und Scores landen in einer einzigen Tabelle. Mit wachsender Zahl von Features und Konsumenten wird das Objekt schwer wartbar. Stattdessen: Master-Profile schlank halten, alles andere in spezialisierten Tabellen oder einem Feature Store.
Dazu kommt eine vierte, leise Falle: Das Modell wird aufgebaut, ohne konkrete Folgeanwendungen festzulegen. Tatsächlich ist 360 die Voraussetzung für die nächsten Schritte: Kundensegmentierung, CLV-Modellierung, Churn-Prediction, Next Best Action. Ohne Segmentierung, Churn, Aktivierung oder Reporting bleibt der Nutzen gering.
Grenzen
Kein Ersatz für Kundenstrategie
Ein 360-Aufbau lohnt erst, wenn die Customer-Intelligence-Strategie steht und konkrete Konsumenten benannt sind. Ohne definierte Entscheidungen erzeugt auch ein vollständiges Profil keinen zusätzlichen Geschäftswert.
Grenzfälle bleiben trotz guter Modelle
Unsichere oder widersprüchliche Zuordnungen bleiben bestehen, da Datenqualität, Identifier und Geschäftsmodell stark variieren. Für Grenzfälle braucht es klare Eskalations- und Stewardship-Prozesse.
Mehr Quellen erhöhen Compliance-Aufwand
Mit jeder zusätzlichen Datenquelle steigen die Anforderungen an Zweckbindung, Löschung und Auskunft. Datenminimierung ist eine bewusste Designentscheidung: Welche Daten gehören wirklich ins Master-Profile, welche reichen als verlinkter Verweis.
Auch Standardprodukte brauchen Implementierungsaufwand
Vorkonfigurierte Produkte benötigen trotzdem eigene Datenmodelle, Matchregeln, Berechtigungen und Integrationen. Die Dauer hängt stark von Datenlage, Quellsystemen und organisatorischer Vorbereitung ab.
Branchenzahlen zur Verbreitung einer vollständigen Kundensicht sollten nur mit aktueller und belastbarer Quelle verwendet werden.
Fazit
Customer 360 ist ein Datenmodell-Programm für Identität, Profil, Verhalten und Kontext, kein Dashboard-Projekt.
Customer 360 legt fest, welche gemeinsame Kundendefinition für Analytics, ML und Aktivierung gilt. Die Grundlage bilden getrennte Bereiche für Identität, Profil, Verhalten und abgeleitete Signale. Berechtigungen, Ownership, Lineage und Consent sollten zentral verwaltet werden. Zusätzlich braucht es definierte Wege in CRM, Marketing, Service und operative Anwendungen.
Ob ein Customer-360-Programm funktioniert, hängt vor allem von Datenmodell, Identity Resolution, Governance, Ownership und tatsächlicher Nutzung ab. Ein Dashboard macht Kundendaten sichtbar, schafft aber noch keine gemeinsame Datenbasis. Eine reine Produktentscheidung überlässt zentrale Modellfragen dem jeweiligen Anbieter. Ein sauber definiertes Datenmodell schafft dagegen eine wiederverwendbare Grundlage für weitere Customer-Intelligence-Anwendungen.
Der erste Schritt sollte eine fachliche Skizze des Kundenobjekts und seiner Beziehungen sein:
- Welche Daten gehören zu Identität, Profil, Verhalten und Kontext?
- Welche Match-, Konflikt- und Survivorship-Regeln gelten?
- Welche Attribute sind kanonisch und langfristig stabil?
- Welche Scores und Aggregate werden getrennt für einzelne Anwendungen berechnet?
- Welche Systeme konsumieren Profile, Segmente und Entscheidungen?
Erst danach lässt sich sinnvoll entscheiden, welche Teile selbst gebaut und welche als Produkt bezogen werden.
Erster Schritt: Kundenobjekt und Beziehungen fachlich skizzieren, bevor Tools ausgewählt werden.
Passt eine eigene 360-Schicht zu eurer Architektur?
Ob eine Customer-360-Schicht im Lakehouse zu eurer Daten- und Aktivierungsstrategie passt oder ob eine CDP beziehungsweise eine hybride Architektur geeigneter ist, lässt sich in einem strukturierten Data-&-AI-Assessment bewerten.
- Welche Quellsysteme verlässliche Identifikatoren und führende Stammdaten liefern
- Welche Match-, Konflikt- und Hierarchieregeln benötigt werden
- Welche Anforderungen aus Datenschutz, Consent, Audit und Berechtigungen berücksichtigt werden müssen
- Welche Kombination aus Lakehouse, CDP und Aktivierungskomponenten zur Roadmap passt
FAQ
Customer 360 ist eine gemeinsame Kundendefinition, die Identität, Profil, Verhalten und abgeleitete Signale miteinander verbindet. Sie stellt eine konsistente Datenbasis für Segmentierung, CLV, Churn, Reporting und Aktivierung bereit. Produkte und Visualisierungen können dieses Modell unterstützen oder konsumieren, ersetzen es jedoch nicht.
