Pre-Import Requirements
Before importing product hierarchy 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.
You must have already created the account and product purchase templates.
If you have completed this, you are now ready to set your templates and load data.
What is Product Hierarchy?
The Product Hierarchy is the family tree of your products or SKUs. It is a representation of how your SKUs are classified under different product categories. The classification can go up to four levels deep including the SKUs. Businesses typically have their product hierarchy stored in an ERP system. All the product purchases are usually tied to the SKU of the Product Hierarchy.
File Construct
The Product Hierarchy can be very different depending on the company. They can have multiple levels with millions of SKUs. D&B CDP requires this file to conform to one schema. We currently follow the below representation as shown in the screenshot above. Each row will contain one SKU and up to three product levels. The topmost parent is product level I and goes down to product level III. The SKU falls under product level III. In this way, we represent the multi-level hierarchy in a CSV file. Some SKUs may have fewer levels and in such cases, the hierarchy’s topmost should always be the product level I. If there are multiple hierarchical families in the file, an SKU can belong to only one family.
Hierarchy Validation
The hierarchy provided in the file is validated before loading into Atlas. If the validation fails, the hierarchy is not loaded and the previous hierarchy available in the system will be used. Some common errors are
- SKU belonging to more than one hierarchical family in the same file
- Circular dependencies, where the parent becomes the child and child becomes a parent.
- Broken links in the family tree
Creating Import Templates
Step 1: Mapping Product Hierarchy Fields
Mandatory Fields
Every Product Purchase or Transaction can have have the following information associated with it.
Required:
- Product Id
- Product Level 1
Optional:
- Product Level 2 & Product Level 3 - You have the option of loading up to 3 levels from your product hierarchy.
Step 1a: Load a Sample File to Create a New Template
Start by clicking on the Import Data button.
Click on Create Template for the Product Hierarchy object.
We recommend using a sample file to create your template. You can load your actual data once the template has been created.
Step 1b: Map Product Hierarchy Fields
Attribute |
Definition |
Type |
---|---|---|
Product ID |
This is a unique ID that identifies the SKU of the transaction. It is also used to join with the product’s Table. Refer the Product Bundle and Product Hierarchy sections for more info. The field can accept alphanumeric characters. |
Standard |
Attribute |
Definition |
Type |
---|---|---|
Product Level 1 |
This is the highest level of the hierarchy. This is a mandatory field. The field can accept alphanumeric characters. |
Standard |
Product Level 2 |
This is the second highest level of the hierarchy. This field is optional. This field can accept alphanumeric characters. |
Standard |
Product Level 3 |
This is the third highest level of the hierarchy. This field is optional. If present, this level forms the last parent level before the SKUs. This field can accept alphanumeric characters. |
Standard |
Step 2: Validation and Save
Step 2a: Save Template
Once the upload and field mapping process is complete, D&B CDP 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 2b. 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 platform.
To avoid accidental data loads, we 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 2c. 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 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 through the UI. This option is only recommended for smaller data sets and ad-hoc data loads.
Step 2d. Activate Automated Sync for Template(s)
Before activating automated sync for the template(s), we recommend verifying that:
- Templates are set up correctly and accurately reflect unique IDs and match IDs
- 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.
Considerations for Loading Product Hierarchy Data:
Editing Product Hierarchy
The Product Hierarchy cannot be incrementally loaded in two different Process and Analyze jobs. If there are multiple Product Hierarchy files, they have to be provided in the same Process and Analyze job or may be combined into the same file. When a new file is provided in a later job, the new file replaces the entire Product Hierarchy. If you provide an empty file, it will clean up the existing Product Hierarchy present in the system.
You can download the existing product bundle configuration from the existing template.
Hierarchy Validation
The hierarchy provided in the file is validated before loading into Atlas. If the validation fails, the hierarchy is not loaded and the previous hierarchy available in the system will be used. Some common errors are
- SKU belonging to more than one hierarchical family in the same file
- Circular dependencies, where the parent becomes the child and child becomes a parent.
- Broken links in the family tree
Choosing File 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. In such cases, you will need to change the column name to something else while uploading.
Column Name Limits
There is a fixed length you can have on each column name. The maximum length a column name can have is 63 characters.
Comments
0 comments
Please sign in to leave a comment.