What Solutions are Google Proposing for the Removal of Third-Party Cookies?

In our recent webinar, Futureproofing Analytics for the Cookieless World, we took a look at the impact that Google’s decision to effectively push back their changes to Chrome – and the removal of third-party cookies – for another 12 months will have on marketers.

As a follow on to that we now take a closer look at:

• What cookie replacement options is Google putting on the table?
• Cookies replacement proposal #1 – Google Topics API
• Cookies replacement proposal #2 – FLEDGE API (including Google Signals)
• Cookies replacement proposal #3 – Attribution API

What cookie replacement options is Google putting on the table?

Google has been working on different options for cookie replacements for a while now.

For a good period of time FLoC was the leading replacement option before very real concerns surfaced that, in practice, it didn’t prevent any invasion of privacy at all.

So where does that leave us? The original plan was to have a solution in place for Q4 2022 but Google has pushed this back a year.

As you can see from the above timeline, there are 3 proposals in trial as follows:

• Topics API
• FLEDGE API
• Attribution Reporting API

The challenge for marketers is a lack of clarity around when we can really start ramping up spend into these solutions.

But, at QueryClick, we think that somewhere around the middle of 2023 we need to able to all move away from cookie-based solutions.

A closer look at the third-party cookie replacement options on offer

Let’s now take a closer look at each of these solutions in turn:

Cookies replacement proposal #1 – Google Topics API

Google Topics is a browser-based system that assigns a user a set of interests based on the type of website they visit and is designed for prospecting.

It is there to allow very high-level targeting, essentially on an interest or topic level basis. In practice there are 350 categories available for advertisers to place ads against, which is a low number by any definition.

So, how does that play out in practice?

As our diagram below shows, if you’re a specialty coffee retailer the most relevant topic that you will be able to bid against is not specialty coffee.

Or even coffee.

It’s food and drink.

Which is a big step back from where we are now from a targeting perspective.

Now, those 350 areas are pulled from the IAB’s content taxonomy.

There are several thousand areas in the content taxonomy itself and it is expected that Chrome will widen that number. But how significantly they do this is unclear right now.

And, as things stand, Google benefits greatly by keeping the number of topics limited to 350. As what happens in that scenario is that we move away from targeting on the basis of a third-party cookie – which has some level of relevancy to us – to placing ads at a very generic level. Where there will be a greater volume of competing ads for that slot.

And greater competition and volumes of auctions will end up driving up ad costs quite significantly for those 350 topic areas.

Which means we are both capturing less targeted traffic and end up end up paying more for the privilege.

Cookies replacement proposal #2 – FLEDGE API (and Google Signals)

FLEDGE is the current proposal for retargeting alongside the use of Google Signals.

FLEDGE for retargeting

Our diagram above shows the stages involved in the current FLEDGE process – which are relatively familiar to anyone who is working with AdTech.

Ultimately, you have user interactions. Those user interactions, however, are purely on a browser-level basis on the individual chrome browser instance in question. And they enable users to join an ad interest group. And sites that user subsequently lands on may be able to display ads associated with that interest group.

At that stage, you’ve got a match and you will be able to serve an ad against that individual.

One of the limitations in this approach is that for a browser to join an interest group requires the individual using Chrome to ‘opt in’.

That is clearly going to be slightly problematic as the opt in rates when Apple introduced a change in iOS 14.5 (to require people to opt into data sharing) was significantly less than 2% for the entirety of the iPhone user group. So, you can imagine similar rates will likely occur for Chrome.

However, it is worth pointing out that, distinct from Topics, we are able to generate groups ourselves using our DSPs or our ad tech generally. Meaning that advertisers do at least have a bit more control over how granular and how focused we can be in the creation of those interest groups.

Google Signals are a sort of cookie

Connected to any sort of element of retargeting on the Google ecosystem is Google Signals which is another type of third-party cookie.

Signals works when someone is signed into their Google account, and they have agreed to allow that to be used to retarget them. That sign in is then treated as the equivalent to a third-party cookie that can be compliantly used to improve ad targeting.

There are a couple of changes to this aspect of retargeting in Chrome, and on Google accounts, that it is important to be aware of.

User segments have been replaced with audiences in GA4 and audiences are based on these aggregate Google Signals.

You do also need now to consider giving consent and requesting consent for the use of Google Signals data – and the use of that on your site. If you’re a publisher and you plan to use it when advertising.

Google plans to follow Apple’s lead on App privacy

The other component, I think it’s worth calling out here is that Google owns a big chunk of the app ecosystem – in fact it has 69% of the market.

So, there are more Android devices on the market than Apple devices. And Google recently announced that they would essentially copy the iOS 14.5 change – changing its’ default setting from opted-in to requiring opt-in – as part of their Privacy Sandbox on Android devices.

And they set a two-year timeline for that four or five months ago now.

This is clearly something we also need to have on our radar when it comes to handling replacements for third-party cookies. Because ultimately, individual journeys cross into App ecosystems – with all the implications for future tracking that this throws up.

Cookies replacement proposal #3 – Attribution API

So what about the data that we will receive form these new solutions? What reporting opportunities are going to be made available to us?

So, the Chrome attribution API, as it stands is available to access. And you can interact with it and understand the data shared to a relatively deep degree. The two areas that are being made available under the new trials at the moment are:

• event-level reports
• aggregate reports

The two other components which have not been progressed are:

• app to web – trying to measure through into an Android app
• cross device – which is looking at cross device clicks and views

At the moment, neither of those last two are in origin trials and are unlikely to progress.

And, as mentioned, cross device would also require opt-in which is likely therefore to have under 2% level of uptake. So, it’s also really unlikely to progress as part of the origin trials.

Now, the data for event-level and aggregated reports is collected in the same way.

So, this API is trying to offer on-device attribution. Meaning your Chrome instance is the only instance that’s supplying data. And all processing is done within the Chrome instance itself – on device, in the browser as shown in our diagram below.

All of this has a couple of meaningful implications for measurement.

The first major one is that all event-level data that you receive from the attribution API is siloed by by the individual browser ID. We know, due to being heavily invested in the world of attribution, that single browser conversion paths are less than 20% of all such paths.

And so, it’s only that 20% of data that we’re going to be getting meaningful data on.

And as you can see in our diagram below, that by moving to AI-based measurement – like the approach used in our own Corvidae platform – and completely ignoring all cookie data we were able to move that 20% accuracy rate up to beyond 85%.

A figure that is now up well beyond 97% accuracy for our zero cookie-based system.

So, AI modelling is a potential path to help move away from this device-based siloing that Google is proposing. And the data itself is also worth interrogating that we get from Chrome.

So, we have these two types of data available to us. We have event data which is intended for ad optimisation. It is associating an ad click with what’s called course conversion data. Meaning conversion data that’s not necessarily detailed beyond the fact that there was a conversion.

In addition, Google has advised that they will be introducing (and do currently have in their trials) an element of time delay and randomisation for a portion of the data being returned as event data. The intent here is for that randomisation to help prevent any form of reverse engineering to find out which individual had actually created that event.

On the aggregate side, aggregate data is intended for conversion data. And joining click and view data to that aggregate conversion data itself.

You can see an example of each type of data below. And you can also read through the API spec in detail to understand current proposals. In essence, these two different use cases are the two types of data that are provided back through the attribution API.

One final point here, which is crucial to get your head around is that that the API actually does not support any level of attribution. Despite the name of it!

This is because the attribution model being used is Last Click.

And one suggested reason for that is because Google is well aware of the fact that the siloed measurement in browser (not even in device but in browser which is even more limited) means that trying to apply any level of attribution to that will just simply increase the amount of inaccuracy being presented by the data.

And the second point, is that viewability checks are not supported.

This means that there is no capability for you to understand if an ad has, in fact been seen. And been seen by a human being.

So, all of your event data will make an assumption that the viewability was acceptable. Now, ad fraud is a particular problem in some areas of display advertising. And we think this is a critical flaw in the current API as it stands.

So, these are the 3 Chrome based components that are available in API for us to test and play with at the moment. And we should be building our strategies around either the use of them or looking for alternatives that that we can put in place for the end of third-party cookies.

Learn more

If you are looking to research your options for when the end of third-party cookies does eventually come why not download a copy of our eBook, Is Cookie Free Attribution a Myth?, and discover:

• The main reason cookies are flawed
• How to fix your 80% broken data
• Our unique patented technology – and how it completely replaces the cookie