Pre-Import Requirements
Before importing contact data, make sure you have first reviewed and the Configuring Identity Resolution article. You should have done the work of creating a system catalog, defining the priority of your systems and defining how the systems are related. If you have completed this, you are now ready to set your templates in Lattice and load data.
Creating Import Templates
In order to import first party data into D&B CDP you need to first create systems and import templates.
Step 1: Add a New System in D&B CDP
You will need to create a new system in D&B CDP for each data source that you are planning to bring in data from.
Start by clicking on the Import Data button.
Create a new system.
Start by creating the systems that do not have any match IDs followed by systems that have match IDs. D&B CDP does not allow creating a match ID if the system to which it matches does not exist. Systems that do not have match IDs can be created in any order.
D&B CDP supports the following systems: Salesforce, Marketo, Eloqua, Pardot, Others. This helps D&B CDP pre-create standard entities commonly found in these systems.
The table below describes the entities that are created automatically with each system.
System | Entities |
Salesforce | Account, Contact, Lead, Opportunity |
Eloqua |
Contact, *Marketing Activity |
Marketo | Contact, *Marketing Activity |
Pardot | Contact, *Marketing Activity |
Others | Account, Contact, Product Purchases, Product Hierarchy, Product Bundles |
*Web Activity | Web Visit |
*Only the D&B CDP services team can configure these systems.
When you create any system you should give it a name that is understandable and clear to users who will be using D&B CDP. The name of the system will become visible in D&B CDP once data has been loaded and will be used to understand what the source of your data is.
Step 2: Configure System Templates and Priority
A template is a collection of field mappings for an entity. The key steps here are to define the unique ID, match ID and match attributes.
With D&B CDP you have the ability to load both data that has a unique Id and data that does not have a unique ID.
Use sample data from the system to set up the template. Doing this speeds up the process, as D&B CDP can automatically detect standard fields and data types. You can view a sample file for configuring contact templates in the attachments of this article.
Step 2a: Setting Ids in D&B CDP
Loading Data to D&B CDP with a Unique Id
A unique ID is a unique column that identifies each record separately. The unique ID column is used as a key column to join different objects (Accounts, Contacts, and Products) together as well as deduplicate your accounts. You should have created a catalog of these IDs when you defined your system relationships.
While a unique ID is not required to load data to D&B CDP, some best practices for using one are:
- The ID should not be empty. If a column is sparsely populated, it is not suitable for an ID column
- It should be stable, meaning the column does not change frequently over time
- It should be available as soon as the account is created. This makes sure that every record can be associated with an ID
- It should be unique
Note: A unique ID is required for contacts if you want your event data such as marketing activity, opportunities and sales activities associated with contacts.
Loading Data to D&B CDP without a Unique ID
If your records do not have a unique ID, you can rely on match attributes to match and merge your data. Match attributes are standard fields from entities that can help uniquely identify records even in the absence of a unique ID. You should have created a catalog of system match attributes when you defined your system relationships. For details on how D&B CDP uses match attributes to match and merge your data you should review the Identity Resolution Overview.
Setting Match Ids
It is not uncommon for a system to have more than one ID. These additional IDs are usually used to connect data from one system to another. For example, a Salesforce contact can have a Datawarehouse Id; the DataWarehouseId connects the contact in Salesforce to the contact in the data warehouse. D&B CDP can use these IDs to join the data together in D&B CDP. You should have created a catalog of system match IDs when you defined your system relationships.
It is a best practice to use a match ID whenever it is available as it is a deterministic way to match your records across systems.
Map Optional 3rd Party Ids
Some of the D&B CDP activation connectors require a 3rd party Id to be mapped for the connection to be successful. You should review the articles for the activation channels you are using to determine if you need to map a 3rd party ID.
Step 2b: Map Standard Fields in D&B CDP
Map Contact Matching Fields
If your records do not have a unique ID, you can rely on match attributes to match and merge your data. Match attributes are standard fields from entities that can help uniquely identify records even in the absence of a unique ID. You should have created a catalog of system match attributes when you defined your system relationships. For details on how D&B CDP uses match attributes to match and merge your data you should review the Identity Resolution Overview.
If you do not plan on using Match Fields to join your data across systems, you may still want to map your contact fields in this section. First Name, Last Name, Title, Primary Email and Primary Phone Number are all standard fields in D&B CDP. Any field from any system that is mapped to a standard field will assume a standard name. These fields can be used to consolidate differently named fields across systems into one standard field. This can prevent you from having duplicate fields that have the same meaning in D&B CDP.
Attribute |
Definition |
Type |
---|---|---|
First Name |
First name of the Contact. The field is required. The field can accept alphanumeric values. |
Standard |
Last Name |
Last name of the contact. The field is required. The field can accept alphanumeric values. |
Standard |
Title |
Title or designation of the contact within the organization. The field is required. The field can accept alphanumeric values. |
Standard |
Primary Email |
The primary email address of the contact. The field is required. The field can accept alphanumeric values. |
Standard |
Primary Phone Number |
The phone number of the contact. The field is required and can accept numeric values. |
Standard |
Map Analysis Fields
D&B CDP has additional standard fields that can be used for analysis if you are using D&B CDP Buyer Insights. These fields can be used to consolidate differently named fields across systems into one standard field.
Attribute |
Definition |
Type |
---|---|---|
Secondary Email | The secondary email address of the contact. The field is optional and accepts alphanumeric values. | Standard |
Other Email | A tertiary email of the contact. The field is optional and accepts numerical values. | Other |
Secondary Phone Number | The secondary phone number of the contact. The field is optional and accepts numerical values. | Standard |
Other Phone Number | A tertiary phone number of the contact. The field is optional and accepts numerical values. | Other |
Address |
Address of the contact. The field is optional and can accept alphanumeric values. |
Standard |
City |
The city of the contact. The field is optional and can accept |
Standard |
State |
The state of the contact. The field is optional and can accept alphanumeric values. |
Standard |
Country |
The country of the contact. The field is optional and can accept alphanumeric values. |
Standard |
Postal Code |
The postal code of the contact. The field is optional and can accept alphanumeric values. | Standard |
Lead Status |
Status of the contact based on the journey stage. The field is optional. The field can accept alphanumeric values. Example, “MQL”, “Hand Raiser”, etc. |
City |
Lead Type |
Used to associate a type to the contact. Customers usually use this field to tag the type of account, such as “Prospect”, “Key Account”, “Commercial”, etc. This field is optional. The field can accept alphanumeric characters. |
State |
Lead Source |
Used to identify the source from which the contact turned into a lead. The field is optional. The field can accept alphanumeric values. |
Country |
Created Date |
System creation date of the contact. This field is optional. The field accepts date formats |
Postal Code |
Last Modified Date |
Latest date on which information of the contact was modified. This field is optional. The field accepts date formats. |
Other |
Has Opted Out of Phone Calls |
Indicates if the contact has opted-out of phone communications. This field is optional. The field accepts only boolean formats. |
Other |
Has Opted Out of Email |
Indicates if the contact has opted-out of email communications. This field is optional. The field accepts only boolean formats. |
Other |
Step 2c: Match to Accounts
If your contacts are associated to your accounts through an unique ID you can map the unique ID in this section. You should have created a catalog of system match IDs when you defined your system relationships.
Unique Account Identifier |
The Account ID column will be used as a key to join to other objects as well as dedupe your accounts universe. Thorough thought must be given before deciding on the Account ID column. Read the Identifying Account ID section. The column mapped as ID may be re-used in later pages. The field can accept alphanumeric characters. |
Standard |
System Name |
The name of the System that these contacts should match to. This should be the same system that is the source of the accounts that these contacts are being matched to. |
Standard |
If your contacts are not associated to an account through a unique ID you can use account information to match your contacts to an account. You should have created a catalog of system match attributes when you defined your system relationships.
Step 2d: Map Custom Fields
Attribute |
Definition |
Type |
---|---|---|
Custom Attributes |
This page allows you to bring all the 1st party data on the contact and make them available on Atlas. This is a strong feature that allows you to create a 360 view of you contact. The fields are optional. You may also choose to ignore any field from your file on this page. Once the field is mapped, the field types have to be made sure. Incorrect mapping of the field’s data type can result in blank values or even failure of the Import job. You are not allowed to use reserved names for any custom attributes, see Choosing File Column Names. |
Contact Extensions |
Note: If a user previously mapped any custom fields, this page also shows all previously mapped custom attributes. Please make sure that the data type for these fields are correct. D&B CDP will automatically detect data types based on values in the input, but the detect is not 100% accurate.
Step 3: Validation & Save
In this step, D&B CDP will automatically validate field mappings and detect common errors (see below).
- All required fields are being mapped
- Validate date attributes are correctly detected including timezone
- Check data type of fields (e.g. Numbers mapped to Text)
D&B CDP shows all errors and will provide an option for the user to fix these errors before going to the next and final step.
Step 3a: Save Template
Once the upload and field mapping process is complete, Lattice will provide you an option to import the data along with the template creation. If you check the option, the file is queued for validation and import. We recommend setting up all the templates first before uploading data.
You will need to confirm by clicking “Submit”. Clicking “Submit” along with the import data option will take you to Jobs page. You will be able to track the progress of the job on this page. For more information on the jobs processing, please refer to the Data Processing and Analysis tab under the Job Page.
Step 3b: Configure System Priority
When you are done setting the templates for each source of account data, you should ensure that each system has the desired priority.
Step 3c. Pause Automated Sync for Template(s)
A customer master is the final view of data from all your systems. It is strongly recommended that the relationships across systems that contribute to the master are clearly defined upfront before loading the data.
Any changes to the relationship after data is loaded will require a deletion and rebuilding of the customer master. This is an expensive process that can delay access to the D&B CDP platform.
To avoid accidental data loads, D&B CDP strongly recommends pausing the automated data sync for your template(s). Pausing the automated sync ensures that data available in S3 will not be automatically
Step 3d. Create Data Automation Pipeline
Each entity in a system in D&B CDP has a dedicated AWS S3 drop folder. Data for each entity from the system can be sent to the drop folder in CSV format. The CSV columns should match the template defined in step 2.
Any changes to the format should follow these steps
- Pause the automated sync for the template(s).
- Modify the template(s) to reflect the changes.
- Send data in the new format.
- Activate the automated sync for the template(s).
It’s recommended that you automate the data transfer from your systems to D&B CDP after templates have been set up. There are several options, including:
- Use built-in Lattice connectors to set up automation. This option is only available for Salesforce, Marketo, Eloqua and Pardot.
- Use commercial ETL (extract, transfer and load) tools such as Informatica, Dell Boomi, Stitch Data, etc. to transfer data to specific AWS S3 folders.
- Create custom scripts to extract data from the systems and copy to specific AWS S3 folders.
Note: Data can also be loaded directly from the D&B CDP app. This option is only recommended for smaller data sets and ad-hoc data loads.
Step 4e. Activate Automated Sync for Template(s)
Before activating automated sync for the template(s), D&B CDP recommends verifying that:
- Templates are set up correctly and accurately reflect unique IDs, match IDs and match attributes.
- Data being loaded matches the template and is available in the correct location.
Activate the automated sync for your template(s). Once activated, D&B CDP will monitor for data in the drop folder and automatically import data.
Edit Template
D&B CDP provides the option of changing the saved template with the "Edit Template" option. When it is clicked, the user will be guided through the same field mapping workflow to map/re-map the columns from the input file.
Considerations for Loading Contact Data:
Column Name Limits
There a fixed length you can have on each column name. The maximum length a column name can have is 57 characters.
Duplicate Column Names
The platform does not allow to use duplicate names. The platform has a smart feature for auto-mapping and hence names such as, “Account ID”,”accountid”,” account id”, etc will all be identified as the ID column. Using it more than once causes a duplicate column issue and fails the upload.
The D&B CDP Platform uses columns names and terms that are reserved to the platform to perform internal operations. These are called Reserved Columns. For example, “Rating” is given to every account and cannot be used in the input file. In such cases, you will need to change the column name to something else while uploading. Also, if a column is mapped as ID, and the file still has an “Account ID” as another column in it, the upload will fail with duplicate column issue.
Contact Name
The contact’s name should be split into first and last name. The Atlas platform has to capability to store them separately and combine them whenever needed. This was designed keeping in mind that most of the Martech systems follow this schema. They are created to conform all the different schemas on different platforms into one schema in Atlas. If you do not wish to split the name, you may choose to map the entire name into a single field.
Incremental Loading
The contacts can be split into multiple files and loaded incrementally. This is helpful when the contacts list can come from multiple systems.
There are standard attributes that are required in order to perform the basic operations. They are created to conform all the different schemas on different platforms into one schema in Atlas. There are certain optional attributes that may be provided to leverage advanced features on the Lattice Platform. And, finally there are custom attributes that allow you to import any special information that you have on your contacts. All the attributes along with the Lattice Data Cloud are available for Advanced Segmentation.
Comments
0 comments
Please sign in to leave a comment.