Ein einheitliches Kundenprofil
für jeden Händler, den Sie beliefern
Last-Mile-Logistikdienstleister empfangen Kundendaten von Dutzenden Händlern — Amazon, eBay und interne Systeme — jeder in einem anderen Format, mit maskierten E-Mails und inkonsistenten Adressangaben. Tilores löst fragmentierte Datensätze in Echtzeit zu einem einzigen lieferbaren Profil pro Kunde auf.
Wo Logistikteams Tilores einsetzen
Derselbe Kunde kommt von Amazon, eBay und Ihrem internen CRM unter verschiedenen Namen und Adressformaten. Tilores löst sie zu einem kanonischen Profil auf — ein Datensatz zum Abfragen, ein Datensatz zum Aktualisieren.
Normalisieren Sie Adressen über Händlerformate hinweg und lösen Sie Adressvarianten in eine kanonische Form auf, bevor die Sendung erfolgt. Reduzieren Sie fehlgeschlagene Zustellungen durch inkonsistente Daten aus Marktplatzintegrationen.
Identifizieren Sie mehrere Kunden an derselben Lieferadresse, ohne sie zusammenzuführen. Zeigen Sie haushaltweite Lieferpräferenzen, gemeinsame Abstellgenehmigungen und kombinierte Bestellhistorien auf.
Lösen Sie Carrier-Identitäten über TMS- und Tarif-Plattformen hinweg auf. Derselbe Carrier, der unter mehreren MCNs oder SCAC-Codes erscheint, ist eine einzige aufgelöste Entität — ein Datensatz für Finanzen, Betrieb und Compliance.
Erkennen Sie Duplikat-Konten, Adressmanipulation und verdächtige Haushaltsmuster durch Auflösung von Entitätsbeziehungen über Ihr Kunden- und Versendernetzwerk.
Deduplizierte, normalisierte, haushaltsmäßig verknüpfte Profile sind bereit für LLM-Personalisierung, prädiktives Routing und Empfehlungs-Engines — ohne eine separate MDM-Schicht.
150 Millionen Datensätze. 38,1 Millionen reale Kunden. 99,5 % Genauigkeit.
Ein führendes europäisches Last-Mile-Logistikunternehmen empfing Kundendaten von Amazon, eBay und internen Systemen — 150 Millionen Datensätze, viele gehörend zu denselben Personen. Tilores verarbeitete den vollständigen Datensatz in 36 Stunden und erzeugte 38,1 Millionen deduplizierte goldene Profile, mit einer durch Tests bestätigten Genauigkeit von 99,5 %.
Ein Kunde. Vier Händler. Ein API-Aufruf.
Dieselbe Person kommt von Amazon, eBay, dem internen CRM und der mobilen App — jeweils mit unterschiedlichen E-Mail-Formaten, Adressangaben und Namensvarianten. Ein GraphQL-Aufruf gibt die aufgelöste Entität und alle zugrundeliegenden Quelldatensätze zurück.
{
entity(input: { id: "<CUSTOMER_ENTITY_ID>" }) {
entity {
id
recordInsights {
sources: frequencyDistribution(
field: "sourceSystem"
) { value frequency percentage }
deliveryAddresses: frequencyDistribution(
field: "addressNorm"
) { value frequency }
firstOrder: sort(criteria: [{
field: "orderDate", direction: ASC
}]) { first { orderDate retailer } }
totalOrders: count
}
}
}
} // response.json · 4 Datensätze aufgelöst { "recordInsights": { "sources": [ { "value": "amazon_de", "percentage": 25.0 }, { "value": "ebay_de", "percentage": 25.0 }, { "value": "internal_crm", "percentage": 25.0 }, { "value": "mobile_app", "percentage": 25.0 } ], "deliveryAddresses": [{ "value": "MÜLLERSTRASSE 12 10115 BERLIN DE", "frequency": 4 // gleiche Adresse, 4 Rohformate }], "firstOrder": { "first": { "orderDate": "2022-03-15", "retailer": "amazon_de" }}, "totalOrders": 47 // über alle Quell-Händler } }
Mehrere Personen an einer Adresse.
Aufgelöst ohne Zusammenführung.
Suchen Sie nach einer normalisierten Lieferadresse und erhalten Sie das aufgelöste Profil jedes Haushaltsmitglieds — als separate Entitäten. Ermöglicht gemeinsame Lieferpräferenzen, Personalisierung auf Haushaltsebene und Erstlösungsquoten, ohne die Über-Zusammenführung, die nachgelagerte Systeme beeinträchtigt.
{
search(input: {
parameters: {
addressNorm: "MÜLLERSTRASSE 12 10115 BERLIN DE"
}
}) {
entities {
id
records { firstName lastName sourceSystem }
recordInsights {
retailers: frequencyDistribution(
field: "sourceSystem"
) { value frequency }
orderCount: count
}
}
}
}
eBay maskiert E-Mails.
Tilores braucht sie nicht.
eBay leitet Kunden-E-Mails über Proxy-Adressen weiter — diese Adressen sind als Matching-Schlüssel wertlos. Tilores löst stattdessen über normalisierte Adressen und Telefonnummern auf. Tippfehler in Namen, Adressabkürzungen und systemübergreifende Formatunterschiede werden behandelt, bevor die Matching-Engine einen Datensatz sieht.
ETM-Normalisierung entfernt maskierte eBay-E-Mails vor dem Matching — sie werden nie als Matching-Schlüssel verwendet
Adressnormalisierung behandelt Abkürzungen, Diakritika und systemübergreifende Formatunterschiede
Fuzzy-Name-Matching löst „Schmidt" vs. „Schmitt" über konfigurierbare Ähnlichkeitsschwellenwerte auf
Widersprüchliches Geburtsdatum blockiert die Zusammenführung — keine falschen Positiven, vollständiger Prüfpfad
# Eine Entität – trotz der Formatvarianten
{
search(input: {
parameters: { mobile: "+4917623456789" }
}) {
entities {
id
records {
firstName # "Emma Schmidt" vs "E. Schmitt"
email # echt vs. eBay-maskiertes Format
address # Rohformat je Quellsystem
normalized {
address # kanonisch · alle Datensätze
mobile # E.164 · alle Datensätze
}
}
}
}
} Extrahieren. Transformieren. Matchen.
Eine dreistufige Inline-Pipeline behandelt Normalisierung, Matching und Assembly. Separate Regelsets verhindern das häufigste Versagensmuster im großen Maßstab: Haushaltsmitglieder werden zu einer Phantomentität zusammengeführt.
Rohdaten-Aufnahme
Beliebige Formate — Händler-Feeds, eBay-Integrationen, interne CRM-Exporte — über GraphQL-Mutation aufgenommen. Synchron: gibt die aufgelöste Entität im selben Aufruf zurück. Asynchron: Massenladung für die Erstmigration.
Domänennormalisierung
Adressen → kanonische Form, Telefonnummern → E.164, Namensvarianten und Diakritika — inline normalisiert. Spezialisierte Matcher decken maskierte Marktplatz-E-Mails, Adressformate und Namentransliterationen über Sprachen hinweg ab.
Regelbasiertes Assembly
Verknüpfungsregeln für hochkonfidente Zusammenführungen. Suchregeln für Haushaltserkennung und Betrugsmuster — ohne Familienmitglieder zusammenzuführen. Konsistenzprüfungen blockieren Zusammenführungen bei widersprüchlichem Geburtsdatum. Jede Kante ist auditierbar.
Was zwei Datensätze zur selben Person macht
Nur hochkonfidente Signale. Haushaltsmitglieder teilen eine Adresse — Adresse allein als Verknüpfungsregel würde sie zu einer Phantomentität zusammenführen. Der Tilores-Rule-Linter blockiert dieses Muster vor dem Deployment.
Was zwei Personen in einem Haushalt verbindet
Schwache Signale als Suchanker, niemals als Zusammenführungskriterium. Adresse und Postleitzahl zeigen Haushalte auf, ohne Familienmitglieder in einem Datensatz zusammenzuführen.
In Ihrem AWS-Konto bereitgestellt
Tilores läuft serverlos in Ihrer VPC. Händlerdaten verlassen Ihren Perimeter nicht. Kein Tilores-Mitarbeiter kann auf Ihre Kundendaten zugreifen. Das Deployment wird verwaltet — die Infrastruktur gehört Ihnen.
Echtzeit-Abfrage
Synchrone Aufnahme gibt die aufgelöste Kundenentität im selben API-Aufruf zurück. Liefersysteme fragen Kundenprofile zum Bestellzeitpunkt in unter 10 ms ab.
Recht auf Löschung
Einzelne Datensätze löschen und Entitäten werden automatisch neu zusammengestellt. Erforderlich für DSGVO-Compliance bei Kundendaten aus mehreren Händlern.
Entity Stream
Jede Entitätsänderung löst ein nachgelagertes Ereignis aus — übertragen Sie zusammengeführte Kundenprofile ohne Polling an Ihr WMS, CRM oder Analysesystem.
Skaliert auf jedes Volumen
Sharded serverloser Index ohne In-Memory-Beschränkung. Keine Kapazitätsplanung, keine Migrationsfenster, keine Ausfallzeiten bei wachsendem Datenvolumen.
So läuft ein technisches Engagement ab
Keine Folien. Keine generischen Demos. Hier ist genau, was passiert.
Schema-Mapping · 30 Minuten
Wir überprüfen gemeinsam Ihre Händler-Feed-Schemata, Marktplatz-Integrationsformate und internen CRM-Felder. ETM-Normalisierungsregeln werden gemeinsam konfiguriert — kein Integrationsaufwand im Vorfeld erforderlich. Tilores passt sich an Ihre Feldnamen und Datenformate an.
Live-Demo auf Ihrem Schema · 60 Minuten
Wir erstellen einen synthetischen Datensatz, der Ihrer Datensatzstruktur entspricht, laden ihn in eine Live-Instanz und führen Kundenunifikations- und Haushaltsauflösungsabfragen in Echtzeit aus. Sie sehen echte GraphQL-Antworten — keine Folienpräsentation.
Shadow Mode · optional
Tilores nimmt dieselben Quelldatensätze wie Ihr bestehendes Deduplizierungssystem parallel auf. Wir vergleichen aufgelöste Entitäten 2–4 Wochen lang nebeneinander. Kein Umstieg, kein Risiko, keine Verpflichtung zur Fortsetzung erforderlich.
Sehen Sie, was in Ihren Kundendaten steckt
Wir führen eine 60-minütige technische Demo mit einem synthetischen Datensatz durch, der Ihren Händlerschemata entspricht — Live-Entity-Resolution-Abfragen, echte Ergebnisse. Keine Folien.
Oder kontaktieren Sie uns unter sales@tilotech.io
Häufige Fragen
Wie geht Tilores mit maskierten eBay-E-Mail-Adressen um? +
eBay leitet Käufer-E-Mails über Proxy-Adressen weiter — das Format käufer@members.ebay.com enthält keine Informationen über den tatsächlichen Kunden. Tilores behandelt diese als nicht übereinstimmende Felder und löst den Kunden stattdessen über normalisierte Namen, Adressen und Telefonnummern auf. Die maskierte Adresse wird im Rohdatensatz gespeichert, gelangt aber nie in die Matching-Engine.
Was passiert, wenn derselbe Kunde verschiedene Namensformate bei unterschiedlichen Händlern verwendet? +
Die ETM-Normalisierung läuft vor dem Matching — „E. Schmidt", „Emma Schmidt" und „Emma Schmitt" (Tippfehler) werden alle in eine kanonische Form normalisiert, bevor eine Matching-Regel greift. Konfigurierbare Fuzzy-Ähnlichkeitsschwellenwerte decken den Rest ab. Ein widersprüchliches Geburtsdatum blockiert die Zusammenführung hart und erzeugt eine auditierbare Kante.
Wie genau ist die Adressauflösung über verschiedene nationale Formate hinweg? +
Tilores normalisiert Adressen vor dem Matching in eine kanonische Form — „Müllerstraße 12", „Müllerstr. 12" und „Muller Str 12" fallen alle auf denselben normalisierten Wert zusammen. Das funktioniert über mehrere Länder und Schriftsysteme hinweg und deckt die Adressformatunterschiede ab, die entstehen, wenn Daten gleichzeitig von Amazon, eBay und internen Systemen stammen.
Wie lange dauert eine vollständige Erstladung im Enterprise-Maßstab? +
Die Ladezeit hängt von der Instanzkonfiguration ab, aber die serverlose AWS-Architektur ermöglicht es, den benötigten Durchsatz ohne Kapazitätsplanung oder Wartungsfenster zu konfigurieren. Im Enterprise-Maßstab sind Verarbeitungsraten von 8 Millisekunden pro Datensatz erreichbar.
Können wir Tilores parallel zu unserem bestehenden System betreiben, bevor wir uns festlegen? +
Ja. Tilores kann dieselben Quelldatensätze wie Ihr bestehendes Deduplizierungssystem aufnehmen und unabhängig auflösen. Vergleichen Sie die Entitätsergebnisse 2–4 Wochen lang nebeneinander und entscheiden Sie auf Basis tatsächlicher Ergebnisse, nicht einer Produktpräsentation. Kein Umstieg, kein Risiko, keine Verpflichtung zur Fortsetzung erforderlich.