Experience Platform · Merge policies
Which value wins
Laura sits in three Profile-enabled datasets, and they disagree. Yesterday at 18:10 she changed her email and city in her ecommerce account, and unsubscribed from emails. This morning the CRM and loyalty batches arrived with older data. The merge policy decides which value AJO sees.
Example assumptions
Example customer, datasets, values and times.
Profile-enabled datasets
Laura's three fragments
One row per attribute and one column per dataset, in the order the merge policy applies them. The first cell with a value wins.
Real-Time Customer Profile
What AJO sees
How many attributes the merged profile gets right, and what breaks for each one it gets wrong.
The recommendation
One owner per attribute and a single owner per dataset. Then the merge policy is trivial
No order gets all five attributes right, because each dataset mixes its own data with copies from other systems. A merge policy orders datasets, not fields. The fix lies in what each source sends.
- 01
One owner per attribute
Email and city: the ecommerce account. Consent: the preference centre. Language: the customer service CRM. Club tier: the loyalty programme.
- 02
Each source sends only its own data
The CRM stops re-exporting, every night, the email and consent it does not control, and loyalty stops sending the email. Each dataset carries only its own system's attributes, with upsert.
- 03
A merge policy without conflicts
With one owner per dataset there are hardly any conflicts, and timestamp ordered is enough. Dataset precedence acts as a safety net for the few overlaps left, ordered by trust.
- 04
Same logic on the Edge Network
There is only one active-on-Edge merge policy per sandbox, used by web personalisation and inbound messages. If it does not resolve like the AJO one, the website and email see a different Laura.