TUNE is ahead of the game and we are taking the necessary steps with our customers to ensure that the changes proposed to third-party cookies on Chrome 80 do not affect their ability to track and attribute with the highest level of accuracy.
A cookie’s “party” is determined by the domain in which it is created.
There are essentially two types of cookies: first-party and third-party. From a technical perspective, there is no real difference between the two types of cookies; they both contain the same pieces of information and can perform the same functions.
However, the difference between the two types has to do with how they are created and subsequently used, which often depends on the context.
First-party cookies are created by the domain (website) the user is directly visiting. If User A visits www.hikingapparel.com, a cookie created by hikingapparel.com that stores information about User A is deemed a first-party cookie. Essentially, first-party cookies allow the owner of the website (brand/advertiser) to collect analytics and settings information about User A with the goal of providing that user with a personalized experience every time they visit that website.
Third-party cookies are created by domains other than the one the user is visiting directly, hence the name third-party. This is a lot more common in the world of TUNE’s customers. So taking the above example, let us say User A visits www.besthikesblog.com. On this website, there is an advertisement for an awesome jacket to wear to stay warm while hiking. The ad links out to www.hikingapparel.com. As part of that redirect, if the cookie created for User A by besthikesblog.com is shared with hikingapparel.com, then hikingapparel.com has access to a third-party cookie that was created by besthikesblog.com.
While most websites honor the spirit of cookies – which is the desire to use them to create a high-end, personalized experience for end-users – there are malicious actors that use cross-site scripting to get unauthorized access to cookies and thereby user data that they don’t have the right to.
Modern browsers have been updating how cookies are handled to balance the privacy of users with the promise of a high-end user experience. As part of this, Google is making changes to cookie handling with Chrome version 80 in February 2020.
Before we get into the specifics of the changes in Chrome 80, let’s take a quick look at what the SameSite cookie attribute entails.
The ‘SameSite’ cookie attribute allows website owners to manage the usage of cookies. Specifically, they can declare if browser cookies can be shared in a first-party (same-site) or third-party context.
There are three possible values to SameSite:
- None: This is the most lenient configuration as it means there is no restriction on when a cookie can be shared. It can be sent in either the first-party or third-party context.
- Lax: This value for SameSite dictates that cookies can only be shared in a third-party context with an HTTPS request.
- Strict: This value restricts cross-site sharing altogether.
Google Chrome 80 Changes to SameSite
Prior to Chrome 80, the default value for SameSite was “none”. As of February 2020, that will change to the following:
- Cookies without a SameSite attribute will be treated as SameSite=Lax. Essentially, the default value will change from “none” to “lax”.
- Cookies with SameSite=None must also specify “secure”. This means that if a website attempts to set a cookie with SameSite=None and is not marked secure, Chrome will reject it and not set the cookie.
What This Means for TUNE Customers
To ensure customers continue to track and attribute accurately on TUNE, we are working with our customers on the following fronts:
On TUNE, conversions can be tracked through server postback or client-side pixel. For customers using server postback for conversion tracking on their offers, these changes in Chrome 80 have no impact.
For customers using client-side pixels for conversion tracking, there are a few possible scenarios:
For customers using TUNE’s default tracking domain (go2cloud.org) or a custom tracking domain with an SSL cert installed, TUNE is enhancing the platform to explicitly set cookies as secure and SameSite=None. You will simply need to ensure your offer’s conversion tracking protocol is set to HTTPS iFrame/Image Pixel.
For customers using a custom tracking domain with no SSL cert installed, cookies will not be set because the domain is not secure. This means offers using client-side pixels will no longer convert.
Customers in this situation have three options:
- Move away from client-side pixel tracking and adopt attribution via server postback.
- Purchase and implement an SSL cert for your custom tracking domain. You will also then need to ensure your offer’s conversion tracking protocol is set to HTTPS iFrame/Image Pixel.
All TUNE customers will have to ensure that tracking links sent to TUNE by their partner systems is set to HTTPS. This is necessary so that cookies set on the partner’s website can be shared with TUNE.
For more information on Google’s Chrome 80 update, you can visit https://blog.chromium.org/2019/12/chrome-80-content-indexing-es-modules.html.