Profile Merge Policies
19 Oct 2025 » Platform
I have been dodging the profile merge policies bullet for quite some time, mainly because I never needed to dive deep into it. In fact, I still inadvertently say profile merge rules, from my Adobe Audience Manager days. However, this week I needed to provide a solution that involved creating a new merge policy. So it is high time I explained this capability.
Profile Projection
Unless you know very well how a profile gets projected, before you continue reading this post, I highly recommend that you read my post on profile projection. The summary of the process is:
- A profile is requested for a given identity.
- The identity graph is queried to get all identities linked to the one provided.
- The profile store is queried to get all the fragments with these identities.
- The fragments are combined following a set of rules.
- The projected profile is returned.
In the rest of the post, I will refer to “step [X]”, where X is one of the steps in the process above.
Although I only briefly explained it in my other post, merge policies govern this process. So much so that one of the parameters of the first step is the merge policy to use. Let’s see how this functionality works.
ID Stitching
One of the parameters that you have to configure when creating a new merge policy is how identities are stitched.
None
With this value, the profile projection process completely skips step [2] (querying the identity graph). Yes, I know, it sounds weird, especially when one of the main features of the Adobe Experience Platform (AEP) is to stitch identities. However, in some scenarios, it can be very useful.
Let me try to explain it differently, as I am sure some may not have understood it. When you set “ID Stitching” to “None”, and you project a profile, the algorithm will only use the identity that you have supplied in step [1] to look for profile fragments in step [3].
A typical use case when this value becomes very useful is for some scenarios of profile collapse. Sometimes you do not need the full profile, only the profile fragments that have been submitted with one of the identities. In a way, with this approach, you “uncollapse” the profile. Remember that the profile is not stored anywhere; the profile store only keeps fragments.
Private Graph
This is the default value. In step [2], the algorithm makes a call to the identity store. The identity store subsequently returns all other identities that have been linked to the identity given in step [1].
Default and Edge
Let’s move on to the next two parameters.
Default Merge Policy
There always needs to be a default merge policy, which is the one that will be used if, in step [1], no merge policy is supplied. AEP provides one, but you can change it to one of your own.
Active-On-Edge Merge Policy
When the AEP Edge Network requests a profile to the core, the process is no different, and it also has to supply a merge policy. It could use the default merge policy, but you have the flexibility to use a different one, if your use case requires it. Since the Edge Network Server API does not have the capability to supply a merge policy, you have to predefine it.
Merge Method
The next configuration parameter that you need to set is the merge method.
This method governs how step [4] works. The output of step [3] is a bunch of fragments. However, fragments can overlap; that is, some attributes may be present in multiple fragments. If this happens, which fragments prevail?
Timestamp Ordered
All fragments include a timestamp of when they were last updated in AEP. If you select this option (the most common), AEP will choose the fragment with the timestamp closest to now, irrespective of where it came from. This is the most common option; in fact, I have not seen any customer use the next value.
Dataset Precedence
Instead of relying on the last fragment update to take precedence, you define a priority of datasets. So, if there is a collision between fragments, AEP will choose the one coming from the dataset highest in the hierarchy.
This capability can be useful when you have datasets coming from various sources, some more reputable than others. For example, you may be ingesting data from your CRM and from 3rd-party data providers. If there is any overlap between these data sources, you will likely want your own data, which you control, to take precedence over other sources, which are out of your control.
When you select this option, the UI shows you the datasets, which you have to choose and order. You have to do it for both profile and event datasets. One feature that you also get with this option is that you can leave out some datasets from this merge policy. In other words, you can create a merge policy that will only show a partial profile. I am not sure when I would leave out datasets, but it is always good to have options.
Usage
OK, now you have your shiny, custom merge policies. How do you use them?
Profile UI
The first place where you can use them is when you want to browse some profiles in the UI. You may have already noticed that the first parameter is the merge policy, although you probably have ignored it so far. You can remove the default value and select a new one. I find this option very interesting to see how different merge policies generate different profiles.
Segmentation
While the profile UI has its uses, when you can really take advantage of merge policies is in segmentation. This means that, when evaluating segments, the profiles sent for activation will be generated by using the selected merge policy.
In order to configure this parameter, in the new audience interface, you should see a gear icon. I had never used it until now. When you click on it, you get a few configuration parameters, one of which is the merge policy.
Profile API
Being AEP API-first, the Profile API also supports passing a merge policy. In fact, if you read the documentation under “retrieve an entity”, you get the following explanation:
Additionally, usage of the following query parameter is highly recommended:
mergePolicyId: The ID of the merge policy you want to filter the data with. If no merge policy is specified, your organization’s default merge policy will be used.