Key takeaways:
False matches occur due to broad matching rules, fuzzy matching, unreliable identifiers, or incorrect field mappings that merge different customers’ records.
Audit suspicious unified profiles, trace source records, and inspect match rules to identify why Data 360 incorrectly combined customer records.
Refine matching criteria, correct data issues, and test changes to prevent false matches without separating records belonging to the same person.
Imagine a customer who interacts with your marketing campaigns, makes a purchase, and later contacts your service team for support.
Each of those interactions sits in a different tool, but they all belong to one person. Salesforce Data 360 Identity Resolution pulls those records together into a single unified profile.
It can also go wrong. If a matching rule is too broad, or two people share an identifier, Data 360 may merge records that belong to different people, which affects customer insights, calculated insights, and everything built on them. This guide shows you how to audit and fix false matches.
What Causes False Matches in Data 360 Identity Resolution?
A false match is when Data 360 puts records from two different people into one unified profile. It almost always traces back to the match rules or to the data they run on. These are the four causes to check first.
1. Match Rules That Are Too Broad
Say you match on a phone number alone. In a lot of households, one number covers several people, so their records collapse into a single profile even though they're separate customers. The rule can't tell them apart unless you add a second condition, such as an email address.
2. Poorly Configured Fuzzy Matching
Fuzzy matching allows Data 360 to match records with similar rather than identical values. However, two different people may have similar names or other details. If the matching rules don't include enough criteria to distinguish them, Data 360 may incorrectly combine their records into one.
3. Inaccurate or Shared Identifiers
An identifier is only useful if it still points to the right person. Emails get mistyped, phone numbers get reassigned, and sometimes one address is shared by a whole team. When identity resolution trusts values like these, it links records to whoever the value happens to point to now. One mistyped email, for example, can make a customer's record look like it belongs to a stranger.
4. Incorrect Data Mapping
Identity resolution compares fields, so each source field has to land on the right data model attribute. If one doesn't, Data 360 ends up comparing values that have nothing to do with each other. Say an external reference ID gets mapped to an identifier field it doesn't belong in. Two records that merely share a number can then look like the same person and get merged.
Knowing the cause is only half the job. To fix a false match, you have to open the unified profile, trace it back to the source records behind it, and find the rule that joined them. That's the audit, and it's next.
How to Audit False Matches in Data 360
Before changing your Identity Resolution rules, identify which records have been incorrectly combined and understand what caused them to match. Data 360 provides tools to inspect unified profiles, trace their source records, and review identity resolution results. Here’s how to audit suspicious matches.
1. Inspect Suspicious Unified Profiles
Open Profile Explorer and look for unified profiles that seem to contain more than one person. Common signs are names that don't match, or a phone number that has no connection to the email address on the same profile.
For example, two records might have different first names but the same last name and date of birth. That isn't proof of a false match, since a nickname could explain it. Treat it as a flag, and check the source records before you decide.
2. Trace the Profile Back to its Source Records
When you find a suspicious profile, open the source records linked to it. Compare their names, email addresses, phone numbers, and any other details, and ask whether they really describe one person.
The source objects and unified link objects show which records fed into the profile, so check those too. If the details conflict or have nothing in common, write down which records should stay separate. You'll need that list when you fix the rules
3. Review Identity Resolution Match Rules
Next, open the relevant Identity Resolution ruleset and review its match rules and criteria. Look for conditions that could have grouped unrelated records, such as matching on a shared phone number or using fuzzy name matching without enough additional identifiers.
Check how the criteria are combined, too. Depending on the configured rules, records may qualify for a match through different combinations of conditions. Understanding that logic helps you identify which rule may have allowed the false match.
Also, check for warnings about missing field mappings or insufficient matching criteria. These can point to configuration issues worth investigating.
4. Check Identity Resolution Processing Results
Last, open Processing History and Resolution Summary to see how identity resolution behaved in recent runs. Watch for sudden shifts in profile counts or consolidation rates, especially right after you changed a match rule or added a new data source.
These numbers show that something changed, but not which rule caused an individual false match. Use them to back up what you've already found in the unified profile, its source records, and the match rule configuration.
Once you know the likely cause, you can adjust the match criteria or fix the data mapping. After that, test the change to make sure it stops the wrong merges without creating duplicate profiles.
Need help with other aspects of your Data Cloud setup? Explore our guide to Salesforce Data Cloud tools and resources to find your way around the platform.
How to Fix False Matches in Data 360 Identity Resolution
Once you know why records were merged, fix the matching logic or the data behind it. Your goal here is to keep unrelated records apart while merging records for the same person.
1. Refine the Match Criteria
If a rule matches on a shared or weak attribute, add stronger identifiers to it. Matching on phone numbers alone, for example, merges family members who share a line. Pairing it with an email address, or another reliable identifier, separates them.
Before you edit anything, look at how the conditions in each rule are combined. More criteria cut false matches, but go too far and the rule stops matching people it should. Try the new logic on a sample of representative records before you roll it out widely.
2. Tighten Fuzzy Matching
If fuzzy matching is merging people with similar names, back it up with something stricter. Don't let a similar name carry the match alone. Pair fuzzy name matching with an exact match on another reliable identifier, such as date of birth or email address, where that suits your data. That way Data 360 still copes with spelling variations in names, but it doesn't treat every near-match as the same person.
3. Correct Data Mapping and Source Data Issues
Correct any field mappings that associate source attributes with the wrong Data 360 data model fields. Identity Resolution should compare values that represent the same type of information.
For inaccurate or outdated identifiers, address the underlying data issue in the source system where possible. Correcting a mapping won't fix an incorrect email address or a phone number shared by multiple customers. Also, consider whether the affected attribute is reliable and appropriate for identity matching.
4. Rerun Identity Resolution and Check the Results
Once you've adjusted the rules or fixed the data, run identity resolution again and open the new unified profiles. Make sure people who were wrongly merged are now separate, and that records for the same person still come together.
Then look at the updated Processing History and Resolution Summary to see how the profile counts and consolidation rates moved. Those numbers can flag something odd, but they can't tell you the fix worked. Only the individual profiles can do that, so check the ones that were originally merged by mistake.
If wrong merges are still showing up, go back to the source records and the matching criteria. Don't keep changing rules without evidence.
How to Test and Validate Your Fixes
Changing the match rules is only half the job. You also have to confirm that the new setup stops false matches without splitting records that belong to the same person.
1. Test the Updated Matching Rules
Run the revised rules on a set of sample customer records. Make sure the set covers three situations:
Different people who share a phone number
Two customers with similar names
One customer whose details differ across source systems
Then check the results against what you'd expect. People who are different should stay separate, and records for the same person should match once they meet the criteria you set.
2. Check the Unified Profiles
When the rerun finishes, open Profile Explorer and look at the updated profiles. See which source records now sit together, and compare their details.
The records from the original false matches should be separate now. Check the other direction too, because a rule that's too strict can split records that belong to the same person.
3. Review the Results of the Latest Run
Compare the latest Processing History and Resolution Summary with earlier runs. Watch for jumps in the number of unified profiles or the consolidation rate after your rule changes. Those numbers can point to a problem, but they can't prove the matches are right. For that, open the affected profiles and their source records and see what changed.
Conclusion
False matches usually come down to two things: match rules that are too loose, or source data you can't trust. Find the cause, make a targeted fix, and test it on real profiles. Then your unified profiles stay accurate, and legitimate matches still go through.
If your Data 360 setup is hard to manage, our Data 360 services can help you sort out identity resolution and clean up your customer data.
Suggested Reading
Frequently Asked Questions
-
A false match merges records from different people into one profile, such as two family members who share a phone number.
A missed match is the opposite: records for the same person stay split across several profiles, such as one customer who used a different email at checkout and on a support form.
Tightening your rules reduces false matches but can cause more missed ones, so the balance between the two is required.
-
To find out whether you have a false match problem, open Profile Explorer and look for unified profiles with details that don't agree, such as mismatched names or phone numbers. Watch Processing History and Resolution Summary for sudden shifts in profile counts or consolidation rates, especially after a rule change.
-
Segments and campaigns run on unified profiles, so a wrong merge carries into everything built on it. Two people's purchases, preferences, and contact details get blended together. That can send the wrong offer, address someone by the wrong name, or leave a customer out of a segment they belong in. It also skews your customer insights, so reports on behavior and value stop reflecting real individuals.
-
Treat both email addresses as identifiers for the same customer only when other reliable information supports the match.
If the matching rules rely on exact email equality alone, the two records may remain separate. Consider combining email matching with other suitable identifiers, such as name or date of birth, based on your data and matching requirements.
Related Readings
Let's Talk
Drop us a note, we’re happy to take the conversation forward 👇🏻
