How are AEP Identity Namespaces related to AAM Data Sources
This article discusses the correlation between AEP Identity Namespaces, AAM Data Sources, and Customer Attribute data sources created via the People Core Service (which themselves are special AAM data sources available to all customers regardless of AAM License status). To enable the sharing of data between AEP and Experience Cloud Audiences using a SHA256 Hashed email address as well as provide a way to pass identities to AAM and Customer Attributes datasources via the Identity Map Schema Field Group, a type of connection had to be made between AAM data sources and AEP Identity names spaces. Exactly how that connection is made and whether or not an AEP identity namespace was created for the corresponding AAM datasource in question depends on when the AAM or Customer attribute datasource was created.
Description description
Environment
- ÃÛ¶¹ÊÓƵ Experience Platform (AEP)
- ÃÛ¶¹ÊÓƵ Audience Manager (AAM)
- People Core Service (Customer Attributes)
Issues/Symptoms
Is there a relationship between AAM (and Customer Attribute) Data Sources and AEP Identity Namespaces?
Resolution resolution
Yes. They are related in the following ways.:
- All AAM cross-device data sources created in AAM and Customer Attribute data sources created in the People Core Service UI between April 2019 and February 2024 have a corollary AEP identity namespace created in the production sandbox with the same name in the same Experience Cloud Org, even if the Experience Cloud Org was not licensed for AEP.
- All AAM cross-device and Customer Attribute data sources created prior to April 2019 had their corollary AEP identity namespace created in April 2019.
- All AAM cross-device and Customer Attribute data sources created after Feb 2024 have not had a corollary AEP Identity Namespace created for them, but their identifiers can still be passed to AAM and Customer attributes via theIdentity Map Schema Field Group. Additional details below.
- Any automatically-generated identity namespaces have a pointer to but are not the same entity as their AAM cross-device or Customer Attribute data source counterparts. They are separate identities referenced in the same row of a lookup table on the Experience Edge.
- Only AAM cross-device and Customer Attribute data sources can have an identity namespace counterpart. Cookie-based AAM data sources do not.
Given this information, here are some important caveats to be aware of:
- The deletion of an AAM cross-device or Customer Attribute data source with a corollary identities namespace will result in the deletion of that corollary identity namespace.
- Any updates to the AAM cross-device or Customer Attribute data source name or integration code will NOT be reflected in a corollary AEP identity namespace UI.
- The namespace symbol may or may not match the legacy customer attributes alias or AAM integration code. The symbol can be found in one of the ways listed in the next section.
How does one practically apply this information?
If an existing AAM or Customer Attribute implementation needs to be maintained during a migration to the AEP Web or Mobile SDKs, then the way to pass the user or CRM IDs to AAM and Customer Attributes (what was historically done via the setCustomerIDs function/method of the ECID Identity Service) is by setting the SDK Identity Map with the identity namespace symbol  that identifies the AAM or Customer Attributes data source. The identity namespace symbol can be found in a few different ways:
- Use the AEP or Data Collection UI to find the identity namespace that corresponds with the AAM cross-device or Customer Attribute data source in question. If this is not immediately clear or the needed AEP identity namespace is not in the identities UI, then try another one of the options below.
- For those with an AAM license, navigate to Audience Data
>Datasources within the AAM UI. Click into the data source in question and the value in the greyed-out Namespace field is the identity symbol to use. All Customer attribute data sources will also be in the AAM UI, so this method also works for those who use both Customer Attributes and AAM. - Use the AAM API for one of the potential AAM data sources using  to return a JSON payload that contains the
customNamespaceCodefield. The value of that field is the identity symbol to use. The same API call can be used to determine the symbol to use for a Customer Attributes datasource. - If none of the options above work, either because the AEP identity namespace is not in the identities UI or the organization is not licensed for AAM, then contact AAM support and ask for the identity symbol that references the Customer Attributes data source in question.
When the proper identity symbol is in the identity map, the Experience Edge will forward the data collection hit to Audience Manager (assuming the Audience Manager Service is enabled on the datastream) where AAM will see the identity symbol, look up the corollary AAM integration code or Customer Attribute alias, then update the hit with the proper AAM integration code or Customer Attribute alias, thereby allowing the AAM cross-device data source or Customer Attribute Alias to continue collecting user IDs for the AAM and Customer Attribute use cases.
Ensuring the right identities go to the right solution
There are cases where the identities meant for AAM and Customer Attributes should and should not be used for AEP use cases. Keep the following information and tips in mind as you decide which identities need to be send to which solutions:
- AEP will treat any identities passed via the identity map that also has a corollary AEP identity in the AEP Identities UI as stitchable identities, even if the identity namespaces in question are not tied to a profile-enabled XDM field. This can be problematic if the IDs that need to be passed to AAM or Customer Attributes are not individual/profile-level IDs. This can lead to multiple AEP profiles being merged/collapsed into one if the ID in question were a household ID, for example, instead of an individual ID. Using the Identity Graph Linking Rules can help with this situation as well.
- If the identity is passed in via the Identity Map, but that same entity does not exist in the AEP identities UI, then AEP ingestion will throw an error unless there is another identity marked as Primary.
- If the desired functionality is to have AEP and AAM/customer attributes use the same identity, but no AEP identity namespace has been created, then one can be created using the same identity namespace symbol found in the AAM UI (see previous section). This will allow one Identity Map entry to handle sending the ID to AEP, AAM, and Customer Attributes. However, be aware it will be used as a stitch ID as mentioned in the first bullet.
- If the AEP identity namespace is in the AEP identities UI and it has the same identity symbol as the AAM and Customer Attribute dataset, there is no supported way to preventing that identity from getting to AEP.
Related Reading:
AEP Web SDK Authenticated States in AAM: This article discusses the issue where cross-device IDs/data sources are not syncing or behaving in the same way as before you migrated.