7.3 Real-Time Customer Profile & Profile Merge Policies

7.3 Real-Time Customer Profile and Merge Policies

Real-Time Customer Profile gives applications a combined view of data associated with a person. It brings together profile fragments and event history without pretending every source became one permanently rewritten row.

Profile fragments

Each profile-enabled dataset can contribute a fragment: CRM attributes, loyalty data, consent state, commerce history, and other records. Identity Service links compatible identities according to namespaces and graph rules. The combined profile exposes attributes and events for use by audiences and applications.

The source datasets remain governed data stores. Correcting a profile issue often requires fixing the source or identity relationship, not editing a fictional master table.

Why merge policies exist

Two datasets may contain different values for the same record attribute. A CRM says preferred language is English; a recent preference-center record says Spanish. A merge policy determines which fragment supplies the value displayed in the combined profile.

This applies to record attributes. Experience events remain time-series occurrences rather than competing for one “winning” event.

Timestamp-ordered precedence

Timestamp precedence chooses the value from the fragment with the most recent relevant update. It works when sources update timestamps reliably and “latest wins” reflects the business rule.

It can be unsafe when a lower-authority source sends a newer but less trustworthy value. A late file or clock problem can also make “newest” misleading. Validate source timestamp semantics before selecting it.

Dataset precedence

Dataset precedence uses an ordered list of datasets. A higher-priority authoritative dataset wins conflicts even when another dataset has a newer timestamp.

This fits scenarios where an approved preference center, compliance system, or mastered CRM must outrank less authoritative enrichment. The business—not a universal exam rule—decides which source is authoritative. Do not claim that one merge method always governs consent; design and policy determine it.

Default and active use

A sandbox has a default merge policy used where another policy is not selected. Adobe Experience Platform limits how many merge policies can exist in a sandbox; current documentation specifies five. Edge and audience use cases can impose additional active-on-edge requirements.

Changing the default can alter how many profiles and audiences resolve attributes. Treat it as platform governance, test affected audiences, and coordinate with data owners.

Inspecting a profile

Use the Profile viewer to review:

• known identities and namespaces;
• record attributes and their source;
• ExperienceEvent history;
• audience membership and qualification;
• merge policy used for the view.

If a journey shows an unexpected value, inspect the same identity and merge policy before blaming personalization. A profile may have two unlinked identity graphs, a source may not be Profile-enabled, or a lower-priority dataset may legitimately lose.

Example

Dataset A, mastered preference center:

• language = Spanish
• update time = Monday

Dataset B, web registration:

• language = English
• update time = Tuesday

Timestamp precedence shows English. Dataset precedence with A above B shows Spanish. Neither result is inherently correct without the business rule. If A is legally authoritative, dataset precedence may be appropriate; if the web registration is an accepted preference update, timestamp precedence may be appropriate.

Merge policy and audiences

Audience rules evaluate the profile view produced under the applicable merge policy. A conflict can therefore change qualification. If an audience requires loyalty tier Gold and two sources disagree, the merge policy determines the visible tier.

When comparing an audience count to a source-file count, account for identity stitching, deduplication, Profile enablement, and merge policy. The numbers need not match.

Troubleshooting checklist

1. Search the expected identity and namespace.
2. Confirm whether identity fragments are linked.
3. Identify the contributing datasets.
4. Verify Profile enablement.
5. Inspect conflicting values and timestamps.
6. Confirm selected/default merge policy and precedence.
7. Re-evaluate the audience if needed.
8. Retest the journey with the corrected profile.

Events and merge precedence

Merge precedence resolves conflicting record attributes; it does not select one ExperienceEvent and discard the others. If two sources report purchases, both valid events can remain in history while record attributes such as current tier still require precedence. Keep this distinction clear when an audience combines “current status” with “has performed an event.”

Document the chosen precedence and its business owner so later source additions do not silently change the intended profile view.