Merge Policy
mosesdinakaran@gmail.comIntro
A merge policy tells AEP how to assemble one person's profile from multiple data sources.
Why it exists
One customer can have data spread across many datasets:
Dataset 1 (CRM) → Alice, email, account status
Dataset 2 (Billing) → Alice, bill amount, due date
Dataset 3 (Usage) → Alice, 9.2 GB used, 92%
AEP needs rules to merge these into one unified profile. That's the merge policy.
What it controls (3 things)
| Setting | Question it answers | Options |
|---|---|---|
| Dataset selection | Which datasets contribute to the profile? | All datasets / Selected datasets |
| Attribute merge | If two datasets disagree on a field, which wins? | Timestamp ordered (newest wins) or Dataset precedence (you rank them) |
| ID stitching | How to link identities across datasets? | None (exact match only) or Private Graph (use identity graph to connect related IDs) |
Simple analogy
Think of building a puzzle of a person:
- Datasets = puzzle pieces from different boxes
- Merge policy = the instructions that say:
- Which boxes to use (dataset selection)
- If two pieces overlap, which goes on top (attribute merge)
- How to know two pieces belong to the same puzzle (ID stitching)
How data gets from Dataset to Profile
When you ingested Alice's record, here's what happened behind the scenes:
Dataset vs Profile — what's the difference?
| Concept | Dataset | Profile |
|---|---|---|
| What | A table of raw records (like a database table) | A unified view of ONE person |
| Storage | Data Lake | Profile Store |
| Contains | Rows of data exactly as you ingested them | Merged attributes from ALL datasets about that person |
| Think of it as | A filing cabinet drawer full of papers | A complete dossier about one person, assembled from many drawers |
Example: If you had 3 datasets about Alice:
- customer_profile dataset → name, account, billing
- usage_events dataset → data usage records
- support_tickets dataset → support call history
The Profile for CUST001 would combine ALL of them into one unified view of Alice.
What is a Merge Policy?
Since a Profile is assembled from multiple datasets, AEP needs rules for:
- Which datasets to include — maybe you only want certain datasets in the profile
- How to handle conflicts — if two datasets have different values for the same field, which one wins?
That's what a Merge Policy defines:
Merge Policy = "Rules for how to assemble a profile from multiple datasets"
The two key settings:
1. Attribute Merge (how to handle conflicts):
| Method | How it works |
|---|---|
| Timestamp ordered | Most recent record wins (recommended) |
| Dataset precedence | You rank datasets — higher rank wins |
Example: If dataset A says accountStatus = "active" (updated yesterday) and dataset B says accountStatus = "suspended" (updated today):
- Timestamp ordered → picks "suspended" (newer)
- Dataset precedence → picks whichever dataset you ranked higher
2. ID Stitching (how to link identities):
| Method | How it works |
|---|---|
| None | Only match on exact same identity |
| Private Graph | Use the Identity Graph to link related identities (CUST001 ↔ alice@citisignal.com ↔ +15551230001) |
Why you couldn't see Alice in Profiles
You ingested data → Data Lake ✓ → Profile Store ✓
↓
But when you Browse...
↓
AEP asks: "Which merge policy?"
↓
The DEFAULT merge policy may not
include your dataset, or may not
know how to find dinakara_customerid
Bottom line: Your data IS in the Profile Store. The merge policy just controls which "lens" you use to view it. Now try Profiles → Browse with the Default Timebased merge policy, namespace dinakara_customerid, value CUST001 — and let me know if Alice shows up.
