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 contain the same information and can perform the same functions.
However, the difference between the two types is how they are created and subsequently used, which often depends on the context.
First-party cookies are created by the domain (website) the user visits. If User A visits www.hikingapparel.com, a cookie created by hikingapparel.com that stores information about User A, it is deemed a first-party cookie. Essentially, first-party cookies allow the website owner (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 visits directly, hence the name third-party. This is a lot more common among 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 created by besthikesblog.com.
While most websites honor the spirit of cookies – the desire to use them to create a high-end, personalized experience for end-users – some malicious actors use cross-site scripting to get unauthorized access to cookies and, thereby, user data they don’t have the right to.
Modern browsers have been updating how cookies are handled to balance user privacy with the promise of a high-end user experience. As part of this, Google is changing cookie handling with Chrome version 80 in February 2020.
Before we discuss the specific changes in Chrome 80, let’s briefly examine the SameSite cookie attribute.
The ‘SameSite’ cookie attribute allows website owners to manage cookie usage. Specifically, they can declare whether 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 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
Before 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. 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:
Conversion Tracking
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.
- Implement our Javascript SDK for cookie-less tracking.
- Purchase and implement an SSL cert for your custom tracking domain. You must also ensure your offer’s conversion tracking protocol is set to HTTPS iFrame/Image Pixel.
Tracking Links
All TUNE customers must ensure that tracking links sent to TUNE by their partner systems are set to HTTPS. Sharing cookies set on the partner’s website with TUNE is necessary.
For more information on Google’s Chrome 80 update, visit https://blog.chromium.org/2019/12/chrome-80-content-indexing-es-modules.html.