Der Golden Record – wirklich so wichtig, wie alle sagen?

Heutzutage stolpert man immer wieder über Begriffe wie Customer Data Platform oder auch Customer 360. Das Konzept ist schnell klar: Es geht um einen einheitlichen und vollständigen Blick auf den Kunden. Das heißt, alle wichtigen Informationen zentral verfügbar und auf einen Blick (oder auch zwei) sichtbar.

Die Theorie klingt einfach. Ich ziehe einfach alle Informationen zu einem Kunden zusammen, speichere sie und biete eine Visualisierung der Daten – ob in Diagrammen oder Tabellenform. Dass es oftmals schon an dem Zusammenziehen (der Integration) scheitert, lassen wir hier außen vor. Nehmen wir jetzt an, dass die Integration realisiert ist, z.B. mit der Marini Integration Platform, dann steht man vor der nächsten Herausforderung: der Bildung des Golden Records. Denn dieser ist untrennbar mit einer Customer Data Platform verbunden. Der Golden Record führt die verfügbaren Daten einer Entität (z.B. Person oder Firma) zusammen. Aber von Anfang an.

Das altbekannte Problem: Datensilos

Liegen Kundendaten verteilt über viele Systeme, (z.B. CRM, ERP, E-Commerce, Marketing Automation) dann zeigt jedes System einen lediglich unvollständigen Blick auf die theoretisch verfügbaren Daten. Der Fokus liegt erst einmal auf Stammdaten, welche zusammengeführt und konsolidiert werden. Stammdaten fassen Daten zusammen, welche zur regelmäßigen Verarbeitung eines Datensatzes notwendig sind und sich nicht häufig ändern. Beispiele für Stammdaten eines Kontaktes: Vorname, Nachname, Adresse, Geschlecht. Beispiele für eine andere Entität wie die eines Produktes: Bezeichnung, Beschreibung, Kategorie. Das Management der Stammdaten nennt man auch Master Data Management (engl. für Stammdaten-Management). Häufig gibt es eigene Systemtypen, sogenannte Master Data Management Systeme, für die Zusammenführung und Konsolidierung von Stammdaten.

Führt man die Stammdaten einer Entität aus mehreren Systemen zusammen, werden diese in einem Golden Record verdichtet. Dieser Golden Record vereint nun Daten aus mehreren Quellen, welche sich auf das gleiche reale Objekt beziehen (z.B. auf die gleiche Person, die gleiche Firma). Uniserv bezeichnet den Golden Record auch als den eindeutigen Datensatz. Der Golden Record wird mit einer Persistent ID (PID) versehen. Diese dient der eindeutigen Identifizierung eines Objekts aus der realen Welt (z.B. Kontakt, Firma etc.). Die PID kann nun in die verschiedenen Quellsysteme zurückgespielt werden, aus welchen die Daten zusammengezogen wurden. Dadurch können auch über Systeme hinweg eine Person oder Firma eindeutig identifiziert werden, da z.B. Informationen wie Namen nicht eindeutig sein können. Nehmen wir folgendes Beispiel:

Beispiel für verteilte Stammdaten über verschiedene Systeme

Obige drei Datensätze würden nun zu einem Golden Record zusammengeführt werden, da sie sich auf das gleiche Objekt (in unserem Fall eine Person) in der realen Welt beziehen, nämlich auf John Müller von Marini Systems. Im nächsten Schritt würde diesen drei Datensätzen die gleiche PID zugeordnet werden, sodass man den Datensatz über das ERP, CRM und die Marketing Automation hinweg eindeutig als denselbigen identifizieren kann. Jetzt sind die Stammdaten der verschiedenen Systeme, welche im Unternehmen eingesetzt werden, nicht mehr isoliert. Das Management der Stammdaten (Master Data Management) kann nun zielgerichtet erfolgen. Ein nächster logischer Schritt wäre z.B. die Daten zu vereinheitlichen oder in einem zentralen System (CDP, EDP, MDM) zusammenzuführen.

Vom Golden Record zur Customer 360

Neben Stammdaten (engl. Master Data) gibt es noch den Typ der Transaktionsdaten. Transaktionsdaten werden häufig auch als Bewegungsdaten bezeichnet. Im Gegensatz zu Stammdaten, welche sich tendenziell nicht häufig ändern (d.h. eher schwerfällig in ihrer Veränderung sind), sind Transaktionsdaten dynamisch. Transaktionsdaten speisen sich aus wortwörtlich aus einer Transaktion. Das kann im Kontext von Personendaten vieles bedeuten wie z.B.:

• der Kauf eines Produkts
• der Besuch einer Webseite
• das Abonnement eines Newsletter
• die Anmeldung zu einem Webinar
• eine Produktbeschwerde

Generell gesprochen, subsumieren wir hier Interaktionen (an Touchpoints) mit dem Kunden (B2B oder B2C), welche als Daten erfasst werden.

Wird der Golden Record nun mit Transaktionsdaten angereichert, sprechen wir auch von Customer 360. Man erhält einen 360 Grad-Blick auf den Kunden. Alle Informationen, welche man über den Kunden gesammelt hat, sind auf einen Blick verfügbar: im Golden Record, welcher ein ganzheitliches Kundenprofil abbildet. Die Sicht auf ein solches Profil wird über Customer Data Plattformen realisiert. Mit einer solch holistischen Sicht, lassen sich fundiertere Marketing- und Vertriebsaktionen auslösen. Der Kunde rückt in den Fokus und das Unternehmen kann kundenzentrierter agieren und somit seinen Erfolg steigern.

Wenn Datensätze (Records) nun zu einem Golden Record zusammengeführt werden sollen, stellt sich die Frage, anhand welches Kriteriums über eine Zusammenführung entschieden werden soll. Wir sprechen hier von Record Linkage. Zwei Records werden einander zugeordnet, weil sie sich auf das gleiche Objekt in der realen Welt beziehen. Dabei bestehen drei Möglichkeiten.

1. Wenn-Dann-Regelwerk
2. Machine Learning (wahrscheinlichkeitsbasiert)
3. Eine Kombination aus 1. und 2.

Wenn-Dann-Regelwerk

Die einfachere, aber nicht immer mögliche Variante, ist ein Wenn-Dann-Regelwerk. Es werden Regeln festgelegt, wann Records einander zugeordnet werden. Der einfachste Fall zieht ein Feld des Records in Betracht. Beispielsweise könnte man zwei Records einander zuordnen, wenn ihre E-Mail-Adressen übereinstimmen. Dies ist jedoch nicht immer eindeutig. Denken wir daran, dass Ehepaare E-Mail-Adressen teilen können, Kinder die E-Mail-Adresse ihrer Eltern nutzen, in Unternehmen Sammeladressen (z.B. wie info@marini.de) genutzt werden oder das Sekretariat die Adresse des Chefs nutzt. So entstehen ausreichend Fälle, in denen das einfache Regelwerk „gleiche E-Mail-Adresse“ nicht mehr genügt bzw. die Gefahr einer großen Unschärfe mit sich bringt.

Daher werden oftmals mehrere und kombinierte Regeln genutzt, d.h. ein Regelwerk gebildet. Dieses ist anwendungs- und unternehmensspezifisch zu bilden und erfordert neben Domänenwissen auch unternehmensspezifisches Wissen. So könnte ein einfaches Regelwerk lauten: Wenn Nachname und E-Mail-Adresse oder Vorname, Nachname und Straße übereinstimmen, dann werden die Records einander zugeordnet. Es wird jedoch klar, dass die Ausarbeitung des Regelwerks auf gesundem Menschenverstand basiert und schwerlich validiert werden kann.

Machine Learning

Ein Nachteil jedes Wenn-Dann-Regelwerks liegt darin, dass Felder gleich sein müssen. Wenn dieses und/ oder jenes Feld gleich sind, dann werden die Records gelinkt. Dahingegen kommt bei einer Machine-Learning-Lösung sogenanntes „fuzzy matching“ zum Tragen. Für jedes Feld zweier Datensätze wird ein Distanzmaß berechnet. Je nach Datentyp können verschiedenste Distanzmaße eingesetzt werden, z.B.

• String: Jaro-Winkler, Levenshtein, Jaccard
• Datum: Differenz in Tagen
• Integer: Differenz
• Boolean: Dummy-Variable

Diese werden dann klassisch als Features in einem Machine Learning Modell (Support Vector Classifier eignen sich beispielsweise gut für diese Fragestellung) verwendet. Der Nachteil bei diesem Ansatz ist, dass man einen Trainingsdatensatz mit gelabelten Daten benötigt (vgl. supervised learning). Ist das Modell trainiert, kann es für Paare neuer Datensätze eine Wahrscheinlichkeit vorhersagen, dass diese gleich sind. Basierend auf der Wahrscheinlichkeit könnte automatisiert ab einem bestimmten Schwellenwert zugeordnet werden. Alternativ können die Vorschläge auch manuell gelinkt werden, um eindeutigere Ergebnisse zu erzielen.

Record Linkage mithilfe von Machine Learning hat den Vorteil, dass auch nicht exakt gleiche Datensätze gematcht werden können. Theoretisch müsste kein Feld genau gleich sein, wenn die insgesamte Ähnlichkeit ausreichend hoch ist, würde der Algorithmus eine entsprechend hohe Wahrscheinlichkeit ausgeben. So würde den Strings Kaiserstraße 57, Kaiserstr. 57 und Kaiser Straße eine hohe Ähnlichkeit ausgestellt. Trotz unterschiedlicher Schreibweisen wird berücksichtigt, dass die Schreibweisen sehr ähnlich sind.

Der Fall eines Record Linkages birgt jedoch viele weitere Herausforderungen wie hinreichende Blocking-Regeln (aus Performance-Gründen), transitive Zuordnung, Klassen-Imbalance oder eine hinreichende Menge an Trainingsdaten.

Wenn-Dann-Regelwerk + Machine Learning

Selbstredend können auch beide Ansätze von oben kombiniert werden. So kann eine Wahrscheinlichkeit mittels Machine Learning berechnet werden und als Vorselektierung dienen, wonach erst eine Regel angewendet wird. Generell ist bei einer Automation immer der Trade-Off zwischen Falsch-Positiven und wenigen Positiven zu beachten. Je laxer die Regeln oder die Matching-Wahrscheinlichkeit desto mehr Falsch-Positive-Fälle (also Datensätze, welche fälschlicherweise zugeordnet wurden). Auf der anderen Seite, je strenger die Regeln oder die Schwelle der Wahrscheinlichkeit, desto weniger gleiche werden gefunden.

Persistent Identifier

Seien, mit einer der obigen Methode, Records nun zugeordnet, wird dem Golden Record, der die zugeordneten Records subsumiert, eine PID zugeordnet. Die PID führt gleiche Entitäten über verschiedene Systeme durch eine ID mit einer 1:n Relation zusammen. Einer PID sind eine oder mehrere IDs (aus verschiedensten Systemen, quasi die Source-IDs) zugeordnet. Die PID erlaubt nun eine eindeutige Identifizierung eines Objekts (wie einer Person) über die komplette Systemlandschaft.

Integrationen ist inhärent, dass, sobald Daten von einem System in ein anderes übertragen werden, (besonders, wenn Stammdaten übertragen werden) zwangsläufig Dubletten entstehen. Dieses Problem gilt es zu adressieren. Der Golden Record ist die Antwort darauf. D.h. sobald Stammdaten integriert werden, ist die Bildung eines Golden Records zu empfehlen.

Datenredundanzen verursachen verteilte Informationen und dadurch Informationsverlust. Daraus resultieren Kosten. Datenintegration mit Golden Records (und der Bildung einer PID) kontert Datenredundanzen und unvollständige Daten.

Für die Entität „Account“ übernimmt z.B. der Datenanbieter Dun & Bradstreet das Record Linkage mit dem Ausliefern der sogenannten DUNS (der PID für Accounts von D&B). So können nicht nur Dublikate bei Accounts erkannt werden, sondern der einzelne Datensatz kann noch um zahlreiche Daten angereichert werden wie z.B. um Risk oder Financial Data. Zudem werden die Daten durch D&B validiert, d.h. Inkonsistenzen wie Schreibweisen bei der Straße werden angeglichen.

Fazit

Der Golden Record rückt immer mehr in den Fokus – besonders in der heutigen Systemlandschaft in Unternehmen. Stammdaten und dazugehörige Transaktionsdaten liegen verstreut in Silos. Der Golden Record ist der Versuch, all diese Daten zu vereinen und somit einen ganzheitlichen Blick auf den Kunden zu ermöglichen – Customer 360. Möchte ich einen vollständigen Blick auf meinen Kunden, führt am Golden Record kein Weg vorbei. Und sogar in einem vorherigen Schritt, sobald ich Stammdaten aus verschiedenen Quellen integriere, ist es ratsam einen Golden Record zu bilden und somit Duplikate aufzulösen. Denn Datenredundanz ist kostenintensiv und vertriebshemmend!