Day6: Merge Policies, How AEP Decides Which Customer Data Wins
In theory, a single customer view sounds simple. Website data plus CRM data plus app data plus loyalty data equals one unified profile. Then reality shows up.
The CRM says the customer's email is john.doe@company.com. The loyalty platform has john.personal@gmail.com. The website profile shows johndoe@yahoo.com. Three systems, three emails, one person. So which value is correct, and more to the point, which one should the Profile actually use?
That decision is controlled by merge policies. And it's the moment you realize the Real-Time Customer Profile isn't just combining data. It's constantly deciding between conflicting versions of the truth.
Where this sits in the series
Day 5 showed that the Profile is an assembly engine, not a table. It pulls fragments from many datasets and builds the customer view on demand. This post is the next layer down. When those fragments disagree, merge policies are the rulebook that decides who wins.
The assembly flow looks like this:
- Start from the identity graph, which says which records belong to one person.
- Pull all the related profile fragments from across datasets.
- Detect where attributes conflict.
- Apply the merge policy to resolve each conflict.
- Return the assembled profile.
So merge policies aren't a separate feature off to the side. They're a step inside the assembly you already learned about.
What a merge policy actually is
The simplest definition:
A merge policy is the rulebook AEP uses to decide which profile data becomes the final customer truth.
When two fragments give different values for the same field, the merge policy decides which value survives, which gets overridden, which datasets are trusted more, and whether recency beats authority. The key shift in thinking:
AEP does not magically know which system is right. You have to teach it.
If you come from AEM, this is the same instinct as resolving inherited properties in templates or MSM live copies. When values can come from more than one place, you set the precedence rule and the platform follows it. It doesn't guess. Merge policies are that idea applied to customer data.
The two ways AEP picks a winner
There are two main approaches, and the difference between them is the whole concept.
Dataset precedence. A specific system is trusted more, regardless of recency. If the order is CRM then Loyalty then Website, the CRM email wins even when the website value is newer, because CRM is the source of truth.
Here's the same comparison as a table:
| Timestamp ordered | Dataset precedence | |
| Logic | Newest value wins | Most trusted source wins |
| Decides by | Recency | Authority |
| Best for | Fresh engagement, changing preferences | Identity, consent, compliance, master data |
| Default | Yes | No, you configure it |
The realization that changes how you think about it
The instinct is "why not always use the latest value?" Then you think about a real scenario.
A customer mistypes their email during checkout. That wrong value is now the newest data the website has. Under timestamp ordered, that temporary mistake would overwrite the verified CRM email. Probably the last thing you want.
That's the moment merge policies stop feeling like technical configuration and start feeling like business truth management. Sometimes the newest data is not the most trustworthy data, and only you know which fields fall into which camp.
One customer can have several truths
This one surprises people. AEP lets you apply different merge policies for different use cases, which means the same customer can look slightly different depending on which policy is in play.
-
The marketing team may want the freshest engagement signals, so timestamp ordered fits.
-
The compliance team wants authoritative consent records, so dataset precedence with a trusted source fits.
-
The analytics team wants stable master-data values, so precedence again.
Same customer, same underlying fragments, three different but equally valid views. That flexibility is powerful, and it's also where profile architecture can quietly become inconsistent if nobody is governing which policy is used where.
What merge policies do not fix
This part matters. Merge policies are not a cleanup tool. They do not fix:
- Bad schemas
- Broken identities
- Poor namespace strategy
- Duplicate customers
- Incorrect stitching
If the identity graph wrongly links two different people, a merge policy only decides which of their mixed-up values wins. It can't un-merge them. Merge policies resolve conflicts between correctly linked fragments. They can't repair a foundation that linked the wrong things in the first place.
The most common mistake
The pattern shows up again and again: teams leave the default merge policy untouched, then later wonder why things feel off.
- Why CRM values keep disappearing
- Why profiles feel inconsistent between teams
- Why consent fields behave strangely
- Why segmentation looks unreliable
The answer is usually that AEP is faithfully following timestamp ordered, the default, when the business actually needed certain fields to come from a trusted source. The platform was following the rules it was given, not the business logic people assumed it had.
The bigger idea
The deeper takeaway from this episode is uncomfortable but useful. A customer profile is not objective truth. It's constructed truth. That construction depends on schemas, identities, profile enablement, unions, and merge policies. Merge policies are the specific layer where business decisions turn into profile behaviour.
When they're designed well, profiles feel trustworthy, journeys behave correctly, personalisation feels relevant, and segmentation is reliable. When they're left to default and forgotten, everything downstream slowly becomes unpredictable, and the root cause is nearly invisible.
The one line to keep
Real-Time Customer Profile does not automatically know which data is correct. Merge policies are the rules that teach AEP what your business considers truth.
Most customer experience problems are data conflict problems underneath. Merge policies are one of the least visible and most important systems deciding how those conflicts get resolved.
What comes next
Day 7 moves into the Segmentation Service: how AEP continuously evaluates audiences across batch, streaming, and edge. That's where the trustworthy profile you've now learned to build becomes real-time customer intelligence at scale.