Protected App Signals is a game changer for Privacy Sandbox targeting and ad relevance

When Google first unveiled Privacy Sandbox on Android, I was seriously underwhelmed by the targeting options. Topics API, it seemed to me, offered little better than contextual targeting. But Google has massively upgraded Protected Audiences API in Privacy Sandbox with, among other things, Protected App Signals. The result is greatly enhanced targeting capability that ad networks will be able to take advantage of and deliver for their mobile user acquisition customers.

And there’s probably more to come.

My goal here:
Unpack Protected App Signals and explore what this will offer for better on-device ad targeting in Privacy Sandbox.

Protected App Signals: what are we talking about here?

The key concept behind Protected App Signals will be familiar to everyone who knows even a little about Privacy Sandbox: the API stores clues and hints about what a person using an Android device might find interesting in the future, locally on-device.

Those hints and signals can be then used to make ads shown on that device more relevant to what its owner wants, does, or likes.

If it works, it’s the modern adtech gold mine: privacy-preserving ad relevance.

By design, Protected App Signals can only be accessed only by the adtech SDK that stored them. They’re created and stored on device to avoid data leakage, and they are encrypted to ensure privacy. When needed off-device for ad auctions, they are sent encrypted to a Trusted Execution Environment, but they’re only sent with enough data for targeting, not with data that reveals personally identifiable information.

 

 

Apps and SDKs cannot read or inspect these signals while on-device: there is no API for doing so. And the APIs that move Protected App Signals into Trusted Execution Environments for ad auctions are “designed to avoid leaking the presence of signals.” 

Signals? What kind of signals?

Pretty much anything you would have wanted to know from IDFA or you know now from GAID can be an app signal in Protected App Signals. Google’s documentation says signals like “app installs, first opens, user actions (in-game leveling, achievements), purchase activities, or time in-app” all count.

What we don’t know yet is how many app signals you can store.

The number of signals you can save is subject to storage quotas set by the system, and each adtech vendor gets allocated only a certain amount of storage space. Furthermore, app signals are stored on a first in, first out basis. Think of a dynamic queue that, once it’s full, every newly added item pushes the oldest item out.

Given that Protected App Signals looks to be a much more powerful targeting mechanism than Topics API, one of ad networks’ top priorities as Privacy Sandbox ramps up will be to determine the size of that buffer. It’s going to be fairly large, if the space that Google has allocated for campaign data is any indicator: we’re talking 64 bits for the Attribution Reporting API upper funnel event-level reports.

There’s a problem though.

The amount of space Privacy Sandbox will allocate for Protected App Signals will need to cover all of an ad network’s clients. If an SSP is in thousands of apps, that space could fill up fairly quickly, limiting targetability to niche and long-tail apps and games.

In addition, signals have a max TTL, or time to live. In other words, they are temporary, not permanent, and will eventually expire out of memory. How long it takes for that to happen is unknown outside of the Privacy Sandbox team, at least so far.

Interestingly, adtech companies with an on-device SDK can update as well as delete signals along with creating them. So theoretically, if certain signals turn out to be ineffective for targeting, an ad network could modify or just get rid of them, saving space in its queue.

Fresh signals can be sent to ad auctions as often as hourly. So while it’s not as quick as minutes after an add-to-cart action, for instance, it is relatively fast.

What about context and Protected App Signals?

Well, context still matters.

In ad auctions under Privacy Sandbox, buyers’ custom logic will process Protected App Signals along with contextual data provided by the publisher.

Some of that will be zero-party data that both buyers and sellers can infer, like date, time of day, day of the week. All of that can be combined with some degree of knowledge about the world, work days, holidays and vacation days, and global events like the Summer Olympics coming up in Paris this year. There’s additional zero-party data such as app placement information that will need to come along for mediation platforms, DSPs, or other adtech vendors to be able to bid on the ad slot and deliver the right kind of ad.

Some of it is likely to be first-party data such as rough location, language settings, some device data, the publisher app the ad slot is in, and so on. There may also be some rough contextual data from Topics API and other sources as well.

All in all, adtech companies will compete on how they store Protected App Signals, how many of them they store, what verticals of app they store them from, and how enriched the Privacy Sandbox signals can be.

And reporting?

We of course know that Privacy Sandbox reports postbacks via the Attribution Reporting API with significant amounts of upper-funnel campaign and delivery data along with much less engagement and conversion data, somewhat similar to Apple’s SKAdNetwork or the new AdAttributionKit (AAK).

But what about reporting specifically on the success/failure indicators in Protected App Signals? That remains to be determined, Google says:

“Auction participants receive applicable win reports and loss reports. We are exploring privacy-preserving mechanisms for including data for model training in the win report.”

Google is enhancing Privacy Sandbox steadily and regularly; stay tuned for more on this front. The goal is to be able to send event-level user data outside of trusted execution environments (TEEs) in a privacy-safe way. One option Google is using in the short term is adding noise to the data, but there may be better options available in the future.

So much better targeting than Topics API

When I first looked at Topics API in Privacy Sandbox, I said this:

“This is not granular at all. In fact, it’s very coarse-grained.

“We’re talking 350 topics initially, which is tiny. For reference, the IAB Taxonomy is 1500 terms, and even that is really, really limited compared to a somewhat-complete taxonomy which might have hundreds of thousands of terms.”

Just imagine sports. It needs hundreds of topics in and of itself: type of sport, league, anything around intent or purpose. Just buying ice hockey gear versus finding an app to check the Stanley Cup playoff scores would be challenging.”

But even with more topics, Topics API is contextual data. 

Clearly, Protected App Signals is much more powerful: it’s based on behavioral data, which is much more predictive of real-world activity. It’s something that adtech experts think is a gamechanger and are starting to get excited about. Obviously, we’re going to have to see what this looks like and how it works in the real world, but that testing is going on right now and it is starting to look pretty good.

Google is also updating Privacy Sandbox regularly:

 

 

That’s also good news: as an area of focus, Protected App Signals is likely to continue to get some attention and additional features.

 

How important is it to have your SDK on devices for Protected App Signals?

Only ad networks or MMPs with on-device SDKs can generate Protected App Signals, and only adtech companies that generated the Protected App Signals can access them. So it’s pretty critical to work with a vendor that has its SDK on-device.

Interestingly, Privacy Sandbox may significantly privilege companies with scale, specifically for these signals, because not only will ad networks with their SDKs in many apps see a lot of activity that can be used for Protected App Signals, they are the only ones who can move those signals into a trusted execution environment in order to conduct an auction.

That may make it harder for SSPs and other adtech companies with smaller SDK footprints to compete.

Webinar on Privacy Sandbox

Clearly, there’s a lot to learn about Privacy Sandbox. While we don’t know when it will be fully operational and implemented across all Google-maintained Android devices, it’s likely at some point in 2025.

How should you prepare? Start by attending this webinar.

What we’ll talk about:

• What will life for a user acquisition team look like with Privacy Sandbox?
• How much will marketers have to change in their workflows?
• What levers you can use to drive incremental growth after launch
• What do you need to do to be campaign-ready with network partners and MMPs?
• How to start testing so you can hit the ground running?

See you there!