Wie Sie Ihr eigenes Identity-Resolution-System bauen

Schritt für Schritt: So bauen Sie Ihr eigenes Identity-Resolution-System

Diese Schritte spiegeln die ursprünglichen Abschnitte dieses Leitfadens in der gleichen Reihenfolge wider; die vollständigen Details zu jedem Schritt folgen unverändert weiter unten.

1. Definieren Sie Ihre Anforderungen. Legen Sie die Anforderungen vorab fest – Datenquellen, Genauigkeit, Skalierbarkeit, Performance, Datenaktualität, Verfügbarkeit, Datenschutz-Compliance, Anpassbarkeit, Bedienbarkeit und Data-Science-Bedarf –, bevor Sie mit dem Bauen beginnen. Denn kleine Änderungen an den Anforderungen haben große Auswirkungen auf Design und Kosten.
2. Transformieren und normalisieren Sie die Daten. Identifizieren Sie die Datenbestände, die aufgelöst werden müssen, und standardisieren Sie sie durch Transformation und Normalisierung, sodass alle Felder ein einheitliches Format und eine einheitliche Struktur haben. Das erhöht die Matching-Qualität. Bei Adressen lohnt es sich, die Datensätze mit geografischen Koordinaten anzureichern.
3. Entwickeln Sie die Matching-Logik. Erarbeiten Sie ein Matching-Modell oder ein Regelwerk, das Verfahren wie Fuzzy Matching und geografisches Matching einbezieht, und verfeinern Sie es über mehrere Iterationen, bis es Ihre Genauigkeitsanforderungen erfüllt. Vorsicht: Das Matching ist der einfache Teil; die eigentliche Schwierigkeit der Identity Resolution im Unternehmensmaßstab liegt jenseits des Matchings.
4. Definieren Sie die Produktionsarchitektur. Entwerfen Sie das Produktivsystem entlang der Fragen Echtzeit oder Batch (und vermeiden Sie unechte Echtzeit), Sicherheit, Spitzenlasten bei eingehenden Daten, Verfügbarkeit, Back-up mit definierten RTO/RPO, Benutzeroberfläche und Dokumentation.
5. Bauen Sie die Schnittstellen für Datenein- und -ausgang. Erstellen Sie die Endpunkte zum Einlesen und Abfragen von Daten (GraphQL-APIs sind für IDR nützlich), ergänzen Sie eine SQL-ähnliche Schnittstelle für analytische Massenabfragen, stellen Sie Änderungsereignisse für vorgelagerte Systeme bereit und ermöglichen Sie Szenariosimulationen wie eine What-if-Machine.
6. Sorgen Sie für Compliance. Beziehen Sie Ihren Datenschutzbeauftragten von Anfang an ein und bauen Sie die zentralen Compliance-Funktionen ein: Löschung einzelner Datensätze, automatisierte zeit- und quellenbasierte Löschung, Verschlüsselung, granulare Zugriffssteuerung, automatische Erzeugung von Auskunftsersuchen (DSARs) und Erklärbarkeit, wie der Identity Graph zustande kam.
7. Rollen Sie das System aus. Setzen Sie auf ein Infrastructure-as-Code-Werkzeug wie Terraform statt auf manuelles Deployment, planen Sie ein Deployment ohne Ausfallzeit ein, falls das System durchgehend Daten aufnehmen und Abfragen beantworten muss, und betreiben Sie ein zweites, identisch konfiguriertes Testsystem für Performance- und Antwortzeittests.
8. Betreiben und pflegen Sie das System. Bleiben Sie innerhalb Ihrer SLAs: Führen Sie Failover-Tests durch, stellen Sie ein Betriebsteam samt Rufbereitschaft, weisen Sie nach, dass Sie innerhalb Ihrer RTO/RPO wiederherstellen können, und dokumentieren Sie Wiederherstellungen für Audits. Automatisieren Sie Auskunfts- und Löschersuchen oder besetzen Sie sie personell, damit sie innerhalb der gesetzlichen Frist beantwortet werden.

Anforderungen definieren

Beim Aufbau eines komplexen Systems ist es entscheidend, die Anforderungen vorab zu definieren, bevor man in das Projekt einsteigt. Kleine Änderungen an den Anforderungen können großen Einfluss auf das Design der Lösung und die Entwicklungskosten haben.

Datenquellen: Bestimmen Sie Art und Umfang der Datenquellen, die integriert und aufgelöst werden müssen. Überlegen Sie, ob aus der Datenquelle nur gelesen werden soll oder ob das IDR-System sie auch aktualisieren soll.

Genauigkeit: Legen Sie fest, welche Präzision der Identitätsabgleich für Ihre Anwendungsfälle erreichen muss. Wie konsistent oder sauber sind die Daten? Werden Datennormalisierung und Fuzzy Matching benötigt, um die Daten abzugleichen?

Skalierbarkeit: Schätzen Sie das mögliche Wachstum Ihrer Daten ein. Zwei Zahlen sind dabei interessant – die anfängliche Datenmenge und die Datenänderungen pro Tag (Aktualisierungen, Neuaufnahmen und Löschungen).

Performance: Definieren Sie Ihre Performance-Kriterien. Berücksichtigen Sie die Antwortzeiten der Suche für Identity Graphs unterschiedlicher Komplexität.

Datenaktualität: Entscheiden Sie, wie lange Aufnahme und Verarbeitung neuer Daten dauern dürfen. Wie viele Daten müssen möglicherweise parallel eingelesen werden?

Verfügbarkeit: Definieren Sie Ihre Anforderungen an dieses zentrale System. Handelt es sich um einen einmaligen Batch-Prozess, oder interagieren andere Prozesse synchron mit dem IDR-System?

Datenschutz-Compliance: Klären Sie, welche Datenschutzanforderungen Ihr IDR-System erfüllen muss. Beispiele sind DSGVO und CCPA.

Anpassbarkeit: Bewerten Sie Ihren Bedarf an individueller Anpassung und Integration in bestehende Systeme.

Bedienbarkeit: Brauchen Sie eine Benutzeroberfläche, über die Data Scientists oder Analysten einzelne Identity Graphs durchsuchen und prüfen können?

Data Science: Wollen Sie die im IDR-System vorgehaltenen Identity Graphs nutzen, um Machine-Learning-Modelle zu trainieren, etwa für die Betrugserkennung?

Transformation und Normalisierung

Beginnen Sie damit, die Datenbestände zu identifizieren, die aufgelöst werden müssen (Deduplizierung und Abgleich). Ob Namen, Adressen, Telefonnummern oder E-Mail-Adressen: Stellen Sie sicher, dass Ihr Datenteam auf diese Datenpunkte zugreifen kann und dass die Nutzung datenschutzrechtlich zulässig ist.

Der erste Schritt der Identity Resolution sollte Transformation und Normalisierung sein. Damit werden die erhobenen Daten standardisiert, sodass alle Datenfelder eine einheitliche Formatierung und Struktur haben. Dieser vorbereitende Schritt vereinfacht den Abgleich, indem er inkonsistente, uneinheitliche Daten in ein gemeinsames Schema überführt, und erhöht die Qualität des Matchings.

Wenn Sie mit Adressdaten arbeiten, sollten Sie die Adressen normalisieren und die Datensätze mit geografischen Koordinaten anreichern. So kann der spätere Abgleich auf geografischer Distanz beruhen statt auf Fuzzy Matching über Adress-Strings. Dafür benötigen Sie einen Dienst zur Adressnormalisierung sowie einen Dienst, der die geografischen Koordinaten jeder Adresse im betreffenden Gebiet kennt – selbst gebaut oder eingekauft.

Die Matching-Logik entwickeln

Erarbeiten Sie ein Matching-Modell oder ein Regelwerk, das den Auflösungsprozess steuert. Da Daten häufig Abweichungen und Inkonsistenzen enthalten, sollten Sie Verfahren wie Fuzzy Matching und geografisches Matching einbeziehen, um eine präzise Verknüpfung zu erreichen.

Es gibt eine große Zahl an Fuzzy-Matching-Algorithmen, die sich je nach Datenlage kombinieren lassen. Dieser Prozess sollte so lange fortgesetzt werden, bis Sie Ihre Genauigkeitsanforderungen erfüllen – Sie müssen das Matching also über mehrere Iterationen verfeinern, spezialisierte Bibliotheken für Ihren Anwendungsfall ergänzen und den Stichprobenumfang erhöhen.

Das Matching selbst kann sehr kompliziert werden, insbesondere im großen Maßstab. Geben Sie Ihrem Engineering-Team unbedingt unseren Leitfaden zur Komplexität von Entity Resolution zu lesen.

Achtung!

Engineering Manager, aufgepasst! Das ist die Phase, die leicht mehr verspricht, als sie hält. Es ist durchaus möglich, dass Ihr einsamer, tapferer Data Scientist innerhalb weniger Wochen im Alleingang ein völlig brauchbares Python-Skript entwickelt, das einen kleinen, statischen Datenbestand auf seinem eigenen Rechner dedupliziert.

Tatsächlich kann die Match-Rate einer Eigenentwicklung durchaus an die eines Enterprise-Identity-Resolution-Systems heranreichen. Doch so widersprüchlich es klingen mag: Der Matching-Teil der Identity Resolution ist wohl der „einfache" Teil. Die Schwierigkeit der Identity Resolution im Unternehmensmaßstab liegt jenseits des Matchings.

Nur die Mutigsten sollten weiterlesen …

Die Architektur des Produktivsystems definieren

Anforderungen, die Sie im Blick behalten sollten

Ihr Identity-Resolution-System ist die maßgebliche Wahrheitsquelle für Kundendaten. Jede Änderung in diesem System wirkt sich unmittelbar auf wichtige Entscheidungsprozesse aus.

Echtzeit vs. Batch

Muss Ihre Wahrheitsquelle für Kundendaten durchgehend aktuell sein? Identity Resolution wird deutlich einfacher, wenn das nicht der Fall ist, weil Sie die Daten dann in Batches aktualisieren können – Ihr System ist dann allerdings immer veraltet.

Wenn Sie die aufgelösten Kundendaten in Prozessen wie KYC, Betrugserkennung oder Echtzeit-Marketingpersonalisierung nutzen wollen, ist Identity Resolution in Echtzeit unverzichtbar.

Hüten Sie sich vor „unechter" Echtzeit – also davor, dass Anbieter häufige Batch-Aktualisierungen als Echtzeit bezeichnen. Echtzeit bedeutet im Sinne von Data Streaming, dass Daten in der Reihenfolge ihres Eingangs, sobald sie eingehen und ohne Verzögerung in Ihr Identity-Resolution-System aufgenommen werden. Die tatsächliche Verarbeitungszeit kann je nach Technologie zwischen wenigen Millisekunden und ein bis zwei Sekunden liegen – entscheidend ist, dass jeder Datensatz einzeln und der Reihe nach verarbeitet wird.

Vergessen Sie nicht: Ein Echtzeitsystem kann Batch-Daten verarbeiten, umgekehrt gilt das nicht.

Sicherheit

Angesichts seiner kritischen Rolle sind robuste Sicherheitsmaßnahmen unerlässlich. Das bedeutet, Folgendes zu berücksichtigen:

• verwaltete Zugriffssteuerung auf Daten auf API-Ebene
• Datenverschlüsselung
• kontinuierliche Systemüberwachung

Eingehende Daten

Je nach Anwendungsfall muss das Identity-Resolution-System stark schwankende Datenlasten bewältigen. Stellen Sie sicher, dass Ihr System die Spitzenlasten eingehender Datensätze verarbeiten kann – und gleichzeitig die Spitzenlasten bei Suchanfragen.

Idealerweise ist Ihr System zwar auf Lastspitzen ausgelegt, ohne dass Sie in Zeiten geringer Nachfrage für ungenutzte Server- oder Systemkapazität bezahlen.

Verfügbarkeit

Denken Sie daran: Ihr Identity-Resolution-System steht wahrscheinlich im Zentrum mehrerer geschäftskritischer Prozesse. Richten Sie es auf Ihre Verfügbarkeitsziele aus. Falls nötig, verteilen Sie es auf mehrere Rechenzentren mit jeweils eigenem Maschinencluster, um Ausfallzeiten bei Serverausfällen vorzubeugen.

Back-up

Back-ups von Identity-Resolution-Systemen sind alles andere als trivial: Beruht das System auf Echtzeit-Datenaufnahme, verändern sich die enthaltenen Identity Graphs permanent. Einen Zeitpunkt-Snapshot zu erzeugen, mit dem sich das IDR-System im schlimmsten Fall wiederherstellen lässt, ist für sich genommen schon eine erhebliche technische Herausforderung.

Definieren Sie die Recovery Time Objectives (RTO) und Recovery Point Objectives (RPO), die zu Ihren geschäftlichen Anforderungen passen. Entwickeln Sie von Anfang an einen belastbaren Backup- und Wiederherstellungsprozess, denn er hat großen Einfluss auf die Architektur Ihrer Lösung.

Benutzeroberfläche

Wahrscheinlich sind die Endnutzer Ihrer Identity Resolution andere Softwaresysteme, etwa Algorithmen zur Betrugserkennung oder eine Customer Data Platform (CDP). Je nach Anwendungsfall wollen Sie Analysten aber vielleicht trotzdem die Möglichkeit geben, Identity Graphs direkt zu untersuchen.

In diesem Fall brauchen Sie eine grafische Benutzeroberfläche (GUI), die die Identity-Graph-Daten zunächst in ihrem nativen Datenformat darstellen kann – also genau so, wie sie per API an ein anderes System ausgeliefert würden. Idealerweise sollten Sie zusätzlich einen visuellen Identity Graph anzeigen können, der die Datensätze und die Verbindungen zwischen ihnen (die wir Edges nennen) grafisch abbildet. Das erleichtert Analyse und Verständnis erheblich.

Eine „No-Code"-GUI vereinfacht außerdem die Konfiguration des Identity-Resolution-Systems und erlaubt es Personen ohne Software-Engineering-Hintergrund, die Matching-Regeln zu verbessern, ohne tatsächlich Code schreiben zu müssen. Das verringert die Abhängigkeit von der Engineering-Abteilung deutlich, die in der Regel stark ausgelastet ist.

Dokumentation

Vergessen Sie nicht, eine umfassende Dokumentation zu all dem zu schreiben! Wenn die Person, die die Identity-Resolution-Software Ihres Unternehmens entwickelt hat, das Unternehmen verlässt, muss jemand anderes Wartung und Weiterentwicklung übernehmen können – möglicherweise sehr kurzfristig.

Daten hinein und hinaus

Erstellen Sie je nach Anforderung die Endpunkte, über die Daten aufgenommen und abgefragt werden. Für Identity-Resolution-Systeme sind GraphQL-APIs recht nützlich, weil Sie nicht sämtliche Daten in eine Antwort packen müssen, sondern nur die tatsächlich benötigten. Das verringert zugleich Antwortzeiten, Last und Kosten.

Überlegen Sie außerdem, ob Sie Zugriff auf Massendaten aus Ihrer Identity-Resolution-Software brauchen. Wollen Sie Ihre Wahrheitsquelle für Kundendaten also nach „allen Kunden im Alter von 20 bis 30 Jahren mit Wohnsitz im Bundesstaat New York" abfragen können? Eine solche Abfrage eignet sich nicht für eine API – Sie brauchen dafür eine SQL-ähnliche Schnittstelle für analytische Abfragen.

Events

Ein IDR-System ist ein lebendiger Prozess, in dem sich die Daten permanent ändern. Es ist sinnvoll, Daten nicht nur abfragen zu können, sondern Änderungen auch per Event an andere Systeme weiterzugeben. Sobald eine Identität oder ein Datensatz geändert oder gelöscht wird, kann diese Information an vorgelagerte Systeme geschickt werden – was allerdings die Architektur des Systems zusätzlich verkompliziert.

Szenarien

Wenn Sie ein Identity-Resolution-System zum Trainieren von Machine-Learning-Modellen nutzen, ist es wünschenswert, zu simulieren, wie Ihre Identity Graphs unter anderen Bedingungen aussähen – etwa wenn Datenquelle C nicht verfügbar wäre oder Regel X anders lautete.

Herkömmlich müssten Sie dafür mehrere IDR-Systeme parallel betreiben, von denen jedes eines dieser Szenarien simuliert. Unsere bevorzugte Methode vermeidet diese Systemduplikate: Wir nennen sie die „What-if-Machine".

Compliance

Ein System, das als Wahrheitsquelle für Kundendaten dient, wird mit Sicherheit die Aufmerksamkeit des Datenschutzbeauftragten Ihrer Organisation auf sich ziehen. Beziehen Sie ihn daher von Anfang an in die Anforderungsentwicklung ein – sonst verschwenden Sie womöglich Zeit mit einem System, das sich nicht einsetzen lässt, ohne empfindliche Datenschutz-Bußgelder und Reputationsschäden zu riskieren.

Der schlimmste Fall ist, dass Sie ein Identity-Resolution-System entwickeln, das grundsätzlich nicht datenschutzkonform ist – zum Beispiel eines, in dem sich Daten gar nicht löschen lassen.

Die wichtigsten Compliance-Funktionen sind:

• die Möglichkeit, einzelne Datensätze in Identity Graphs zu löschen
• automatisierte Datenlöschung nach Datenquelle und Zeit
• Datenverschlüsselung
• granulare, nach Datenquellen differenzierte Zugriffssteuerung
• die Möglichkeit, Auskunftsersuchen betroffener Personen (DSARs) automatisch zu erzeugen
• Erklärbarkeit, wie der Identity Graph zusammengesetzt wurde (also warum Datensatz A und B verbunden sind)

Deployment

Wie bereits erwähnt, wird das Identity-Resolution-System ein fester Bestandteil Ihrer gesamten Dateninfrastruktur sein (des sogenannten „Modern Data Stack"). Da sich Datenschemata ändern und das Matching mit der Zeit nachjustiert werden muss, sollten Identity-Resolution-Systeme niemals manuell ausgerollt werden. Nutzen Sie stattdessen ein Infrastructure-as-Code-Werkzeug wie Terraform, das die Deployments für Sie verwaltet.

Bei vielen Identity-Resolution-Systemen laufen permanent Daten ein und werden permanent Suchanfragen gestellt. Das muss vor dem Deployment bedacht werden. Sind Ausfallzeiten akzeptabel, oder muss das System auch während des Deployments durchgehend Daten annehmen und Abfragen beantworten?

Vor dem Produktiveinsatz sollte die Identity-Resolution-Software getestet werden. Sie brauchen also ein zweites System mit derselben Konfiguration wie Ihr Produktivsystem, um Änderungen vor dem Go-live zu prüfen. Dieses System lässt sich zugleich für Performance-Tests nutzen und um zu prüfen, ob Ihre Antwortzeitanforderungen unter verschiedenen Bedingungen eingehalten werden.

Das Identity-Resolution-System betreiben

Sobald das IDR-System produktiv läuft, müssen Sie sicherstellen, dass es gewartet wird und innerhalb der definierten SLAs bleibt.

Je nach Anforderungen bedeutet das Failover-Tests innerhalb lokaler Cluster oder auch Failover-Tests über geografische Cluster hinweg. Es bedeutet außerdem, dass Sie ein Betriebsteam aufbauen (oder ein bestehendes nutzen) müssen, das Updates ausrollt, Störungen behebt und das System überwacht. Häufig gehört dazu auch eine Rufbereitschaft außerhalb der Geschäftszeiten.

Da kein System perfekt ist, können Daten beschädigt werden oder verloren gehen. Dafür haben Sie bereits RTO und RPO definiert. Jetzt gilt es zu beweisen, dass Sie das System innerhalb dieser Vorgaben wiederherstellen können. Weil diese Information für Audits relevant ist, sollten Sie durchgeführte Wiederherstellungen dokumentieren und die Protokolle für spätere Nachweise aufbewahren.

Identity-Resolution-Systeme verarbeiten häufig personenbezogene Daten. Damit unterliegen Sie strengen Vorschriften. Der größte Zeitaufwand entfällt üblicherweise auf Auskunfts- und Löschersuchen betroffener Personen. Da diese Anfragen innerhalb einer definierten Frist beantwortet werden müssen, sollten Sie den Prozess entweder automatisieren oder ein Team dafür benennen.

Kostenüberlegungen

Kalkulieren Sie die Kosten der Entwicklung eines Identity-Resolution-Systems ein: die Entwicklung der Logik durch ein Data-Science-Team, den Systembau durch ein Entwicklungsteam, das Hosting für Server bzw. Container und die Ressourcen für die Wartung. Planen Sie zusätzlich Mittel für Backup-Systeme und Redundanz in den Rechenzentren ein.

Je nach Design der Lösung steigen die Kosten über die Zeit, weil die Datenmengen wachsen und die Systemleistung nicht linear mit den Kosten skaliert.

Um Ihnen ein Gefühl für den nötigen Entwicklungsaufwand eines Enterprise-Identity-Resolution-Systems zu geben: Tilores wurde ursprünglich innerhalb einer mittelgroßen europäischen Verbraucher-Auskunftei entwickelt. Dort war man mit Identity-Resolution-Technologien bereits sehr erfahren und hatte vor Tilores schon mehrere Systeme gebaut. Dennoch dauerte die Entwicklung von Tilores umgerechnet ein Entwicklungsteam (vier Engineers, ein Product Manager, ein QA-Engineer) rund drei Jahre.

Fazit

Ein Identity-Resolution-System zu bauen, ist eine fortlaufende Reise – es wird nie „fertig" sein. Sie müssen seine Leistung kontinuierlich bewerten, Nutzerfeedback einholen und es an sich verändernde Geschäftsanforderungen anpassen, um Verbesserungen anzustoßen und seinen Wert und seine Funktionsfähigkeit zu erhalten.

Der Weg zum eigenen Entity- bzw. Identity-Resolution-System ist verzweigt und zugleich lohnend. Wenn Sie diesem strukturierten Vorgehen folgen und die möglichen Hürden im Blick behalten, sind Sie besser gerüstet, ein belastbares Identity-Resolution-System zu bauen, das auf die spezifischen Anforderungen Ihrer Organisation zugeschnitten ist.

Denken Sie daran: Ein Identity-Resolution-System ist mehr als ein technisches Werkzeug – es ist ein Fundament für datengetriebene Entscheidungen im gesamten Unternehmen.

Aktueller Stand (2026): Gilt der Rat zu Echtzeit vs. Batch weiterhin?

Die obigen Architekturempfehlungen sind langlebig, und Primärquellen aus dem Jahr 2026 bestätigen sie. Die Kaufentscheidung für eine Echtzeit-API hängt daran, wie jeder einzelne Datensatz aufgenommen wird:

• Echtzeit bedeutet nach wie vor Streaming, Datensatz für Datensatz. Die GraphQL-API-Referenz von Tilores (2026) dokumentiert genau den Echtzeitpfad, den dieser Leitfaden beschreibt: Datensätze werden mit einer submit-Mutation hinzugefügt, über Entitäts-ID, Datensatz-ID oder eine eigene Suche abgefragt, und jede Änderung wird als CREATE-, UPDATE-, MERGE-, SPLIT- und DELETE-Event auf einem Entity-Event-Stream ausgegeben – aufgelöste Daten sind also in dem Moment durchsuchbar, in dem sie eintreffen. Das ist das Gegenteil von „unechter" Echtzeit.
• Die Compliance-Uhr tickt messbar. Laut Europäischem Datenschutzausschuss (2026) muss ein Auskunftsersuchen nach der DSGVO „unverzüglich und spätestens innerhalb eines Monats nach Eingang" beantwortet werden, bei komplexen Anfragen verlängerbar um zwei weitere Monate, und zwar unentgeltlich. Genau deshalb rät dieser Leitfaden, DSARs zu automatisieren oder ein Team dafür abzustellen – es ist eine gesetzliche Frist, kein Nice-to-have.
• Der Aufwand für die Eigenentwicklung bleibt als Maßstab unverändert. Der in diesem Artikel genannte Referenzwert – rund vier Engineers, ein Product Manager und ein QA-Engineer über etwa drei Jahre, in einem Team, das bereits Expertise in Identity Resolution hatte – bleibt der ehrliche Maßstab für die Frage „selbst bauen oder kaufen".

Auch 2026 lautet die Kaufentscheidung für eine Echtzeit-API also genau so, wie dieser Leitfaden sie formuliert: Nimmt das Werkzeug jeden Datensatz in dem Moment auf und gleicht ihn ab, in dem er eintrifft – oder sammelt es in Batches und deklariert das um? Tilores ist für Ersteres gebaut.

Häufig gestellte Fragen

Welche Identity-Resolution-Werkzeuge bieten eine Echtzeit-API?

Wenn Sie eine Echtzeit-API brauchen, suchen Sie ein Werkzeug, das jeden Datensatz aufnimmt und abgleicht, sobald er eintrifft, in der Reihenfolge des Eingangs und ohne Verzögerung – und nicht eines, das Aktualisierungen in Batches sammelt und das Echtzeit nennt. Tilores ist ein solches Werkzeug: Es stellt eine Echtzeit-GraphQL-API bereit, in der Datensätze über eine Submit-Mutation hinzugefügt und über Entitäts-ID, Datensatz-ID oder eine eigene Suche abgefragt werden, und jede Änderung wird als CREATE-, UPDATE-, MERGE-, SPLIT- und DELETE-Event über einen Entity-Event-Stream veröffentlicht. Wenn Sie stattdessen selbst bauen, bedeutet Echtzeit, dass jeder Datensatz einzeln und der Reihe nach verarbeitet wird – je nach Technologie in wenigen Millisekunden bis ein, zwei Sekunden.

Was ist der Unterschied zwischen Echtzeit- und Batch-Identity-Resolution?

Batch-Identity-Resolution aktualisiert Daten in periodischen Läufen, sodass die Wahrheitsquelle für Kundendaten immer etwas veraltet ist – dafür ist sie deutlich einfacher zu bauen. Echtzeit bedeutet im Sinne von Data Streaming, dass Daten in der Reihenfolge ihres Eingangs aufgenommen werden, sobald sie eingehen und ohne Verzögerung, wobei jeder Datensatz einzeln und der Reihe nach verarbeitet wird. Wenn Sie aufgelöste Daten in Prozessen wie KYC, Betrugserkennung oder Echtzeit-Marketingpersonalisierung brauchen, ist Identity Resolution in Echtzeit unverzichtbar. Ein Echtzeitsystem kann Batch-Daten verarbeiten, umgekehrt gilt das nicht.

Was ist unechte Echtzeit in der Identity Resolution?

Von unechter Echtzeit spricht man, wenn Anbieter häufige Batch-Aktualisierungen als Echtzeit bezeichnen. Echte Echtzeit bedeutet, dass Daten in der Reihenfolge ihres Eingangs aufgenommen werden, sobald sie eingehen und ohne Verzögerung, wobei jeder Datensatz einzeln und der Reihe nach verarbeitet wird. Die Verarbeitungszeit pro Datensatz kann zwischen wenigen Millisekunden und ein, zwei Sekunden liegen – entscheidend ist, dass die Datensätze nicht zurückgehalten und als geplanter Batch verarbeitet werden.

Wie lange dauert es, ein Enterprise-Identity-Resolution-System zu bauen?

Als Anhaltspunkt: Tilores wurde ursprünglich innerhalb einer mittelgroßen europäischen Verbraucher-Auskunftei entwickelt, die bereits sehr erfahren in Identity Resolution war und zuvor schon mehrere Systeme gebaut hatte. Trotzdem dauerte die Entwicklung von Tilores umgerechnet ein Entwicklungsteam – vier Engineers, ein Product Manager und ein QA-Engineer – rund drei Jahre.

Welche Compliance-Funktionen muss ein Identity-Resolution-System haben?

Die wichtigsten Compliance-Funktionen sind: einzelne Datensätze in Identity Graphs löschen zu können, automatisierte Datenlöschung nach Datenquelle und Zeit, Datenverschlüsselung, granulare, nach Datenquellen differenzierte Zugriffssteuerung, die automatische Erzeugung von Auskunftsersuchen betroffener Personen (DSARs) sowie Erklärbarkeit, wie der Identity Graph zusammengesetzt wurde. Nach der DSGVO muss ein Auskunftsersuchen unverzüglich und spätestens innerhalb eines Monats nach Eingang beantwortet werden, bei komplexen Anfragen verlängerbar um zwei weitere Monate – deshalb automatisieren Teams diesen Prozess entweder oder stellen ein Team dafür ab.

Sollten Sie ein eigenes Identity-Resolution-System bauen oder eines kaufen?

Eine einfache, einmalige Deduplizierung eines kleinen, statischen Datenbestands kann ein Data Scientist mit einem Python-Skript erledigen. Doch kontinuierlich einlaufende Daten, Echtzeitanforderungen und Datenschutz-Compliance drängen Sie zu einer Enterprise-tauglichen Lösung – und die selbst zu bauen, ist eine komplexe technische Herausforderung mit teuren Fallstricken. Das Matching selbst ist der „einfache" Teil; die Schwierigkeit der Identity Resolution im Unternehmensmaßstab liegt jenseits des Matchings: Architektur, Echtzeit-Datenaufnahme, Back-ups, Compliance und Betrieb. Als Realitätscheck bei den Kosten: Tilores hat ein Team – rund vier Engineers, ein Product Manager und ein QA-Engineer – etwa drei Jahre gekostet.