How the Sitecore cookie crumbles

AmpleEdge

How the Sitecore cookie crumbles

Since GDPR became an essential part of managing your website, it is unavoidable to also think about the cookies your site leaves behind.

For the Sitecore cookie, it is not apparent how it impacts the privacy of your visitors, and therefore how to qualify it towards GDPR impact.

In this post, we will describe what the Sitecore cookie is, how it works, and give you some guidance on how to approach it in your privacy considerations.

Disclaimer: you should always consult with your legal team and technical team, as the content described here may not apply to your situation. Also, this content assumes the Sitecore Experience Platform 9+.

Cookies and Consent

Before we dive into Sitecore cookies, let's first address what the cookies are.

A cookie - more formally called an HTTP cookie - is a small piece of data a website stores on a visitor's computer by the user's web browser. This way, information can be 'remembered'; for example, it is used to add items to a shopping cart. Cookies help preserve information when you move from page to page, or even when you return to the website after a couple of days.

Cookies are also used to record the user's browsing activity. So that the next time you visit the website, these cookies are read and utilized for personalization and other marketing activities.

So when we talk about cookies, not all of them fall into the same category or behave the same. And looking into those different behaviors, it is crucial to distinguish the first party versus third party cookies.

The first-party cookies are the ones controlled by you and your platform. The third-party cookies are cookies used by 3rd party apps. These can be other marketing platforms, CRM systems, or advertising services. Anything you send your visitors data to or use to analyze your website.

The 3rd party cookies have become an essential aspect of the digital footprint discussion over the past years, with concerns over data breaches and privacy growing. The European Union has introduced legislation (GDPR) to allow more control for citizens of the EU to manage their data. As such, it has impacted the usage of (primarily) 3rd party data collection and the cookie as a gatekeeper.

Therefore, the foremost aspect that GDPR is trying to control is consent. With cookie banners as the most visual outlet. But first look at what consent is, as it is such an important aspect. Consent is:

  1. Freely given. The visitor has the right to provide or decline his consent without suffering any retribution if he refuses to do so.
  2. Specific. The question to which visitor is answering must be transparent. For example, the visitor has the right to know the individual types of data processing and decide which he wants or doesn't want to give consent.
  3. Informed. The visitor needs to be made aware of the impact of what it is consenting to.
  4. Unambiguous. The language of the message must be simple and clearly defined.
  5. Clear affirmative action. The visitor must expressly consent by doing, for example, selecting a checkbox and submitting their preferences.

Nevertheless, we still see these kinds of cookie bars on websites:

A way to simple cookie bar

Yet visitors do not buy these types of cookie bars anymore, as these give no right to decline nor to control what it wants to choose.

Given the requirements to consent, this is the perfect example of how the cookie bar should look:

A more appropriate cookie bar

It gives a clear insight into the purpose of the cookies of a website. And even tho we see numerous variations, the categorization of cookies in these three main categories works best to manage consent:

  1. Necessary
  2. Marketing
  3. Statistics

What approval requires Sitecore?

Now that we have an understanding of the relationship between cookies, privacy, and consent, let see in which category Sitecore cookies belong.

Sitecore typically places three cookies on your computer:

  • ASP.NET_SessionId
  • SXA_WEB
  • SC_Analytics

The first two cookies are the easy picks. Both are necessary and are solely there to ensure a more efficient operation on the servers.

The answer to the question where the SC_Analytics cookie belongs is harder to determine. So we will look into the impact of this cookie with three examples: personalization, Sitecore Forms, and marketing automation.

Personalization

Bakery - getting a croissant

Let's take an example from everyday life. Imagine that you are entering a bakery for the first time. You browse the bakery for a while, and you select a delicious croissant to buy. The people working in the bakery can see you, and they know what you are browsing while going from counter to counter.

You selected what you want to buy, and you proceed with the payment. The cashier has no idea who you are, but he sees that you purchased croissants and offers you a chocolate croissant.

How would this translate to Sitecore?

The equivalent of the bakery visitor would be a visitor arriving at your website for the first time. When he opens your website in his browser, a session gets initialized. The visitor browses the site, going from page to page, and by browsing the assortment, the visitor triggers a couple of goals with engagement values assigned to them.

All this behavior (visiting pages) and actions (triggering goals) will be remembered by Sitecore in the session state, allowing you to apply personalization roles to respond to previous behavior. The equivalent of the cashier in the bakery offering you chocolate croissant, because you have shown an interest in croissants.

So, how does that and the cookie fit in this scenario and analogy? For that, imagine you would visit the bakery the next day for the second time. The cashier recognizes your face from the last visit and offers you another sweet croissant as he remembers you purchased them the day before.

This is where the SC_Analytics cookie comes in to play on the Sitecore side. As a webserver can not just see a face, they use cookies to recognize you on a return visit. When you come to the website which is running on Sitecore, the session gets initialized, and you receive the SC_Analytics cookie.

So by default, when your visitor will decline the Sitecore cookie, it does not take away the ability to personalize. You will still be able to apply personalization in the context of that session. Refusing the cookie will, however, take away the ability to recognize the visitor on a return visit.

A behavior closely related to this is Sitecore's ability to collect analytics. Sitecore calls this 'tracking.' After every session, the behavioral data received with that visit gets stored in Sitecore's Experience Database (xDB).

The SC_Analytics cookie contains a key that Sitecore stores with the tracking data in the xDB. On a next visit (session), Sitecore will use that key to retrieve the previously stored tracking data, and at the end of the visit to the site, it stores the newly tracked data with the same key. This way, Sitecore assembles the history of a visitor, what we often refer to as the Experience Profile.

Example of a Sitecore Experience Profile

Refusing the SC_Analytics cookie will not stop Sitecore from tracking, or collecting the visitor data. It will hinder Sitecore in recognizing a visitor, and use the insights collected on previous visits for personalization.

So with the SC_Analytics cookie and the tracking, you allow Sitecore not only to recognize a visitor (remember his face) but also to remember his past actions and interests (loves croissants).

Please note that by default, your actions are unknown. The collected data will appear in aggregated reports as a visitor who has browsed the website. But personal data remains anonymous, making it GDPR compliant. Privacy sensitive data like IP addresses (also known as PII-data) are not collected or made unreadable (hashed).

All this behavior can be set up differently, so verify your setup with your developers, and if needed point them to Sitecore's privacy guide.

Sitecore Forms

Now let's go to the bakery again. The bakery is on your way to work, and you started to go there frequently. And as a frequent visitor, a membership card is being offered.

With this card, you can collect points to get additional discounts and be informed when they have new promotions. To get a membership card, you need to share personal data with the bakery.

The equivalent of sharing information with Sitecore is Sitecore Forms. Forms allow you to ask for information from your visitors. However, this data is typically privacy sensitive, and you will have some processing of that data in your organization. And you can not assume anymore that people who submit their contact details want automatically to be contacted and to be signed up for the newsletters. So you will most likely need to ask for consent on that form to be compliant with (GDPR) regulations.

By default, Sitecore offers the ability to store the submitted data in a database that is separate from the Experience Database. For that, we use the 'save data'-submit action.

But how does this all relate to the Sitecore cookie? Well, there is no direct relationship. Accepting or refusing the SC_Analytics cookie has no direct influence on the way forms work, or how you process the consent.

If your visitor blocks the SC_Analytics cookie, the next time he will visit your website, he is anonymous again. Meaning no previous context is available, including any consent given or refused.

Marketing Automation

In our bakery example, you already have a membership card, and you have submitted your data to receive new promotions.

This is where the two stories unite. The bakery will want to use Sitecore's Marketing Automation and Email Experience Manager (EXM) to send out promotions to their customers.

Example of Sitecore's preference center.

Marketing automation works with data that is "more" than the standard profile. The data you collect and assign to a profile depends entirely on your business needs and requirements. Yet this data is typically PII sensitive, which has an impact on how we handle this data when a visitor exercises his right of opposition, and we anonymize a profile. At which point, we need to destroy all PII classified data of the Experience Profile.

A perfect example of how to give to a user full overview and rights to their data is Subscription management in EXM. We use EXM to send promotions and newsletters, but the user has a clear overview that it can opt-out at any time.

How does all of this relate to a cookie? As in all previous examples, we only use the ID of the cookie to link the visitor with its Sitecore profile. Once again, there is no personal information available on a cookie itself. Even if you block cookies, this will not stop organizations from sending a personalized email through EXM. The only way to do that is by opting out, and that has no relation with the cookie itself.

Summary

Blocking cookies does not imply blocking of personalization nor tracking. From the visitor's perspective, it is a good idea to provide the transparency that you serve personalized content. How you capture and process the data, has no connections with a cookie but with data storing and data processing. For that, your organization is responsible.

You should always consult with your legal department before you make any decision. No one solution fits them all since every business has different requirements and different platforms that are connected.


AmpleEdge

Boris Leenaars

Founder

Boris has been building for the world wide web since 1996.

Do you have questions?  Boris is happy to help!

  • LinkedIn icon
  • Twitter icon
  • Calendar icon