Progress inside Google’s Privacy Sandbox – its open forum for proposing and developing alternatives to third-party cookies – tends to be pretty quiet.
Google itself rarely makes much noise about any particular proposals, instead leaving developments to be discussed within the W3C, and on GitHub threads.
Nonetheless, it’s important to keep a close eye on what’s happening inside the Sandbox. Given the time it takes to propose and discuss ideas, the proposals which Google is backing and pushing through to industry trials are likely to be the APIs which end up being used on Google’s Chrome browser – meaning they’re almost certain to become a major part of the digital advertising infrastructure.
For a long time, it was the targeting APIs – FLOC and FLEDGE (which evolved from TURTLEDOVE) – that received the most attention. And at the start of this year, those VideoWeek spoke with said they were concerned about a lack of progress around measurement.
Google is throwing its weight behind Attribution Reporting API, a tool which it says allows marketers to measure when an action (such as a click or a view) leads to a conversion, without using cross-site identifiers. But how does this API actually work?
Not a like-for-like replacement
No single Sandbox proposal is designed as an entire like-for-like replacement for the third-party cookie. Instead, each proposal is designed to fill a specific use case which has previously been filled by the third-party cookie.
Third-party cookies have been a simple and effective way to measure and attribute campaigns. To put it simply, an advertiser or ad tech company can currently drop cookies on a user’s browser, and then recognise those same cookies on third-party sites.
Thus, an advertiser could tell when a user had visited The Guardian, and seen an outstream ad in an article. And they could then also recognise that same user landing on the advertiser’s own website, and adding the advertised product to their basket.
The Attribution Reporting API will look to enable the same functionality.
At the moment, Google is looking specifically to support click-through conversion attribution measurement (when a consumer clicks on an ad, and then goes on to take an action such as buying a product or signing up for a service), and view-through conversion attribution measurement (where a user sees an ad and then takes an action).
Google is also working on two separate, complementary, types of attribution reports. Event-level reports will give advertisers feedback on individual conversion events. So for example, an advertiser will see that a specific impression led to a conversion. Aggregate reports meanwhile, as the name suggests, will give aggregated reporting on how a campaign as a whole has performed, and how it’s driven conversions.
In both of these cases, the browser plays a significant role in observing user behaviour and reporting conversions.
A basic run through
The simplest use-case, and the first developed within the Sandbox, is event-level reporting for click-through conversion attribution measurement.
This works as follows. A user loads a page on a publisher site – say ‘sports.com – with an ad – for example, an ad for a new toaster. When the user clicks on the ad, they will be taken through to ‘toaster.com’.
A piece of code assigns an ID to the ad click – for example 12345, which the ad tech company knows relates to a specific impression on a specific website. The code also tells the browser to watch out for a specific web page loading (in this case, toaster.com).
Say the user then clicks on the ad, and lands on toaster.com. The browser then knows to store some data about this event – that the user clicked on the ad on the publisher’s page (recognisable by the ad ID) and landed on the advertiser’s webpage.
Later down the line, the user goes on to buy a toaster. The advertiser then tells its various ad tech partners that the purchase has happened, and a bit of information about the purchase, in order to trigger attribution.
The ad tech company condenses all this information into a very simple request to the browser – limited to just three bits (i.e ones and zeroes) of data. This limit means that the information passed on by the ad tech company can take one of just eight values, as that’s the maximum number of different values that can be assigned with three bits of data.
So the ad tech company tell the browser ‘John Smith bought a $50 toaster”. But instead, the ad tech user can assign a different meaning to each of these eight values. So the request might just give the browser the number ‘2’, which the ad tech company knows means a purchase between the value of $35-55.
The browser provides a report (after a delay), feeding back the stored ad ID (12345), and the same bit of information it received from the ad tech company (2). This then allows the ad tech company to recognise that an ad click on sports.com contributed to a ‘$35-55 conversion, without knowing any information about the user.
There are several other processes involved to make sure privacy is preserved. One important piece is that ‘noise’ is added, which means that in a small percentage of cases, random data is sent by the browser instead of the real data.
This same logic described above can be adapted for view-through conversion measurement (though it takes extra work for the browser to know when to save attribution data without the user clicking anything).
The process can also be adapted for aggregate reporting. Without going through the specifics of how the process differs, the most important thing to know is that aggregate reporting allows more data on the nature of the conversion to be passed through the system (for example, data on the specific item purchased, and the location of those purchases. The tradeoff is that the report received by the ad tech company and advertiser won’t give information on specific ad clicks or views, only general-level data.
Still work to be done
Google’s belief is that event-level reporting and aggregate reporting will work together in tandem.
Event-level data, with less information available, will be better for mid-campaign optimisation, fraud monitoring, and attribution in cases where it’s not necessary to report back granular information on the conversion itself.
Aggregate reporting meanwhile will be better for measuring return on investment, helping brands to understand how a campaign performed once it’s been running for a significant period of time.
Google also hopes to add further functionality to the API further down the line, including app-to-web reporting (where a user sees or clicks on an ad in a mobile app, and converts on a website), and cross-device reporting (where the impression and the conversion happen on completely separate devices.
But there’s still plenty of work to be done.
While the Aggregate Reporting API has been released for trials, so far this has been limited to just the most basic use case – event-level reporting for click-through conversions.
And Google recognises that even with these extra use-cases, the Aggregate Reporting API is still only one piece of the measurement puzzle, with further APIs needed for a broader ranger of measurement and attribution use cases.
