[Beta]{class="badge informative"}
Examples of graph configuratoions
- “CRMID” and “loginID” are custom namespaces. In this document, “CRMID” is a person identifier and “loginID” 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 “CRMID” and another with the identity symbol “loginID”. Identity symbols are case sensitive.
This document outlines graph configuration examples of common scenarios that you might encounter when working with identity graph linking rules and identity data.
CRMID only
This is an example of a simple implementation scenario where online events (CRMID and ECID) are ingested and offline events (profile records) are only stored against the CRMID.
Implementation:
Events:
You can create this scenario in graph simulation by copying the following events to text mode:
CRMID: Tom, ECID: 111
Algorithm configuration:
You can create this scenario in graph simulation by configuring the following setup for your algorithm configuration:
Primary identity selection for Real-Time Customer Profile:
Within the context of this configuration, the primary identity will be defined like this:
Graph examples
The following is an example of an ideal single-person graph, where CRMID is unique and given the highest priority.
The following is an example of a multi-person graph. This example displays a “shared device” scenario, where there are two CRMIDs and the one with the older established link gets removed.
Graph simulation events input
| code language-shell |
|---|
|
CRMID with hashed email
In this scenario, a CRMID is ingested and represents both online (experience event) and offline (profile record) data. This scenario also involves the ingestion of a hashed email, which represents another namespace sent in the CRM record dataset along with the CRMID.
Implementation:
Events:
You can create this scenario in graph simulation by copying the following events to text mode:
CRMID: Tom, Email_LC_SHA256: tom<span>@acme.com
CRMID: Tom, ECID: 111
CRMID: Summer, Email_LC_SHA256: summer<span>@acme.com
CRMID: Summer, ECID: 222
Algorithm configuration:
You can create this scenario in graph simulation by configuring the following setup for your algorithm configuration:
Primary identity selection for Profile:
Within the context of this configuration, the primary identity will be defined like this:
Graph examples
The following are examples of a pair of ideal single-person graphs, where each CRMID is associated with their respective hashed email namespace and ECID.
The following is an example of a multi-person graph scenario where a device is shared by two people.
Graph simulation events input
| code language-shell |
|---|
|
The following is an example of a multi-person graph scenario where email is not unique and is being associated with two different CRMIDs.
Graph simulation events input
| code language-shell |
|---|
|
CRMID with hashed email, hashed phone, GAID, and IDFA
This scenario is similar to the previous one. However, in this scenario, hashed email and phone are being marked as identities to utilize in Segment Match.
Implementation:
Events:
You can create this scenario in graph simulation by copying the following events to text mode:
CRMID: Tom, Email_LC_SHA256: aabbcc, Phone_SHA256: 123-4567
CRMID: Tom, ECID: 111
CRMID: Tom, ECID: 222, IDFA: A-A-A
CRMID: Summer, Email_LC_SHA256: ddeeff, Phone_SHA256: 765-4321
CRMID: Summer, ECID: 333
CRMID: Summer, ECID: 444, GAID:B-B-B
Algorithm configuration:
You can create this scenario in graph simulation by configuring the following setup for your algorithm configuration:
Primary identity selection for Profile:
Within the context of this configuration, the primary identity will be defined like this:
Graph examples
The following is an ideal single-person graph scenario where hashed email and hashed phone are marked as identities for use in Segment Match. In this scenario, the graphs are split into two, to represent to disparate person entities.
The following is a multi-person graph scenario where a device (computer) is shared by two people. In this scenario, the shared computer is represented by {ECID: 111} and is linked to {CRMID: Summer} because that link is the most recently established link. {CRMID: Tom} is removed because the link between {CRMID: Tom} and {ECID: 111} is older and because CRMID is the designated unique namespace in this configuration.
Graph simulation events input
| code language-shell |
|---|
|
The following is a multi-person graph scenario where an android device is shared by two people. In this scenario, CRMID is configured as a unique namespace, and therefore, the newer link of {CRMID: Tom, GAID: B-B-B, ECID:444} supersedes the older {CRMID: Summer, GAID: B-B-B, ECID:444}.
Graph simulation events input
| code language-shell |
|---|
|
The following is a multi-person graph scenario where an Apple device is shared by two people. In this scenario the IDFA is shared, but the ECID does not reset.
Graph simulation events input
| code language-shell |
|---|
|
The following is a multi-person graph scenario where an Apple device is shared by two people. In this scenario, the ECID resets, but the IDFA remains the same.
Graph simulation events input
| code language-shell |
|---|
|
The following is a multi-person graph scenario where the same phone number is being shared by two people.
Graph simulation events input
| code language-shell |
|---|
|
In this example, {Phone_SHA256} is also marked as a unique namespace. Therefore, a graph cannot have more than one identity with the {Phone_SHA256} namespace. In this scenario, {Phone_SHA256: 765-4321} is unlinked from {CRMID: Summer} and {Email_LC_SHA256: ddeeff} because it is the older link,
The following is a multi-person graph scenario where email is shared by two people.
Graph simulation events input
| code language-shell |
|---|
|
Single CRMID with multiple login IDs (simple version)
In this scenario, there is a single CRMID that represents a person entity. However, a person entity may have multiple login identifiers:
- A given person entity can have different account account types (personal vs. business, account by state, account by brand, etc.)
- A given person entity may use different email addresses for any number of accounts.
Implementation:
Events:
You can create this scenario in graph simulation by copying the following events to text mode:
CRMID: Tom, loginID: ID_A
CRMID: Tom, loginID: ID_B
loginID: ID_A, ECID: 111
CRMID: Summer, loginID: ID_C
CRMID: Summer, loginID: ID_D
loginID: ID_C, ECID: 222
Algorithm configuration:
You can create this scenario in graph simulation by configuring the following setup for your algorithm configuration:
Primary identity selection for Profile:
Within the context of this configuration, the primary identity will be defined like this:
Graph examples
The following is a single-person graph scenario with a single CRMID and multiple loginIDs.
The following is a multi-person graph scenario where a device is shared by two people. In this scenario, {ECID:111} is linked with both {loginID:ID_A} and {loginID:ID_C} and the older established link of {ECID:111, loginID:ID_A} gets removed.
Graph simulation events input
| code language-shell |
|---|
|
The following is a multi-person graph scenario that involves bad data. In this scenario, {loginID:ID_D} is wrongly linked to two disparate users and the link with the older timestamp is deleted, in favor of the more recently established link.
Graph simulation events input
| code language-shell |
|---|
|
The following graph simulates a “dangling” loginID scenario. In this example, two different loginIDs are bound to the same ECID. However, {loginID:ID_C} is not linked to the CRMID. Therefore, there is no way for Identity Service to detect that these two loginIDs represent two different entities.
Graph simulation events input
| code language-shell |
|---|
|
Single CRMID with multiple login IDs (complex version)
In this scenario, there is a single CRMID that represents a person entity. However, a person entity may have multiple login identifiers:
- A given person entity can have different account account types (personal vs. business, account by state, account by brand, etc.)
- A given person entity may use different email addresses for any number of accounts.
Implementation:
Note: By default, AAIDs are blocked in Identity Service, therefore, you must place a higher priority on your ECIDs than AAIDs, when using the Analytics source. Read the implementation guide for more information.
Events:
You can create this scenario in graph simulation by copying the following events to text mode:
CRMID: Tom, Email_LC_SHA256: aabbcc, Phone_SHA256: 123-4567
CRMID: Tom, loginID: ID_A
CRMID: Tom, loginID: ID_B
loginID: ID_A, ECID: 111
CRMID: Summer, Email_LC_SHA256: ddeeff, Phone_SHA256: 765-4321
CRMID: Summer, loginID: ID_C
CRMID: Summer, loginID: ID_D
loginID: ID_C, ECID: 222
Algorithm configuration:
You can create this scenario in graph simulation by configuring the following setup for your algorithm configuration:
Primary identity selection for Profile:
Within the context of this configuration, the primary identity will be defined like this:
Graph examples
The following is an example of two single-person graphs that each have one CRMID and multiple loginIDs.
The following is a multi-person shared device scenario where {ECID:111} is linked to both {loginID:ID_A} and {loginID:ID_C}. In this case, the older established links get removed in favor of the more recently established links.
Graph simulation events input
| code language-shell |
|---|
|
In this scenario, instead of sending only the loginID, both loginID and CRMID are sent as experience events.
Graph simulation events input
| code language-shell |
|---|
|
In this scenario, {loginID:ID_C} is linked to both {CRMID:Tom} and {CRMID:Summer}, and is therefore deemed to be bad data because ideal graph scenarios should not linked the same loginIDs to two disparate users. In this case, the older established links are removed in favor of the more recently established links.
Graph simulation events input
| code language-shell |
|---|
|
In this scenario, a non-unique email is being linked with two different CRMIDs, therefore, the older established links are removed in favor of the more recently established links.
Graph simulation events input
| code language-shell |
|---|
|
In this scenario, a non-unique phone number is being linked with two different CRMIDs, the older established links are removed in favor of the more recently established links.
Graph simulation events input
| code language-shell |
|---|
|
Usage in other Adobe Commerce
The graph configuration examples in this section outline use cases for Adobe Commerce. The examples below are focused on retail customers with two user types:
- Registered user (users that created an account)
- Guest users (users that only have an email address)
Implementation:
Events:
You can create this scenario in graph simulation by copying the following events to text mode:
CRMID: Tom, Email: tom@acme.com
CRMID: Tom, ECID: 111
Algorithm configuration:
You can create this scenario in graph simulation by configuring the following setup for your algorithm configuration:
Primary identity selection for Profile:
Within the context of this configuration, the primary identity will be defined like this:
Graph examples
The following is an example of an ideal single-person graph.
The following is an example of a multi-person graph where two registered users are browsing using the same device.
Graph simulation events input
| code language-shell |
|---|
|
In this scenario, a registered user and a guest user share the same device.
Graph simulation events input
| code language-shell |
|---|
|
In this scenario, a registered user and a guest user share a device. However, an implementation error occurs as the CRMID does not contain a corresponding email namespace. In this scenario, Tom is the registered user, and Summer is the guest user. Unlike the previous scenario, the two entities are merged since there is no common email namespaces across the two person entities.
Graph simulation events input
| code language-shell |
|---|
|
In this scenario, two guest users share the same device.
Graph simulation events input
| code language-shell |
|---|
|
In this scenario, a guest user checks out an item and then registers using the same device.
Graph simulation events input
| code language-shell |
|---|
|
Next steps
For more information on identity graph linking rules, read the following documentation: