> For the complete documentation index, see [llms.txt](https://docs.zingg.ai/zingg/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zingg.ai/zingg/zingg-concepts/zingg-configuration/field-definition/match-types/email_optimised-match.md).

# EMAIL\_OPTIMISED Match

Same matching behavior as EMAIL with faster evaluation on large datasets. The production-scale choice for email address matching in Enterprise.

### What `EMAIL_OPTIMISED` does

`EMAIL_OPTIMISED` produces the same matching results as `EMAIL` - it splits on `@`, discards the domain, and scores the local part using the similarity function. It is not an exact/binary comparison; it is `FUZZY`.

The scoring pattern is exactly the same as `EMAIL` - only the computation time differs. `EMAIL_OPTIMISED` is substantially faster when comparing large numbers of email addresses.

### What `EMAIL_OPTIMISED` matches and what it does not

<table><thead><tr><th valign="top">Value A</th><th valign="top">Value B</th><th valign="top">Match?</th></tr></thead><tbody><tr><td valign="top">j.smith@company.com</td><td valign="top">j.smith@other.com</td><td valign="top">Yes - same as <code>EMAIL</code>, identical local part, domain ignored</td></tr><tr><td valign="top">j.smith@company.com</td><td valign="top">john.smith@company.com</td><td valign="top">Partial - same as <code>EMAIL</code>, local parts differ but share "smith"; scores a graded similarity, not a hard match or non-match</td></tr><tr><td valign="top">support@ibm.com</td><td valign="top">support@microsoft.com</td><td valign="top">Yes - identical local part, even though the organisations are unrelated</td></tr><tr><td valign="top">[null]</td><td valign="top">j.smith@company.com</td><td valign="top">Yes - same as <code>EMAIL</code>, a null/blank value on either side is an automatic match; add <code>NULL_OR_BLANK</code> if you want nulls excluded</td></tr></tbody></table>

### When to use `EMAIL_OPTIMISED`

<details>

<summary><strong>Email fields on large datasets</strong></summary>

Any use case where you would use `EMAIL` but your dataset is large enough that\
performance matters. Customer datasets, patient registries, voter files—any domain where millions of email addresses are being compared.

</details>

### When not to use `EMAIL_OPTIMISED`

<details>

<summary><strong>When the domain is part of the identity signal, or should factor into the score</strong></summary>

`EMAIL_OPTIMISED` carries the same domain-blind scoring as `EMAIL` - "<support@ibm.com>" and "<support@microsoft.com>" still score as an identical-local-part match even though the organisations are unrelated. If you are matching organisations rather than individuals, or the domain should count towards the score rather than be ignored, use `EXACT` (full email must match) or `FUZZY_OPTIMISED` (fuzzy-matches the whole string, domain included) instead.

</details>

{% hint style="info" icon="right-long" %}
`EMAIL_OPTIMISED` is Enterprise only. The Community (open source) edition does not support this match type. Available in Enterprise Lite and above.
{% endhint %}

{% hint style="success" icon="right-long" %}
**Related types**:

* `EMAIL` - use in Community or in development (all editions)
* `FUZZY_OPTIMISED` - same optimisation pattern for name/text fields

**Read more**: [Match types](/zingg/zingg-concepts/zingg-configuration/field-definition/match-types.md)
{% endhint %}


---

# 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.zingg.ai/zingg/zingg-concepts/zingg-configuration/field-definition/match-types/email_optimised-match.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.
