> For the complete documentation index, see [llms.txt](https://docs.dinmo.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dinmo.io/identity-resolution/customer-deduplication.md).

# How customer deduplication works

Customer deduplication is the process of finding records that represent the same customer and grouping them under one resolved profile.

In DinMo, deduplication is handled by [Profile Resolution](/identity-resolution/profile-resolution.md). The result is a canonical profile spine keyed by [`dinmo_id`](/identity-resolution/dinmo-id.md).

## Deduplication flow

DinMo deduplicates records in five steps:

1. **Select profile models**\
   Choose source models that represent customers, users, contacts, accounts, or subscribers.
2. **Define identifiers**\
   Decide which logical identifiers can be used to match records, such as email, phone, user ID, customer ID, or name attributes.
3. **Map model fields**\
   Map physical source fields to those identifiers in each model.
4. **Apply matching rules**\
   Use exact and, when appropriate, anchored [fuzzy matching](/identity-resolution/fuzzy-matching.md) rules to decide which records merge.
5. **Create the golden record**\
   Emit one [golden record](/identity-resolution/golden-record.md) per resolved profile.

## Exact and fuzzy matching

Exact matching is best for stable identifiers such as user ID, customer ID, standardized email, or normalized phone.

Fuzzy matching can help when secondary values contain small variations, such as names. Fuzzy criteria should be anchored by at least one exact criterion in the same rule.

## Guardrails

Deduplication must stay conservative. DinMo uses guardrails such as:

* identifier standardization
* [conflict limits](/identity-resolution/profile-resolution/matching-rules.md#conflict-limits)
* unresolved records
* rule-level monitoring
* audit tables

These guardrails make it possible to improve match coverage while reducing unsafe merges.

## What to validate

Before consuming deduplicated profiles downstream, validate:

* resolved profile count
* match rate
* unresolved records
* conflict rate
* rule contribution
* identifier completeness
* sample matched profiles

See [Review and monitor](/identity-resolution/profile-resolution/review-and-monitor.md) for the validation workflow.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.dinmo.io/identity-resolution/customer-deduplication.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.