Identity Graph Linking Rules configurations guide configurations-guide
- 鈥淐RMID鈥 and 鈥渓oginID鈥 are custom namespaces. In this document, 鈥淐RMID鈥 is a person identifier and 鈥渓oginID鈥 is a login identifier associated with a given person.
- To simulate the example graph scenarios outlined in this document, you must first create two custom namespaces, one with the identity symbol 鈥淐RMID鈥 and another with the identity symbol 鈥渓oginID鈥. Identity symbols are case sensitive.
Read this document to learn about different implementation types that you can configure using Identity Graph Linking Rules.
Customer graph scenarios can be grouped into three different categories.
- Basic: Basic implementations include graphs that most often include simple implementations. These implementations tend to revolve around a single cross-device namespace (for example, CRMID). While basic implementations are fairly straightforward, graph collapse can still occur, often due to shared device scenarios.
- Intermediate: Intermediate implementations include several variables such as multiple cross-device namespaces, non-unique identities, and multiple unique namespaces.
- Advanced: Advanced implementations involve complex and multi-layered graph scenarios. For advanced implementations, it is essential to establish the correct namespace priority order to ensure that the appropriate links are removed, thereby preventing graph collapse.
Get started
Before diving in to the following document, ensure that you familiarize yourself with several important concepts of Identity Service and Identity Graph Linking Rules.
Basic implementations basic-implementations
Read this section for basic implementations of Identity Graph Linking Rules.
Use case: simple implementation that uses one cross-device namespace
Generally, 51黑料不打烊 customers have a single cross-device namespace that is used across all of their properties including, web, mobile, and applications. This system is both industry and geographically agnostic as customers in retail, telecom, and financial services use this type of implementation.
Typically, an end-user is represented by a cross-device namespace (often a CRMID), therefore, the CRMID should be classified as a unique namespace. An end-user who owns a computer and an iPhone and does not share their device, could have an identity graph like the following.
Imagine that you are a data architect at an e-commerce company called ACME. John and Jane are your customers. They are end-users who live together in San Jose, California. They share a desktop computer and use this computer to browse your website. Similarly, John and Jane also share an iPad and occasionally use this iPad to browse the internet, including your website.
Text mode
CRMID: John, ECID: 123
CRMID: John, ECID: 999, IDFA: a-b-c
Algorithm configuration (Identity Settings)
Configure the following settings in the Graph Simulation interface before you simulate your graph.
Simulated graph
In this graph, John (the end-user) is represented by the CRMID. {ECID: 123} represents the web browser that John used on his personal computer to visit your e-commerce platform. {ECID: 999} represents the browser that he used on his iPhone and {IDFA: a-b-c} represents his iPhone.
Exercise
Simulate the following configuration in Graph Simulation. You can either create your own events, or copy and paste using text mode.
Shared device (PC)
Text mode:
| code language-json |
|---|
|
Simulated graph
In this graph, John and Jane are represented by their own respective CRMIDs:
{CRMID: John}{CRMID: Jane}
The browser on the desktop computer that they both use to visit your e-commerce platform is represented by {ECID: 111}. In this graph scenario, Jane is the last authenticated end-user, and therefore, the link between {ECID: 111} and {CRMID: John} is removed.
Shared device (mobile)
Text mode:
| code language-json |
|---|
|
Simulated graph
In this graph, John and Jane are both represented by their own respective CRMIDs. The browser that they use is represented by {ECID: 111} and the iPad that they share is represented by {IDFA: a-b-c}. In this graph scenario, Jane is the last authenticated end-user, and therefore, the links from {ECID: 111} and {IDFA: a-b-c} to {CRMID: John} are removed.
Intermediate implementations intermediate-implementations
Read this section for intermediate implementations of Identity Graph Linking Rules.
Use case: Your data includes non-unique identities
-
A non-unique identity is an identity associated with a non-unique namespace.
-
You must create custom cross device namespaces for 鈥淐RMID鈥 and 鈥淐Chash鈥 to complete the intermediate implementation exercises below. 鈥淐CHash鈥 is a custom namespace that represents a hashed credit card number.
Imagine that you are a data architect working for a commercial bank that issues credit cards. Your marketing team has indicated that they want to include past credit card transaction history to a profile. This identity graph could look like the following.
Text mode:
CRMID: John, CChash: 1111-2222
CRMID: John, CChash: 3333-4444
CRMID: John, ECID: 123
CRMID: John, ECID: 999, IDFA: a-b-c
Algorithm configuration (Identity Settings)
Configure the following settings in the Graph Simulation interface before you simulate your graph.
Simulated graph
There are no guarantees that these credit card numbers, or any other non-unique namespaces, will always be associated to one single end-user. Two end-users may register with the same credit card, there may be non-unique placeholder values that erroneously ingested. Simply put, there is no guarantee that non-unique namespaces will not cause graph collapse.
To solve this issue, Identity Service removes the oldest links and retains the most recent links. This ensures that you just have one CRMID in a graph, thereby preventing graph collapse.
Exercise
Simulate the following configurations in Graph Simulation. You can either create your own events, or copy and paste using text mode.
Text mode:
| code language-json |
|---|
|
Simulated graph
Two different end-users sign up for your e-commerce website with the same credit card. Your marketing team wants to prevent graph collapse by ensuring that the credit card is associated with just one single profile.
Text mode:
| code language-json |
|---|
|
Simulated graph
Due to unclean data, an invalid credit card number is ingested into Experience Platform.
Text mode:
| code language-json |
|---|
|
Simulated graph
Use case: Your data includes both hashed and unhashed CRMIDs
You are ingesting both an unhashed (offline) CRMID and a hashed (online) CRMID. The expectation is that there is a direct relationship between both unhashed and hashed CRMIDs. When an end-user browses with an authenticated account, the hashed CRMID is sent along with the device ID (represented on Identity Service as an ECID).
Algorithm configuration (Identity Settings)
Configure the following settings in the Graph Simulation interface before you simulate your graph.
Exercise
Simulate the following configurations in Graph Simulation. You can either create your own events, or copy and paste using text mode.
John and Jane share a device.
Text mode:
| code language-json |
|---|
|
Due to errors in the hashing process, a non-unique hashed CRMID is generated and sent to Identity Service.
Text mode:
| code language-json |
|---|
|
Use case: Your data includes three unique namespaces
Your customer defines a single-person entity as follows:
- An end-user with an assigned CRMID.
- An end-user who is associated to a hashed email address, so that profiles can be activated to destinations that support hashed email (for example, Facebook).
- An end-user associated with an email addresss, so that support personnel can look up their profile on Real-Time CDP using said email address.
Simulate the following configurations in the graph simulation tool. You can either create your own events, or copy and paste using text mode.
In this scenario, John and Jane both log in to an e-commerce website.
Text mode
| code language-json |
|---|
|
Text mode
| code language-json |
|---|
|
Advanced implementations advanced-implementations
Advanced implementations involve complex and multi-layered graph scenarios. These types of implementations include the usage of namespace priority in order to identify the correct links that must be removed in order to prevent graph collapse.
Namespace priority is metadata that ranks namespaces by their importance. If a graph contains two identities, each with a different unique namespaces, Identity Service uses namespace priority to decide which links to remove. For more information, read the documentation on namespace priority.
Namespace priority plays a critical role in complex graph scenarios. Graphs can have multiple layers - an end-user may be associated with multiple login IDs, and these login IDs could be hashed. Additionally, different ECIDs could be linked to different login IDs. In order to ensure that the right link, in the right layer is removed, your namespace priority configurations must be correct.
Read this section for advanced implementations of Identity Graph Linking Rules.
Use case: You need support for multiple lines of businesses
Your end-users have two different accounts, a personal account and a business account. Each account is identified by a different ID. In this scenario, a typical graph would look like the following:
Text mode*
CRMID: John, loginID: JohnPersonal
CRMID: John, loginID: JohnBusiness
loginID: JohnPersonal, ECID: 111
loginID: JohnPersonal, ECID: 222
loginID: JohnBusiness, ECID: 222
Algorithm configuration (Identity Settings)
Configure the following settings in the Graph Simulation interface before you simulate your graph.
Simulated graph
Exercise
Simulate the following configuration in Graph Simulation. You can either create your own events, or copy and paste using text mode.
Text mode
| code language-json |
|---|
|
| code language-json |
|---|
|
Use case: You have complex implementations that require multiple namespaces
You are a media and entertainment company and your end-users have the following:
- A CRMID
- A loyalty ID
Additionally, your end-users can make a purchase on the e-commerce website and this data is tied to their email address. User data is also enriched by a third-party database provider and is sent to Experience Platform in batches.
Text mode
CRMID: John, loyaltyID: John, Email: john@g
Email: john@g, orderID: aaa
CRMID: John, thirdPartyID: xyz
CRMID: John, ECID: 111
Algorithm configuration (Identity Settings)
Configure the following settings in the Graph Simulation interface before you simulate your graph.
Exercise
Simulate the following configuration in Graph Simulation. You can either create your own events, or copy and paste using text mode.
Text mode
| code language-json |
|---|
|
Text mode
| code language-json |
|---|
|
Text mode
| code language-json |
|---|
|
Text mode
| code language-json |
|---|
|
Text mode
| code language-json |
|---|
|
Next steps
For more information on Identity Graph Linking Rules, read the following documentation: