Identity graph linking rules overview
With Adobe Experience Platform Identity Service and Real-Time Customer Profile, it is easy to assume that your data is ingested perfectly and that all merged profiles represent a single individual person through a person identifier, such as a CRMID. However, there are possible scenarios where certain data could try to merge multiple disparate profiles into a single profile (“graph collapse”). To prevent these unwanted merges, you can use configurations provided through identity graph linking rules and allow for accurate personalization for your users.
Get started
The following documents are essential in understanding identity graph linking rules.
Example scenarios where graph collapse could happen example-scenarios-where-graph-collapse-could-happen
This section outlines example scenarios that you may consider when configuring identity graph linking rules.
Shared device
There are instances where multiple logins can occur on a single device:
In these cases, from a graph standpoint, with no limits enabled, a single ECID will be linked to multiple CRMIDs.
With identity graph linking rules, you can:
- Configure the ID used for login as unique identifier. For example, you can limit a graph to store just one identity with a CRMID namespace, and thus define that CRMID as the unique identifier of a shared device.
- By doing this, you can ensure that CRMIDs do not get merged by the ECID.
Invalid email/phone scenarios
There are also instances of users who provide fake values as phone numbers and/or email addresses when registering. In these cases, if limits are not enabled, then phone/email related identities will end up being linked to multiple different CRMIDs.
With identity graph linking rules, you can:
- Configure either the CRMID, phone number, or email address as the unique identifier and thus limit one person to just one CRMID, phone number, and/or email address associated with their account.
Erroneous or bad identity values
There are cases where non-unique, erroneous identity values are ingested in the system, irrespective of namespace. Examples include:
- IDFA namespace with the identity value of “user_null”.
- IDFA identity values should have 36 characters: 32 alphanumeric characters and four hyphens.
- Phone number namespace with the identity value of “not-specified”.
- Phone numbers should not have any alphabet characters.
These identities could result in the following graphs, where multiple CRMIDs are merged together with the ‘bad’ identity:
With identity graph linking rules you can configure the CRMID as the unique identifier to prevent unwanted profile collapsing due to this type of data.
Identity graph linking rules identity-graph-linking-rules
With Identity graph linking rules you can:
- Create a single identity graph / merged profile for each user by configuring unique namespaces, which will prevent two disparate person identifiers from merging into one identity graph.
- Associate online, authenticated events to the person by configuring priorities
Terminology terminology
Unique namespace unique-namespace
You can configure a namespace to be unique using the identity settings UI workspace. Doing so, informs the identity optimization algorithm that a given graph may only have one identity that contains that unique namespace. This prevents the merging of two disparate person identifiers within the same graph.
Consider the following scenario:
- Scott uses a tablet and opens his Google Chrome browser to go to acme.com, where he signs in and browses for new basketball shoes.
-
Behind the scenes, this scenario logs the following identities:
- An ECID namespace and value to represent the use of the browser
- A CRMID namespace and value to represent the authenticated user (Scott signed in with his username and password combination).
-
- His son Peter then uses the same tablet and also uses Google Chrome to go to acme.com, where he signs in with his own account to browse for football equipment.
-
Behind the scenes, this scenario logs the following identities:
- The same ECID namespace and value to represent the browser.
- A new CRMID namespace and value to represent the authenticated user.
-
If CRMID was configured as a unique namespace, then the identity optimization algorithm splits the CRMIDs apart into two separate identity graphs, instead of merging them together.
If you do not configure a unique namespace, you may end up with unwanted graph merges, such as two identities with the same CRMID namespace, but different identity values (scenarios like these often represent two different person entities in the same graph).
You must configure a unique namespace to inform the identity optimization algorithm to enforce limitations on the identity data that are ingested into a given identity graph.
Namespace priority namespace-priority
Namespace priority refers to the relative importance of namespaces compared to one another. Namespace priority is configurable through the UI and you can rank namespaces in a given identity graph.
One way in which namespace priority is used is in determining the primary identity of experience event fragments (user behavior) in Real-Time Customer Profile. If priority settings are configured, then the primary identity setting on Web SDK will no longer be used to determine which profile fragments are stored.
Unique namespaces and namespace priorities are both configurable in the identity settings UI workspace. However, the effects of their configurations are different:
- Namespace priority does not affect graph behavior when the limit of 50 identities per graph is reached.
- Namespace priority is a numerical value assigned to a namespace indicating its relative importance. This is a property of a namespace.
- 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 (usually ingested via CRM records) or events (usually ingested from experience events, or online data).
- Namespace priority determines the primary identity for experience event fragments.
- For profile records, you can use the schemas workspace in the Experience Platform UI to define identity fields, including the primary identity. Read the guide on defining identity fields in the UI for more information.
- If an experience event has two or more identities of the highest namespace priority in the identityMap, it will be rejected from ingestion because it will be deemed as “bad data”. For example, if the identityMap contains
{ECID: 111, CRMID: John, CRMID: Jane}, the entire event will be rejected as bad data because it implies that the event is associated to bothCRMID: JohnandCRMID: Janesimultaneously.
For more information, read the guide on namespace priority.
Next steps
For more information on identity graph linking rules, read the following documentation: