FLEDGE (Protected Audience API)

FLEDGE — short for First Locally-Executed Decision over Groups Experiment and now renamed the Protected Audience API — is a proposal in Google's Privacy Sandbox that lets advertisers show remarketing ads without third-party cookies. Instead of tracking a user across sites with a shared cookie, the browser itself remembers which interest groups a user has joined, such as visited this product page, and later runs the ad auction on the user's own device. Advertisers never receive a cross-site identifier, because the browser keeps the interest-group membership private and reveals only the winning ad. It is one piece of Google's plan to retire third-party cookies in Chrome while preserving the ad use cases those cookies enabled. Keep in mind the API is still evolving, so specifics change.

The flow has a few named steps. When you visit an advertiser's site, its code can call joinAdInterestGroup() to ask your browser to add you to an interest group, along with the ads and bidding logic to use later. When you visit a site that sells ad space, the seller calls runAdAuction(), your browser invites the relevant interest-group owners to bid, scores the bids locally, and renders the winner in a protected fenced frame that cannot leak data back out. The point is that the decision happens on-device, in the browser, rather than on an ad server that has stitched your identity together across the web. That relocation of the auction is the whole idea behind the locally-executed part of the name.

Classic retargeting worked by dropping a third-party cookie. An ad-tech vendor recognized the same cookie on the shoe store and later on a news site, knew you had browsed shoes, and served you a shoe ad. That model depends on cross-site identity, which is exactly what browsers are now restricting. FLEDGE keeps the outcome — a relevant remarketing ad — but removes the mechanism, the shared cross-site identifier. The interest-group membership lives in your browser, not in a vendor's user profile, and the auction that picks the ad runs on your device rather than in the cloud. So the advertiser can still reach people who visited a product page, but nobody assembles a cross-site trail of who you are along the way. The privacy improvement is structural, not just a policy promise.

The trade-offs are real, and honest assessment matters. On-device auctions are more complex to build and measure than cookie-based retargeting, and reporting is deliberately coarser to protect privacy, which frustrates advertisers used to user-level attribution. The API has changed repeatedly and been renamed, so anyone integrating it should treat documentation as a moving target and verify current behavior. It also does not restore every capability of cookie targeting, since frequency capping, measurement, and creative logic all work differently now. For marketers, the right stance is to learn the Protected Audience model now, test it, and pair it with first-party data and other Privacy Sandbox APIs rather than expecting a drop-in replacement for the cookie that behaves exactly as the old system did.

Using FLEDGE well means treating it as one tool in a post-cookie stack, not a like-for-like swap. It handles remarketing and custom audiences — reaching users who joined an interest group — while measurement, attribution, and broader targeting rely on separate Privacy Sandbox pieces such as the Attribution Reporting and Topics APIs. The practical work is defining useful interest groups, supplying good bidding logic, and rebuilding reporting around the aggregated, privacy-preserving signals the API provides. Because the auction is on-device and the results are anonymized, teams have to give up the granular user-level view they once had and design campaigns and metrics that work with less. Test early, because the mechanics reward hands-on familiarity more than a spec read.

The pitfalls are assuming FLEDGE is just retargeting with a new name, expecting cookie-grade user-level reporting, and building integrations against outdated docs after the several renames and revisions. Another is neglecting first-party data, since the interest groups you can define are only as good as the audiences you actually collect. The discipline is to map which of your old cookie use cases the Protected Audience API genuinely covers, verify current API behavior before shipping, and combine it with consented first-party data and complementary Sandbox APIs. Done that way, it preserves useful remarketing while removing the cross-site tracking that made third-party cookies a privacy problem in the first place, which is the entire reason the effort exists.

FLEDGE is an acronym for First Locally-Executed Decision over Groups Experiment, since renamed the Protected Audience API within Google's Privacy Sandbox.

Etymology: source.

Search interest for this term over the last five years:

View interest-over-time on Google Trends →

Areas of marketing where fledge (protected audience api) is a core concern: