AdExplainer: Meet The FLEDGE API

AdExplainer first versionThere’s movement in the Privacy Sandbox.

With FLEDGE origin trials just begun – they finally kicked off on March 31 after multiple delays – publishers and advertisers need to get up to speed.

Because they’re in a race against time to find workable solutions to replace third-party cookies in the Chrome browser, which Google plans to disable by the end of 2023.

But how is FLEDGE different from other targeting-focused proposals within the Chrome Privacy Sandbox, and what use cases does it support?

Most importantly, though, is FLEDGE a viable and privacy-safe alternative to third-party cookies?

“The proof will be in the pudding,” said Paul Bannister, chief strategy officer at CafeMedia.

The before times

Comic: Something To Tell Our GrandkidsIn a cookie-based world, advertisers collect information about a user’s interests in the hopes of serving relevant ads by tracking people’s behavior across websites.

Users are often trailed by hundreds of third-party cookies, and tracking is completely decentralized.

The idea behind FLEDGE is to protect user privacy by centralizing that power. Instead of the ad server fielding bids based on identity signals passed by exchanges and read by DSPs, everyone will bid on information held in the browser, and the ad auction happens on a user’s device.

FLEDGE in a nutshell

FLEDGE stands for “First Locally-Executed Decision over Groups Experiment,” which is exactly what it aims to do.

The FLEDGE API will enable interest-group-based advertising by tasking the browser with choosing which ads users see based on the sites they’ve previously visited. That’s the “groups experiment” part of the acronym.

In order to keep this data secure, FLEDGE proposes the browser conducts an on-device auction. That’s the “locally-executed decision” part of the acronym.

If the tech works as intended, it will support cross-site use cases without relying on cookies or other traditional tracking mechanisms.

Although retargeting is the biggie use case to keep in mind for FLEDGE, that definition is “a little too narrow,” said Michael Kleber, Google’s lead engineer for the Chrome Privacy Sandbox.

The best way to think about FLEDGE is as an alternative way to create custom audiences that aren’t tied to cookies, which goes beyond just retargeting. These audiences could be used for reengagement campaigns, frequency capping, to target in-market consumers or reach people based on their affinity, like “movie lovers,” “runners” or “cooking enthusiasts.”

So, how does FLEDGE work?

Sellers initiate the ad auction by calling the FLEDGE API. The browser’s job is to decide which ads to show based on the sites a person has visited and the type of people an advertiser wants to reach.

Say a user visits an advertiser’s website and looks at a tennis racket. At that point, the advertiser’s DSP can make a JavaScript call asking the browser to add that person to an interest group and pass along data. This data could include information about ads that might be relevant to the user and URLs to access bidding logic for the subsequent on-device auction.

Comic: Mount CookieAt this point, the browser knows its user is possibly in the market for a tennis racket.

The next time that user visits a website that monetizes with advertising, the party responsible for selling the ad space (most likely the publisher’s SSP partner) would call the FLEDGE API, triggering an auction in the browser on the user’s device.

The browser would then call a “trusted server” to fetch any metadata associated with the ads competing to reach eligible interest groups and share that information with the seller. (It’s not yet clear who would serve as the trusted server in this scenario, but it could be Google or an independent third party.)

Once the auction is finished, the winning ad for that tennis racket would be displayed to the user in a fenced frame, which is a type of iframe that can render an ad but prevents the ad code from being able to interact with the page around it. A fenced frame is a bit like a firewall.

Buyers and sellers are able to access some real-time data while the auction is running, such as whether the ad creative complies with publisher policies and how much budget is left in an ad campaign. This information is passed using trusted servers.

Advertisers are also told whether anyone clicked on the winning ad – but they know nothing else about the person other than his or her purported interest in tennis.

Thanks to the fenced frame, publishers can’t access any data about the winning ad either, including the source URL. This stops the publisher from being able to infer any information about a user’s interests, which could be a privacy issue.

FLEDGE vs. Topics API

But how is FLEDGE different from the Topics API, which Google announced in January as the sandbox successor to FLoC? (FLoC, which stands for “federated learning of cohorts,” failed to make it out of the testing phase last year.)

Put simply, Topics is a less complex version of FLEDGE.

The Topics API creates audience segments on a weekly basis by inferring a small handful of topics users might be interested in based on the hostnames of the sites they visit. A topic might be “fitness,” “travel,” “entertainment,” “sports” or “health & beauty.”

Topics are stored for three weeks and updated weekly. In a nod to privacy protection, topic selection is done by the browser on a user’s device without the involvement of any external servers (including Google’s own servers).

Comic: The Privacy Sandbox Naming CommitteeThree topics can be shared at a time with publishers, advertisers and their ad tech partners to help sites serve relevant ads.

Both Topics and FLEDGE are designed to prevent third parties from tracking a user’s browsing behavior across sites. But whereas the Topics API could be relatively easily integrated into the way ad serving functions today, FLEDGE requires “more of a conceptual change,” Kleber said, because it creates a completely new ad-serving flow.

But using FLEDGE gives companies “more control” over the creation of interest groups, he said.

Think of the Topics API as a way to tap into predefined audiences and FLEDGE as a way to find and target custom audiences.

(Topics and FLEDGE also come from what you might call different bloodlines. Topics is the next generation of FLoC, while FLEDGE is an evolution of TURTLEDOVE that also incorporates elements from Dovekey, which was proposed by Google Ads, and pulls in elements from counter-proposals put forward by ad tech companies, including Criteo’s SPARROW, Magnite’s PARRROT and NextRoll’s TERN. Good night.) 

But is FLEDGE viable?

Whether FLEDGE is a workable alternative to third-party cookies depends on how well it can replicate the functionality of said cookies and if it can move decisioning to the browser without overtaxing a user’s device.

For all their many faults, cookies track multiple ad performance drivers, said Nancy Marzouk, CEO and founder of identity data company MediaWallah.

Surfing behavior, for example, indicates a variety of interest-related data, including site content, purchase intent and demographic information, Marzouk said, and the recency of that data is also important.

But FLEDGE doesn’t take most of that into consideration, she said.

“FLEDGE only allows an advertiser, ad tech platform or publisher to define an interest and retarget that user based on previously expressed interest,” Marzouk said. “But it doesn’t take into account that the user might no longer be interested.”

Or the fact that users look at lots and lots (and lots) of different products as they browse the internet.

“Users might look at hundreds of web pages over the course of a few days, which could mean that hundreds of companies have asked their browser to store interest group information about them,” said CafeMedia’s Bannister. “That means for any opportunity on a publisher site, they’re eligible for potentially hundreds and hundreds of ad auctions.”

Comic: The Field Guide to the Privacy SandboxAnd where do those auctions take place? On the user’s device. Problem is, running so many auctions could take up too much network bandwidth.

“What was previously executed on a server, some high-speed machine somewhere in a data cluster, is now happening on your laptop,” Bannister said. “Your laptop is taking on the burden of looking through effectively hundreds of ads that could be relevant to you and picking the best one.

“This complicated system,” he said, “has to work in your browser in a way that doesn’t kill your computer.”

No one wants ads that make laptop fans whir or turn phones into hot bricks.

Does FLEDGE protect privacy?

Clearly, there are some kinks to iron out during the ongoing origin trials.

But there’s another burning question: Does FLEDGE do what it says on the tin and protect user privacy?

One of the main reasons FLoC failed to fly and why it was replaced by the Topics API is because it wasn’t necessarily more privacy preserving than cookies. It was still possible to do cross-site tracking and fingerprinting using FLoC IDs.

But FLEDGE has baked in privacy fail-safes, said Łukasz Włodarczyk, VP of programmatic ecosystem growth and innovation at RTB House.

With FLEDGE, it’s clear who owns the data, who is responsible for the calculations and which entity is assigning users to an interest group. FLEDGE also makes it clear how and to whom data is being transferred.

“The concept is quite complicated,” Włodarczyk said. “But, frankly speaking, it needs to be in order to provide the right privacy guarantees.”

Enjoying this content?

Sign up to be an AdExchanger Member today and get unlimited access to articles like this, plus proprietary data and research, conference discounts, on-demand access to event content, and more!

Join Today!