Data source merge strategies

When you import person (contact) records into Ortto, such as via a data source like Salesforce, Segment, or CSV import, you will need to decide how you want to handle the incoming records in consideration of any existing records in your CDP. 

For this purpose, you can select from a number of merge strategies, which tell Ortto what to do if a person’s record already exists in your CDP. 

The merge strategy options are:

• Import and merge new data only. When a record exists only new data will be added.
• Import and merge new data for existing records only. When a record exists only new data will be added. Don’t add new records.
• Import and overwrite any data that exist. When a record exists all fields will be overwritten. This is our recommended option.
• Import and overwrite any data that exist for existing records only. When a record exists all fields will be overwritten. Don’t add new records.
• Import new records only. If a record exists it will not be modified.

About merge key strategies

When connecting a data source you will be asked to select a merge strategy and a merge key strategy (this may also be referred to as a find strategy). The merge key strategy refers to the unique identifiers set in your Ortto account when determining how to merge contacts and organizations.

The merge key strategies are:

• Merge with any key match
• Match only if previous merge key is empty.

Your chosen merge strategy will be applied according to the merge key strategy you select. 

Merge with any key match

This merge key strategy will merge data source records with existing Ortto records based on any key match. (It tells our system to find any match.)

This strategy will look at both your primary and fallback unique identifiers (e.g. email and phone number) to determine whether a match can be found.

For example, you have your unique identifiers set to use email as the primary identifier and phone number as the fallback. Using Shopify as an example, if your Shopify contact’s email address or phone number matches with an existing Ortto record, merge with that record. If no Ortto record exists with a matching email or phone number, create a new record.

Match only if previous merge key is empty

This merge key strategy will review the merge keys present in the inbound (data source) data in priority order and look for a matching record in Ortto. If we can’t find a match on the first key but can by the second key, we check if the first key value is present (not empty) on an existing contact which matched the second key. If yes, we skip that contact and create a new one.

The merge key priority order is determined by whether or not the data source has a hidden identifier (ID), and your unique identifiers. 

Let’s look at an example using 3 merge keys: data source record ID, email and phone. This merge key strategy will firstly check if a match can be found based on the data source record ID:

• If yes, the contact will be merged.
• If no, we will check for a match on the email:
  • If the email matches and the data source record ID is empty, the contact will be merged.
  • If the email matches but the data source record ID has a different value, a new contact will be created.
• If no match on the data source record ID or email, we will check for a match on the phone number:
  • If the phone number matches and the data source record ID and the email are empty, the contact will be merged.
  • If the phone number matches but the data source record ID and/or the email have different values, a new contact will be created.

Choosing a merge key strategy

When choosing a merge key strategy, it’s important to consider what type of records you have and whether they share any common values. Depending on the identifier values your data source contacts have, you may need to adjust the unique identifiers in Ortto to suit your merge key strategy.

For a CRM data source like Salesforce, Pipedrive or HubSpot, you might have contacts that share a common work email address or phone number. As such, you may find it more suitable to set your primary unique identifier to a Contact ID or similar, with the email address as a fallback. Then you can use these identifiers with the Match only if previous merge key is empty strategy to prevent contacts who share an email address from being merged.

For an e-commerce data source like Shopify, you might prefer to keep the default unique identifiers (email as primary, phone number as fallback) and use the Merge with any key match strategy to merge records with matching identifiers to avoid creating duplicate customer records.

Data sources have hidden identifiers

Ortto applies a hidden unique identifier (ID) to data source records as an additional merge key.

The hidden ID is used to handle cases where you have more than 1 of a particular data source connected to the same Ortto account. Each data source gets its own unique hidden identifier so that Ortto knows whether or not to merge a data source’s records (depending on the merge and merge key strategies). 

As an example, you have 2 Salesforce accounts (A and B) connected to your Ortto account. In each Salesforce account, you have the same organization record called Rainy Day Insurance. The Rainy Day Insurance record has been synced to Ortto for Salesforce account A but not for Salesforce account B.

You then import Rainy Day Insurance from Salesforce account B to Ortto.

• If you use the merge key strategy Match only if previous merge key is empty, you may end up with 2 Rainy Day Insurance records in your Ortto account. This is because Ortto has identified that each Rainy Day Insurance record has a different hidden ID (Salesforce account ID) so each is treated as an individual record.
• If you choose the merge strategy Merge with any key match, and the records share a unique identifier (such as a phone number or email address), the two Rainy Day Insurance records will be merged.

Here is an illustration of how the merge key strategies work in conjunction with the hidden ID. This example uses the email as the primary unique identifier and phone number as the fallback identifier: