When Google announced the Privacy Sandbox in August 2019, it was a set of proposals to replace third-party cookies in online advertising. At the time it was ideas rather than code that could be implemented.
Since then we have seen counter-proposals from independent AdTech companies—like SPARROW from Crtieo and PARRROT from Magnite—amid slow progress during discussions at the W3 Consortium and little progress on real-life models that can be tested in the wild.
On January 22, 2021, Google announced plans for its “First Locally Executed Decision over Groups Experiment” or FLEDGE for short. The announcement on Github describes how they will operationalize TURTLEDOVE for a first test.
Primer On TURTLEDOVE
You’ll recall that for TURTLEDOVE advertisers put snippets of code on their site that assigns users to an Interest Group, for an automotive company think Hatchbacks or SUVs etc.
These snippets of code replace the third-party cookies that advertisers can no longer use. That a user is assigned to a given interest group is only stored in their browser.
TURTLEDOVE envisages ad calls for these interest groups being sent at random intervals with responses stored in the browser, publishers would then be able to compare bids solicited when a user visits their site against the best responses that had been stored in the browser via an API. The browser would then serve the most appropriate result, with results being sent back to the publisher ad server and DSPs or other intermediaries within the ecosystem.
The FLEDGE Documentation
The FLEDGE documentation provides significant detail on the key stages of the first TURTLEDOVE including:
- Storing Interest Groups & updating them.
- On-device auctions.
- On-device bidding.
- Ad Rendering
It is likely they’ll be processes in the FLEDGE that do not make it into future tests (anyone for SLEDGE?) or indeed the final version, equally it’s likely there are features that will appear in future versions of the TURTLEDOVE not in the first test, indeed this is something called out in the Github documentation.
Storing Interest Groups In Browsers
Chrome will keep track of the interest groups it has joined and it will store information about who owns the group and who can advertise to these interest groups.
A number of different types of companies may become an owner, the most obvious is an advertiser or their agent, here TURTLEDOVE is likely used to cover In Category (Read: remarketing) purposes, with FLoCs being used for general interest-based advertising.
Beyond advertisers, the FLEDGE documentation highlights that third-party adtech companies might own an in-market segment, or publishers might create and own an interest group of people who have read a certain type of content on their site. The FLEDGE documentation suggests some businesses would charge for the ability to target this list, so perhaps this is how data brokers will live on post the death of the third-party cookie.
The FLEDGE documentation highlights that a browser will remain in an interest group for a limited amount of time, 30 days unless the advertiser makes another call to it again at a later date to keep the browser in a given group.
It’s worth noting that Chrome will allow segments to be updated daily for interest groups with a sufficiently large number of people, e.g. at least 100 browsers.
Sellers Run On-Device Auctions
Invoking this API will cause the browser to execute the appropriate seller and buyer “worklets” in the browser to run an auction for interest Groups.
It is likely that the on-device auction for interest groups will run alongside other S2S auctions be they contextual or powered by identity vendors like Liveramp or iD5. For IG ads the seller decides:
- Which buyer may participate
- Which bids are eligible to enter the auction
- What the score of each bid is.
I am not entirely clear from the FLEDGE documentation in the first test bids on Interest Group ads will be compared to:
- Auctions that are run outside of the browser e.g. contextual.
- Auctions for ads from other sellers for interest Groups.
But the consensus view is that long term this will be done as per the Original TURTLEDOVE proposal with the adserver passing the winning ad from their adserver to the browser via an API so the winning ad can be compared to the bids from the on-device auction for Interest Groups.
Bidding In On-Device Auctions
Interest groups can be bid on by their owners and agents of the owner in on-device auctions that occur against standard auctions. When the buyer is sent a bid request by a seller for the on-device auction they will:
- Choose whether or not they want to participate in an auction.
- Pick an advert & enter it in the auction along with a bid price.
- Metadata which the seller requires in order to score an ad.
The metadata accompanying the returned ad is not specified in the FLEDGE document so sellers and buyers (owners of the interest groups and their agents) are free to establish whatever protocols they want here, this may be an area where IAB style open standards makes sense long term.
When the owner of an Interest Group wins an on-device auction the browser renders the winning creative within a Fenced Frame. This is a mechanism that is under development for rendering a document in an embedded context so it is unable to communicate with the surrounding page. Another safety feature is Fenced Frames will not use the network to load any data from a server.
When a winning ad has rendered in its Fenced Frame on the publisher’s site, the seller and the winning buyer each have an opportunity to perform logging and reporting on the auction outcome. Chrome will also provide losing bidders with information about the auction clearing price so they can use this information to inform their bidding.
If any of this sounds too technical, I have a TL;DR FLEDGE explainer over on Twitter. Also, FLEDGE testing will be made available through origin trials in Chrome later this year, and ad tech companies will be able to use the API under a “bring your own server” model.