8.1 Identity Service, Namespaces & Identity Graphs
Key Takeaways
An identity namespace gives an identifier semantic meaning; the same text under different namespaces is not the same identity.
Identity-enabled fields and identityMap data create graph links only when ingested with valid namespace configuration.
A primary identity identifies the principal identity context for a schema record, but it is not automatically the organization's universal golden ID.
Shared or unstable identifiers can collapse unrelated people into one graph, so identity rules and source data quality are critical.
Identity graphs are limited to 50 identities; guardrail handling of excess links does not mean the underlying Profile data is deleted.
8.1 Identity Service, Namespaces, and Identity Graphs
Journey Optimizer needs to know which person an event, audience membership, or profile attribute belongs to. Adobe Experience Platform Identity Service supplies that linking layer.
Identity values need namespaces
An identifier is a value plus its namespace. “12345” could be a CRM customer number, loyalty ID, household ID, or unrelated device value. Namespaces preserve the meaning.
Common namespaces include ECID, email, phone, and organization-defined CRM or loyalty IDs. Namespaces can have identity types that influence graph behavior. Configure custom namespaces deliberately and do not reuse one namespace for semantically different IDs.
Normalization must match the namespace and source design. Do not assume Identity Service universally trims, lowercases, or corrects every value. Email casing, phone formatting, and whitespace should be handled consistently before ingestion according to documented namespace behavior.
Identity fields and identityMap
A schema field can be marked as an identity under a namespace. A payload can also carry identity values in an identity map where supported. When data includes more than one valid identity in the same event or record, Identity Service can create links among them.
For example, an authenticated login event may carry ECID and CRM ID, allowing the anonymous device activity and known customer fragment to join. The link is only as trustworthy as the event. A shared kiosk, recycled phone, or incorrectly populated CRM ID can create a false merge.
Primary identity
A schema defines a primary identity for its records. This establishes the main identity context for data ingestion and Profile. It does not mean that value is always the enterprise's single golden identifier, nor that all other identities are lower quality.
Journey entry also selects or relies on a namespace. A Read Audience journey configured for CRM ID cannot admit a member that exposes only an unrelated namespace. Channel delivery then separately needs the appropriate email, phone, or push address.
Graph quality
A healthy graph connects identities that truly belong to one person. Two major risks are:
- False merge: identities from different people become linked, causing data and personalization to mix.
- Fragmentation: identities for the same person never link, so Profile and audience membership remain split.
Prevent false merges by excluding shared values, validating source authentication, avoiding placeholder IDs, and monitoring graphs with implausible counts. Prevent fragmentation by standardizing namespaces and ensuring trusted authenticated events carry the necessary links.
Identity rules can protect graphs from known problematic relationships. Work with the data architecture team; a journey author should not compensate for graph corruption with canvas conditions.
Guardrails
An identity graph supports up to 50 identities. When graph activity exceeds the guardrail, Identity Service removes older graph links/identities according to its processing behavior so the graph stays within the limit. This affects graph association; it does not mean the underlying records are automatically deleted from Real-Time Customer Profile or the Data Lake.
A graph approaching the limit often signals too many devices, shared identifiers, or source-quality problems. Investigate instead of relying on eviction as normal identity management.
Journey example
A cart event arrives with ECID and authenticated CRM ID. The unitary event configuration uses CRM ID for Profile retrieval. Identity Service links the identifiers from a trusted authenticated event. The journey can retrieve the combined profile and send to the available channel address.
If the event carries only ECID while the journey expects CRM ID and no trusted link exists, the journey cannot assume the conversion. Inspect the graph and the configured namespace.
Troubleshooting
- Search the exact value in the intended namespace.
- Confirm the source payload's identity field or identityMap.
- Verify schema identity markings and primary identity.
- Inspect graph links and timestamps.
- Check for shared/placeholder values.
- Verify the selected journey or audience namespace.
- Inspect the combined profile and channel address.
- Correct the source/link rule and retest.
Privacy and governance
Identities are highly sensitive. Apply identity labels and policy controls, restrict access, and avoid exporting raw graphs casually. Privacy Service requests and consent are separate workflows; deleting a link from a graph is not a substitute for an approved privacy deletion request.
Warning
Never join on a convenient value merely because it is present in both systems. A namespace and trusted co-occurrence establish meaning; a matching string alone does not.
Why is an identity namespace required?
It chooses an email template.
It makes all events business events.
It disables merge policies.
It gives the identifier semantic meaning, distinguishing values such as CRM ID, ECID, email, or phone.
What is a false merge?
Identities belonging to different people are incorrectly linked into one graph.
Two treatments have equal traffic.
A dataset is not Profile-enabled.
An offer has no fallback.
What does the 50-identity graph guardrail imply?
Every customer must have exactly 50 identities.
Excess graph links are handled to keep the graph within the limit, but underlying Profile/Data Lake records are not thereby deleted.
The entire sandbox is deleted at 51.
Only email identities count.
Sections you finish are checked off in the contents.