150 Millionen Datensätze, 99,5 % Genauigkeit, 36 Stunden: Wie Tilores Kundendaten im Enterprise-Maßstab transformierte

Für ein führendes europäisches Last-Mile-Logistikunternehmen waren Kundendaten zu einer strukturellen Belastung geworden. Das Unternehmen lieferte Pakete im Auftrag von Dutzenden Einzelhändlern — Amazon, eBay und einer Reihe regionaler Plattformen — die jeweils Kundendatensätze in unterschiedlichen Formaten, mit unterschiedlichen Namenskonventionen und unterschiedlichen Qualitätsstandards lieferten.

Das Ergebnis war eine Kundendatenbank mit 150 Millionen Datensätzen — ohne zuverlässige Möglichkeit festzustellen, wie viele davon tatsächlich einzigartige, reale Personen repräsentierten.

Das Problem im großen Maßstab

Wenn ein Kunde im selben Monat über Amazon, eBay und den eigenen Onlineshop eines Händlers bestellt, erscheint er in den Systemen des Logistikdienstleisters typischerweise als drei separate Datensätze. Jeder Händler formatiert Namen und Adressdaten unterschiedlich. eBay maskiert E-Mail-Adressen durch Proxy-Formate. Manche Plattformen übermitteln Mobilnummern, andere nicht. Die Adressformate variieren je nach Schnittstellenintegration.

Bei geringen Mengen ist diese Art von Duplikaten handhabbar. Bei 150 Millionen Datensätzen beeinträchtigte sie jeden nachgelagerten Prozess:

Liefergenauigkeit litt unter inkonsistenten Adressdaten für denselben Kunden aus verschiedenen Quellen
Kundenservice konnte Anfragen nicht beim ersten Kontakt lösen, da Mitarbeiter nur Datenfragmente statt vollständiger Historien einsahen
Betrugserkennung war auf Einzelquell-Muster beschränkt — händlerübergreifende Betrugsmuster blieben unsichtbar
Personalisierung basierte auf unvollständigen Kundenhistorien und lieferte schwache Relevanzsignale

Verschiedene Deduplizierungstools waren bereits evaluiert worden. Keines konnte die Kombination aus Volumen, händlerübergreifender Komplexität und Echtzeitanforderungen bewältigen.

Was diesen Datensatz besonders schwierig machte

Drei Eigenschaften machten diesen Datensatz besonders herausfordernd.

Maskierte eBay-E-Mail-Adressen. eBay leitet Käufer-E-Mails über Proxy-Adressen weiter — das Format kaeufername@members.ebay.com enthält keine Informationen über den tatsächlichen Kunden. Jedes Deduplizierungssystem, das E-Mail als primären Matching-Schlüssel verwendet, scheitert sofort bei eBay-Datensätzen. Die Matching-Logik muss ohne dieses Signal funktionieren.

Inkonsistente Adressformate. Jede Händler-Integration lieferte Adressen in einem eigenen Format. „Müllerstraße 12" aus einer Quelle, „Müllerstr. 12" aus einer anderen, „Muller Str 12" aus einer dritten. Exakte Übereinstimmungsregeln erfassen diese Varianten nicht. Das Auflösungssystem benötigte eine Adressnormalisierung vor dem Matching — nicht danach.

Skalierung und Genauigkeit in Kombination. Bei 150 Millionen Datensätzen erzeugt selbst eine falsche Positiv-Rate von 1 % 1,5 Millionen Phantomzusammenführungen — Kunden, die als dieselbe Person erscheinen, es aber nicht sind. Bei 100.000 Datensätzen ist das ein tolerierbares Datenqualitätsproblem. In diesem Maßstab unterbricht es operative Prozesse.

Der Tilores-Ansatz

Tilores verarbeitet Datensätze in einer dreistufigen Pipeline: Extrahieren, Transformieren, Matchen (ETM).

Die Extraktionsstufe nimmt Rohdaten in beliebigen Formaten entgegen. Die Transformationsstufe normalisiert sie, bevor die Matching-Engine sie verarbeitet — Adressen in eine kanonische Form, Telefonnummern in E.164, Namensvarianten in eine standardisierte Kodierung. Für diesen Datensatz wurden zehn spezialisierte Matcher konfiguriert, die die spezifischen Formate jeder Händlerintegration abdecken — einschließlich maskierter eBay-Adressen.

Die Matching-Stufe wendet dann zehn Matching-Regeln auf normalisierte Daten an. Diese Regeln sind in zwei Gruppen mit unterschiedlichen Funktionen unterteilt:

Verknüpfungsregeln behandeln hochkonfidente Zusammenführungen — Fälle, in denen zwei Datensätze mit hoher Wahrscheinlichkeit dieselbe Person repräsentieren. Diese kombinieren mehrere starke Signale: normalisierte Telefonnummer plus Fuzzy-Name-Matching plus normalisierte Adresse. Adresse allein ist unzureichend und wird durch den Rule-Linter blockiert.

Suchregeln behandeln schwache Signalverbindungen — Fälle, in denen Datensätze ein gemeinsames Merkmal teilen, das es wert ist, aufgedeckt zu werden, aber nicht stark genug für eine Zusammenführung ist. Haushaltsmitglieder an derselben Adresse werden durch Suchregeln verknüpft, nicht durch Verknüpfungsregeln. Diese Unterscheidung verhindert das häufigste Versagensmuster im großen Maßstab: Über-Zusammenführung, bei der verwandte, aber unterschiedliche Personen zu einer Phantomentität zusammengefasst werden.

Jede Zusammenführung erzeugt eine auditierbare Kante, die aufzeichnet, welche Regel ausgelöst wurde und auf welchen Feldern. Die Entscheidung ist abfragbar und umkehrbar.

Verarbeitung von 150 Millionen Datensätzen in 36 Stunden

Die vollständige Erstladung wurde in 36 Stunden abgeschlossen — etwa 8 Millisekunden pro Datensatz. Tilores läuft serverless auf AWS Lambda und DynamoDB, bereitgestellt in der eigenen VPC des Kunden. Es gibt keine In-Memory-Begrenzung, keine Kapazitätsplanung und kein Wartungsfenster.

Vor der Vollladung wurde eine Stichprobe von 1.000 Datensätzen verarbeitet und manuell überprüft. Die Überprüfung ergab 377 Datenqualitätsprobleme — fehlerhafte Adressen, Kodierungsprobleme und Datensätze mit widersprüchlichen Feldwerten. Diese wurden in den ETM-Normalisierungsregeln behoben, bevor die Vollladung startete. Dieses frühe Stichprobenverfahren ist Standardpraxis bei Tilores-Deployments und erfasst konsistent die Probleme, die andernfalls als falsche Positive im großen Maßstab auftreten würden.

Die Ergebnisse

Die Validierung nach der Ladung bestätigte 99,5 % Genauigkeit im gesamten aufgelösten Datensatz.

150 Millionen Datensätze wurden zu 38,1 Millionen goldenen Kundenprofilen aufgelöst — ein Deduplizierungsverhältnis von 3,9:1. Jedes goldene Profil ist die kanonische Darstellung eines realen Kunden, zusammengesetzt aus allen Quelldatensätzen, die über beliebige Händlerkombinationen hinweg übereinstimmten.

Die 38,1 Millionen Profile sind in Echtzeit über GraphQL abfragbar. Ein Liefersystem kann einen Kunden zum Bestellzeitpunkt nachschlagen und in einem einzigen API-Aufruf die kanonische Adresse, die vollständige händlerübergreifende Bestellhistorie und Haushaltsdaten erhalten — in unter 10 Millisekunden.

Jenseits der Deduplizierung

Die goldenen Profile ermöglichten Funktionen, die mit fragmentierten Daten nicht möglich waren.

Haushaltsauflösung. Suchregeln zeigen alle Kunden an einer gemeinsamen Lieferadresse als separate Entitäten an. Das Logistikunternehmen kann nun Lieferpräferenzen auf Haushaltsebene identifizieren — bevorzugte Zeitfenster, hinterlegte Ablageinstruktionen, kombinierte Bestellhistorie — ohne Familienmitglieder in einem einzigen Datensatz zusammenzuführen.

Händlerübergreifende Betrugserkennung. Muster, die innerhalb der Daten eines einzelnen Händlers unsichtbar waren, werden sichtbar, wenn Datensätze über Quellen hinweg aufgelöst werden. Mehrere Konten an derselben Adresse, widersprüchliche Identitätsfelder und Volumenanomalien können nun als abfragbare Entitätsmuster erkannt werden.

KI- und LLM-Integration. Deduplizierte, normalisierte, haushaltsmäßig verknüpfte Profile bieten die Grundlage für prädiktives Routing, proaktives Ausnahmemanagement und personalisierte Lieferkommunikation. Die Entitätsauflösungsschicht sorgt für Datenqualität; die KI-Systeme verarbeiten den Output.

Zeitplan

Das Projekt bewegte sich in drei Wochen vom initialen Schema-Mapping bis zur Produktionsreife. Die erste Woche umfasste die Überprüfung der Händler-Feed-Schemata und die ETM-Regelkonfiguration. Die zweite Woche deckte Rule-Testing, Stichprobenvalidierung und Datenqualitätsverbesserung ab. Die dritte Woche beinhaltete die vollständige Ladung von 150 Millionen Datensätzen, die Genauigkeitsvalidierung nach der Ladung und die Übergabe an die Produktions-API-Endpunkte.

Dieser Zeitplan entspricht einem konsistenten Muster bei Tilores-Deployments: Der Großteil des Implementierungsaufwands entfällt auf Schema-Konfiguration und Datenqualitätsuntersuchung, nicht auf Infrastrukturarbeit. Tilores passt sich an Kundendatenformate an; Kunden müssen ihre Daten nicht für Tilores transformieren.

Zur Logistics-Lösungsseite →