Identity graph linking rules are currently in Limited Availability. Contact your Adobe account team for information on how to access the feature in development sandboxes.
Every 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:
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.
Determination of namespace priority is based on the following factors:
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.
“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.
An identity represents a real-world object. There are three objects that are represented in the identity graph. In order of importance, they are:
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.
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.
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.
You cannot prioritize device/cookie namespaces over person namespaces. This restriction ensures that misconfigurations do not happen.
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.
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.
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
).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).
This section provides an example of how priority configuration can affect your data.
Suppose that the following configurations are established for a given sandbox:
Namespace | Real-world application of the namespace | Priority |
---|---|---|
CRMID | User | 1 |
IDFA | Apple hardware device (iPhone, IPad, etc.) | 2 |
GAID | Google hardware device (Google Pixel, Pixelbook, etc.) | 3 |
ECID | Web browser (Firefox, Safari, Google Chrome, etc.) | 4 |
AAID | Web browser | 5 |
Given the configurations outlined above, user actions and determination of primary identity, will be resolved as such:
User action (Experience event) | Authentication state | Data source | Namespaces in event | Namespace of primary identity |
---|---|---|---|---|
View credit card offer page | Unauthenticated (anonymous) | Web SDK | {ECID} |
ECID |
View help page | Unauthenticated | Mobile SDK | {ECID, IDFA} |
IDFA |
View checking account balance | Authenticated | Web SDK | {CRMID, ECID} |
CRMID |
Sign up for home loan | Authenticated | Analytics source connector | {CRMID, ECID, AAID} |
CRMID |
Transfer $1,000 from checking to savings | Authenticated | Mobile SDK | {CRMID, GAID, ECID} |
CRMID |
For a given merged profile, segment memberships will be stored against the identity with the highest namespace priority.
For example, assume that there are two profiles:
If John and Jane share a device, then the ECID (web browser) transfers from one person to another. However, this does not influence the segment membership information stored against John and Jane.
If the segment qualification criteria were solely based on anonymous events stored against the ECID, then Jane would qualify for that segment
This section outlines how namespace priority can affect other Experience Platform services.
Data hygiene record delete requests functions in the following manner, for a given identity:
primary=true
), or a field marked as primary identityFor more information, read the advanced lifecycle management overview.
If identity settings is enabled, then computed attributes will use namespace priority to store the computed attribute value. For a given event, the identity with the highest namespace priority will have the value of the computed attribute written against it. For more information, read the computed attributes UI guide.
Data ingestion to data lake will continue to honor the primary identity settings configured on Web SDK and schemas.
Data lake will not determine primary identity based on namespace priority. For example, Adobe Customer Journey Analytics will continue to use values in the identity map even after namespace priority is enabled (such as, adding a dataset to a new connection), because Customer Journey Analytics consumes their data from data lake.
Any schema that is not an XDM Experience Event, such as XDM Individual Profiles, will continue to honor any fields that you mark as an identity.
For more information on XDM schemas, read the schemas overview.
When selecting your data, you will need to specify a namespace, which will be used to determine the events that compute scores and the events that store the computed scores. You are recommended to select the namespace that represents a person.
This configuration results in computing scores only using authenticated events.
For more information, read the documents on Attribution AI and Customer AI.
Updated audience disqualification results for profiles associated to a shared device may not be sent to downstream destinations. This may happen in certain rare occurrences where:
For more information on partner-built destinations, read the destinations overview.
Privacy Service deletion requests function in the following manner, for a given identity:
For more information, read the Privacy service overview.
Adobe Target may yield unexpected user targeting for shared device scenarios when using edge segmentation.