Lead matching rules and duplicate leads

What it does

Matching rules decide whether a form submission updates an existing lead or contact, or creates a new one. They are the reason a scoring model has one record with fifteen interactions on it instead of five records with three each, which is why they belong in any lead scoring conversation.

Key facts

Configured at Settings > Matching rules > New. A rule targets either the Lead or the Contact table; you save the rule first, then the Conditions tab becomes available.
A rule has three parts: a main condition, optional additional conditions, and a plain-language Summary of the resulting logic.
The main condition always runs first to pull candidate records. It is exact match only — no fuzzy matching — and multiple attributes within it are combined with OR.
Additional conditions filter the candidates from the main condition. Attributes inside one additional condition are combined with OR; separate additional conditions are combined with AND.
Additional conditions support a Degree of Match: Exact (full character match), High (almost all characters), Medium (at least 50%), Low (at least 25%).
If no record matches, a new one is created. If several match, the most recently updated record is used.
Matched inactive records are treated the same as active ones and are not reactivated by the match.
Rules apply to marketing forms and event registration forms. Every attribute used in the rule must be present on the form, and those fields must be set as required.
Link tracking interacts with matching: where a tracked link identifies a known record and the submitted values match the rule, that identified record is updated; where they don't, the last modified record is updated instead.
For a combined lead and contact audience, the contact rule is evaluated first; if the matched contact has a child lead that satisfies the lead rule, the lead takes priority.

When to use / skip

You don't really get to skip this. There is default matching behaviour, and on a simple email-only B2C form it is usually fine. The moment the client has multiple forms, gated content, event registrations and an existing lead database, the default gets you duplicate leads, and duplicate leads split the interaction history that scoring depends on.

Build custom rules when the client's identity model is anything other than "email is the person". Multi-brand organisations where one person registers with a personal address at an event and a work address on a whitepaper form, or B2B clients where several people share a departmental mailbox, both need a considered rule.

Where to genuinely go light: single-form, single-brand, email-required setups. Adding phone number as a second matching attribute there mostly produces false merges when half the records have blank phone fields.

Configuration decisions

Match on identity or on identity plus corroboration. Email alone is permissive and merges aggressively; email AND phone is strict and creates more duplicates. Pick the failure mode you'd rather have.
Which attributes go in the main condition. Only exact-match attributes belong there, and they must be reliably populated on every form that uses the rule.
Degree of Match per additional condition. Medium and Low are useful for name fields where people type inconsistently; they are a poor choice for anything used as an identifier.
Lead rule, contact rule, or both. Decide how the lead-to-contact relationship should work before you write either, because the contact rule is evaluated first in mixed-audience scenarios.
Form field requirements. Every matching attribute has to be a required field. That has a direct effect on form conversion rates and needs the marketing team's agreement.
Dedupe ownership. Matching rules reduce duplicates; they don't eliminate them. Agree who runs merges and how often.

Gotchas

Empty values in matching attributes are the classic failure. A rule matching on mobile phone against a database where most records have no phone number behaves unpredictably — hence the required-field rule.
Merging duplicates afterwards breaks scoring quietly: the model stops scoring the surviving primary record until you delete the scores on the merged records or republish the model. Every dedupe runbook needs that step in it.
Multiple matches resolve to the most recently updated record, not the oldest or the "best" one. If an integration touches records nightly, "most recently updated" is effectively arbitrary.
Matching an inactive record updates it without reactivating it, so the submission lands somewhere nobody is looking.
Low and Medium degrees of match are more permissive than they sound — 25% character overlap will merge records you did not intend to merge.
A rule referencing an attribute that isn't on a given form doesn't warn you at design time; the behaviour just degrades on that form.

Consultant notes

Test rules with real, messy data from the client's existing database, not with clean records you typed yourself. The failure modes only appear in the mess.
Show the client the trade-off explicitly: strict rules create duplicates, loose rules merge strangers. Make them choose, and write down which they chose.
Check every form against every rule before go-live — required fields, attribute presence, and the event registration forms, which people always forget.
Add "republish the scoring models" to the merge runbook and hand it to whoever owns data quality. This is the single most common reason a working model appears to stop scoring.
If the client has a serious duplicate problem, fix it before scoring goes live. Scoring a fragmented database produces low scores everywhere and destroys confidence in the model.

Worth revisiting if the client changes their form strategy or takes on a new brand — matching rules rarely survive either untouched.