Identity namespaces and primary identity in AEP, explained

Why this matters

Setting up a schema without a primary identity prevents Real-Time Customer Profile from building a unified view of a user. Without it, data from different sources—like browser sessions or emails—can’t be linked together, so each interaction remains isolated. This means a user who signs in with an email later browses from a new device will appear as a separate person in the system.

Using non-unique values like shared emails or "unknown" as identities creates false connections. This links unrelated individuals, distorting customer behavior and leading to incorrect targeting or personalization. A clear, well-defined primary identity ensures that each person is accurately tracked and recognized across devices and touchpoints. Without it, the identity graph fails to form reliable connections, and the entire customer profile becomes fragmented and unreliable.

The key ideas

A namespace tells the system what kind of identifier a value is—like Email, Phone, or a company’s internal CRM ID. For example, an ECID identifies a device or browser session, while an email address or CRM number identifies a specific person. In a schema, you mark which fields are identities, and one of them is chosen as the primary identity. This primary identity is essential because it allows the Real-Time Customer Profile to recognize and connect a person across events.

The identity graph links different identities that appear together in the same record or event. So, when an anonymous ECID appears with an email address, the system connects them, forming a profile of the same person. However, if a value isn’t unique—like a shared family email or "unknown"—it can incorrectly link unrelated people. That’s why choosing a unique and reliable identity, such as a known email or CRM number, is critical.

In practice, if you’re setting up a schema for the first time, pick a clear, unique identifier as the primary identity. Use custom namespaces for internal IDs that Adobe doesn’t support. This helps ensure the profile accurately represents each person, not just browser sessions or shared addresses.

How to apply it

When setting up your first Profile-enabled schema, start by defining which fields represent identities. Assign each field a namespace—like Email, Phone, or a custom CRM ID—to clarify what kind of identifier it is. For example, if you’re tracking a customer number from your internal system, create a custom namespace for it. Choose one identity field to be the primary identity—this is the one that defines the person in the Real-Time Customer Profile. Without a primary identity, the schema won’t activate for Profile.

Next, ensure that the identity graph can connect different identifiers. If a record includes both an ECID and an email, the system will link them automatically. But if you use a shared email or a placeholder like "unknown", the system may incorrectly connect unrelated users. To avoid this, always use unique identifiers—such as a known email or a single, persistent CRM number. This way, the identity graph builds accurate connections and keeps your profile data reliable.

Mistakes to avoid

• Avoid marking a non-unique value—like a shared family email or "unknown"—as a primary identity. This incorrectly links unrelated people and creates false associations in the identity graph.

• Don’t assign a primary identity without ensuring it’s unique to a person. Using an ECID or email instead of a shared or placeholder value ensures accurate identity resolution. Without a unique identifier, the identity graph fails to correctly connect users, undermining the entire Profile-enabled schema. Always define the primary identity as a known, one-to-one identifier such as an email or CRM ID. This prevents identity confusion and ensures real-time profile accuracy.

Quick checklist

• Define each identity field in your schema with a clear namespace, such as Email, Phone, or a custom CRM ID.
• Assign one field as the primary identity—this must be a unique identifier for a specific person.
• Ensure the primary identity is a value that uniquely identifies a person, not something shared (like a family email or "unknown").
• Include an ECID field in your schema if you’re tracking device or browser-level data.
• Create a custom namespace for any internal identifiers (like a customer number) that Adobe doesn’t provide.
• Confirm that the schema is configured to support Real-Time Customer Profile by having a defined primary identity.
• Verify that identity values in your data are linked through the identity graph, which connects similar values across events.
• Avoid using non-unique identifiers in primary identity fields to prevent merging unrelated individuals.