One Golden Profile for Every Customer,
Across Every Retailer You Ship For
Last-mile logistics operators receive customer data from dozens of retailers — Amazon, eBay, internal systems — each with different formats, masked emails, and inconsistent address notations. Tilores resolves fragmented records into a single deliverable profile per customer, in real time.
Where logistics teams use Tilores
The same customer arrives from Amazon, eBay, and your internal CRM under different names and address formats. Tilores resolves them to a single canonical profile — one record to query, one record to update.
Normalise addresses across retailer formats and resolve address variants to a canonical form before dispatch. Reduce failed deliveries caused by inconsistent data from marketplace integrations.
Identify multiple customers at the same delivery address without merging them. Surface household-level preferences, shared safe-place instructions, and combined order history.
Resolve carrier identities across TMS and rate platforms. The same carrier appearing under multiple MCNs or SCAC codes is a single resolved entity — one record across finance, operations, and compliance.
Detect duplicate accounts, address manipulation, and suspicious household patterns by resolving entity relationships across your customer and shipper network.
Deduplicated, normalised, household-linked profiles are ready for LLM personalisation, predictive routing, and recommendation engines — without requiring a separate MDM layer.
150 Million Records. 38.1 Million Real Customers. 99.5% Accuracy.
A major European last-mile logistics company was receiving customer data from Amazon, eBay, and internal systems — 150 million records, many belonging to the same people. Tilores processed the full dataset in 36 hours and produced 38.1 million deduplicated golden profiles, confirmed at 99.5% accuracy through testing.
One Customer. Four Retailers. One API Call.
The same person arrives from Amazon, eBay, the internal CRM, and the mobile app — each with different email formats, address notations, and name variants. One GraphQL call returns the resolved entity and every source record behind it.
{
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 records resolved { "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": "23 BAKER ST LONDON EC1A 1BB", "frequency": 4 // same address, 4 raw formats }], "firstOrder": { "first": { "orderDate": "2022-03-15", "retailer": "amazon_de" }}, "totalOrders": 47 // across all source retailers } }
Multiple People at One Address.
Resolved Without Merging.
Search by a normalised delivery address and get every household member's resolved profile — as separate entities. Enables shared delivery preferences, household-level personalisation, and first-contact resolution, without the over-merging that breaks downstream systems.
{
search(input: {
parameters: {
addressNorm: "23 BAKER ST LONDON EC1A 1BB"
}
}) {
entities {
id
records { firstName lastName sourceSystem }
recordInsights {
retailers: frequencyDistribution(
field: "sourceSystem"
) { value frequency }
orderCount: count
}
}
}
}
eBay Masks Emails.
Tilores Doesn't Need Them.
eBay proxies customer emails — those addresses are meaningless as match keys. Tilores resolves through normalised address and phone instead. Name typos, address abbreviations, and cross-system format differences are handled before the matching engine sees a record.
ETM normalization strips masked eBay emails before matching — they are never used as match keys
Address normalization handles abbreviations, diacritics, and cross-system formatting differences
Name fuzzy matching resolves "Schmidt" vs "Schmitt" via configurable similarity thresholds
Conflicting date of birth blocks the merge — no false positives, full audit trail
# One entity — despite the format variants
{
search(input: {
parameters: { mobile: "+4917623456789" }
}) {
entities {
id
records {
firstName # "Emma Schmidt" vs "E. Schmitt"
email # real vs eBay-masked format
address # raw format per source system
normalized {
address # canonical · all records
mobile # E.164 · all records
}
}
}
}
} Extract. Transform. Match.
A three-stage inline pipeline handles normalisation, matching, and assembly. Separate rule sets prevent the most common failure mode at scale: over-merging household members into one phantom entity.
Raw Record Intake
Any format — retailer feeds, eBay integrations, internal CRM exports — ingested via GraphQL mutation. Sync: returns the resolved entity in the same call. Async: bulk load for initial migration.
Domain Normalisation
Addresses → canonical form, phones → E.164, name encoding variants and diacritics — normalised inline. Specialised matchers cover masked marketplace emails, address formats, and name transliterations across languages.
Rule-Based Assembly
Linking rules handle high-confidence merges. Search rules surface households and fraud patterns without merging family members. Consistency checks block merges on conflicting date of birth. Every edge is auditable.
What makes two records the same person
High-confidence signals only. Household members share an address — using address alone as a link rule would merge them into one phantom super-entity. Tilores' rule linter blocks this pattern before deployment.
What connects two people at a household
Weak signals used as search anchors, never as merge criteria. Address and postcode surface households without merging family members into one record.
Deployed in Your AWS Account
Tilores runs serverless in your VPC. Retailer data never leaves your perimeter. No Tilores staff can access your customer records. The deployment is managed — the infrastructure is yours.
Real-Time Lookup
Synchronous ingest returns the resolved customer entity in the same API call. Delivery systems query customer profiles at order time, in under 10ms.
Right-to-Erasure
Delete individual records and entities re-assemble automatically. Required for GDPR compliance across multi-retailer customer data.
Entity Stream
Every entity change triggers a downstream event — push merged customer profiles to your WMS, CRM, or analytics system without polling.
Scales to Any Volume
Sharded serverless index with no in-memory wall. No capacity planning, no migration windows, no downtime as record volumes grow.
What a Technical Engagement Looks Like
No slides. No generic demos. Here is exactly what happens.
Schema Mapping · 30 minutes
We review your retailer feed schemas, marketplace integration formats, and internal CRM fields. ETM normalisation rules are configured together — no integration work required upfront. Tilores adapts to your field names and data formats.
Live Demo on Your Schema · 60 minutes
We build a synthetic dataset matching your record shape, ingest it into a live instance, and run customer unification and household resolution queries in real time. You see actual GraphQL responses — not a slide deck.
Shadow Mode · optional
Tilores ingests the same source records as your existing deduplication system in parallel. We compare resolved entities side-by-side for 2–4 weeks. No cutover, no risk, no commitment required to proceed.
See What's in Your Customer Data
We run a 60-minute technical demo against a synthetic dataset matching your retailer schemas — live entity resolution queries, real results. No slides.
Or reach us at sales@tilotech.io
Common Questions
How does Tilores handle masked eBay email addresses? +
eBay proxies buyer email addresses — the format buyer@members.ebay.com contains no personal identifier. Tilores treats these as non-matching fields and resolves the customer through normalised name + address + phone instead. The masked address is preserved in the raw record; it never pollutes the match engine.
What happens when the same customer uses different name formats across retailers? +
ETM normalization runs before matching — "E. Schmidt", "Emma Schmidt", and "Emma Schmitt" (typo) are all normalized to a canonical form before a matching rule fires. Fuzzy similarity thresholds cover the remainder. A conflicting date of birth hard-blocks the merge and produces an auditable edge.
How does address resolution work across different national formats? +
Tilores normalizes addresses to a canonical form before matching — "Müllerstraße 12", "Müllerstr. 12", and "Muller Str 12" collapse to the same normalized value. This works across multiple countries and scripts, covering the address format differences that arise when data comes from Amazon, eBay, and internal systems simultaneously.
How long does a full initial data load take at scale? +
Load time depends on instance configuration, but the serverless AWS architecture means you configure the throughput you need without upfront capacity planning or downtime windows. Processing rates of 8 milliseconds per record are achievable at enterprise scale.
Can we run Tilores in parallel with our existing system before committing? +
Yes. Tilores can ingest the same source records as your existing deduplication system and resolve independently. Compare entity outputs side-by-side for 2–4 weeks and decide based on actual results, not a product pitch. No cutover, no risk, no commitment required to proceed.