I85PREP
⌘ K
Adobe Real-Time CDP Developer Expert study materials
Adobe Real-Time CDP Developer Expert study resources

Two Namespaces, One Customer, Zero Merge

Adobe Real-Time CDP Developer Expert · Put your knowledge to work in context.

All case studies

Two Namespaces, One Customer, Zero Merge

A retailer ingests two data streams into the same profile-enabled dataset. Stream A carries CRM records with crmId mapped to a custom identity namespace RetailCRM. Stream B carries web behavior with email mapped to the Email namespace. Both streams include a hashed loyalty number, mapped to a third namespace Loyalty. The identity graph is configured so RetailCRM and Loyalty are in the same namespace group, but Email is not linked to either. Analysts report that known customers who log in on web are showing as separate anonymous profiles with only email, and their CRM history never appears alongside their web events. Additionally, a small set of profiles show two different crmId values merged together - investigation shows those records share a single loyalty number because a household shares one loyalty account.

1. Explain why the web profiles never merge with CRM profiles, and describe what configuration change would link them.

Read the worked answer

The identity graph only merges identities that are connected through the configured namespace relationships. Email sits outside the namespace group containing RetailCRM and Loyalty, so even when the same person appears under both, the graph has no edge to traverse and the profiles stay separate.

To link them:

  1. Add Email to the same namespace group as RetailCRM and Loyalty (or create a linking relationship), so the graph can traverse email → loyalty → CRM.
  2. Confirm both streams actually carry a shared, consistent identifier. If web events only carry email and never the loyalty number, the graph can still link email ↔ loyalty only if some stream supplies both on the same record. Verify at least one stream emits the email+loyalty pair, otherwise the graph has no bridge.

Note the ordering caveat: identity graph changes are not retroactive for already-ingested data in all cases - plan a backfill or re-ingest of the affected window to realize merges on historical profiles.

2. Evaluate the household loyalty-number collision and recommend how to handle it.

Read the worked answer

This is a false-positive merge caused by treating a shared identifier as a person-level identity. The loyalty account is a household-level key, so using it as an identity namespace edge collapses distinct people into one profile - which is worse than a missed merge because it corrupts downstream audiences, suppression lists, and consent state.

Recommendations:

  1. Stop using the loyalty number as a person identity edge. Either remove it from the namespace group or demote it to a non-identity attribute used for grouping/analytics only.
  2. Establish a true person key - for example, per-person email or a person-level CRM ID - and build the graph on that.
  3. Add collision detection: monitor for profiles where multiple distinct crmId values attach to one loyalty number; alert when the ratio exceeds a threshold.
  4. Remediate existing bad merges: identify affected profiles via the collision query and correct them through profile deletion/re-ingest of the affected identities rather than leaving corrupted merged profiles in place.
  5. Document the identity model so future source onboarding does not reintroduce household keys as person edges.