Identity Resolution: Kundenidentitäten sicher zuordnen

Identity Resolution und Entity Resolution bezeichnen Verfahren zur Zuordnung verteilter Datensätze zu realen Entitäten. Dabei wird anhand verfügbarer Merkmale bewertet, ob Datensätze zur selben Person, Organisation oder einem anderen Objekt gehören. Bei ausreichend hoher Übereinstimmung werden die Quellsätze über eine gemeinsame Entitäts-ID verbunden. Identity Resolution umfasst Kandidatenbildung, Vergleichslogik, Schwellenwerte und Entscheidungen für unsichere Fälle. Verwandte Begriffe sind Record Linkage, Entity Matching und Duplicate Detection.

Damit liegt Identity Resolution unterhalb von drei Begriffen, mit denen es regelmäßig verwechselt wird. Die Abgrenzung ist keine Wortfrage, sie entscheidet, wo Verantwortung und Aufwand sitzen.

Ein Golden Record kann auf Identity Resolution aufbauen, bezeichnet aber den konsolidierten Datensatz und nicht die Zuordnungslogik selbst. Wie aus den verknüpften Records ein einziger führender Satz mit gewählten Attributen wird, klären wir im Überblick zum Golden Record.

Customer 360 nutzt die aufgelösten Identitäten, um Stammdaten, Transaktionen, Interaktionen und Scores zusammenzuführen. Diese Sicht setzt voraus, dass die Identitäten bereits sauber aufgelöst sind. Wie das Datenmodell für die einheitliche Kundensicht aufgebaut wird, zeigen wir im Überblick zu Customer 360.

Master Data Management umfasst neben Matching auch Governance, Stewardship, Hierarchien, Synchronisation und fachliche Pflege. Identity Resolution ist damit ein Baustein innerhalb eines umfassenderen Stammdaten- oder Customer-Data-Ansatzes.

Die Methode sollte nicht mit einer einmaligen Bereinigung einer Liste gleichgesetzt werden. Deduplizierung identifiziert doppelte oder ähnliche Datensätze innerhalb eines begrenzten Datenbestands. Identity Resolution muss neue und geänderte Datensätze laufend berücksichtigen. Ohne dauerhaften Betrieb entstehen mit neuen Quellen und Änderungen erneut fragmentierte Profile.

Vor allem regelbasierte, probabilistische und ML-gestützte Verfahren werden kombiniert, um Records zu vergleichen. Die Verfahren können nacheinander oder parallel eingesetzt werden. Produktive Lösungen nutzen häufig eine gestufte Logik, beginnend mit sicheren Regeln und anschließend komplexeren Vergleichen.

Deterministisches Matching verknüpft Datensätze über exakt übereinstimmende, ausreichend verlässliche Identifikatoren: gleiche Steuernummer, gleiche Kundennummer, gleiche verifizierte Mailadresse. Auch exakte Übereinstimmungen sollten nur dann als sicher gelten, wenn der Identifikator tatsächlich eindeutig, korrekt und nicht geteilt ist. Deterministische Regeln sind meist gut nachvollziehbar und können eine hohe Präzision erreichen. Bei Tippfehlern, fehlenden Werten, Formatunterschieden oder veralteten Attributen sinkt die Trefferquote. Die Methode eignet sich besonders für sichere, standardisierte Schlüssel.

Probabilistisches Matching bewertet die Übereinstimmung über mehrere Attribute und gewichtet deren Aussagekraft. Das etablierte Fellegi-Sunter-Modell gewichtet jedes Attribut danach, wie verlässlich eine Übereinstimmung ist und wie häufig sie zufällig auftritt: Seltene und stabile Merkmale können stärker gewichtet werden als häufige oder unsichere Attribute. Häufig vorkommende Namen oder geteilte Adressen sind allein nur schwache Hinweise. Dazu gehört unscharfes Matching, das Tippfehler und Namensvarianten toleriert. Die Methode ermöglicht eine feinere Abwägung zwischen Präzision und Recall. Gewichte, Vergleichsfunktionen und Schwellenwerte müssen auf den eigenen Datenbestand abgestimmt werden, und eine gute Konfiguration für eine Quelle oder Domäne ist nicht automatisch auf andere Daten übertragbar.

ML-gestützte Verfahren lernen aus bestätigten Match- und Non-Match-Beispielen oder nutzen semantische Repräsentationen. Sie können Namensvarianten, Abkürzungen und komplexere Muster erkennen, die mit einfachen Regeln schwer abzubilden sind. Ob ML tatsächlich bessere Ergebnisse erzielt, hängt von Trainingsdaten, Merkmalsqualität und Evaluation ab. Dafür entstehen zusätzlicher Aufwand für Labeling, Betrieb, Monitoring und Erklärbarkeit, und komplexere Modelle sind für Stewardship und Audit häufig schwieriger zu erklären. Ohne geeignete Schwellen, Testdaten und Reviewprozesse können auch ML-Modelle falsche Zusammenführungen erzeugen.

Ein praktisches Problem steckt im Mengengerüst. Ein vollständiger Vergleich aller Datensatzpaare wächst quadratisch mit der Datenmenge und ist bei großen Beständen meist nicht praktikabel. Blocking oder Candidate Generation reduziert die Zahl der zu vergleichenden Paare. Verglichen werden zunächst nur Datensätze, die ausgewählte gemeinsame Merkmale oder Schlüsselbereiche teilen, etwa dieselbe Postleitzahl oder die ersten Buchstaben des Namens. Erst innerhalb dieser Blöcke läuft das eigentliche, teure Matching. Die Kandidatenbildung beeinflusst sowohl Laufzeit als auch Trefferquote wesentlich: Zu enge Blöcke übersehen Matches, zu breite Blöcke erhöhen Rechenaufwand und Fehlerrisiko.

Am durchgängigen Beispiel: Der Shop-Record mit Tippfehler im Namen und alter Adresse, der CRM-Record mit Firmenname und einer zweiten Mailadresse, das Support-Ticket mit nur einer Telefonnummer. Im Beispiel reichen exakte Regeln nicht aus, weil kein eindeutiger Identifikator übereinstimmt. Ein probabilistisches Verfahren kann Namensähnlichkeit, Adresshistorie und Telefonnummer gemeinsam bewerten. Bei ausreichender Evidenz werden die drei Quellsätze über eine gemeinsame Entitäts-ID verbunden. Geteilte E-Mail-Adressen oder Telefonnummern zeigen, warum ein einzelnes Merkmal nicht automatisch als eindeutiger Schlüssel gelten darf.

Im B2B müssen neben Personen auch Accounts, Standorte, Rechtseinheiten und Konzernbeziehungen berücksichtigt werden. Ein Geschäftskunde kann aus Muttergesellschaft, Tochterunternehmen, Abrechnungseinheiten, Geschäftsbereichen und Ansprechpartnern bestehen. Identity Resolution muss diese Ebenen sauber auflösen und gleichzeitig die Beziehungen zwischen ihnen abbilden.

Ein umfassendes B2B-Datenmodell unterscheidet mehrere Hierarchie-Ebenen, von der obersten Muttergesellschaft über Abrechnungseinheiten und Geschäftsbereiche bis zu einzelnen Nutzern. Die Zahl und Ausprägung der Ebenen hängt vom Geschäftsmodell und den verwendeten Quellsystemen ab. Fehlende Hierarchien können Umsatz, Potenzial und Verantwortlichkeiten auf die falsche Unternehmensebene verschieben. Ein Standort kann beispielsweise fälschlich als eigenständiger Kunde statt als Teil eines Konzerns bewertet werden, sodass die Umsatz-Hochrechnung auf den Gesamtkonzern nicht stimmt und die Account-Strategie am tatsächlichen Entscheidungszentrum vorbeizielt.

Die zwei Fehlerrichtungen bekommen dadurch eine zweite Dimension. Auf Account-Ebene bedeutet Übermerge, rechtlich oder wirtschaftlich getrennte Organisationen unzulässig zusammenzufassen. Untermerge lässt verbundene Gesellschaften oder Ansprechpartner außerhalb des relevanten Accountzusammenhangs. Beides verfälscht die Kundensicht, nur auf einer Ebene, die im reinen B2C-Fall gar nicht existiert. B2B-Identity-Resolution benötigt getrennte Regeln für Personen, Accounts und Beziehungen zwischen den Entitäten.

Identity Resolution verbindet Datensätze, korrigiert aber nicht automatisch falsche oder veraltete Inhalte. Fehlerhafte Werte können auch im korrekt zugeordneten Cluster bestehen bleiben. Ein falsch erfasster Name, eine veraltete Adresse, ein vertippter Geburtstag bleiben falsch, auch wenn sie sauber dem richtigen Kunden zugeordnet sind. Validierung, Standardisierung und Korrektur gehören in einen ergänzenden Datenqualitätsprozess, der der Auflösung vorgelagert ist. Wie sich Datenqualität als Disziplin steuern lässt, klären wir im Überblick zur Data Governance.

Identity Resolution legt nicht fest, welche Attribute ein Kundenprofil enthalten oder wie Beziehungen modelliert werden. Welche Attribute eine Kundenentität überhaupt führt, wie die Kundensicht aufgebaut ist und welche Quellen einfließen, gehört in das Customer-360- oder Stammdatenmodell. Das Verfahren liefert die korrekten Verknüpfungen in dieses Modell hinein und erzeugt das Modell selbst nicht.

Unsichere Fälle benötigen häufig eine manuelle oder fachlich unterstützte Prüfung. Bei häufigen Namen und wenigen Zusatzmerkmalen kann eine sichere automatische Entscheidung unmöglich sein, etwa „John Smith" an einer Adresse ohne weiteres Merkmal. Diese Grenzfälle gehören aus dem automatischen Verfahren heraus in eine Review-Queue, die Belege, Matchscore, beteiligte Datensätze und Entscheidungsverlauf anzeigt. Vollständige Automatisierung sollte bei mehrdeutigen Datenbeständen kritisch geprüft werden, weil sie das Problem sonst nur verschiebt, bis es als Fehlmatch sichtbar wird.