FLEDGE or the "First Locally-Executed Decision over Groups Experiment" is the first attempt at delivering ads using the concepts outlined in the TURTLEDOVE proposal arising out of the Google Privacy Sandbox initiative.
FLEDGE stays true to the core tenets of TURTLEDOVE but also incorporates feedback from the other avian-inspired proposals from various ad tech companies. These proposals include:
Despite its ongoing metamorphosis, the goal of FLEDGE remains unchanged from TURTLEDOVE. FLEDGE provides a privacy-compliant method of delivering behaviorally targeted ads via an on-device auction.
FLEDGE presents a variety of concepts meant to usher in a new era of advertising on the web. But the ideas introduced in the proposal also add a notable amount of complexity.
With Chrome set to deprecate third-party cookies by 2022, Google wants to get this party started now so the Chrome team, along with the ad tech industry, can iron out all the wrinkles before it's showtime. FLEDGE is the first attempt at implementing the proposal in the real-world.
Google even acknowledges that FLEDGE is not final from a feature or privacy standpoint:
"This still lacks some features that are important for web advertising, and lacks some privacy protections that are important for preventing cross-site tracking."
So Google will forego some privacy-specific features that they will eventually require before they finalize the approach, for the sake of expediency:
"But while third-party cookies are still available, this simplified opt-in preview of a post-3p-cookies technique offers a way that we can all experiment with the on-device ad selection approach together."
FLEDGE consists of several distinct components that form a single standard on which publishers, advertisers, and ad tech platforms work in concert to reach the end goal of privacy by design behavioral targeting.
How does FLEDGE Work?
FLEDGE is a five-step process, with either the browser, seller, or buyer performing each step:
- Browser Records Interest Groups
- Sellers Run On-Device Auction
- Buyers Provide Ads and Bidding Functions
- Browser Renders the Winning Ad
- Seller and Buyer Event Level Reporting (temporary)
Let's take a look at each step in more detail.
Browser Records Interest Groups
The entire initiative is predicated on the concept of advertisers, publishers, and ad tech providers adding users to interest groups based on browsing activity or behavior.
One of these entities will call a joinAdInterestGroup() JavaScript function that instructs the browser to store an individual in an interest group for a set period of time (max 30 days).
const myGroup = {
'owner': 'www.example-dsp.com',
'name': 'womens-running-shoes',
'bidding_logic_url': ...,
'daily_update_url': ...,
'trusted_bidding_signals_url': ...,
'trusted_bidding_signals_keys': ['key_1', 'key_2'],
'user_bidding_signals': {...},
'ads': [shoes_ad1, shoes_ad2, shoes_ad3],
};
navigator.joinAdInterestGroup(myGroup, 30 * kSecsPerDay);The interest group owner defines an owner value that is equivalent to their business domain (ex. http://ownerdomain.com) and passes other information like the group name, the actual ads for this interest group, and other information meant to facilitate the auction process.
Interest group owners can delegate the ability to create interest groups on their behalf via a list of domains hosted at a 'well-known' URL on the owner's domain.
The site visited by the browser, where the joinAdInterestGroup() function runs, can control which entities can add interest groups. The default behavior is that a script must have access directly on the page, but the site can grant permission to cross-domain iframes via an HTTP Feature-Policy.
Delegating cross-domain iframes to create interest groups on an owner's behalf could facilitate a use case where an SSP can add its DSP partners' interest groups based on the context of the page that the browser is visiting on a publisher's site.
So in this brave new privacy-focused world, instead of an SSP firing a DSP cookie sync pixel, an SSP may instead add interest groups on behalf of the DSP.
Sellers Run On-Device Auction
A 'seller' is whoever is running the on-device auction. A publisher can run the auction themselves or have a third-party ad tech provider run it on their behalf.
There are three responsibilities of a seller:
- Deciding which buyers can participate in an auction and which bids are eligible
- Processing bid price and metadata to determine a "desirability" score based on business logic embedded in JavaScript code written by the seller
- Report on the auction outcome
A seller initiates an auction by invoking a JavaScript API inside the publisher's page:
const myAuctionConfig = {
'seller': 'www.example-ssp.com',
'decision_logic_url': ...,
'interest_group_buyers': ['www.example-dsp.com', 'buyer2.com', ...],
'additional_bids': [other_source_ad1, other_source_ad2, ...]
'auction_signals': {...},
'seller_signals': {...},
'per_buyer_signals': {'www.example-dsp.com': {...},
'www.another-buyer.com': {...},
...},
};
const auctionResultPromise = navigator.runAdAuction(myAuctionConfig);Interest groups can only participate in the auction if the browser has joined the group and the group owner is in interest_group_buyers field. Alternatively, the seller can declare 'interest_group_buyers': '*' to allow all interest groups to participate in the auction and determine eligibility based on other criteria passed in the bid.
The value in the decision_logic_url points to a script that contains the seller's auction logic. Within this script, the seller can define the rules of the auction, but somewhere in the code, the seller must run a score_ad() function for each ad from eligible interest groups.
score_ad(ad_metadata, bid, auction_config, browser_signals) {
...
return desirabilityScoreForThisAd;
}The function uses ad metadata and a bid price provided by the buyer to determine a desirability score. A desirability score less than or equal to zero indicates that the ad is not eligible to win — for example, an ad whose bid price cannot beat the bid price of a contextual-based ad.
(As a reminder, a key concept of TURTLEDOVE is competing contextual-based ads requested outside this auction with the interest group ads inside the auction.)
The score_ad() function can also access the original auction configuration to provide arbitrary data on a variety of items relevant to an ad candidate's desirability. These items can include the rev share agreement with a publisher or high-priority ads that need to deliver to meet commitments despite a lower bid price.
Buyers Provide Ads and Bidding Functions
Each party bidding in an auction is a "buyer", which could be an advertiser who owns an interest group or a DSP who owns an interest group acting on behalf of an advertiser.
The buyer has three responsibilities of their own:
- Determine whether they want to participate in the auction or not
- Pick an ad and submit it to the auction along with a bid price and metadata
- Report on the auction outcome (See section 5)
But before any of this takes place, there is an opportunity for the buyer to gain real-time data (like campaign budget remaining) that can influence their bid. The browser can call a "trusted server" that "performs no event-level logging and has no other side effects based on these requests" but will return simple key-value pairs to provide information to the buyer.
This "trusted server" model arose from Criteo's SPARROW and was further refined in Google's DOVEKEY, acknowledging the need for some server-side intervention in the auction process.
There are still many open questions on how a trusted server is established and who runs it, but for the FLEDGE experiment, the buyer can run the trusted server themselves.
The browser would build the call to the trusted server by checking the eligible interest groups for trusted_bidding_signals_url and trusted_bidding_signals_keys. If they exist, the browser will call the URL:
https://www.kv-server.example/getvalues?hostname=publisher.com&keys=key1,key2The response should be a JSON object containing the requested keys and associated values.
The buyer's bidding_logic_url is then called, which must contain a generate_bid() function:
generate_bid(interest_group, auction_signals, per_buyer_signals, trusted_bidding_signals, browser_signals) {
...
return {'ad': ad_object, 'bid': bid_value, 'render': render_url};
}
This function uses information from the eligible interest group, the trusted server, information about the auction (ex. 1st or 2nd price), and contextual information about the page (ex. ad size, publisher ID) to generate a bid. Additional auction and contextual information are either passed to all buyers (auction_signals) or this specific buyer (per_buyer_signals).
The generate_bid() function will return the bid price, the render URL of the creative, and arbitrary ad metadata that the seller can use in its decision logic.
Browser Renders the Winning Ad
The seller must then render the winning ad in a Fenced Frame. This concept is still under development, but the main idea is to render an embedded document without allowing it to communicate with the surrounding page.
Blocking communication with the page promotes privacy by preventing websites from learning about a visitor's interests by inspecting the ads they are viewing. It also prevents any timing attacks where a server could correlate a request for an interest group creative with contextual ad requests made alongside the interest group auction.
The desired end-state is for a buyer to provide all the data needed to render an ad in a previously downloaded web bundle. Since Fenced Frames are still under development, and to move FLEDGE along, Google will allow ads to render from resources provided directly by a network call to a server.
Event Level Reporting (temporary)
The browser will call a reporting function for both the seller and the winning buyer. Google will temporarily allow event-level reporting that can include contextual and winning interest group information.
Event-level reporting is another temporary concession to expedite FLEDGE. Google aims to introduce a more privacy-compliant aggregate reporting model. Reporting in aggregate would prevent buyers and sellers from learning the interest group of any individual visitor.
Seller reporting
The seller can include a report_result() function in the same script executed from the decision_logic_url.
report_result(auction_config, browser_signals) {
...
return signals_for_winner;
}
The seller passes the configuration for the auction and additional browser signals to the function. The browser signals include the winning interest group, creative, bid value and the desirability score, and other auction win signals.
The seller can have the function call their reporting APIs. The output of report_result() is not for the seller but instead used as an input for the buyer's reporting function.
Buyer Reporting
The buyer can include a report_win() function in the same script executed from the bidding_logic_url:
report_win(auction_signals, per_buyer_signals, seller_signals, browser_signals) {
...
}
The inputs passed to this function include the previously mentioned auction_signals, per_buyer_signals, browser signals, and the seller_signals (the output of the seller's reporting function).
Google does not provide a solution to pass those oh-so-important viewability signals, either by the publisher page or Fenced Frame, but acknowledges that it is needed.
Google also acknowledges the need to design an additional function for losing bidder reporting. At the very minimum, buyers would need some way to count the number of times they bid and at what price the auction ultimately cleared.
What's next for FLEDGE?
Google continues to accept feedback on the FLEDGE proposal and has not publicly indicated when they will make the necessary browser APIs available in Chrome. The only indication of release timing is that it will take place in 2021 to prepare for Chrome third-party cookie deprecation in 2022.
Completely re-writing the foundation of interest and behavior-based digital advertising is no small feat, and Google still does not have all the answers. FLEDGE still has quite a few holes that will need filling before it is a fully-realized standard.