MERIDIANIdentity and Identity Graphs Overview7:36
The identity problem
The same person looks like different "people" across channels. Anonymous on the website. Authenticated in the app. CRM record with a different email. Loyalty card scanned in store. The identity graph stitches these views into a single profile.
ECID: a8f2…
+
Email: jane@…
+
CRM: c-9924
+
Loyalty: L-3381
↓ stitched into
Jane Doe — Unified Profile
Namespaces and identifiers
Every identifier in MDP belongs to a namespace. Namespaces are how MDP knows that email:jane@ and CRM:c-9924 are different kinds of things even when both are strings.
  • Standard namespaces ship with MDP — Email, Phone, ECID, AAID, IDFA, and others.
  • Custom namespaces are what you create for engagement-specific identifiers — Loyalty ID, Trade Account ID, CRM ID.
  • Identity type matters — namespaces are tagged as Cross-Channel (person-level, like email) or Device (like ECID). Person-level can be marked unique per graph; device-level usually shouldn't be.
  • Priority order determines which identifier "wins" when graphs need to merge. Email and CRM ID typically top the list.
Graph stitching and graph collapse
MDP automatically stitches identifiers together when they appear on the same record. But aggressive stitching can cause "graph collapse" — unrelated people getting merged into a single profile because they shared a device, a browser cookie, or a household IP.

Healthy graph

Email is unique per graph. Two different emails on the same device stay in two separate graphs. Each person keeps their own profile.

Graph collapse

Email NOT unique per graph. Two emails on the same device get merged into one profile. Personalization, suppression, and consent all break.

The rule

Mark person-level namespaces (Email, CRM ID, Loyalty ID) as unique per graph. Leave device-level namespaces (ECID) as not unique. This protects against collapse while keeping device-to-person stitching working.

0:00
1 / 3