In this video, we’ll use the Adobe Experience Platform UI to create a new Merge Policy.

Merge Policies are the rules that Platform uses to determine which data should be used and prioritized when combining data from disparate sources in order to create customer profiles. Before we get into the UI, let’s go over the basics of Merge Policies and how they operate in Platform. When data is ingested from multiple sources, it is in the form of fragments. Each fragment contains information about just one identity out of the total number of identities that could exist for an individual. When merging that data together to form a real-time customer profile, there’s the potential for that information to conflict and priority must be specified. That’s where Merge Policies come in. A Merge Policy defines the specific way that dataset attributes should be prioritized if a conflict occurs when merging. To understand the basic components of a Merge Policy, let’s go into the UI and start creating one of our own. Select Profiles in the left navigation, then select the Merge Policies tab. Here, we can see a list of existing policies for our organization. If we select Create Merge Policy in the top right of the tab, a new Merge Policy workflow appears. From here, we can start to configure our Merge Policy. Let’s start by providing a short descriptive name for the Merge Policy that will help us identify it later.

Schema class represents the experience data model class associated with the Merge Policy. You can create multiple merge policies per schema class. However, only the XDM Individual Pprofile class is available in the UI. Next, we choose whether we want to enable ID stitching for this policy. Identity stitching is the process of identifying data fragments and combining them together to form a complete profile record. To help illustrate these different stitching behaviors, consider a single customer who interacts with a brand using two different email addresses. If identity stitching is disabled, IDs will not be stitched together and therefore, each email address is stored as a separate profile. When segmentation occurs Platform will only consider the attributes attached to each individual ID when determining if the customer qualifies for a segment membership. This could result in the customer having multiple profiles for each email address. Each of these profiles could qualify for different segments resulting in multiple marketing messages being sent to the same customer. If identity stitching is enabled, multiple identities related to the same individual are stitched together. This results in the customer having a single profile and allows segmentation to consider multiple attributes from multiple related identities when determining segment qualification. To enable identity stitching, select Private graph. To prevent identity staging, select None. Finally, we can select whether this will be the Default Merge Policy for the organization. While you can define many merged policies for a single schema class, you can only have one default Merge Policy per class. When merging profile fragments, the default Merge Policy is used unless another policy is specified. Select Next, and on the next screen, we can choose the merge method for our profile datasets. A Merge Policy can employ one of two possible methods. Timestamp ordered and Dataset precedence. Timestamp ordered means that in the event of a conflict, priority is given to the dataset that was updated most recently. Dataset precedence gives priority to profile fragments based on the dataset from which they came. When using this option, you must choose the related datasets and their order of priority. For this Merge Policy, we’ll select timestamp ordered as our merge method, then select Next to continue. The next step for ExperienceEvent datasets depends on the merge method we selected in the previous step. Since we selected Timestamp ordered, all event datasets will be prioritized based on their last updated date and therefore we don’t need to configure anything. If we selected Dataset precedence, we would have to manually choose and prioritize those specific datasets here as well. Select Next to one more time, and from here, we can review the details of our new Merge Policy. Since we selected Timestamp ordered, all datasets that have been created under the schema class are included. If we selected Dataset precedence, only datasets that we manually selected would be included in these totals. Once we’re satisfied, select Finish and the new Merge Policy is added to the list of existing policies in the profile’s workspace.

You can now use this Merge Policy when working with profile data and Experience Platform including creating segments and browsing individual profiles. You now know the basics of Merge Policies, in Experience Platform and how to create a new policy in the UI. For more information on real-time customer profile and segmentation, please refer to the documentation. Thanks for watching. -