What is the Protected Audience API and does it change remarketing?

By Niv Klein

Google’s likely deprecation of GAID in 2024 is big news for businesses and app marketers. For those who leverage remarketing as a prime strategy for retention and engagement — and there are many as chart A below shows — it’s even concerning.

However, before you ring the alarm, it’s important to stress that Privacy Sandbox is not as scary as it seems at face-value. Marketers aren’t left high and dry. This disruptive update is accompanied with technological innovation to ensure there are solutions in place to help marketers achieve their goals.

Alongside the move to reduce reliance on device IDs, new privacy-preserving technologies are being put in place. At AppsFlyer, we’re working closely with Google and industry partners to design a solution that is privacy-forward, while enabling businesses to grow and retain their users through remarketing.

The Protected Audience API (formerly known as FLEDGE) is Google’s framework for a privacy-centric, on-device, ID-less remarketing on Android.

But does the Protected Audience API change remarketing as we know it?

And looking beyond marketing teams, how will this new framework affect app developers and advertising partners?

Answers ahead.

Protected Audience API, simplified

So how will remarketing work in the age of the Protected Audience API? Here’s a simplified explanation comparing the current, advertising-ID-based remarketing to remarketing using the Protected Audiences API.

Remarketing with GAID

Today, remarketing is enabled by Google Advertising ID (GAID) – a cross app mobile device ID that is generated by the Android OS and communicated across ad networks to help marketers personalize their campaigns as follows:

Custom audience segmentation: App users are grouped into custom audiences according to shared traits or app usage, with each app user represented by their GAID.

Custom audience communication: GAID is used for sharing an app user’s custom audience membership with advertising partners (such as ad networks and their publisher apps)

Custom audience targeting: Ad platforms can then tailor personalized ads and bids to specific GAIDs according to their custom audience membership, and serve the ad once the GAID becomes available within a publisher app.

Custom audience attribution and measurement: User engagement with remarketing ads is communicated using GAID, which is the vehicle that MMPs leverage for their attribution models. This information is also passed to ad networks and publisher apps to help them further optimize their ad logic in real-time.

Now that we’re all fully versed in the ins and outs of remarketing today, let’s explore how it will work without the use of GAID.

Remarketing with the Protected Audience API

With the Protected Audience API, the Android OS will facilitate the exchange of information between advertiser and publisher apps, and their corresponding buy side and sell side adtech platforms.

Instead of relying on a shared identifier, as is done today, audiences will be created on-device for custom targeting. This way, all the data is siloed on the device without giving any third party the ability to access it.

The sequence for remarketing within the Protected Audience API will be as follows:

Custom audience segmentation: Users are grouped into custom audiences according to shared traits or app usage. Each user is added to the audience on device by the advertiser app itself through Android’s Protected Audience API.

Custom audience communication: Upon audience creation, a specific ad platform (such as a DSP ad network or an SRN, such as Meta for example) is defined to display ads to this audience. Due to the fact that the device’s audience membership cannot be communicated outside of the device, ad serving processes that traditionally occurred on the ad platform’s server will now be set to run on the device itself.

To achieve this, the advertising app must pre-define the following elements as part of the audience:

Ad creatives: the ads they intend to serve to the audience on other apps
Bidding signals: factors that are important for determining a future bid such as the user’s locale, activity, LTV score, etc.
Bidding logic: the logic for how to use the different variables received from the custom audience and the publisher app for determining a bid in real time. Since the logic itself is not at the user level and is subject to real time updates it is fetched from a trusted server on the ad platform side
Activation/Expiration time: the time when the custom audience is planned to be activated and the time it is set to expire
For example, a shopping app wishes to remarket to users who purchased recently in order to incentivize them to make their next purchase.

Once “App user A” has completed a purchase, the app will call Android’s Protected Audience API to join “App user A” to the custom audience “Purchased in the last 7 days”.

The on-device custom audience will include the ad network name where the shopping app set their ad campaign, the ads within that campaign, an activity score for tailoring a competitive bid, a pointer to fetch the ad network’s bidding logic in real time, and expiration time set to 7 days from the time of purchase

Custom audience targeting: Once a publisher app requests to display an ad, it will call the Protected Audience API to receive a winning ad and bid as derived from the custom audiences set on the device. Here too, elements that are required will be communicated by the publisher app and its sell side partner to determine a winning ad:
- Seller and ad auction signals: factors that are important for determining a winning ad and bid such as the type of app or ad placement and comprehensive contextual information.
- Decision logic: the logic for how to score an ad based on the variables shared by the buy and sell sides.
- For example, a news app wishes to display an ad within their fashion section. Once “App user A” opens an article in the fashion section, the news app will call the Protected Audience API to check if there is a custom-audience based ads targeted for this app user.

This “ad selection” request will include the seller ad network/SSP through which the action is made, the requesting app and app vertical, the ad format and dimensions, the content category, and a pointer to fetch the seller ad scoring logic in real time. This information is used to bid against other custom audience based ads as well as other ad inventory.

The Protected Audience API will respond with a winning ad and bid to be served by the publisher app

Custom audience attribution and measurement: Winning impressions will be reported back to both the buy and sell sides for measurement and optimization purposes. This element is still undergoing design and we will share more details as it evolves.

Protected audience API: Advertiser originated custom

How will the Protected Audience API impact me?

Let’s start with the perceived challenges:

Users can only be added to custom audiences while active: Unlike GAID, where audiences can be created retroactively, the Protected Audience API requires the app to be active (i.e. open, in the device’s foreground) in order to add the user to an audience. This will require app developers to:

Define a robust custom audience targeting strategy throughout the user lifecycle, since many of the audience strategies could only be set in advance.

For example, if an advertiser intends to show the user a remarketing ad after 7 days of inactivity, they should set this audience in advance each time the user launches the app (with activation time set to the future), and remove the user from the audience in case they engage with the app before the 7 days of inactivity period.

Be fast to compute audience membership: Having a limited timeframe to add the user to an audience means audience segmentation will require agility and speed.
User control details yet to be defined: Android users will be able to control which apps are allowed to add them to custom audiences. Android has not yet shared the full details of this design, but given their commitment to the persistence of the ecosystem demonstrated throughout all the Privacy Sandbox initiatives, we don’t foresee disruptive opt-out rates.
Advertiser-originated custom audiences must utilize an SDK: Advertiser’s BI and CRM teams are traditionally able to perform custom audience segmentation on their end and then upload custom audiences to ad platforms manually using CSV file uploads or programmatically using direct API integrations.

With the move to on-device audience management, advertisers would need to either implement these abilities directly in their app’s SDKs or use designated ad tech platforms. Utilizing the AppsFlyer SDK, advertisers can use the AppsFlyer Audiences platform for custom audience management in the same way it is being used today.

To review the advertiser generated flow, please see the diagram above

Ad platform-originated custom audiences: GAID enabled advertisers to delegate audience segmentation to ad platforms (e.g. DSPs or Ad networks) without being required to implement designated mobile SDKs within their apps. In contrast, the Protected Audience API requires an SDK in order to add users to custom audiences which might create a technical and operational overhead for advertisers and ad platforms alike. To help bridge this gap, AppsFlyer is building partner integrations that will allow for partner-defined custom audiences as well – see Graph C for more information.

Protected audience API: Ad platform originated custom

Now let’s zone in on the unique advantages

Protects user privacy: The Protected Audience API offers major progress when it comes to user privacy. This solution facilitates a privacy-centric way for brands to personalize communication with their target audience without sharing user information to 3rd parties. It can unlock remarketing for many businesses that hesitated to do so due to their fear of sharing user information. Beyond remarketing, the Protected Audience API is a significant advancement for the app ecosystem and displays how to leverage technology to preserve privacy, without compromising user experience or ad optimization.
App install ads filtering: The Protected Audience API includes a dedicated feature that enables app developers to opt-in devices to app install ads filtering. With this filtering logic, ad platforms could set UA campaigns to exclude existing app users as part of their ad selection, thus optimizing acquisition costs.
User bidding signals: Protected Audience API enables advertising platforms to perform granular, device level bid optimization through the use of user bidding signals that are added to each custom audience. This functionality helps ad platforms optimize their bidding logic by enriching it with additional details in a privacy-centric manner. For example, apps can now pre-set a more competitive bid for a user who generates higher revenues.

What should I do next?

The Protected Audience API and the reduction of our reliance on device IDs has varying implications, depending on what side of the aisle you’re sitting on. While we have determined that remarketing will have successful continuity thanks to the Protected Audience API, you’ll have to form different strategies, depending on if you’re a marketer or an ad partner.

Wearing a marketer’s hat

The Protected Audience API introduces massive technological changes on Android and as such education is a huge component for successful preparation. This is necessary for many internal stakeholders, including marketing, BI, and dev teams. Advertisers will need to map their current retargeting infrastructure and strategies and make sure they fit to the new flow. As your partner for growth, AppsFlyer is here to help you understand and actualize the potential of the changes the Protected Audience API offers.

Beyond internal teams, marketers will need to ensure that their advertising and tech platforms are prepared for the change. AppsFlyer is developing technological assets and partnerships throughout the app ecosystem to help amplify your growth within this new framework.

Walking a mile in an ad platform’s shoes

Ad platforms are faced with many new elements that they’ll have to adapt to, with some tectonic shifts of server-side mechanisms to on-device. While sell-side entities such as SSPs and monetization SDKs already require on-device presence, buy-side platforms such as ad networks and DSPs have not traditionally required their advertisers to implement a mobile SDK for running advertising campaigns.

AppsFlyer is collaborating with ad platforms to enable custom audience targeting within the Protected Audience API framework by utilizing the AppsFlyer SDK. This will streamline the connectivity between advertisers and advertising partners, which is required for executing these critical marketing flows.

Connecting the ecosystem to re-envision remarketing

To sum up, while remarketing is changing it is by no means becoming extinct. And it is through collaboration that we can further this strategy’s success, while ensuring it preserves end-user privacy.

It is this vision that has led AppsFlyer to collaborate closely with Google, our customers, and our advertising partners in shaping the framework for utilizing the Protected Audience API. It is my hope that we as a community can further collaborate, so that we continue advancing our privacy practices in tandem with growing business success and retention.

Remarketing