Strategy for Mapping Fields and IDs in the CDP

Introduction 

The Rev.Up CDP allows you to turn your multiple sources of siloed data into a unified data set that can give you a 360 view of your customers and prospects and allow you create powerful campaigns. 

To create this unified view of data you must first map fields from your various systems to fields within the CDP. It is common for systems to contain data points about customers or prospects that also exist in another system. All systems will also contain data points that are unique to that system.

This article will walk through some of the best practices for mapping fields to the CDP. 

What is a CDP attribute? 

When importing attributes into Rev.Up, fields from your own system must be mapped to an attribute in the CDP. This is known as the CDP Attribute name.

For example, if you want to add an Industry field from your CRM to the CDP, you will need to map your own industry field (indicated on the right side of the field mapping below) to the "Industry" CDP Attribute (on the left in field mapping). 

Some common CDP attributes have been created for you by default to make it easy for you to get up and running quickly. 

You can create up to 500 CDP attributes per account and contact objects. The CDP attributes that you create are then available to select to create segments for your target audiences. 

What is the benefit of mapping my source fields to a CDP attribute? 

1. It is not best practice to map every single field from your source system to the CDP. You should map fields from your source system that are relevant to your campaign use cases only. You can always come back and map new fields from your source system at a later date.
2. It is common for different systems to contain the same information about your customers and prospects. It is also common for these fields to go by different names across different systems. You can create one CDP attribute to map all the different fields that mean the same thing to one single field in the CDP. This will prevent you from having many different fields that mean the same thing and is part of creating a unified view of your data. 

What types of fields can be mapped to the CDP?

The CDP supports 6 data types for fields. Supported data types are Text, Boolean, Date, Number, Integer and ID. 

Why would I map a field to the ID data type? 

An ID type field is has special significance within the CDP. Only a field that is mapped as an ID data type can be used to create relationships between two data sources. You can manage relationships between two data sources within the Source Settings. 

How should I map my ID fields so that my CDP will join my data together and unify my data? 

It is important to understand the implications of mapping a field as an ID type. The ID fields in the CDP will determine how the records imported will merge (or not). There are two types of IDs that can be utilized when importing your records: Unique IDs and Matching IDs.

• Unique ID (Primary Key) - these are IDs that you have selected as unique when creating an account or contact source for a connection. They will uniquely identify records from this system.

• Matching ID (Foreign Key) - these IDs are used to merge records of the same type (ex: contact objects) from separate systems together if they share the same value. Matching IDs will relate objects of different types (ex: contacts and accounts) if they share the same value.
  • In the example below, the SFDC Contact ID has been selected as a matching ID for contacts imported from Eloqua. This will merge contacts imported from Eloqua with contacts from Salesforce if they share the same SFDC Contact ID.

• • In the example below, the Eloqua Contact ID has been selected as a matching ID in the Marketing Activity object. This will associate the Eloqua Marketing Activity to the Eloqua Contacts with matching ID values.

Some important information to take into consideration when you map your ID fields:

• Two different records of the same type (accounts and contacts) cannot share the same ID values. If ID values are shared for two separate account records, they will be merged together.  
• Avoid mapping Unique IDs from different systems to the same ID field in the CDP if you would like to merge and unify records. This will prevent records from merging together if the Unique IDs have different values.
• It is best practice to create a new CDP ID attribute for each Unique ID from different systems. This includes scenarios where you are importing records from different instances of the same system type (ex: multiple Salesforce instances). New ID attributes can be created during the field mapping process as shown below.

• Only default IDs from the CDP will be shown during the field mapping process of a different object type. This includes the "Account ID", "Contact ID", and IDs from our natively supported systems (Salesforce, Eloqua, and Marketo).
• To relate objects of different types together (ex: Accounts and Contacts, Contacts and Marketing Activity, etc.) using newly created IDs, the ID must be created during the field mapping process for both objects. You may then establish a relationship between these IDs from each object in the source settings.

Learn more about how Rev.Up matches and merges your data using IDs and Identity Resolution.

I am creating a new data source and noticed that I do not have a field from my system to map to every attribute in the CDP. Is this okay? 

Yes, it is common for systems to have fields that are specific only to that system. You do not have to map a field from a source to every CDP attribute.