As of December 2019, Google Chrome was the most popular web browser with a market share of 69%. Google recently released their newest Chrome browser version 80 which introduced clear guidelines around how cookies need to be set moving forward keeping in mind privacy regulations such as GDPR and CCPA. As an example, Safari now completely blocks 3rd party cookies from being set. Given that Google has advertising platforms which primarily leverage 3rd party cookies, there are still a few years left before Google completely phases out 3rd party cookies by 2022 which means we don't have a lot of time left. So, what does it mean for companies like Adobe which also rely on cookies for measuring user behavior using 1st party cookies and activating anonymous profiles on publishers using 3rd party cookies in the interim?
In this post, I will review changes made by the Adobe Identity Service team to address cookie setting requirements in Google Chrome 80. I will refer to this article written by the Adobe Identity service team and validate changes made by Adobe primarily around the Experience Cloud ID Service cookies. So let's dive in!
What is all the Fuss About?
Here, I'll cover exactly was has been changed by Chrome 80 and I've made a simple decision tree to depict what the change is in regards to the new cookie guidelines. At a high level, 3rd party cookies need to be secure with a SameSite attribute equal to "None". On the other hand, cookies without a SameSite attribute will default to "lax".
The World Before Google Chrome 80
I'm first looking at Chrome version 79 and I've visited an Adobe customer website using the Experience Cloud Visitor ID Service.
I'll primarily focus on the demdex which is our 3rd party cookie that is most susceptible to deletion after this change. I previously wrote about migrating to the Visitor ID service where I've covered some of the cookies set by the ID service in more detail. The first thing we see is an error in the developer console specifically calling out the demdex cookie and stating that it's set without the SameSite flag.
The World After Google Chrome 80
In this section, I will show how the Google Chrome error for demdex went away after I updated my browser version and look at the site customer website in incognito mode.
Looking at what the developer console shows for the same customer website, we can see that the change was made by the Adobe ID Service (demdex) server side and the error went away. Please note that it DID NOT require a Visitor ID service version upgrade as the change was made server side. Having said that, it's always advisable to upgrade your ID service library to the latest version.
Now looking at how the demdex cookie is now set as shown by Chrome 80, we can see that the cookie has both the SameSite=None and Secure values set with a TTL expiration of 6 months.
What is the Recommendation for 1st Party Cookies on Safari?
In this section I want to talk about the importance of leveraging a CNAME tracking server to measure your website activity in Adobe Analytics which is more of an issue post ITP2.1 in Safari (slightly going off topic). This Adobe article covers how we can use a CNAME to set a new s_ecid cookie that extends the AMCV cookie expiration to 2 years instead of 7 days which Safari enforces today (see below).
Please note that this requires ID service version 4.3.0 + to take advantage of this change to extend your visitor expiration to 2 years instead of 7 days on Safari.
So, that's it! Hope found this helpful in understanding what changes were made by Chrome 80 and how Adobe is prepared to address any potential tracking issues as a result of this.
So, that's it! Hope found this helpful in understanding what changes were made by Chrome 80 and how Adobe is prepared to address any potential tracking issues as a result of this.
