Namespace priority
AVAILABILITYEvery customer implementation is unique and tailored to meet a particular organization’s goals, and as such, the importance of a given namespace varies from customer to customer. Real-world examples include:
- Your company might consider each email address to represent a single-person entity and therefore use identity settings to configure the email namespace as unique. Another company, however, might want to represent single-person entities as having multiple email addresses, and thus configure the email namespace as not-unique. These companies would need to use another identity namespace as unique, such as a CRMID namespace, so there can be a single-person identifier linked to the multiple email addresses.
- You might collect online behavior using a “Login ID” namespace. This Login ID could have a 1:1 relationship with the CRMID, which then stores attributes from a CRM system and may be considered the most important namespace. In this case, you are then determining that the CRMID namespace is a more accurate representation of a person, while the Login ID namespace is the second most important.
You must make configurations in Identity Service that reflect the importance of your namespaces as this influences how profiles and their related identity graphs are formed and split.
Determine your priorities
Determination of namespace priority is based on the following factors:
Identity graph structure
If your organization’s graph structure is layered, then namespace priority should reflect this so that the correct links are removed in the case of graph collapse.
TIP-
“Graph collapse” refers to scenarios where multiple disparate profiles are inadvertently merged together into a single identity graph.
-
A layered graph refers to identity graphs that have multiple levels of links. View the image below for an example of a graph with three layers.
Semantic meaning of the namespace
An identity represents a real-world object. There are three objects that are represented in the identity graph. In order of importance, they are:
- People (Cross-device, Email, Phone number)
- Hardware device
- Web browser (Cookie)
Person namespaces are relatively immutable compared to hardware devices (such as IDFA, GAID), which are relatively immutable compared to web browsers. Basically, you (person) will always be a single entity, who can have multiple hardware devices (phone, laptop, tablet, etc.), and use multiple browsers (Google Chrome, Safari, FireFox, etc.)
Another way to approach this topic is through cardinality. For a given person entity, how many identities will be created? In most cases, a person will have one CRMID, a handful of hardware device identifiers (IDFA/GAID resets should not happen often), and even more cookies (an individual could conceivably browse on multiple devices, use incognito mode, or reset cookies at any given time). Generally, lower cardinality indicates a namespace with a higher value.
Validate your namespace priority settings
Once you have an idea of how you will prioritize your namespaces, you can use the Graph Simulation tool in the UI to test out various graph collapse scenarios and ensure that your priority configurations are returning the expected graph results. For more information, read the guide on using the Graph Simulation tool.
Configure namespace priority
Namespace priority can be configured using the identity settings UI. In the identity settings interface, you may drag and drop a namespace to determine its relative importance.
IMPORTANTNamespace priority usage
Currently, namespace priority influences system behavior of Real-Time Customer Profile. The diagram below illustrates this concept. For more information, read the guide on Adobe Experience Platform and applications architecture diagrams.
Identity Service: Identity optimization algorithm
For relatively complex graph structures, namespace priority plays an important role in ensuring that the correct links are removed when graph collapse scenarios happen. For more information read the identity optimization algorithm overview.
Real-Time Customer Profile: primary identity determination for experience events
-
Once you have configured identity settings for a given sandbox, the primary identity for experience events will be determined by the highest namespace priority in the configuration.
- This is because experience events are dynamic in nature. An identity map may contain three or more identities, and namespace priority ensures that the most important namespace is associated to the experience event.
-
As a result, the following configurations will no longer be used by Real-Time Customer Profile:
- The primary identity configuration (
primary=true) when sending identities in the identityMap using the Web SDK, Mobile SDK, or Edge Network Server API (identity namespace and identity value will continue to be used in Profile). Note: Services outside of Real-Time Customer Profile like data lake storage or Adobe Target will continue to use the primary identity configuration (primary=true). - Any fields marked as primary identity on an XDM Experience Event Class schema.
- Default primary identity settings in the Adobe Analytics source connector (ECID or AAID).
- The primary identity configuration (
-
On the other hand, namespace priority does not determine primary identity for profile records.
- For profile records, you should continue to define your identity fields in the schema, including the primary identity. Read the guide on defining identity fields in the UI for more information.
TIP-
Namespace priority is a property of a namespace. It is a numerical value assigned to a namespace to indicate its relative importance.
-
Primary identity is the identity in which a profile fragment is stored against. A profile fragment is a record of data that stores information about a certain user: attributes (for example, CRM records) or events (for example, web site browsing).
