> 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/dont_use-match.md).
# DONT\_USE Match
Includes a field in Zingg output but excludes it from matching entirely. No similarity computation is run on DONT\_USE fields.
### What `DONT_USE` does
`DONT_USE` tells Zingg to carry a field through to the output without using it in any similarity computation. No matching algorithm is applied. The field appears in every output record exactly as it appeared in the input.
`DONT_USE` fields are also hidden from the labeller when the `showConcise` flag is set to `true` so your domain experts see only the fields that are actually being used for matching when they label pairs.
{% hint style="success" icon="right-long" %}
`DONT_USE` performs no computation. There is no similarity algorithm to describe - the field is passed through to output unchanged.
{% endhint %}
### When to use `DONT_USE`
Record IDs and internal keys
Any field that uniquely identifies a record in a source system `customer_id`, `account_id`, `case_id`, `transaction_id` should use `DONT_USE`.
These fields must appear in output so you can trace resolved clusters back to source records. But they should never influence matching - different source systems use different ID schemes for the same entity.
Using `FUZZY` on a customer\_id field would cause records with similar-looking IDs from different systems to match, which is almost certainly wrong.
Audit and traceability fields
Timestamps, data source identifiers, record creation dates, batch IDs - any field needed in output for audit or traceability purposes but irrelevant to entity identity.
Reducing labeller noise with showConcise
When your schema has many fields but only 4-6 are actually used for matching, setting `DONT_USE` on the rest and using `--showConcise=true` in the CLI makes the labelling\
interface cleaner. Labellers see only the fields that drive decisions.
### When not to use `DONT_USE`
When the field carries a matching signal
If a field has information that should influence whether two records represent the same entity, even as a weak signal, do not use `DONT_USE`. Use `FUZZY`.
`DONT_USE` is for fields that carry zero matching information.
When the field is a decent blocking key, even if it's a poor similarity signal
`DONT_USE` removes a field from blocking as well as similarity scoring - there's no way to keep a field eligible for blocking while excluding it from the match score. If a field would narrow down candidate pairs well (a good blocking key) but you don't want its raw value driving the similarity score, `DONT_USE` is the wrong choice - it throws away the blocking value too. Give it a real match type instead, even a low-signal one, so it stays available to blocking.
For example, a `region_code` field cheaply splits records into non-overlapping candidate sets - a good blocking key - but two records sharing the same region says almost nothing about whether they're the same entity, so you don't want it driving the match score. Marking it `DONT_USE` strips it from blocking too, forcing Zingg to compare far more candidate pairs than necessary. Use `EXACT` on it instead - its similarity contribution will be weak, but blocking can still use it.
{% hint style="success" icon="right-long" %}
**Related types**:
* `NULL_OR_BLANK` - for fields that should participate in matching but have frequent nulls
* `EXACT` - for fields that should contribute an exact match signal
**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/dont_use-match.md?ask=&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.