Sitecore CDP tracks user behavior by linking browsing session, events, and orders to a guest profile. By default, guests are marked as “visitors” meaning we do not know who they are. A guest can become a “customer” meaning we know who they are. In order to identify a guest, we must send an “IDENTITY” event. An identity event is a specific type of event that tells Sitecore CDP to begin the identity resolution process. This process is well documented. I read through this documentation multiple times and did not really understand the process until I needed to implement it for myself. If you have been confused by identity in CDP, read on!
Background
A guest profile is created when you browse a site. Your guest profile is linked to your browser through a browser id. By default your guest profile is has the status of visitor. In order to identify as a customer, you must send an IDENTITY event. Any time you collect a piece of information that identifies the person, you can send the IDENTITY event. This event can be the result of logging in, filling out a contact form, or registering for a newsletter. When you send an identity event, you send an identifiers attribute in the event object. This identifiers attribute has properties for 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);
Identity Resolution
When you send an IDENTITY event, CDP will store the identity values in the identifiers array of the guest linked to your browser id. CDP will use the string value in the provider property and search all guests for a matching id within the same provider. If none are found, it changes the status of the guest profile to “customer” since it now knows who you are. If it does find another customer with the same provider/id, it merges the current guest visitor profile with the existing guest customer profile. This process is called identity resolution.
The identity resolution process makes more sense if you enable debug mode for CDP and look at the properties of a guest. CDP has an internal property called “identifiers” for each guest. Notice how the properties you sent in the IDENTITY event are stored with the guest.
CDP debug information showing the empty identifiers property
CDP debug information showing the identifiers property with one provider
Multiple Identifiers
In the real world, we have multiple ways we can be identified: date of birth, social security number, drivers license id, passport id, email, username, account id, etc. CDP allows the same behavior digitally. Each guest profile can store multiple identifiers.
CDP debug information showing the identifiers property with two providers
You can send multiple provider/ids in the identifiers attribute 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
CDP uses email by default, but allows you to create up to 5 identity rules.
Identity rules in Sitecore CDP
Imagine that you have an identity rule for username. In CDP you would define a new rule called “username”. When you send an identity event, you can pass {provider: username, id: c_barton}. CDP will store this value in the identifiers property of the guest just like it did with the email. So now guests have two ways they can be identified. CDP does not allow you to set the order of the rules. But you can send the identity providers in the IDENTITY event in the order you want to process them. If CDP does not find a match with the first listed provider, it evaluates all remaining providers in the order listed.
Conclusion
The most important to know that the identity rules and the identity resolution process is that the provider is just a string label. You could call it “abracadabra”, “alohomora”, or “Supercalifragilisticexpialidocious”. Just be sure to send the same string label in the IDENTITY event so the identity resolution process can match guests correctly.
