In this blog post, I will describe an element of AEP that is often overlooked in the discussion but is definitely crucial for running your Adobe Experience Platform the way it should be: The Merging Policies.
I call this kind of concept, the “practical challenges“. They are challenges or discussions that you normally don’t have with clients before they actually signed the contract and ingested some batches.
Everyone is focus on how to ingest data, where data is stored and so on (rightfully so) but how data are kept together is coming usually later in the discussion.
It is nonetheless crucial to understand and we will try to do that below.
This blog post won’t be that long as the merging policies are quite self-explanatory once you get the concept. We will also see where they could be applied and how they can change your data on your report or actions.
What and Where are merging policies ?
To understand the merging policies, we need to have a look at the unified profile concept in Adobe Experience Platform.
As usual, I am explaining again and again that AEP is built to work with your customer / visitors data or more globally your company identities.
Lots of people are confused that AEP is a way for them to manage Big Data and are engulfing every possible workflow to AEP.
Yes, AEP can do Machine Learning.
Yes, AEP can ingest any type of data.
However, it doesn’t mean that you should run your logistic platform analysis in AEP. You probably can but it was not built to work this way.
It would be like to use a Ferrari for rallying. Yes a Ferrari is a good car, Yes Rallying is made by using a car. But it was not meant to be used like this.
— Sorry, living in Munich makes me do car analogy way more often that I would like —
The Data Model in Adobe Experience Platform has been optimized to work on 1:1 relationship with some sort of identities that you have defined previously.
For more info, take a look at my article on Identity Service. Or just the official documentation if you want lengthy explanation.
To summarize: this identity servicy will merge your user profiles (your identities) into a single, 360°, view of your customers.
From every data points that has been touched and ingested to Platform, you will be able to realize actions, analysis, segments, and so on in real time (or close to).
This is not small feat as we are dealing with Gigabites of data every minutes. But more importantly, it is quite complex to decide which data are the correct one to be ingested.
Yes, not all data are correct. imagine something like this:
USE CASE
I am logging to an ecommerce website with my Facebook account.
As you are tracking the information from the user on your website, you are ingesting Experience Events.
However, when I am logging in, I provide you things like:
- Name
- Birth date
- Gender
- Address
These are not events, these are profile attributes so you want to ingest them within an Individual Profile dataset. Not an Experience Events like the others.
The challenges starts when you realize that my Facebook account is not so great as keeping my profile updated because I have set it up something like 10 years ago and I moved a lot since then.
So my address states (broadly) France, as I was in France at that time.
Later, I am actually doing an order and this time I provide my new address in Germany.
Now we have 2 addresses attached to the same customer.
How can you deal with that ?
Several answer could be given on this use-case. I will explain 2 and dig into the Merging Policies after.
- Different Attributes for different Sources
By this, I mean that you can track the loginAddress and the orderAdrress as 2 different entities of a profile.
This answer is the smart one if you don’t want to use the unified profile capabilities. This way, you still get both information and you don’t have any issue when a possible merges come.
However, this doesn’t take advantage of the Unified Profile logic. The big advantage to get an unified profile is to have a complete view of the customer and apply actions directly on him based on this view.
The first big problem is that my Facebook address is wrong, so you don’t actually get a valuable information in your system (and by the way, the “weight” of your profiles – amount of info attached to a profile – count in your billing).
The second problem is that you need to document the correct attributes to use.
I can see customer doing that when they are suffering from the “let-s-track-everything” illness.
Data is gold but by tracking everything and anything, you actually mixing gold and coal.
2. Use the correct merging policies
As you could have imagined by now, the merging policies have been built to deal exactly with that. There are several options (2 at the moment) to deal with merging policies and they are as follow:
Timestamp order
As you have probably guessed, this policy take a look at the ingestion timestamp of your profile attribute and takes the most recent one.
This is very interesting if you are ingesting data over and over again, especially for similar data sources. You know that the data sources have more recent information uploaded so you want to overwrite the old data with the new one.
To be clear : Merge Policies don’t apply to a single dataset, if you are uploading different data for the same users in the same dataset, they will simply override the existing one and the unified profile will consider the new one (with a new timestamp).
The unified profile is merging data from different datasets.
This may be exactly what we want as default because in our example, we load the CRM data after the user has signed in and did the order. So it will display the correct information.
Dataset order
The second option is to have a dataset preference on which dataset takes precendence for the unified profile.
This may actually be better, even in our example.
With the timestamp setup, we may have an issue if we capture the sign-in on the next connection in the future. In that case, we will record my old Facebook data again and that timestamp of the batch ingested will take precedence.
With the dataset option, we would ensure that the CRM data are never over-written by the online login option.
Which setup to use ?
This is the million dollar question.
I believe that this kind of setup comes very close to the Profile Merge Rule that Adobe Audience Manager has. Therefore, it will probably be easier for AAM people to wrap their heads around it. It reflects the way you want to look at your data. At the end, it is planned to only allow 3 Merging Policy available, like the Profile Merge Rules. However, as of today (March 2021), this limitation is not enforced.
In our example, we went a bit extrem by setting either wrong or correct information. However, truth may be a matter of perspective.
It may be that some profile attribute may be contextual to a specific data source.
If you are a multi entities company with different brands and a single Adobe Experience Platform.
You may want to have a timestamp enabled to have a “snapshot” of your current profile attributes but also a dataset preference to keep your different brand datasets separated.
Yes, I didn’t mention it but when you set up your dataset preference, if you are not explicitly including a dataset, it will not be taken into consideration for your unified profile merge.
Where to use the(se) merge rule(s) ?
The thing important to know about the merge rules is that you can have multiple ones and call the one you want on some AEP actions.
There is a default merge policy in place but you still have options when requesting your unified profile.
Segments
A bit unknown of most users is the capability to change the merge policy used during the segment creation.
This is a very important feature that could completely change the user-qualification so at least you are aware of it.
Segment export
A very cool thing in Adobe Experience Platform is the ability to export the segment population.
It has not always been easy to do that in Adobe tools before, but what is even cooler is the fact that you can extract a specific unified profilte attribute with that export.
As you probably have already guessed it now, because it appears in this list, you can export that segment population when assigned to a specific MergeRuleId.
So not only can you change the qualification of a user based on the mergeRuleId, you can also see how that mergeRuleId impact the unified profile.
How cool is that ?
More details in the export documentation
Real Time Customer Profile
When you use the API, you can also change the merge policy used in order to retrieve the information on your users. This is exactly the use-case when you want to have a specific view on a customer that is not your default view (for your Customer Care people per example)
See information in the API documentation here.
I hope this has been helpful to you and you will better understand and use the merge Policy in the future.