Understanding Identity Resolution

Sales and marketing teams use specialized tools to manage how your customers and prospects interact with your business. Salesforce, Dynamics or SAP as CRM for sales; Marketo, Eloqua or Pardot as Marketing Automation; Google, LinkedIn or a DSP for advertising.  These tools store disparate snapshots of your customer data and are only a piece of the entire story of how they're engaging with your campaigns and progressing through they buying journey.

D&B's CDP creates a single source of truth amongst those disparate data sources for your accounts and contacts with Identity Resolution, a capability that automatically matches, merges, and links all incoming 1st and 3rd party data from sources such as intent, web visits, marketing automation, CRM, and ERP.

What does Identity Resolution do?

Identity Resolution works to categorize all of the data related to your customers and prospects. There are two types of data:

• Metadata – provides more information about your customers and prospects. Examples include company information (name, domain, address, phone number) and user information (contact and lead information, such as email, phone number, name, title, department)
• Engagement Data – how your customers and prospects engage with your business and campaigns. Examples include transactions (what products and services your customers have bought and when), web visits, sales and marketing activities, etc.

Both Metadata and Engagement Data types are added as appended attributes to your Accounts and Contacts. This allows D&B to create a customer master by doing the following:

1. Matching accounts across multiple systems to create a unified account
2. Matching contacts across multiple systems to create a unified contact
3. Associating contacts from multiple systems to accounts (lead to account matching)
4. Creating new accounts if the contacts do not match to an existing account

How does Identity Resolution work?

Identity Resolution works to match and merge accounts and contacts across multiple systems to create a customer master. The Matching process detects if accounts and contacts across multiple systems represent the same account or contact. The Merging process involves ensuring the value in the customer master is from the system that is most accurate.

Matching Accounts

In many instances, the same account will have different values across systems (e.g. the account ID is different in CRM, data lake, and 3rd party file). 

The above examples illustrate how Identity Resolution can match accounts from multiple systems. The CRM and Data Lake share a common ID (CRM_ID). Identity Resolution can use a shared ID across systems to create a deterministic match. This guarantees that identical accounts from your system continue to be represented accurately in in your D&B CDP.

Identity Resolution also matches accounts when a deterministic match is not possible. In the example above, the 3^rd party data does not have an account ID, but has additional information (Name, Website, Country) that can be used to match to it to its counterparts.

The resulting account in your D&B CDP combines the appended attributes across all systems to create a master account. In addition to retaining all of the system specific IDs, the CDP also assigns a global ID for the account that can be used in the future to identify this account.

Your D&B CDP uses the following rules to match accounts from multiple systems:

1. Deterministic (based on ID) matching has the highest priority. If two systems share a common ID, the CDP will automatically match based on their IDs.
2. A system may have a unique ID to identify unique records from each other, but they may not share a common ID with another system. Your D&B CDP relies on non-deterministic matching for these systems. The CDP relies on other clues for non-deterministic matching (also known as Match Attributes) to determine the account. The following matching keys are used: Account Name, Website or Domain, Location (Country, City, State, Postal Code) and D-U-N-S Number. The CDP uses the following criteria to find a matching account:
1. If Domain/Website and Country is available, the CDP attempts to find a matching account with the exact Domain/Website and Country in the customer master. The CDP automatically uses USA as the default country if no country is provided by the system providing new data.
2. Next, the CDP tries to find a matching account with the exact name and country in the customer master.
3. Next, if the new system provides a D-U-N-S Number, the CDP uses it to find a matching account with the same D-U-N-S Number in the customer master.
4. Next, the CDP uses fuzzy matching using Name, Website, and location information to find a matching account.

Note: If you want to match strictly on a D-U-N-S Number you can configure this in the UI by ignoring all other match keys and only mapping the field that represents a D-U-N-S Number.

Matching Contacts

In many instances, the same contact will have different values across systems (e.g. CRM, MAP, social or display ad cookie ID). 

The above example shows how Identity Resolution can match contacts across multiple systems. The CRM and MAP don’t share a common ID, but the CDP will match them based on the email address while the ad click and lead are matched based on the cookie ID. The result is the creation of a master contact with combined data from all three sources, based on the email domain, as that is the only information available about the company of the user.

Your D&B CDP uses the following rules to match contacts from multiple systems:

1. Deterministic (based on ID) matching has the highest priority. If two systems share a common ID, the CDP will automatically match based on their IDs.
2. A system may have a unique ID to identify unique records from each other, but may not share a common ID with another systems. The CDP relies on non-deterministic matching for such a system. The CDP relies on other attributes (matching keys) for non-deterministic matching to determine the contact & account such as Email Address, First Name, Last Name, Phone Number and Account Info (DUNS, Name, Website, Location). These are the criteria to find a matching contact:
1. Your D&B CDP does an exact match using the exact Email and account Information.
2. Next, the CDP does an exact match using the exact First Name, Last Name & account Information.
3. Next, the CDP does an exact match using Email to find a matching contact.
4. Finally, the CDP does an exact match using First Name, Last Name and Phone to find a matching contact.

Merging Accounts and Contacts

The Merging process involves ensuring the value in the customer master is from the system that is most accurate. Any new data coming in to your D&B CDP first goes through the matching process. If the system finds a match, the CDP merges the new account or contact to the customer master.

The merging process could result in:

1. New attributes (fields) added to existing accounts or contacts
2. Overwriting data of existing attributes if the new system also provides new values for an attribute that already existed in your D&B CDP

New Attributes

Type, Product Usage, Employee Range, Country are all examples of each system providing new data. The systems adds all of these attributes to the account in your D&B CDP.

Merging Data

In this example, both CRM and the lead from Marketing Automation provide Title information. The values from these systems are different. The CDP keeps value from only one system. Your D&B CDP relies on System Priority to choose the value from the system that has the highest priority.

If the system with the highest priority does not provide a value for an attribute (e.g. title of a contact) but the system next in priority provide a non-empty value, the system uses the data from the second system as the final value. 

Note: By default you will not be able to replace a non-empty value in your CDP with an empty value. This is disabled to avoid users from accidentally erasing data from your system. If you do want to replace the value in the CDP you can pass Null and the CDP will treat this as an intent to replace the value with empty values. This is not turned on by default. Please reach out to customer support to enable this mode for your instance.