Today’s Google Chrome updates mark another step in the slow march towards the first-party future. With its SameSite updates in Chrome 80, Google pushed out a change to the way that third-party cookies that come from an HTTP (not an HTTPS) domain work— which is to say they won’t work.
This change was explained well by Digiday: “The SameSite update will require website owners to explicitly state label the third-party cookies that can be used on other sites. Cookies without the proper labelling won’t work in the Chrome browser, which has 64% of the overall browser market, according to Stacounter.”
With so many browser changes coming out, like Apple Safari’s ITP or Microsoft Edge’s Tracking Prevention, it can be hard to keep track of all the ways browser developers are reshaping the cookies landscape. I asked Ty Gavin, our VP of Engineering, to discuss what this update means today, and what it could mean for the future.
What is going on with Google’s SameSite update?
Ty Gavin: Google Chrome will be (was) updated in version 80 to change the default SameSite value. The new default changes from “None” to “Lax”. That means that anyone wanting to read a 3rd party cookie in a 3rd-party context needs to change the way they set the cookie. Tealium is (has) made the update to our Tealium Collect and other data-collection endpoints to respond with a setcookie response to “None”. This means the Tealium server-side cookie is now readable in a 3rd-party context. Because this cookie is used to stitch visitors across web properties (when possible) this is a required change in Tealium data collection. This is also required in all data collection endpoints that want to use third-party cookies.
This gives the third-party cookie a little more of an extended life in Google Chrome. It does not mean it will always be readable, but for now, Google allows third-party cookies to be read when the developer creating the cookie says, “Yes, please allow this to be read across domains.”
Can you explain the difference between ITP and SameSite?
TG: Apple’s ITP is primarily a reduction for those features that many digital marketing vendors (mostly ad networks) use to understand visitor behavior across web properties. ITP limits third-party cookies and first-party cookies in specific cases. Recent updates to ITP restrictions are now limiting the duration of LocalStorage (a first-party storage similar to cookies) when someone clicks through an advertisement.
Why are Google and Apple making these changes now?
TG: My perspective is that Ad networks abused their cookie privileges and that made consumers aware of and resentful towards the mysteries tracking of behavior online. Other features like “privacy mode” in browsers also made consumers aware that their behavior was not private. Following that was security breaches that were highly publicized and adding to consumer concern. Lastly, legislation, led by EU in an effort to “protect its citizens” from the likes of data giants Apple is making these changes to help sell their iPhones as the security-conscious consumer phone of choice while Google is doing these things to resolve specific security risks that are common to web developers. Whether these features are originally here to protect people or protect us from poorly coded websites, large corporations (and even smaller nonprofits such as Mozilla) are jumping on the bandwagon and attempting to turn a challenge into an opportunity.
How are data and analytics teams going to be affected? What should data and analytics teams do to limit the impacts of their data degradation?
TG: Data will be slightly “off” when looking at analytics reports around Safari. Right now, looking at trends in Chrome browser users is a quick workaround. We need to be proactive at this point to move towards first-party data collection whenever possible. The quickest path to first-party data collection is using CNAME or “alias” for data collection endpoints to match the website root domain.
Are third-party cookies really dead? Peter Spande, CRO at Insider Inc., told AdWeek that Google’s plans are “the nail in the coffin for the cookie.” Would you agree with that?
TG: Yes, it is only a matter of time before third-party cookies are impossible for a developer (data collection end point) to set or to read. This is probably a good thing for the end-user. For the digital marketer, the time is now to start implementing entirely-first-party solutions.
What is Tealium doing to help solve this issue?
TG: Tealium’s immediate update is to support the Google Chrome 80 release with updating server-side response when setting cookies to use SameSite=None. This will allow for existing use cases around visitor stitching across domains.
Tealium also provides the ability to CNAME data collection to match your domain in order to provide a central data collection endpoint that can be used to send data to other vendors server-side (such as Google Analytics or Adobe Analytics). When you have your visitor’s consent, Tealium’s solutions help you increase data accuracy and data collection for analytics and other digital marketing efforts.
Keep up with the latest browser news and how they affect your data management efforts by following our blog.
