Duplicate Matching, Merging and Unification Are Different Things

When two records appear to represent the same person, it is easy to treat the problem as a simple duplicate. But modern customer platforms provide several different ways to respond, and each one serves a different business purpose.

• Duplicate matching helps identify possible duplicates.
• Merging combines confirmed duplicates into one operational record.
• Unification connects related records to create a broader view of the person without changing the original records.

These capabilities are related, but they are not interchangeable.

Understanding the difference helps organisations make better decisions about data quality, customer service, reporting and engagement.

Duplicate matching happens in your CRM

Your CRM is the operational system your teams use to manage customers, supporters, members or other constituents. When a new record is created or an existing record is updated, duplicate matching rules can compare it with records already held in the CRM. Those rules might consider information such as:

• name;
• email address;
• phone number;
• postcode;
• date of birth;
• other identifying details.

Depending on how the organisation configures them, the CRM may warn the user, prevent the record from being created or flag a possible duplicate for review. For the business, this helps reduce unnecessary duplication at the point information enters the organisation. It helps staff find an existing person rather than creating another record and splitting their history across several places.

But duplicate matching does not necessarily prove that two records are the same person. It tells the business:

Duplicate review allows the business to decide

Some possible duplicates are obvious, while others require context that the system does not have.

Two records might share an email address but contain different names. Two people may live at the same address. A parent and child may use the same contact details. One person may use a work email address for one interaction and a personal address for another.

In these situations, the CRM can bring the possible match to someone’s attention so a staff member can decide whether the records are genuinely duplicates or whether they should remain separate.

This provides an important middle ground. The technology helps identify a potential issue, while the business retains control over decisions that may affect customer history, donations, registrations, services or communication preferences.

Merging changes the operational CRM record

When the organisation is confident that two CRM records are genuine duplicates, they can be merged. A merge combines the records and leaves one surviving operational record. The organisation may need to decide:

• which name and address should be retained;
• which contact details are current;
• which record becomes the surviving record;
• how activities, transactions and relationships are transferred;
• what happens when the records contain conflicting information.

For staff, merging can create one trusted place to manage the relationship. It can bring together information that was previously fragmented and reduce confusion about which record should be used.

But merging is a consequential action because it changes the operational data held in the CRM. That is why a possible match should not automatically become a merge.

Duplicate matching asks:

Do these records look like they may represent the same person?

Merging asks:

Are we confident that these records should become one operational CRM record?

They are different decisions.

Unification happens in Data Cloud

Sometimes several records appear to relate to the same person, but merging them is not necessary or appropriate.

A person may:

• register through an event platform;
• volunteer through another system;
• donate through a fundraising platform;
• appear separately in the CRM;
• subscribe using another email address.

Each platform may need to retain its own operational record, while the organisation still wants to understand those records together. This is where Data Cloud identity resolution provides a different capability. Data Cloud can evaluate information from multiple systems and determine which records should be treated as representing the same person for a defined business purpose.

The original records remain unchanged:

• the CRM record stays in the CRM;
• the volunteer record stays in the volunteer platform;
• the fundraising record remains in the fundraising platform;
• the registration record remains in the system that owns it.

Data Cloud creates a unified view across those records. For the business, this can support:

• more complete reporting;
• relevant audience segmentation;
• personalised communication;
• lifetime supporter or customer insights;
• engagement scoring;
• understanding interests and behaviour;
• calculated measures drawn from several systems.

Unification does not physically merge the source records. It allows the organisation to understand them together.

Merging and unification solve different problems

Merging is about correcting operational data in the CRM, while unification is about creating a connected view across records and systems in Data Cloud.

A merge says:

These CRM records are duplicates and should become one operational record.

Unification says:

These records should be understood together for this particular business purpose.

That distinction matters. A volunteer record may be valid in the volunteer system. A fundraising record may be valid in the fundraising platform. A CRM record may be required for customer service and relationship management.

The organisation does not need to destroy those distinctions to understand the broader relationship. Data Cloud provides the connected view while the operational systems continue to perform their own roles.

One identity resolution is not enough

It can be tempting to create one identity resolution and use it for every purpose, but our view is that this introduces unnecessary risk. Different business outcomes require different levels of confidence and different ways of deciding whether records should be understood together.

We recommend three separate identity resolutions in Data Cloud:

1. a marketing and consent identity;
2. an inferred relationship identity for segmentation and calculated insights;
3. a confirmed relationship identity for records the person has explicitly connected.

Marketing and consent identity

The first identity resolution should support marketing communication and consent, and it should be conservative. Its purpose is to ensure that the organisation communicates through the correct contact point and respects the preferences associated with it.

One person may use a work email address for professional events and a personal email address for donations or volunteering. Those email addresses may belong to the same human, but they do not necessarily represent the same marketing relationship. Consent and communication preferences may differ between them.

For marketing, it is therefore safer to use strict matching rules and avoid combining records simply because they appear broadly similar.

The marketing identity should prioritise:

• safe communication;
• correct contact details;
• consent and preference management;
• a low risk of combining different people;
• clear segmentation and journey eligibility.

It may produce a narrower view of the person, but that is appropriate for the purpose.

Inferred relationship identity

The second identity resolution should support internal analysis, segmentation and calculated insights. Its purpose is to help the organisation understand a person’s broader relationship across time, systems and activities, even where that relationship has not been explicitly confirmed.

This identity will lean on fuzzy matching logic, using a wider range of evidence to identify records that are likely to represent the same person even when the details are not identical.

That evidence may include:

• similar or previous names;
• phone numbers;
• current and previous addresses;
• date of birth;
• current and previous email addresses;
• source-system identifiers;
• other relevant matching information.

For example, two records may have slightly different versions of a name, an old and new address, or different email addresses, but enough other information may align for Data Cloud to infer that they probably relate to the same person.

It could connect records for the purpose of calculating:

• lifetime giving;
• total event participation;
• volunteer activity;
• overall engagement;
• engagement scores;
• broader supporter or customer history.

This view effectively says:

Based on the information available and the fuzzy matching rules we have agreed, we believe these records probably relate to the same person.

That can be extremely useful for internal analysis and segmentation, provided the organisation understands that the relationship is inferred rather than proven. The broader the fuzzy matching rules, the more complete the view may become, but the greater the need to ensure the resulting insights are used for an appropriate business purpose.

Confirmed relationship identity

The third identity resolution should represent relationships the person has explicitly confirmed.

For example, someone may sign in and tell the organisation that an older email address, previous account or historical registration also belongs to them. Once that connection has been verified, the organisation has stronger evidence than it gains from matching data alone.

This view effectively says:

You have told us that these records also belong to you, so we have connected them.

A confirmed relationship identity can support more trusted customer views, stronger account continuity and more reliable personalisation.

However, it should not be treated as a complete record of the person’s history. Someone may have forgotten an old email address. They may no longer have access to a previous account. There may be historical, guest or offline activity they do not recognise or know exists.

The confirmed identity therefore provides greater certainty, but it may cover fewer records than the inferred identity.

The same person can have three valid unified views

This may initially sound unusual. If the records represent the same person, why not create one unified identity and use it everywhere?

The answer is that each identity is being resolved for a different purpose.

The marketing and consent identity asks:

Which records can be safely treated together so we communicate through the right contact point and respect consent?

The inferred relationship identity asks:

Which records probably relate to the same person and should contribute to internal insights, segmentation and calculated measures?

The confirmed relationship identity asks:

Which records has the person explicitly told us belong to them?

All three views can be valid at the same time.

The marketing identity may be the narrowest because it must minimise the risk of communicating incorrectly. The inferred identity may be the broadest because it is designed to reveal likely relationships and patterns. The confirmed identity may provide the strongest evidence, while still missing historical records the person has forgotten or cannot verify.

Using three identity resolutions allows the organisation to distinguish between safe communication, useful inference and confirmed connection without forcing one definition of identity to serve every business need.

Authentication is a separate capability

Authentication is often discussed alongside customer identity, but it solves another problem. Authentication determines who is accessing a website, portal or application. It can help people:

• use a consistent login across services;
• return to an existing journey;
• access protected information;
• manage their account;
• confirm that older records or accounts belong to them.

Authentication can provide stronger evidence about authenticated activity, but it does not replace duplicate matching, merging or Data Cloud identity resolution. A person may still have:

• historical records created before the account existed;
• guest donations or registrations;
• offline interactions;
• records created through external systems;
• activity completed on behalf of another person;
• several legitimate email addresses or contact points.

Authentication helps answer:

Who is accessing this digital service?

Duplicate matching, merging and unification answer different questions about the records held across the organisation.

Start with the outcome

The right technology depends on what the organisation is trying to achieve.

If the goal is to stop an unnecessary CRM record from being created, use duplicate matching. If the system has found a possible duplicate but the evidence is uncertain, use a review process. If two CRM records are confirmed duplicates and should be managed as one, merge them.

If valid records across several systems need to be understood together, use Data Cloud identity resolution. If the organisation needs to communicate safely and manage consent, use a conservative marketing and consent identity. If the organisation wants to understand likely lifetime engagement and calculate broader insights, use an inferred relationship identity. If a person has explicitly confirmed that other records belong to them, use a confirmed relationship identity.

Where people need consistent access across digital services, design an authentication and account experience.

The technology should follow the business purpose.

The goal is not one record or one identity rule

Better customer identity does not mean forcing every interaction into one CRM record. Nor does it mean creating one identity resolution and using it for every decision. The better approach is to use each capability deliberately:

• prevent avoidable duplicates in the CRM;
• review uncertain matches;
• merge confirmed duplicates when one operational record is required;
• use Data Cloud to connect valid records across systems;
• keep marketing and consent identity conservative;
• use a broader inferred identity for internal insights;
• retain a separate confirmed identity for relationships the person has explicitly verified;
• use authentication where a consistent account experience creates value.

When organisations understand these differences, they can improve data quality, communicate more safely and gain a fuller understanding of the people they serve without forcing every system and every business purpose into a single definition of identity.