In this lesson, you will create merge policies to prioritize how multiple data sources merge into profiles.
Adobe Experience Platform enables you to bring data together from multiple sources and combine it to see a complete view of each individual customer. When bringing this data together, merge policies determine how data is prioritized and what data is combined to create that unified view.
We’ll stick to the user interface for this lesson, but API options also exist for creating merge policies.
Data Architects will need to create merge policies outside of this tutorial.
Before you begin the exercises, watch this short video to learn more about merge policies:
In the Configure Permissions lesson, you set up all the access controls required to complete this lesson.
You may recall, in the lesson on batch ingestion, we uploaded two records with slightly different information for the same customer. In the Loyalty data, the customer’s first name was Daniel
and he lived in New York City
, but in the CRM data the customer’s first name was Danny
and he lived in Portland
. Customer data changes over time. Perhaps he moved from Portland
to New York City
. Other things change too, such as phone numbers and email addresses. Merge policies help you decide how to handle these types of conflicts when two data sources give different information for the same user.
So, why did Danny
win out as the first name? Let’s take a look:
Danny
won out as the first name in the profile:When multiple schemas are enabled for profile, a Union Schema is automatically created for all profile-enabled, record schema sharing a base class. You can view the Union Schemas by going to the Union Schema tab.
Note that there isn’t a union schema for the ExperienceEvent class. While ExperienceEvent data still lands in profile, because it is time-series based, each event includes a timestamp and id and collisions are not a problem.
Now what if you don’t like that default merge policy? What if Luma decides their loyalty system should be the source of truth when there is a conflict? For that, we will create a merge policy.
Loyalty Prioritized
Luma Loyalty Dataset
and Luma CRM Dataset
to the Dataset panel.Luma Loyalty Dataset
is on top by drag and dropping it above the Luma CRM Dataset
Let’s see if the merge policy is doing what we would expect:
Loyalty Prioritized
policyLuma CRM Id
112ca06ed53d3db37e4cea49cc45b71e
Daniel
is back!When creating Merge policies using dataset precedence, only the datasets of the same base class that you include in the right are included in the profile. Let’s set up another merge policy
Loyalty Only
Luma Loyalty Dataset
to Selected Dataset panel.Now let’s look at what this merge policy does:
Loyalty Only
policyLuma CRM Id
112ca06ed53d3db37e4cea49cc45b71e
CRM Id is an identity field in the Luma Loyalty Dataset
, but only primary identities can be used to look up profiles. So, let’s look up the profile using the primary identity, Luma Loyalty Id
"
Luma Loyalty Id
5625458
In the profile search, change the merge policy used back to Default Timebased
and select the Show profile button. Danny is back!
What is going on here? Well, profile merging is not a one time thing. Real-Time customer profiles are assembled on the fly, based on various factors, including which merge policy is used. You can create multiple merge policies to use in different contexts, depending on which view of the customer you want.
A key use case for merge policies is for data governance. For example, say you ingest third-party data into Platform which cannot be used for personalization use cases, but can be used for advertising use cases. You can create a merge policy that excludes this third-party dataset and use this merge policy to build segments for your advertising use cases.
Now let’s move on to the data governance framework.