TL;DR
- A false match pairs records that share some fields but belong to different people.
- Searches that match on only one or two fields are a common cause.
- Loose comparisons on the wrong field, shared inboxes and placeholder data also group strangers.
- Family members often share an address, phone and last name without being duplicates.
- Dedupely lets you match on several fields, exclude risky matches and reject false ones.
Someone opens a contact after a cleanup and finds two people in one record. A colleague's phone number sits next to the wrong name, or a customer's history now includes their sister's orders.
As the admin, you're the one who has to explain it. The merge did what it was told. The question is why the search told it two different people were one.
In this post, you'll see the five patterns behind most false matches and what each looks like in a duplicate set. You'll also see how to set up searches that keep different people apart before anything merges.
How two people end up as one record
The search decides who is a duplicate. It compares the fields you chose, pairs every set of records that agree, and the merge acts on that list.
So a false match is a search problem. One loose setting can pair hundreds of sets the same wrong way. A bulk or automatic merge then repeats the mistake on every one.
That's why it's worth getting right first: treat every merge as permanent. Our post on why matching and merging are separate decisions covers why the two steps deserve separate checks.
Five reasons a search pairs two different people
What counts as a duplicate is case by case. What one team considers a duplicate, another may not. These five patterns come up across many CRMs, whatever the business.
1. The search matched on one or two fields
One field rarely proves two records are the same person. Two "Maria Garcia" contacts can work at different companies. A last name plus an email domain pairs every colleague who shares a surname.
Two fields aren't much safer when both can be shared. First name, last name and a home phone can describe a parent and a child with the same name. A third field that people don't share, like email, closes that gap.
2. A loose comparison sat on the wrong field
Each field can be compared strictly or loosely. The loose comparisons are useful, but only on the fields they were built for.
- Root domain on a person's email: comparing only the domain groups everyone at a company. On free email domains like gmail.com, it groups strangers. In one team that works with government agencies, domain matching grouped colleagues who shared a last name and an agency domain. They weren't the same person.
- Sounds-alike matching on emails or IDs: phonetic comparison is built for names like Sean and Shawn. On an email or an ID number, it pairs values that only sound close.
- Partial phone comparison: ignoring formatting and country codes catches real duplicates. It can also pair two numbers that end in the same digits, so it needs a second field to confirm.
3. A shared inbox stood in for a person
Addresses like info@, sales@ or support@ belong to a team. When several people fill in forms with the same one, a match on email treats them as one person.
The fix is to leave known shared addresses out of email matches, or to require a matching first and last name as well.
4. Placeholder data filled the field
Values like test@test.com, John Doe or 0000000000 get typed in when a field is required and the real value isn't known. Every record with the same placeholder looks like a duplicate of the others, and those sets are often very large. Our post on placeholder values that make records look like duplicates covers how to spot them.
5. Family members shared everything but a first name
In consumer businesses, a household often shares a last name, an address, a phone and sometimes one email. On those fields, a parent and a child look identical.
Some teams see first name, last name and phone as a sure match. A parent and a son or daughter with the same name can share all three. A family can be one customer for one business and several for another, which is why these sets need a person to decide.
The five patterns at a glance
| Pattern | What the duplicate set looks like | What keeps it apart |
|---|---|---|
| One or two fields | Same surname or same name, different people | Match on at least three fields, including one people don't share |
| Loose comparison on the wrong field | Everyone at one domain, or values that only sound alike | Strict comparison on emails and IDs; loose ones only on names, with a second field |
| Shared inbox | Several people with info@ or sales@ | Leave shared addresses out, or require first and last name too |
| Placeholder data | A very large set built on test@test.com or 0000000000 | Hold back placeholder values and oversized sets |
| Family members | Same last name, address and phone | Add first name and email; send households to review |
How to set up searches that keep people apart
Match on at least three fields
Three fields that agree make a much stronger match than one or two. First name, last name and email together rarely describe two different people. Our guide on which fields to match on covers combinations for each object.
Use the strictest comparison where a mistake costs most
Compare emails and IDs exactly. Keep typo-tolerant and sounds-alike comparisons for names, where another field confirms the match. Use domain matching for companies, not to pair individual people on its own.
Leave known shared values out
A filter can keep shared inboxes and free email domains out of a search. That's simpler than rejecting the same kind of set again and again.
Keep safety thresholds on
A set with dozens of records is rarely one person. Holding back oversized sets and placeholder data stops them from reaching a bulk or automatic merge.
Show the fields that tell people apart
When a search has to match on fewer fields, display extra ones next to each set, like company, phone or created date. You can then compare them before you merge, without changing what the search matches on.
Reject what's wrong and fix the search when it repeats
When you're certain a set holds different people, reject it so it doesn't come back. When the same kind of false match keeps appearing, change the search instead.
Automate only what you'd merge without looking
A common way to start is to automate only searches of three or four strict fields, beginning with the obvious duplicates. Looser searches come later, and their sets get checked by hand before anything merges.
That split keeps the fast path for sets nobody would argue about. Households, shared inboxes and same-name pairs go to a person who can tell them apart.
If a cleanup has already merged two people, the playbook on what to do if you merged the wrong records covers the recovery. Rejecting that match afterward keeps it from merging again.
How Dedupely helps you keep different people apart
In Dedupely, you build duplicate searches on several fields, choose how strictly each one is compared and use filters to leave out shared inboxes. By default, risky matches like sets of more than 20 records and placeholder data are excluded. You can reject false matches, so they stay out of every future search.
The avoiding false matches playbook shows an example setup.
A false match starts in the search
When a cleanup merges two people, the merge followed the search. It matched on too few fields or used a loose comparison in the wrong place. Or it trusted a shared inbox, a placeholder or a family's shared details.
Each pattern has a fix you can make before anything merges. Match on at least three fields, compare strictly where mistakes cost most and leave shared values out. Then send households and same-name pairs to a person.
Frequently asked questions
Why did my CRM merge two different people?
Usually because the duplicate search paired them, by matching on too few fields, comparing a field too loosely or relying on a shared value. Shared inboxes, placeholder data and family members' shared phone and address are common causes. The merge then acted on every set the search found.
What is a false match in deduplication?
A false match is a set of records that look like duplicates but describe different people or companies. Two colleagues who share info@ and every contact with the phone number 0000000000 are typical examples. Rejecting a false match keeps it from coming back in later searches.
How many fields should a duplicate search match on?
At least three for people, since one or two fields create many false matches when people share names, phones and email domains. First name, last name and email together are a safe start. Add a field people don't share before you merge anything automatically.
How do you stop family members from being merged?
Add fields that differ between family members, like first name and email, to the search. Leave out matches built only on last name, address and home phone. Send households to a person who can decide, since a family can be one customer or several, depending on your business.
Can domain matching cause false matches?
Yes, when it's used on people's emails. Comparing only the domain groups everyone at a company, and on free email domains it groups strangers. Use domain matching for companies, pair it with name fields when matching people and leave free email domains out of those searches.
Or sign up with Google
HubSpot user 
