Implementation guide for identity graph linking rules
Read this document for a step-by-step by guide that you can follow when implementing your data with ۶Ƶ Experience Platform Identity Service.
Step-by-step outline:
- Complete prerequisites for implementation
- Create the necessary identity namespaces
- Use the graph simulation tool to familiarize yourself with the identity optimization algorithm
- Use the identity settings UI to designate your unique namespaces and configure priority rankings for your namespaces
- Create an Experience Data Model (XDM) schema
- Create a dataset
- Ingest your data to Experience Platform
Prerequisites for implementation prerequisites-for-implementation
This section outlines prerequisite steps that you must complete prior to implementing identity graph linking rules to your data.
Unique namespace
Single person namespace requirement single-person-namespace-requirement
You must ensure that the unique namespace with the highest priority is always present in every profile. Doing so allows Identity Service to detect the appropriate person identifier in a given graph.
Without a unique namespace to represent your person identifiers, you may end up with a graph that links to disparate person identifiers to the same ECID. In this example, both B2BCRM and B2CCRM are linked to the same ECID at the same time. This graph suggests that Tom, using his B2C login account, shared a device with Summer, using her B2B login account. However, the system will recognize that this is one profile (graph collapse).
Given a unique namespace, (in this case, a CRMID instead of two disparate namespaces), Identity Service is able to discern the person identifier that was last associated with the ECID. In this example, because a unique CRMID exists, Identity Service is able to recognize a “shared device” scenario, where two entities are sharing the same device.
Namespace priority configuration
If you are using the ۶Ƶ Analytics source connector to ingest data, then you must give your ECIDs a higher priority than ۶Ƶ Analytics ID (AAID) because Identity Service blocks AAID. By prioritizing ECID, you can instruct Real-Time Customer Profile to store unauthenticated events to ECID instead of AAID.
XDM experience events
During your pre-implementation process, you must ensure that the authenticated events that your system will send to Experience Platform always contain a person identifier, such as CRMID.
code language-json |
---|
|
code language-json |
---|
|
Do not send an empty string as an identity value when sending events using XDM experience events. If the identity value of the namespace with highest namespace priority is an empty string, the record will be ignored from Real-Time Customer Profile. This applies to both identityMap, as well as fields marked as an identity.
The following example returns an error because the identity value for Phone
is submitted as an empty string.
code language-json |
---|
|
You must ensure that you have a fully qualified identity when sending events using XDM experience events.
code language-json |
---|
|
Set permissions set-permissions
The first step in the implementation process for Identity Service is to ensure that your Experience Platform account is added to a role that is provisioned with the necessary permissions. Your administrator can configure permissions for your account by navigating to the Permissions UI in ۶Ƶ Experience Cloud. From there, your account must be added to a role with the following permissions:
- View Identity Settings: apply this permission to be able to view unique namespaces and namespace priority in the identity namespace browse page.
- Edit Identity Settings: apply this permission to be able to edit and save your identity settings.
For more information on permissions, read the permissions guide.
Create your identity namespaces namespace
If your data requires it, you must first create the appropriate namespaces for your organization. For steps on how to create a custom namespace, read the guide on creating a custom namespace in the UI.
Use graph simulation tool graph-simulation
Next, navigate to the graph simulation tool in the Identity Service UI workspace. You can use the graph simulation tool to simulate identity graphs, built with a variety of different unique namespace and namespace priority configurations.
By creating different configurations, you can use the graph simulation tool to learn and better understand how the identity optimization algorithm and certain configurations can affect how your graph behaves.
Configure identity settings identity-settings
Once you have a better idea of how you want your graph to behave, navigate to the identity settings UI in the Identity Service UI workspace. To access the identity settings UI, select Identities from the left navigation and then select Settings.
Use the identity settings UI to designate your unique namespaces and configure your namespaces by order of priority. Once you are finished with applying your settings, you must wait at least six hours before you can proceed to ingest data, as it takes at least six hours for new settings to be reflected in Identity Service.
For more information, read the identity settings UI guide.
Create an XDM schema schema
With your unique namespaces and namespace priorities established, you can now proceed to required set up in order to ingest your data. First, you must create an XDM schema. Depending on your data, you may need to create a schema for both XDM Individual Profile and XDM ExperienceEvent.
To ingest data into Real-Time Customer Profile, you must ensure that your schema contains at least one field that has been designated as the primary identity. By setting a primary identity, you can enable a given schema for Profile ingestion.
For instructions on how to create a schema, read the guide on creating an XDM schema in the UI.
Create a dataset dataset
Next, create a dataset to provide a structure for the data that you are going to ingest. A dataset is a storage and management construct for a collection of data, typically a table, that contains a schema (columns) and fields (rows). Datasets work in tandem with schemas, and to ingest data to Real-Time Customer Profile, your dataset must be enabled for Profile ingestion. In order for your dataset to be enabled for Profile, it must reference a schema that is enabled for Profile ingestion.
For instructions on how to create a dataset, read the dataset UI guide.
Ingest your data ingest
By this point, you should have the following:
- The necessary permissions to access Identity Service features.
- Namespaces for your data.
- Designated unique namespaces and configured priorities for your namespaces.
- At least one XDM schema. (Depending on your data and specific use case, you may need to create both profile and experience event schemas.)
- A dataset that is based off of your schema.
Once you have all of the items listed above, then you can begin ingesting your data to Experience Platform. You can perform data ingestion through several different ways. You can use the following services to bring your data to Experience Platform:
For any feedback, use the Beta feedback option in the Identity Service UI workspace.
Validate your graphs validate
Use the identity dashboard for insights on the state of your identity graphs, such as your overall identity count and graph count trends, identity count by namespace, and graph count by graph size. You can also use the identity dashboard to view trends on graphs with two or more identities, organized by namespace.
Select the ellipses (...
) and then select View more for further information and to validate that there are no collapsed graphs.
Use the window that appears to view information on your collapsed graphs. In this example, both email and phone are marked as unique namespace, so therefore, there are no collapsed graphs in your sandbox.
Appendix appendix
Read this section for additional information that you can refer to when implementing your identity settings and unique namespaces.
Dangling loginID scenario dangling-loginid-scenario
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.
In this example, {loginID: ID_C}
is left dangling and unlinked to a CRMID. Thus, the person entity that this loginID should be associated with is left ambiguous.
In this example, {loginID: ID_C}
is linked to {CRMID: Tom}
. Therfore, the system is able to discern that this loginID is associated with Tom.
In this example, {loginID: ID_C}
is linked to {CRMID: Summer}
. Therefore, the system is able to discern that this loginID is associated with another person entity, in this case, Summer.
This example also shows that Tom and Summer are to disparate person entities that are sharing a device, which is represented by {ECID: 111}
.
Next steps
For more information on identity graph linking rules, read the following documentation: