Create merge policies

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 will be prioritized and what data will be combined to create that unified view.

We’ll stick to the UI 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:

Permissions required

In the Configure Permissions lesson, you set up all the access controls you need to complete this lesson, specifically:

  • Permission items Profile Management > View Merge Policies and Manage Merge Policies
  • Permission item Profile Management > View Profiles and Manage Profiles
  • Permission item Sandboxes > Luma Tutorial
  • User-role access to the Luma Tutorial Platform product profile

About Merge policies and Union Schema

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 or vice versa. Other things change too, such as phone numbers, email addresses, etc. 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:

  1. In the Platform UI, click Profiles in the left navigation
  2. Click the Merge Polices tab
  3. Note that the default Merge Policy is timestamp ordered. Because you uploaded the CRM data after the Loyalty data, Danny won out as the first name in the profile:

Merge Policy screen

When multiple schemas are enabled for profile, a Union Schema is automatically created for all profile-enabled, record schema sharing the same base class. You can view the Union Schemas by clicking the Union Schema tab.

Merge Policy screen

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 CRM system should be the source of truth when there is a conflict? For that, we will create a merge policy.

Create a merge policy in the UI

  1. On the Merge Policies screen, click the Create Merge Policy button on the upper-right
  2. As the Name, enter Loyalty Prioritized
  3. As the Schema, select XDM Profile (note that your custom class—since it is record data—is available for merge policies, too)
  4. For Id Stitching, select Private Graph
  5. For Attribute Merge, select Dataset precedence
  6. Drag-and-drop Luma Loyalty Dataset and Luma CRM Dataset to the Dataset panel.
  7. Make sure Luma Loyalty Dataset is on top by drag and dropping it above the Luma CRM Dataset
  8. Click the Save button

Merge Policy

Validate the merge policy

Let’s see if the merge policy is doing what we would expect:

  1. Click the Browse tab
  2. Change the Merge policy to your new Loyalty Prioritized policy
  3. As the Identity namespace, use your Luma CRM Id
  4. As the Identity value use 112ca06ed53d3db37e4cea49cc45b71e
  5. Click the Show profile button
  6. Daniel is back!

Viewing a profile with a different merge policy

Create a merge policy with limited datasets

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

  1. On the Merge Policies screen, click the Create Merge Policy button on the upper-right
  2. As the Name, enter Loyalty Only
  3. As the Schema, select XDM Profile
  4. For Id Stitching, select None
  5. For Attribute Merge, select Dataset precedence
  6. Drag-and-drop only the Luma Loyalty Dataset to Selected Dataset panel.
  7. Click the Save button

Loyalty Only Merge Policy

Validate the merge policy

Now let’s look at what this merge policy does:

  1. Click the Browse tab
  2. Change the Merge policy to your new Loyalty Only policy
  3. As the Identity namespace, use your Luma CRM Id
  4. As the Identity value use 112ca06ed53d3db37e4cea49cc45b71e
  5. Click the Show profile button
  6. Confirm that no profiles are found:
    Loyalty Only no CRM Id lookup.

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"

  1. Change the Identity Namespace to Luma Loyalty Id
  2. As the Identity value use 5625458
  3. Click the Show profile button
  4. Click the profile id to open the profile
  5. Click on the Attributes tab
  6. Note that other profile details from the CRM dataset, such as the mobile phone number and email address are not available because we only
    CRM data is not viewable in the Loyalty Only policy
  7. Click on the Events tab
  8. ExperienceEvent data is available despite not explicitly including it in the merge policy datasets:
    Events are viewable in the Loyalty Only policy

More about merge policies

In the profile search, change the merge policy used back to Default Timebased and click the Show profile button. Danny is back!

Viewing a profile with a different merge policy

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 a number of 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.

One use case for merge policies is if you need to replace existing data. For example, say Luma has a new product catalog coming online and they’ve created a new version of their catalog, Luma Product Catalog Dataset v2 with updated SKUs and prices. They can use merge policies to hide this dataset before the cutover date. Afterwards, they can hide the old dataset and show the new one.

Merge policies also tie into data governance and segmentation, which you will see in the next few lessons.

Additional Resources

Now let’s move on to the data governance framework.

On this page