Sitecore CDP tracks user behavior by linking browsing sessions, events, and orders to guest profiles. By default, guests are marked as “visitors,” meaning we don’t know who they are. A guest can become a “customer,” which means we know who they are. To identify a guest, we need to send an email “Identify” event. The Identify event is a specific event type that instructs Sitecore CDP to initiate the identity resolution process. This process is well documented, and I didn’t really understand it until I needed to apply it myself. If you are confused about identities in the CDP, read on!
Background
A guest profile is created when you browse the site. Your guest profile is linked to your browser via a browser ID. By default, your guest profile has a status of “visitor.” To be recognized as a customer, you need to send an Identify event. You can send an Identify event when you collect identifying information about a person. This could result from logging into an event, filling out a contact form, or signing up for a newsletter. When you send an Identify event, you include an identifier property in the event object. This identifier property contains attributes for the provider and ID.
var event = {
“channel”: “WEB”,
“language”: “en”,
“currency”: “USD”,
“page”: window.location.pathname + window.location.search,
“email”: “clint.barton@shield.gov”,
“firstname”: “Clint”,
“lastname”: “Barton”,
“identifiers”: [
{
“id”: “clint.barton@shield.gov”,
“provider”: “email”
}
]
}
engage.event(“IDENTITY”, event);
Identification Solution
When you send an Identify event, the CDP will store the identification values in the guest’s identifier array associated with your browser ID. The CDP will use the string values from the provider property to search for all guests within the same provider that match the corresponding ID. If nothing is found, the guest profile status changes to “Client” because it now knows who you are. If another client with the same provider/ID is found, it merges the existing guest profile with the current guest client profile. This process is known as identity resolution.
Enabling debug mode for the CDP and viewing guest properties makes the identification resolution process more meaningful. The CDP has an internal property called “Identifier” for each guest. Take note of how the attributes sent in the Identify event are stored with the guests.
- CDP Debug Information Displaying Empty Identifier Attributes
CDP Debug Information Displays Identifier Properties with Providers
Multiple Identifiers
In the real world, we have many ways to identify individuals: date of birth, social security number, driver’s license ID, passport ID, email, username, account ID, etc. The CDP allows for multiple identifiers for digital equivalence. Each guest profile can store multiple identifiers.
CDP Debug Information Displays Identifier Properties with Two Providers
You can send multiple provider/ID values in the identifier properties of the identity event.
var event = {
“channel”: “WEB”,
“language”: “en”,
“currency”: “USD”,
“page”: window.location.pathname + window.location.search,
“email”: “clint.barton@shield.gov”,
“firstname”: “Clint”,
“lastname”: “Barton”,
“identifiers”: [
{
“id”: “clint.barton@shield.gov”,
“provider”: “email”
},
{
“id”: “c_barton”,
“provider”: “username”
}
]
}
engage.event(“IDENTITY”, event);
Identity Rules
The CDP uses email by default, but it allows you to create up to 5 identity rules.
Identity Rules in Sitecore CDP
Imagine you have an identity rule for usernames. In the CDP, you would define a new rule called “username.” When you send an identity event, you can pass {provider: username, id: c_barton}. The CDP will store this value in the guest’s identifier properties just as it does with email. This means there are now two ways to identify guests.
The CDP does not allow you to set the order of the rules. However, you can send identity events to the identity providers in the order you want them processed. If the CDP does not match with the first listed provider, it evaluates the values of all remaining providers in the order they are listed.
Conclusion
The most important thing to understand about identity rules and the identity resolution process is that the provider is simply a string label. You can call it “abracadabra,” “alohomora,” or “supercalifragilisticexpialidocious.” Just ensure that you send the same string label in the identity event so that the identity resolution process can match correctly with the guests.
you may be interested in this blog
Oracle enterprise Data management (EDMCS)
Top Future Trends in HANA Architecture (2024 and Beyond)
MASTER SAP BUSINESS PROCESS INTEGRATION IN COMPLEX IT LANDSCAPES
Decoding Complex Salesforce Concepts “A Good – Friendly Guide”