FLEDGE is the latest update in the Google Privacy Sandbox and takes the implementation of the TURTLEDOVE API further.
Google will stop supporting third-party cookies after late 2023, a move that will heavily affect the ad tech industry. Google, however, is also working on Privacy Sandbox APIs, which are intended to allow publishers and advertisers carry out advertisement campaigns without infringing user privacy.
While there are a number of APIs in Google’s Privacy Sandbox, the major focus at the moment is on the TURTLEDOVE family and FLoC APIs. The trials for both of these APIs are expected to be conducted this year as third-party cookies are to be phased out in 2022. In fact, FLEDGE is the first trial aiming to implement the proposal in actuality.
In this blog, we are going to shed light on what FLEDGE is, how it works, and how things will proceed with it.
What is FLEDGE?
FLEDGE (First Locally-Executed Decisions over Groups Experiment) puts into practice the proposed elements in TURTLEDOVE and other proposals that followed it. Being the latest development in the TURTLEDOVE family, FLEDGE keeps the fundamental tenets of TURTLEDOVE and builds upon the following proposals as well:
- SPARROW, proposed by Criteo
- Dovekey, proposed by Google Ads
- PARRROT, proposed by Magnite (previously Rubicon Project)
- And, TERN, proposed by NextRoll
If we back up to TURTLEDOVE, the key idea was that advertisers and publishers will be able to target audiences on the basis of interest groups. Another noteworthy point in this proposal was that the auction-related decisions will take place in the browser as opposed to the ad server (as has been happening till date).
SPARROW and Dovekey both proposed that the bidding and auction decisions should be handled by a third party rather than the browser. This was to prevent walled gardens like Google to be in control of the bidding process.
Since trusting a third party with the auction didn’t seem to agree with a lot of parties in the ad tech industry, PARRROT suggested that auction-decisions should lie with the publisher. This proposal, along with TERN, also provided enhanced clarity regarding the roles of DSPs and SSPs.
So, what exactly does FLEDGE propose?
FLEDGE keeps the major principles of TURTLEDOVE, for example the concept of interest groups, concepts of Gatekeeper from SPARROW and Key-Value server from Dovekey, and the separation between SSPs and DSPs, in terms of functions, as proposed by PARRROT and TERN.
You can also checkout our video on how can publishers build first-party data to monetize websites in a cookie-less world.
How Does FLEDGE Work?
The workflow of FLEDGE entails a 5-step process where either the browsers, sellers, or buyers take measures.
- Browsers record interest groups
Browsers will keep track of all interest groups they have joined and will store information about the owner of the group and will determine who can advertise to a particular interest group. The owner of an interest group can be a publisher or an advertiser.
Owners have the ability to add users to a certain interest group on the basis of their activity or behavior. They will be able to store a user in an interest group for a time period of 30 days (max) by calling a joinAdInterestGroup() JavaScript function. The owner of the interest group will be further responsible for passing on the information, including the ads for the interest group and it’s name, that is needed for carrying out the auction.
Owners can also delegate the responsibility of adding users to the group or creating an interest group. This process can allow SSPs to add interest groups on DSPs’ behalf, while keeping in mind the context of the page. - Sellers run on-device auctions
Sellers are defined in the FLEDGE documentation as the entity who is running the on-device auction. The seller can be the publisher or they might choose a third-party to run the auction on their behalf.
Here’s what the seller is responsible for:
The seller decides which buyers can enter the auction and which bids are eligible.
They have to determine the bid score by processing metadata and bid price. This will be done on the basis of the business logic embedded in the JavaScript code, which will be written by the seller.
Lastly, the seller will be responsible for reporting on the outcome of the auction. This will include reporting on clearing price. - Buyers provide ads and bidding functions
A buyer is the party who will be bidding in an auction. This could be an advertiser owning an interest group or a DSP owning an interest group on the behalf of an advertiser.
In the process, the buyer will be responsible for:
Choosing if they want to participate in an auction.
Picking an ad, entering the ad in the auction, and specifying the bid price and metadata expected by the seller.
Reporting on the outcome of the auction. This will include event-level reporting (more about this later).
Note that at the moment, it’s not specified in the FLEDGE proposal what kind of metadata should accompany the returned ad, which means that buyers and sellers will have to set certain protocols according to their needs. - Browsers render the winning ad
Next, the seller will render the winning ad inside the Fenced Frame, which means that the embedded document will not be able to communicate with the surrounding page. The Fenced Frame concept however is still under development.
Fenced frames will majorly ensure that any sort of data leakage is not occurring when an ad is rendered, thereby protecting the privacy of the users. - Event-level reporting
After the winning ad is rendered in the Fenced Frame on the publisher’s website, the winning buyer and the seller will report on the auction outcome. Google will also auction-related information (clearing price) to the losing bidders.
The event level reporting is a temporary measure at the moment:
In the long term, we need a mechanism to ensure that the after-the-fact reporting cannot be used to learn the advertising interest group of individual visitors to the publisher’s site — the same privacy goal that led to Fenced Frame rendering. Therefore event-level reporting is just a temporary model until an adequate trusted-server reporting framework is settled and in place.
Github
What’s Next?
As of now, there has been no indication from Google’s side about when the experimentation will initiate, just that the first experiment will be shipped sometime during 2021.
Chrome expects to build and ship this first experiment during 2021. The goal is for us to gain implementer experience, and for the ads ecosystem to evaluate its usability, as soon as it is feasible to do so. We need a robust API to take flight before Chrome’s expected removal of third-party cookies in 2022.
Github
We plan to hold regular meetings under the auspices of the WICG to go through the details of this proposal and quickly make any needed changes.
Github
FAQs
“FLEDGE” stands for “First Locally-Executed Decision over Group Experiment.” Simply, it reduces the amount of data flowing around ad systems and bidstreams.
Using FLEDGE, a user’s browser stores advertiser-defined interest groups it is associated with and hosts on-device auctions to display ads.
FLEDGE is a Privacy Sandbox proposal for remarketing and audiences. The software is designed so that third parties cannot track user browsing behavior across websites.
Shubham is a digital marketer with rich experience working in the advertisement technology industry. He has vast experience in the programmatic industry, driving business strategy and scaling functions including but not limited to growth and marketing, Operations, process optimization, and Sales.
