Eine einheitliche Kundensicht über CRM, Marketing und Analytics aufbauen

Von Steven Renwick, CEO & Mitgründer von Tilores.

Kurzfassung: Bauen Sie eine einheitliche Kundensicht auf, indem Sie Datensätze aus CRM-, Marketing-, Analytics- und Warehouse-Systemen aufnehmen, die Identität beim Ingest auflösen, ein Profil mit Lineage speichern und jedes nachgelagerte System den aktuellen aufgelösten Kontext abfragen lassen, statt Kunden separat abzugleichen.

Bauen Sie sie mit Ihren Daten: Buchen Sie eine Demo, um Identity Resolution über CRM, Marketing und Analytics hinweg zu sehen, oder holen Sie sich den Evaluation Build, um sie lokal zu testen – und werfen Sie anschließend einen Blick auf die Tilores Entity Resolution Software und ihre Referenz zur Echtzeit-GraphQL-API.

Wie baut man eine einheitliche Kundensicht Schritt für Schritt auf?

Die Reihenfolge ist überschaubar, entscheidend ist die Abgrenzung. Die Identitätsebene sollte Profile auflösen und aktualisieren, sobald Datensätze eintreffen. CRM, Marketing und Analytics fragen anschließend das aktuelle Profil ab, statt jeweils eigene Merge-Logik zu betreiben.

1. Quelldatensätze inventarisieren. Listen Sie jedes System auf, das Kundendaten erzeugt oder verändert: CRM-Kontakte und -Leads, Kontakte aus der Marketing Automation, Nutzer-IDs aus der Produktanalyse, Supportdatensätze, Abrechnungsdatensätze und Warehouse-Tabellen.
2. Den Profilvertrag definieren. Entscheiden Sie, welche Felder ins aufgelöste Profil gehören, welche quellspezifisch bleiben, welchen Identifikatoren Sie vertrauen und welche Systeme welchen Wert lesen oder schreiben dürfen.
3. Identität beim Ingest auflösen. Übergeben Sie jeden neuen oder geänderten Quelldatensatz an die Identity-Resolution-Ebene und verbinden Sie mit deterministischen Regeln, probabilistischem Matching und Fuzzy Matching die Datensätze, die dieselbe Person oder dasselbe Konto repräsentieren.
4. Ein aufgelöstes Profil mit Lineage speichern. Speichern Sie das aufgelöste Kundenprofil als eine Entität, die aus vielen Datensätzen besteht, und bewahren Sie zugleich die IDs der Quelldatensätze, die Match-Belege, die Merge-Historie und den Löschpfad.
5. Den aktuellen Kontext zur Abfragezeit abrufen. Wenn CRM, Marketing oder Analytics Kundenkontext benötigt, fragen Sie das aufgelöste Profil ab, statt die Entität in der nutzenden Anwendung erneut aus Rohdatensätzen aufzubauen.
6. Identifikatoren mit Bedacht zurückspielen. Synchronisieren Sie stabile Profil-IDs oder ausgewählte Attribute nur dort zurück in die Quellsysteme, wo sie Prozess, Attribution oder Aktivierung verbessern – ohne jedes System in einen weiteren Master zu verwandeln.
7. Einwilligung, Zugriff und Löschung als vollwertige Abläufe betreiben. Behandeln Sie Auskunftsersuchen, Löschungen, Einwilligungsänderungen und Auditfragen als Produktanforderungen und nicht als Aufräumarbeiten, nachdem die Identitätsebene live ist.

Was ist eine einheitliche Kundensicht?

Eine einheitliche Kundensicht ist ein aufgelöstes Profil für einen Kunden oder ein Konto, gebildet aus den Datensätzen, die ihn systemübergreifend beschreiben. In der Sprache des Datenmanagements sind das Identity Resolution, Entity Resolution oder Record Linkage, angewandt auf Kundenkontext. Es ist nicht bloß ein Dashboard, sondern der identitätsbewusste Kontext, den CRM, Marketing, Analytics und kundenseitige Anwendungen einheitlich nutzen können.

In der Praxis hat das Profil zwei Teile. Der erste ist die aktuelle Sicht: Namen, E-Mail-Adressen, Adressen, Kontoverknüpfungen, Lifecycle-Status, Einwilligungsfelder, Produktnutzung und weitere Attribute, die die nutzenden Systeme brauchen. Der zweite ist die Lineage: welche Quelldatensätze beigetragen haben, welche Regeln oder unscharfen Matches sie verbunden haben und wie ein Datensatz später korrigiert, aufgetrennt oder gelöscht werden kann.

Genau wegen dieser Lineage zählt Identity Resolution. Wenn zwei HubSpot-Kontakte, ein Salesforce-Lead, eine Nutzer-ID aus der Produktanalyse und eine Warehouse-Zeile dieselbe Person meinen, sollte die Antwort nicht davon abhängen, welches System Sie zuerst abfragen. Das aufgelöste Profil sollte diese Verbindung explizit machen.

Warum laufen CRM, Marketing und Analytics auseinander?

Sie laufen auseinander, weil jedes System für seine eigene Aufgabe optimiert ist. Die Salesforce-Dokumentation zu REST-Objekten beschreibt Objekte und Datensätze, die über sObject-APIs angesprochen werden. Die Dokumentation der HubSpot-CRM-Contacts-API beschreibt Kontaktdatensätze für Einzelpersonen und den Abgleich von Kontaktdaten mit anderen Systemen. Die GA4-Dokumentation zur User-ID beschreibt Nutzer-IDs, mit denen angemeldete Aktivität über Sitzungen, Geräte und Plattformen hinweg verbunden wird.

Das sind alles nützliche lokale Modelle. Aber es ist nicht dasselbe Identitätsmodell. Ein CRM kann Lead und Kontakt als getrennte Datensätze führen. Die Marketing Automation hält vielleicht noch eine alte E-Mail-Adresse. Die Produktanalyse sieht vor dem Login einen anonymen und danach einen bekannten Nutzer. Das Warehouse trägt historische Snapshots, die für die Analyse korrekt, für einen laufenden Prozess aber veraltet sind.

Die meisten Teams versuchen zunächst, das mit Exporten, Sync-Jobs und manuellen Merge-Regeln zu reparieren. Bei wenigen sauberen Datensätzen kann das funktionieren. Es scheitert, sobald Identifikatoren fehlen, E-Mail-Adressen wechseln, Namen falsch geschrieben sind, B2B-Accounts Tochtergesellschaften haben oder Datensätze fortlaufend aus mehreren Quellen eintreffen.

Die dauerhaftere Antwort ist, Identität als eigene Ebene zu behandeln. Die Quellsysteme machen weiter, was sie gut können. Die Identitätsebene nimmt ihre Datensätze entgegen, löst sie zu Entitäten auf und gibt jedem nutzenden Prozess denselben aktuellen Kundenkontext.

Wo gehört die einheitliche Kundensicht in der Architektur hin?

Die Architektur sollte zusammenführen und dann verteilen. CRM, Marketing Automation, Produktanalyse und Warehouse-Tabellen schicken Quelldatensätze in die Identity-Resolution-Ebene. Die Auflösung geschieht beim Ingest: Die Ebene normalisiert Felder, wendet exakte Regeln dort an, wo sie sicher sind, nutzt probabilistisches und unscharfes Matching für unsaubere Daten und aktualisiert die aufgelöste Entität.

Die nutzenden Systeme sollten die Entität nicht erneut zusammensetzen. Zur Abfragezeit rufen sie den aktuellen aufgelösten Kontext ab: die Entitäts-ID, die Quelldatensätze, ausgewählte Profilfelder, Match-Belege, Duplikate und alle Felder, die das Abfragemodell freigibt. Dadurch bleiben CRM, Marketing und Analytics im Gleichklang, weil sie alle von derselben aufgelösten Entität ausgehen.

Diese Abgrenzung hält auch den Betrieb sauber. Ändert sich ein Quelldatensatz, verarbeiten Sie diese Änderung einmal. Sollen zwei Datensätze getrennt werden, liegt die Split-Logik samt Verbindungshistorie in der Identitätsebene. Trifft ein Auskunftsersuchen nach Artikel 15 DSGVO ein, kann das Team nachvollziehen, welche Datensätze zu der Person gehören und welche Systeme sie beigesteuert haben.

Wo steht eine einheitliche Kundensicht neben CDP, MDM und Warehouse?

Eine Ebene für aufgelöste Identitäten steht neben CDP-, MDM-, Data-Governance- und Warehouse-Systemen. Sie ersetzt sie nicht. Eine CDP kann weiterhin Zielgruppen, Journeys und Aktivierung steuern. MDM kann weiterhin das übergreifende Betriebsmodell für Stammdaten definieren. Das Warehouse bleibt der richtige Ort für Analyse, Modellierung und historische Abfragen.

Die Identitätsebene hat eine engere Aufgabe: zu entscheiden, welche Datensätze denselben Kunden oder dasselbe Konto meinen, diese Entscheidung aktuell zu halten und den aufgelösten Kontext anderen Systemen bereitzustellen. Diese Enge ist nützlich. Sie erlaubt es einer Marketing-Journey, einem Vertriebsprozess, einem Analytics-Report und einem Support-Assistenten, von derselben Identitätsentscheidung auszugehen, ohne dass jedes System zum Master werden muss.

Besonders wichtig ist das bei unsauberen Daten. Deterministische Regeln sind wertvoll, wenn exakte Identifikatoren verlässlich sind. Probabilistisches und unscharfes Matching sind nötig, wenn Namen, Adressen, Telefonnummern und Kontodetails variieren. Die Tilores-Seite zu den Fuzzy-Matching-Algorithmen erklärt, warum flexibles Matching für echte Kundendaten nötig ist, und das Glossar zur Identity Resolution liefert das nötige Vokabular.

Wie unterstützt Tilores dieses Muster?

Tilores ist als dedizierte Ebene für Identity und Entity Resolution genau für diese Art zusammenführender Architektur gebaut. Quelldatensätze werden über die Referenz zur Tilores-GraphQL-API übergeben, wo die Submit-Mutation Datensätze hinzufügt und Entity-Queries aufgelöste Entitäten über Entitäts-ID, Datensatz-ID oder Suchparameter abrufen.

Die Dokumentation zur Schema-Anpassung von Tilores zeigt, wie sich das Ein- und Ausgabemodell für Datensätze an das Datenmodell des Kunden anpassen lässt. Für eine einheitliche Kundensicht ist das entscheidend, denn Datensätze aus CRM, Marketing Automation, Analytics und Warehouse teilen selten ein sauberes gemeinsames Schema.

Auch die Produktabgrenzung ist praxisnah. Tilores kann einen CRM-Prozess, einen Marketing-Aktivierungsfluss, einen Warehouse-Job oder eine Anwendung versorgen, die eine aktuelle Kundensicht braucht. Es steht neben den Systemen, die Sie ohnehin nutzen, statt so zu tun, als wäre es alle zugleich. Für den breiteren Produktkontext siehe die Seite zu den Tilores-Funktionen und den Leitfaden Wie Sie Ihr eigenes Identity-Resolution-System bauen.

Was sind die häufigsten Fehlermuster?

Das erste Fehlermuster ist, das Warehouse zum einzigen Ort zu machen, an dem Identität aufgelöst wird. Für Reporting kann das in Ordnung sein, aber operative Prozesse brauchen das aktuelle Profil oft, während der Kunde noch im Prozess ist. Reine Batch-Logik im Warehouse kann dazu führen, dass CRM-, Marketing- und Produktanwendungen auf veraltetem Kontext handeln.

Das zweite Fehlermuster ist, Merge-Logik in jedes nutzende System zu schieben. Wenn CRM, Marketing und Analytics jeweils eigene Matching-Regeln pflegen, werden sie irgendwann voneinander abweichen. Ein Prozess führt zwei Datensätze zusammen, die ein anderer getrennt hält. So wird aus einer Person drei verschiedene Kunden.

Das dritte Fehlermuster ist, Matching als eine Menge exakter Regeln und nicht mehr zu behandeln. Exaktes E-Mail-Matching ist nützlich, reicht aber nicht bei gewechselten Domains, alternativen Namen, Adressvarianten, gemeinsam genutzten Telefonnummern, Tochtergesellschaften oder Tippfehlern. Eine verlässliche einheitliche Kundensicht braucht deterministisches, probabilistisches und unscharfes Matching unter einem erklärbaren Modell.

Das vierte Fehlermuster ist, Governance zu vergessen. Artikel 4 DSGVO behandelt Kennungen wie Namen, Kennnummern, Standortdaten und Online-Kennungen als Teil des personenbezogenen Kontexts, sofern sie sich auf eine identifizierbare Person beziehen. Artikel 15 DSGVO gibt der Person ein Auskunftsrecht. Die Identitätsebene braucht deshalb von Anfang an Lineage, Zugriffskontrollen und Löschpfade.

FAQ

Was ist der Unterschied zwischen einer einheitlichen Kundensicht und einer CDP?

Eine einheitliche Kundensicht ist das aufgelöste Kundenprofil, das Ihre Systeme nutzen können. Eine CDP kann Marketing-Zielgruppen aktivieren und enthält oft Identitätsfunktionen; eine dedizierte Identity-Resolution-Ebene steht jedoch neben der CDP, wenn Matching-Tiefe, Erklärbarkeit oder Echtzeit-API-Zugriff stärker ausfallen müssen.

Sollte eine einheitliche Kundensicht im Warehouse gebaut werden?

Das Warehouse ist für Analyse und historische Modellierung nützlich, aber nicht immer die richtige Laufzeitebene für operative Identität. Wenn CRM, Marketing oder Analytics das aktuelle aufgelöste Profil während eines laufenden Prozesses braucht, lösen Sie Identitäten beim Ingest auf und fragen das aktuelle Profil über eine API ab.

Wann sollte Identity Resolution stattfinden?

Identity Resolution sollte stattfinden, wenn Quelldaten aufgenommen oder geändert werden. Die Abfragezeit dient dem Abruf des aktuellen aufgelösten Kontexts. Wenn jedes nutzende System sein eigenes Matching während der Abfrage ausführt, kann dieselbe Person in verschiedenen Prozessen unterschiedlich gematcht werden.

Welche Systeme sollten das aufgelöste Profil nutzen?

CRM, Marketing Automation, Produktanalyse, Support, Risikosysteme und Warehouse-Jobs können das aufgelöste Profil alle nutzen. Entscheidend ist die Abgrenzung: Sie nutzen dieselbe aufgelöste Identitätsebene, statt jeweils ein eigenes Matching-Modell zu pflegen.