Recently on Sitecore Stack Exchange, a question was asked regarding the Email Experience Manager (EXM) process and having a double opt-in form for a newsletter subscription. The root of the question actually had nothing to do with EXM and instead, how to manage contacts versus managing users. A lot of early implementations of EXM (and ECM) used the Engagement Plan as the source of how to manage subscribers. However, in later versions of EXM (around 3.2 or 3.3), this was eliminated and subscriptions were only managed by Sitecore’s List Manager. Because of this, the Supervise method in Engagement plans stopped working, which relied on Users, not Contacts.
One of the often forgotten things in Sitecore implementations is managing the Contact cookie. This blog post hopes to shine a light into why users and contacts are so important and provide insight into why purposeful management of the Analytics contact cookie is important to consider.
What is a User?
A USER is an authenticated account residing in the .NET Membership Database or other Federated Authentication service. Users are typically bound to a domain such as sitecore or extranet, or any other configured domain in Sitecore. A user typically has a Profile (ASP.NET Membership Profile) associated with the account that can store various values. The default structure of a username is in the format of domain/username.
What is a Contact?
A CONTACT is a marketing term identifying a visitor to the website. A contact record and associated ID always exists for a visitor on the browser. There are primarily two types of Contacts: an Anonymous Contact and a Known Contact.
Contacts have Facets that provide a place to store Contact information, like Personal Information (name, surname, birthday, gender, etc), Contact Street Addresses, and Email Addresses. The Contact model can also be extended to store custom contact data.
Sitecore personalization can be used to read information from the contact facets for various personalization rules and List Segment Conditions can also be created to automatically create Contact Lists based off of facet information.
The difference between the two types of Contacts is that the visitor has provided some sort of identifying information that allows the site to programmatically identify a contact with some tangible and unique identifier. The most common types of identifiers are Email Addresses and Usernames.
Contacts are stored in Session during the visitor’s visit to the website via a cookie. One a visitor leaves the site, during the SessionEnd() process, the contact, any contact information, and interaction tracking information is moved from the session to the Mongo DB (or xConnect Collection). From there, the xDB Processing role of Sitecore will process the Mongo/xConnect Collection and move the information to the Sitecore Analytics index and the Reporting database.
The cookie persists past the visit so that the Contact, upon coming back, can continue to add visit information to the interactions. This cookie CAN be manually reset back to anonymous contact record by forcing both the visit to end and the Session to be abandoned.
Ending the Contact Visit / Resetting the Analytics Contact Cookie
Tracker.Current.EndVisit(true);HttpContext.Current.Session.Abandon();
The code above ends the visit and invalidates the cookie. Secondly, it forces the Session to end and immediately writes data to Mongo via the processEndSession().
Is there any relationship between a User and a Contact?
There is NO relationship in Sitecore, xDB, or xConnect that associates a User to a Contact. Any such relationship has to be done manually by use of identifiers and even then the application has to maintain that relationship. It is completely plausible that somehow a single logged in user might actually have two contact id’s or 1 contact id could somehow be used on two different users. It is up to the custom application to maintain any type of relationship.
Why is managing the contact cookie important?
In most use cases, we are always thinking of a visiting contact as the primary human using the computer to access the website. In most cases, this is fine. However, when you have an authenticated process, where a user can log into your site, it should be considered what happens when a user is using a public computer or sharing a computer with family/household members. I call this the Library Computer Problem.
The reason this problem exists is that of how the cookie is managed and separated from a logged in account. If Person A sits down at a Library computer and performs an action on your site which would identify that contact as a Known contact, the cookie is placed on that computer. Well, what happens if Person A gets up and Person B sits down on the same computer? Unless an action was performed that would tell the website that it’s a different user, any browsing will be done as Person A. Therefore, it’s important that we consider the purposefully ending the visit of a contact when a user logs out.
Sitecore Hacker 
Leave a Reply