Which fields to match on to find CRM duplicates

Every duplicate search starts with one decision: which fields have to agree before two records count as the same. Pick too few and you merge people who only share a name. Pick too many and the duplicates you wanted to find slip through.

There's no universal list of the right fields. A contact from a web form carries different data than one from an event list. A company record also behaves differently from a deal.

In this post, you'll see where to start and which combinations to try next. You'll also see how the object and source change your choice, and why one field can mislead.

First, decide what a duplicate means in your CRM

Before you pick fields, look at your own data. What makes two records the same customer for your team, and where do your records overlap? Once you know that, the fields to match on, and how strict each one should be, follow from it.

This is case by case: what one team considers a duplicate, another may not.

A team that sells to individuals may treat two contacts with the same email as one person. A team that sells to households may treat them as two buyers who share an inbox.

The same goes for companies. For one team, every office of a company is one account. For another, each office has its own owner and contract, so it must stay a separate record.

Start with the obvious duplicates

The safest first step is the duplicates nobody argues about. These are usually exact matches on the field that identifies each record, and they're the least risky to merge.

Contacts: email

For people, email is the usual starting point. Two contacts with the same work email are very likely the same person, even when the names are spelled differently.

Match it exactly, ignoring capitalization. Leave fuzzier email matching for later, once the obvious sets are merged.

Companies: domain

For companies, the website domain plays the same role. Two company records with the same domain are usually the same company, whatever the name field says.

Domains need a little care. The same company can appear as www.example.com, example.com and https://example.com/contact, so compare the core domain.

Then combine fields

Many duplicates don't share an email or a domain. One record has a work email, the other a personal one, or one has no email at all. To find these, combine two or more fields that together point to one person or company.

Name and company

First and last name together with the company name is a common combination for contacts. It catches people who signed up twice with different emails, and records typed in by hand without one.

Name and country or city

For companies, name plus country is a good next step. It keeps "Northwind" in Germany apart from "Northwind" in Canada, which may be unrelated businesses.

For contacts without a company, name plus city can work, as long as the names in your database aren't too common.

Name and phone

Name with a phone number helps where emails are missing, such as records from calls or in-person events. Phone formats vary a lot, so strip spaces, dashes and brackets and compare the digits.

Leads and deals need their own fields

Contacts and companies follow the starting points above. Leads and deals behave differently, because of what they hold and how fast they're created.

Leads carry little data, so a match on two thin fields deserves a review. Deals carry money, so check owner and stage before you merge, since they decide who gets credit.

Choose fields for each source

Where a record came from tells you which fields you can trust. The same object can need different fields depending on how its records were created.

Web forms

Forms usually capture an email, so email tends to be reliable here. Names are less reliable: people type nicknames, all caps, or their full name in the first name field.

Imports and event lists

Lists from events, partners or vendors often have names and companies but no email, or a personal email. Name with company is usually the better match for these records.

Integrations and enrichment

Records created by another system often carry that system's own ID, which is a strong match when it's present. Enrichment tools can add a company's legal name, so name matches miss where domain matches still work.

Records typed in by reps

Manual entry brings typos, missing fields and values in the wrong field, like a phone number in the email field. Looser name matching helps, and so does checking more than one field.

Why a single field can mislead

There's no fixed list of fields you should never match on alone. It depends on your data. Still, some fields mislead often enough that they deserve a second look:

• Phone numbers: an office switchboard or a family landline can be shared by many people.
• First names: common names like Maria or John match thousands of unrelated people.
• Email: shared inboxes such as info@ or sales@ can stand for a whole team.
• Company name: different businesses can share a name in different countries.
• City or address: a large office building can hold dozens of companies.

None of these is a rule. For a business that serves households, a shared phone number may be exactly what makes two records one customer. That's why the fields have to come from your own definition of a duplicate.

Decide how strict each field should be

Choosing a field is half the decision. The other half is how closely its values have to agree. Exact suits email or domain, looser suits names, and a field that's often blank can be left out.

A useful pattern is one strict field plus one or two looser ones. For example, an exact company domain with a looser contact name finds the same person entered twice at one company. For more on building confidence, see how to correctly identify all duplicates in your CRM.

Let your own data choose the fields

The fields that find duplicates in one CRM can miss them, or pair the wrong records, in another. Starting with exact matches on email and domain clears the obvious sets, and combinations like name with company or country find the rest.

What holds it together is your own definition of a duplicate. Know what makes two records the same customer for your team, and where each source gets its data right or wrong. Then the right fields for each object become much easier to pick.

Frequently asked questions