AEP interview questions on identity: the scenarios and how to answer them

Why this matters

Without proper identity resolution, user profiles become fragmented or merged incorrectly, leading to inaccurate insights and poor personalization. A shared laptop scenario, where multiple people use the same browser, can cause profiles to collapse into one—misrepresenting user behavior and breaking segmentation. This happens when the browser ID is set as primary without a person-level ID, allowing the identity graph to link unrelated users.

If identity values arrive without the correct namespace or are missing, profiles won’t merge, causing data gaps. This leads to incomplete customer journeys and ineffective targeting. The risk is amplified when datasets aren’t enabled for profile, or when the wrong identifier is marked as primary. Without clear, actionable checks—like verifying source identifiers, namespace accuracy, and profile enablement—the system fails to build accurate, reliable user records. This directly impacts campaign performance and journey optimization decisions.

The key ideas

An identity namespace tells you what kind of identifier a value is—like ECID for a browser, Email, or a CRM ID. This helps systems understand the context of each identifier. The primary identity is the one a record is stored against in the profile, and a schema can mark one field as primary. When multiple identifiers appear together—like a browser ID and a CRM ID on the same login—the identity graph links them, showing they belong to the same user.

A key issue is when profiles collapse incorrectly, such as when a shared laptop assigns the same browser ID to multiple people. This happens because no person-level ID is set as primary, and the identity graph links all identifiers under one profile. To prevent this, you should define a person-level identifier as primary and ensure the identity graph only links when there’s strong evidence of user connection.

If data arrives but doesn’t join a profile, common causes include missing identity values, a wrong namespace, or a dataset not enabled for profile. A strong answer starts with the data: list which identifiers arrive, which one should be primary, and what the identity graph will link. This shows practical understanding. You can demonstrate experience by stating what you’d check—first, verify identity values; second, confirm the correct namespace; third, ensure the dataset is active in profile.

How to apply it

Start by reviewing the data sources and the identifiers they send. For each source, identify which identifier is valid and what namespace it belongs to—such as ECID for browser or Email for registration. Then, determine which identifier should be the primary identity in the profile schema, typically the one that’s most reliable and unique per person, like a person-level email. This choice directly impacts how profiles are built and merged.

Next, examine how the identity graph connects these identifiers. If multiple identities appear together—like a browser ID and a CRM ID on the same event—they will link, forming a unified profile. But if no identity is properly marked as primary, or if a value lacks the correct namespace, the graph may fail to join, leading to profile fragmentation or missed data.

Finally, verify that all datasets are enabled for profile and that the identity values are correctly mapped. Check in order: presence of identity, correct namespace, primary identity designation, and graph linkage. This sequence shows practical, hands-on understanding and directly addresses common failure points in identity resolution.

Mistakes to avoid

• A common mistake is using a browser ID as the primary identity without considering shared devices, leading to profile collapse across family members. This happens when the identity graph links multiple people to one browser ID. To avoid it, set a person-level identifier—like an email—as primary and ensure the identity graph only links based on verified, intentional matches.

• Another mistake is missing identity resolution due to incorrect namespace or disabled datasets. If a value lacks a proper namespace (e.g., labeled as Email but actually a phone number), or if the dataset isn’t enabled for profile, data won’t join. To prevent this, verify incoming identifiers, confirm correct namespace assignment, and ensure all relevant datasets are active in profile. Always check in order: presence of identity value, correct namespace, dataset enablement.

Quick checklist

• Confirm which identifiers arrive from each data source and their associated namespaces (e.g., ECID, Email, CRM ID).
• Identify the intended primary identity field in the profile schema and justify why it is the most reliable.
• Verify that the identity graph is configured to link identifiers seen together, such as during login events.
• Check that all relevant datasets are enabled for profile and that identity values are not missing or corrupted.
• Ensure the namespace for each identifier is correctly defined to avoid misclassification (e.g., Email vs. Phone).
• Review the profile merge logic to confirm it aligns with business requirements, especially in shared device scenarios.
• Validate that the identity graph does not create false links due to overlapping identifiers on the same device.
• Use a practice sandbox to simulate merge scenarios and verify outcomes before deploying to production.