# Matching rules

Matching rules define how records are allowed to merge inside an [identity graph](/identity-resolution/identity-graph.md). They are the main control surface for match quality: strict rules reduce unsafe merges, while broader rules increase coverage.

Use this page to understand identifiers, rules, criteria, match types, and conflict guardrails before configuring [Profile Resolution](/identity-resolution/profile-resolution.md).

## Core terms

| Term           | Meaning                                                                                                                                |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Identifier     | A standardized value used to connect records, such as email, phone, user ID, customer ID, anonymous ID, or device ID.                  |
| Rule           | A set of criteria that must be satisfied for records to merge.                                                                         |
| Criterion      | One condition inside a rule. A criterion selects one or more identifiers and a match type, such as exact email or fuzzy name matching. |
| Match type     | The comparison method used by a criterion: exact, fuzzy medium, or fuzzy strong.                                                       |
| Conflict limit | A guardrail that limits how many distinct values of an identifier can exist inside one resolved profile.                               |

## How rule logic works

DinMo evaluates matching logic in two levels:

| Level                    | Logic | Example                                                              |
| ------------------------ | ----- | -------------------------------------------------------------------- |
| Criteria inside one rule | AND   | `email` must match and `last_name` must be similar.                  |
| Multiple rules           | OR    | Merge if rule 1 matches, or if rule 2 matches, or if rule 3 matches. |

This lets you start with strict high-confidence rules and add broader alternatives only when they are justified by your data.

<figure><img src="/files/efVWlIJd4F5Psye7fpZ4" alt="Identity Resolution match rules configuration showing criteria joined by AND and rules joined by OR"><figcaption><p>Rules combine criteria with AND inside each rule, while separate rules act as OR alternatives.</p></figcaption></figure>

## Criteria

A criterion is the smallest matching condition in an identity graph.

Each criterion defines:

* which identifier or identifiers are compared
* which match type is used
* whether the criterion participates in a broader AND rule

For example, a rule can contain:

* criterion 1: exact match on `email`
* criterion 2: fuzzy strong match on `last_name`

Because both criteria are in the same rule, both conditions must match before records can merge.

## Match types

| Match type   | What it does                                    | Recommended use                                                              |
| ------------ | ----------------------------------------------- | ---------------------------------------------------------------------------- |
| Exact        | Values must match after standardization.        | Stable identifiers such as user ID, customer ID, email, or normalized phone. |
| Fuzzy Medium | Allows moderate similarity between values.      | Secondary signals where small differences are expected.                      |
| Fuzzy Strong | Requires stronger similarity than fuzzy medium. | Names or labels that may contain minor typos but should stay conservative.   |

If a rule contains a fuzzy criterion, it must also contain at least one exact criterion. This keeps [fuzzy matching](/identity-resolution/fuzzy-matching.md) anchored to a strong signal and reduces the risk of unrelated profiles being merged.

## Identifier standardization

Standardization is applied before matching so equivalent values can be compared consistently.

Available standardization methods include:

| Method           | Typical use                                                |
| ---------------- | ---------------------------------------------------------- |
| Trim             | Remove extra whitespace around values.                     |
| Case insensitive | Compare values without casing differences.                 |
| Only numeric     | Normalize phone-like values by keeping numeric characters. |

Choose the minimum standardization needed for each identifier. Over-normalizing can make different real-world values look identical.

## Conflict limits

Conflict limits prevent one resolved profile from accumulating too many distinct values for the same identifier.

For example:

* a person should usually have one primary `user_id`
* a profile may have multiple emails, but too many emails can indicate a shared or polluted identifier
* an anonymous ID may be less reliable and should be used cautiously

When a candidate merge violates a conflict limit, DinMo can exclude the unsafe record or cluster from the final [golden record](/identity-resolution/golden-record.md) and expose it in unresolved outputs. Review these records in [Review and monitor](/identity-resolution/review-and-monitor.md) and the warehouse output tables.

## Recommended starting rules

Start with rules that are easy to explain and validate.

| Rule                                                | Why it is safe                                                           |
| --------------------------------------------------- | ------------------------------------------------------------------------ |
| Exact `user_id`                                     | Usually controlled by your application or business system.               |
| Exact `customer_id` or CRM ID                       | Usually stable and system-generated.                                     |
| Exact standardized `email`                          | Commonly available and easy to audit.                                    |
| Exact standardized `phone`                          | Useful when phone formatting is normalized.                              |
| Exact strong identifier + fuzzy secondary criterion | Useful for controlled cleanup, but only when anchored by exact evidence. |

Avoid starting with broad fuzzy-only logic, shared household identifiers, placeholder emails, or low-quality IDs that are reused by multiple people.

## Review rules after each run

After a run, inspect:

* rule applicability
* valid match rate
* conflict rate
* unresolved records
* suspiciously large resolved profiles
* sample profiles for each important rule

Use [Review and monitor](/identity-resolution/review-and-monitor.md) to inspect the Overview, Runs, Rules, and Audit tabs.


---

# Agent Instructions: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.dinmo.io/identity-resolution/matching-rules.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.