A solution for remarketing use cases, designed so it cannot be used by third parties to track user browsing behaviour across sites.

Published on Updated on

Translated to: Español, Português, 한국어, 中文, Pусский, 日本語

FLEDGE can be tested in Chrome from versions 91.0.4472.49 or 92.0.4493.0 with the following flags enabled:


  • This is the in-progress version of FLEDGE for early testing, so it should not be considered feature complete or indicative of the final implementation. Progress and status are discussed in the regular WICG meetings. The minutes for the 2021/05/12 WICG call provide detail on what is and is not supported in the current implementation.
  • Run Chromium with flags explains how to set flags when running Chrome and other Chromium-based browsers from the command line.

Implementation status

FLEDGE is the first experiment to be implemented in Chromium within the TURTLEDOVE family of proposals.

Why do we need FLEDGE?

Understanding user interests can enable more relevant ads than simply choosing ads based on site content (contextual targeting) or by using information that the user provided to the site on which the ad appears (first-party-data targeting). Traditionally, ad platforms have learned about user interests by tracking their behaviour across sites. We need a way to present users with relevant ads without cross-site tracking.

FLEDGE satisfies remarketing use cases, but is designed so it cannot be used by third parties to track user browsing behaviour. The API enables on-device "auctions" by the browser to choose relevant ads, based on websites the user has previously visited.


  • The user's browser, not the advertiser or ad tech platform, stores advertiser-defined interest groups that the user's browser is associated with.
  • The user’s browser combines interest group data with ad buyer/seller data and business logic to conduct an "auction" to select an ad. This ad auction happens locally on the user's device, rather than sharing data with a third party.
  • Ads can be selected for an interest group, but an advertiser cannot combine interest group data with other information about a user—in particular, the identity of a person or the pages they visit. An advertiser cannot learn about what pages a user views on a publisher site.
  • Websites, and the ad networks used by those sites, cannot learn about their visitors' ad interests or interest groups: ad selection is done on the user's browser.

In other words, FLEDGE keeps your interests and browsing activity private. For example, if you visit an online shoe store and show an interest in running shoes, and then visit a news site that displays ads (a publisher), the advertiser (the shoe store) doesn't learn what pages you're viewing on the news site and the publisher (the news site) doesn't learn about your interest in running shoes.

How does FLEDGE work?

When a user visits a page on a site that wants to advertise its products or services (an advertiser) the site can ask the user's browser to associate the user with specific interest groups for a certain period of time (for example 30 days).

The interest group could be unique to the advertiser's website, so that it functions as a remarketing list. Alternatively, multiple websites could agree to assign users to the same interest group, for example if the sites are partnered together or they belong to the same ad network. Periodically the user's browser fetches ads designated for interest groups, along with code that provides instructions from advertisers for when an ad associated with an interest group should be eligible for bidding in an on-device auction, for example only on inventory with ads near the top of the page. When the user visits a publisher site that is configured to accept ads using the FLEDGE API, and to display ads from an ad network used by an advertiser site the user visited previously, ad network code in the page makes a request to the browser to run "auction" code to select an ad. The "winning" ad is displayed.

  1. A user visits a page on a site that wants to advertise its products, such as an online store.
  2. The advertiser site (or the ad tech it uses) asks the user's browser to join an ad 'interest group' by calling joinAdInterestGroup(), passing data including ads relevant to the user's browsing, the ad platform host name, and URLs to access bidding logic and bidding signals.
  3. The user visits a site such as a news publisher, that displays ads and is configured to accept ads selected using FLEDGE.
  4. The user's browser runs an 'auction' to choose an ad for inventory (ad slots) that can accept FLEDGE-selected ads. The 'seller' in this auction might be the site itself or a third party acting on its behalf, such as a supply-side platform. The 'buyers' are third parties bidding for the site's ad inventory, such as demand-side platforms acting on behalf of advertisers. The seller in this ad auction has three jobs:
    • Choose which buyers can participate.
    • Choose which bid is most desirable, based on each bid's price and metadata.
    • Report the auction outcome.
  5. The seller initiates the ad auction by calling runAdAuction(), with data including the host name of the seller, signals from buyers and the seller, and a URL for auction decision logic.
  6. The auction returns data about the winning ad. The data cannot be accessed by the publisher site, except to render the ad in a Fenced Frame.
  7. The ad is displayed.

Engage and share feedback

Find out more

Last updated: Improve article

We serve cookies on this site to analyze traffic, remember your preferences, and optimize your experience.