Protected Audience API (formerly FLEDGE) in Privacy Sandbox on Android: reinventing the mobile ad network?

How will Google’s new Protected Audience API work in Privacy Sandbox on Android? And how will an ad go from an advertiser through a publisher to a person? If Google’s privacy plans come to fruition, that flow is going to change significantly on the world’s most popular computing platform in less than two years.

When Apple introduced SKAdNetwork to iOS in 2021, it changed the privacy narrative on the planet’s most profitable mobile platform. Privacy Sandbox on Android is largely seen as Google’s answer, but the technology that Google is building into PSA goes far beyond privacy. There are significant changes to how mobile SDKs operate, major upheaval to how advertisers target audiences, and huge transformation in how attribution will work after the GAID is retired from service.

But there’s also a massive transition in store for mobile ad networks, and how an ad leaves an advertiser’s digital fingers on a long winding path to a human’s eyeballs.

Today we’re going to dig into exactly that part.

This post is part of an ongoing series on Privacy Sandbox:

SDK Runtime (how Google is sandboxing SDKs)
Topics API (how Google sees ad targeting working)
Protected Audiences API on Android (this post on how Privacy Sandbox will do audiences and remarketing)
- Also: see Protected App Signals, a new part of the Protected Audiences API
Attribution Reporting API (how Google is proposing ad measurement will work)

The big change: the ad network now lives in your app

We’ve had mediation and app bidding and monetization capabilities in apps for some time now. So building ad network functionality into our mobile devices is nothing new. But Privacy Sandbox on Android signals a major shift in how that works. And in what is actually happening.

What data goes where
Who gets access to information
Where the ad auction actually takes place
And much more …

In traditional (as in: current) ad targeting, auctioning, and serving environments within most apps, ads come to our mobile devices, generally speaking, in one of two ways:

App bidding (header bidding)
Ad waterfall

In a waterfall world, an app looking to fill an ad request goes to a sequential list of preferred ad networks looking to fill the slot. The first one that says yes — with a presumably competitive bid but not one that is guaranteed to be the highest — wins and fills the slot with an ad. In an app bidding world, there’s a real-time auction between multiple ad networks and demand-side platforms simultaneously: everyone gets a crack at the slot, and the highest bidder wins.

While the ad fill request is initiated from within a publisher’s app, the actual auction generally takes place on an ad server (in some cases the publisher’s own), and the data informing each player bidding on each ad is generally sent to additional servers owned or used by those companies. There it can be enriched with additional data that helps ad networks value the impression appropriately and guides both the types of ads they feel would be appropriate for that slot and their bidding strategy: specifically the price they’re willing to pay for that impression.

So today, a lot of the mobile advertising ecosystem that both compensates developers/publishers and drives growth and user/customer acquisition happens off-device and involves a lot of data that is sent, managed, processed, and stored in multiple companies’ cloud systems.

A lot of this changes in Protected Audiences API

First off, at least some ads will be stored on device and periodically fetched in the background. There is an endpoint defined in the code for rendering creative, so presumably at least some parts of the ads and/or creative can also be streamed live. In addition, there’s a daily update URL that marketers can use to keep ads fresh.

Interestingly, ad networks will often want to send multiple ads for the same slot.

“Ad tech platforms may want to send multiple contextual ads back to the device and invoke the ad selection workflow to enable app install-based filtering in order to maximize chances to show a relevant ad,” Google says.

Why?

Because targeting lives largely on-device, using privacy-safe data that Topics API assembles from our app use history. Plus, the sandbox has access to additional targeting data such as language and a rough geographic location.

While I’m sure ad networks and other players will try to enrich data about devices or people, it’s not clear how they’d be able to do so under PSA. This could have a major impact on how ad networks, including the emerging titans of adtech, are able to differentiate their services. Device graphs based on identifiers like GAID are going to wither on Android, just as they’ve become largely useless on iOS with the de facto deprecation of the IDFA.

(Major platforms like Facebook or Twitter or Snap or Tiktok or even Google itself, of course, have plenty of their own data and will retain their own targeting and auction systems for their owned apps. Similarly, first-party data on first-party platforms will provide incentives for the continued consolidation of content, capability, and ad monetization.)

It’s not 100% clear which data will be available for the buy-side to make bidding decisions.

Clearly Topics will play a role, and Google says time and coarse location will be available, but Google also refers somewhat obliquely to “contextual information” and “seller signals” that are “supply-side platform specific signals,” and potentially more. Google says “the auction code, such as the bidding logic may need access to private user data such as app install sources.” For that reason, “the runtime will not provide network or storage access.” This suggests that Google is making additional data available which cannot be revealed for privacy purposes but is useful for pricing ad impressions and settling ad auctions. I’m guessing here, but this seems to be more than just topics from the Topics API, because Google is already censoring some of the data around topics (such as when a user deletes one) so that adtech SDKs don’t learn too much about users.

“Ad tech platforms will need to prepare to have some parts of their current auction and ad selection logic deployed and executed on the device,” Google says.

The actual auction or sale of an ad impression also happens on-device. The buy side and sell side meet in the app, and the buy side players run their bidding logic within the sandbox in self-contained Javascript that does not have either network or local storage access.

Functionality in that bid logic will generate a calculated bid amount, and bids will work sequentially for all ads with no guaranteed sequence.

However, there will be filtering on both sides. Publishers can block ads from campaigns they don’t want buying impressions on their apps — presumably, you’d block your direct competitors from advertising to your users in your app — and buy-side platforms can filter ads based on on-device signals. One example Google gives of those on-device signals is ad usage for frequency capping, but presumably there will be more filters.

One of them is filtering for the right ad from multiple that a winning bidder might have prepared and pre-uploaded for a given slot.

The winning ad “has the highest score,” Google says, which presumably includes the right price, and the right degree of relevance. Once a winner is determined, the privacy sandbox sends optimization signals basically immediately to both sell-side and buy-side: “to enable capabilities such as real time budgeting, bidding model updates, and accurate billing workflows.”

Another big change; audiences. And remarketing (but not retargeting)

While there are plenty of changes in Protected Audiences API for ad targeting, ad auctions, and ad serving, there’s also significant changes to how marketers will be able to create and use audiences.

Goodbye GAID, goodbye audiences? Goodbye remarketing?

Not quite.

But yes, a lot of change is coming to audiences, targeting, remarketing, and retargeting on Android. On Android today marketers can create custom audiences — including audiences built with people who once used their apps — and target or retarget them at will. (Just as in the recently-deceased golden era of mobile marketing on iOS, of course.)

But because Google is deprecating the GAID, the mobile advertiser on which these capabilities are built, that functionality is changing, and some of it looks like it will be lost forever. Fortunately, as Google is doing so, it is replacing the disappearing functionality with something that will keep at least some of these marketer superpowers alive. And, maybe, even add a few.

First: remarketing vs retargeting.

These are similar and confusing terms with conflicting definitions, but here’s how I define them in the context of mobile apps and mobile marketing. (And yes, I threw re-engagement in there because … why not.)

Term	Relationship	Mobile examples	Identifiers	Channels
Remarketing	Existing user/customer	Abandoned shopping cart notification	None 100% required GAID (now) Protected Audiences API (future) Email address Phone #	Ad In-app notification Email SMS
Retargeting	Former user/customer	Give us another try; re-download the app	GAID (now) Email address Phone #	Ad Email SMS
Reengagement	Lapsed user/customer	Open the app you already have	None 100% required GAID (now) Protected Audiences API (future) Email address Phone #	Ad Push notification Email SMS

The key insight in the context of Privacy Sandbox for Android? The main way retargeting is done today to recapture former app users is via GAID, and PSA doesn’t include a mechanism for that.

Privacy Sandbox for Android does include a mechanism for remarketing, but it’s explicitly labeled from Google as a solution for people who still have and are still using your app. Reengagement use cases would follow the same logic, because both would use custom audiences that are defined in-app. As it currently stands, however, there is no mechanism in Protected Audiences API for targeting former users of your app: traditional retargeting.

“Audience information is stored on-device and can be associated with relevant candidate ads for the audience and arbitrary metadata, such as bidding signals,” says Google. “The information can be used to inform advertiser bids, ad filtering, and rendering.”

Audiences, which you once created with whatever parameters you wished and targeted via IDFA, GAID, or email address, will be time-limited with a default expiry which can be overridden (probably a timer which needs to be called from time to time to ensure that it is still relevant.) They will have near-instant functionality, which is important for abandoned cart scenarios, for example.

“When an owner adds a user to a custom audience, it may fetch candidate ads from a buy-side platform,” Google says. “Returned ads and metadata can be stored in the custom audience’s “ads” field. Ad tech platforms may want to use this feature if they would like to start serving ads to this user right away.”

Very interestingly, just as with Topics API users can see what topics they’ve been assigned and delete ones they don’t want, people will also be able to see when apps have put them in custom audiences. And, like Topics, they can delete themselves from those audiences. In a very important point that marketers will need to pay attention to, doing so will prevent apps from adding them to audiences in the future.

“The proposal intends to give users visibility to the list of installed apps that have at least one associated custom audience,” Google says. “Users can remove apps from this list. The removal will clear all the custom audiences associated with the apps and prevent the apps from joining new custom audiences.”

That’s kind of a big deal, and Google says details on that are to be determined and released in the future.

App publishers also have some control here: apps can manage how audiences are created from them, and can grant that control to ad networks they trust.

Much more to know about Privacy Sandbox on Android

With targeting, serving, and measuring ads on Android all changing, it’s clear that even though PSA provides much more than SKAN in terms of data, it also changes much more than SKAN in terms of how the mobile ad ecosystem functions. As the industry provides feedback and Google updates its documentation, we’ll continue to update you here.

There is, of course, much more to know about PSA. For more insight, check out these additional articles by Singular experts, including CEO Gadi Eliashiv.

That’s a small selection.

While PSA is definitely still in the future, it’s also definitely coming. And as we saw with SKAN on iOS, when it comes, there will be multiple industry players and partners who are unprepared and unready.

Our suggestion: don’t be one of them.

Talk to Singular about how to future-proof your marketing measurement and mobile attribution: book a demo today.

Stay up to date on the latest happenings in digital marketing

Simply send us your email and you’re in! We promise not to spam you.