Cookies in Site

In this topic:

 

What are cookies and how are they used?

There are essentially two types of cookies: first-party and third-party.

From a technical perspective, there is no real difference between the two, as they contain the same pieces of information and perform the same functions. The difference between the types of cookies has to do with how they are created and subsequently used, which often depends on the context.

There are different benefits of creating first- vs third-party cookies.

First-party cookies are stored by the domain (website) you are visiting directly. They allow website owners to collect analytics data, remember language settings and perform other useful functions that help provide a good user experience.
First-party cookies, as mentioned above, are created directly by the website whenever a user visits the site.
First-party cookies are created by websites within their domains.

Third-party cookies are created by domains other than the one you are visiting directly, hence the name “third-party”.
They are used for cross-site tracking, retargeting and ad-serving.
Third-party cookies are placed not by the website, but by third-parties, e.g. advertisers. 

 

How does Site use cookies?

With all that said, let’s see how Site uses cookies.

In order for you to use Site in the first place, you need to install the Site Script / code snippet on your website. This snippet can be found in the Configuration inside Engage’s admin panel.

This enables you to place a first-party cookie on the browser of the user that visits your site.

As your user interacts with your website, you can pass the user’s behavioral and interest data to Site through the Script.

The Site Script uses first-party cookies to extract identification information about the user to map to the user’s behavior and interest data. This data is then used by Site to power your personalization activities.

Site also uses third-party cookies.

If you own multiple websites that live on different domains and are registered in the same Site universe a third-party cookie will be used to track the user journey across those websites (cross-domain tracking).

As a user hops from one domain to another, the browser communicates with the backend server of Site, and in this process, a third-party cookie is created and placed on the user’s browser.

Note however that third-party cookies are only used to track the behavior of anonymous users.

Through the third-party cookie that lives on the user’s browser, Site is able to deliver a consistent experience across different domains for a single user.

 

Cookies used by Site

Below is an overview of all cookies used by Site.

NAME TYPE CATEGORY LIFETIME VALUE CREATED PURPOSE CONSEQUENCE IF DISABLED
sbt_i Persistent First-party first-party profiling 365 days Unique Site Identifier (hash containing Site id, CRM id, Custom id) Upon first hit This cookie stores the Site profile identifier which allows us to identify a 'device' for the tracked domain. The cookie also stores the Custom identifier when applicable and the Engage identifier when applicable (called CRM identifier) Tracking will be no longer possible, and no reporting on these profiles
sbt_p Persistent First-party first-party profiling 365 days Compressed profile information for non-quality profiles with a size less than 4Kb While the profile is not a quality profile and its size is less than 4Kb This cookie stores the Site information for non quality profiles​ Tracking will be no longer possible, and no reporting on these profiles
sbt_pi Persistent First-party first-party profiling 365 days Returned profile information (JSON) Upon request (if the user uses the saveProfileInfo method on the API) This cookie stores the result of the tracking call when the method BT.saveProfileInfo is called Profile information will be only available as the result of a tracking call
sbt_dnt Persistent First-party Functionality 31 days 1 When the contact has been opted out using the DSR tool, the Optout field in Engage gets a specific value (20180525). During the nightly sync between Engage and Site, this Optout field will automatically be synced together with all other exposed fields. When the Optout value is filled in, and the visitor identifies themselves on the website, the Do Not Track value will be set to true automatically and no profile data will be tracked. A cookie sbt_dnt is placed to avoid any future tracking. This cookie stores information if the visitor can be tracked or not. DNT setting will be ignored and a tracking call will be sent upon each request
sb_<universeGUID> Persistent Third -party first-party profiling 12 months Unique Site Identifier (GUID for Global Universe Identifier) Upon first hit on the universe This cookie is used to store profile information over different website domains, which enables cross-domains tracking. No re-identification when first party cookies are deleted and no cross-domain tracking possible
sbss_<universeGUID> Persistent Third -party first-party profiling 12 months Unique Site Identifier (GUID for Global Universe Identifier) Upon first hit on the universe This cookie is used to store profile information over different website domains, which enables cross-domains tracking. It has been created to support the new Google Chrome third party cookie policy No re-identification when first party cookies are deleted and no cross-domain tracking possible

 

What happens when cookies are deleted

A visitor is recognized by a unique identifier stored on the visitor's device,  in a cookie. But what happens when the visitor deletes his browsing data and with that also this identifier?

The Site identifier that has been created on the device is no longer available. If the visitor lands directly on the website without passing by an email, a new identifier is set on the device and a new anonymous profile will be built. If the visitor lands on your website by clicking through in a Engage Campaign email, the tool will automatically re-identify the visitor and merge his previous identified profile with the new data.

If he was custom identified before, and again logs in on the website, he is also automatically re-identified and his profile data merged.

 

Same Site Cookies

Google Chrome SameSite cookie policies

Google uses the SameSite cookie policies by default for users from Chrome 80 version onwards

Starting with Chrome 80, web developers must explicitly specify which cookies can work across websites.

Google’s cookie recipe

To provide safeguards around when cookies are sent across sites so that users are protected, Google added support for an IETF standard called SameSite, which requires web developers to manage cookies with the SameSite attribute component in the Set-Cookie header.

There are three different values that can be passed into the SameSite attribute: Strict, Lax, or None.

Value Description
Strict Cookies with this setting can be accessed only when visiting the domain on which it was initially set. In other words, Strict completely blocks the cookie from being used across sites. This option would be best for applications that require high security, such as banks.
Lax Cookies with this setting are sent only on same-site requests or top-level navigation with non-idempotent HTTP requests, like HTTP GET . Therefore, this option would be used if the cookie can be used by third-parties, but with an added security benefit that protects users from being victimized by CSRF attacks.
None

Cookies with this setting will work the same way as cookies work today.

Keeping the above in mind, from version Chrome 80 onwards there are two independent settings for users: "SameSite by default cookies" and "Cookies without SameSite must be secure." These settings are enabled by default from Chrome 80 onwards.

  • SameSite by default cookies : When set, all cookies that don’t specify the SameSite attribute will automatically be forced to use SameSite = Lax .
  • Cookies without SameSite must be secure : When set, cookies without the SameSite attribute or with SameSite = None need to be Secure. Secure in this context means that all browser requests must follow the HTTPS protocol. Cookies that do not adhere to this requirement are rejected. All websites should use HTTPS to meet this requirement.

Site follows Google's security best practices

At Marigold, we always want to support the industry’s latest best practices for security and privacy.

We are happy to announce that Site supports the security and privacy settings introduced by Google.

For the "SameSite by default cookies" setting, Site will continue to deliver personalization without any impact and intervention by you.

Site uses first-party cookies and will continue to function properly as the flag SameSite = Lax is applied by Google Chrome.

For the "Cookies without SameSite must be secure" option the first-party cookies in Site will continue to work.

However, when you want to use Site across multiple domains, Chrome requires SameSite = None and Secure flags to be used for third-party cookies.

Site will automatically use the HTTPS protocol and attach the SameSite = None and Secure flags to third-party cookies in Site to ensure that all activities continue to deliver.

What is the impact if you don’t move over to using the HTTPS protocol?

The only use case that will impact you is if you are using Site in a cross-domain tracking perspective.

Without using HTTPS, which is a requirement by Google, you will see a spike in unique visitors across your domains because the third-party cookie we use will be dropped by Google.

And because the third-party cookie will be dropped, Site will not be able to provide a consistent and personalized experience for that user as the user navigates from one domain to another.

The third-party cookie is mainly used to identify a single user navigating across domains you own.

 

Impact of phasing out of Google Third-Party Cookies

Google recently announced to phase out third-party cookies on chrome browsers by second half of 2023 (no exact date has been announced). So what does this mean for Site users?

Site Site only uses third party cookies to track anonymous profiles over different domains or when a visitor deletes the first-party cookie from his browser.

When third-party cookies are no longer available, tracking of anonymous users will only be possible on a single domain. Cross domain tracking for universes with multiple domains will no longer be possible. There is however no impact on tracking of known contacts over multiple domains as identification of a know contact is done in a different way. (Engage identification and customer identification).


How does Site work with cookies

First thing you need to know is that there are 2 types of profiles in Site: an identified profile or a anonymous profile.

An identified profile contains data of a visitor that has been identified thanks to:​

  • a CRM identifier : Campaign id given when a visitor arrives on a website via a Campaign email or page.
  • a Custom identifier : id given as the visitor logs in on the portal website.

An anonymous profile contains data of a visitor who is not CRM or Custom identified.​ Anonymous profiles are given a Site id used to recognize the visitor when he returns later on. That id does not allow to identify him.

There are different scenario's where cookies are used for cross-domain tracking:

An anonymous visitor visits the different websites directly.

Without third-party cookie, it is not possible to track an anonymous visitor across different domains

An unknown CRM identified visitor visits the website coming from an Engage email or page.

A known CRM identified visitor visits the website coming from an Engage email or page.

When the user deletes his first-party cookies.

Without third-party cookie, it is not possible to track a visitor across different domains if has deleted his first-party cookies.

Without third-party cookie, it is possible to track a visitor across different domains if has deleted his first-party cookies, after he gets identified again (by clicking on a Engage email or page, or logging in on a website).

 

Cookies and Browsers (latest update August 2022)

BROWSER WORLD % EU % FIRST-PARTY COOKIE THIRD-PARTY COOKIE
Chrome 65% 59% OK Will end by second half of 2024
Safari 19% 20% lifetime = 7 days Blocked by default
Edge 4% 6% OK Not blocked by default
Firefox 3% 7% OK Blocked by default