Privacy Sandbox on Android: What advertisers need to know

Earlier this year, Google announced its multi-year plan to build the Privacy Sandbox on Android, with the goal of introducing new and more-private advertising solutions. In doing so, it took what is likely the first step toward eventual deprecation of its Google Advertising ID (GAID), the company’s device identifier equivalent of Apple’s now-deprecated Identifier for Advertisers (IDFA). For advertisers, the implications of this move will be significant and far-reaching.

That said, Google’s pivot isn’t happening overnight. So what do advertisers need to know about Google’s path forward? And how can they be future-proofing their marketing strategies in anticipation of the forthcoming changes? In this article, we’ll take a multifaceted look at the implications and topics to watch for advertisers.

Note: This is our second of a two-part series looking at the impact of Google’s Privacy Sandbox on Android in the industry. To read more about what publishers need to know about this pivotal move, check out the first post. 

Is Google getting rid of its Google Advertising ID (GAID)?

Most likely, yes. However, Google will support its mobile ad ID for at least two years while the company works on alternatives.

What’s coming next?

Google will be conferring with the industry in an effort to develop and roll out different frameworks and APIs to solve for the following: 

• Standard and custom targeting
• Attribution (aggregated and at the event level)
• Independence of monetization and attribution SDKs
• Enabling the above across devices

What do these APIs mean for advertisers?

Over the next two years, Google will be rolling out changes on a number of fronts. Here are the key areas that advertisers should be watching closely. 

Standard targeting via Topics

Google’s proposed Topics API represents its coarse-grained approach to interest-based advertising topics and targeting. Under Topics, any given user will be assigned five true and one random topic any time they use an app, and these topics will be refreshed within so-called epochs (an epoch being a to-be-determined period of time, such as one week). Ad tech intermediaries will be able to call on three of those topics — one for each of the past three epochs.

By providing up to three topics, infrequently used apps will have enough topics to find relevant ads, while frequently used apps will learn, at most, one new topic per week.

It’s worth noting that an app can also declaratively opt out of the Topics API, in order to disallow ad SDKs from using the API for that app. Topics associated with opted-out apps will not contribute to the weekly topic computation. Also, if there’s not enough app usage for the platform to infer five topics, the platform may consider options like randomly generating remaining topics.

Importantly: Topics also won’t solve for frequency capping or sequential targeting.

OK, so what’s the difference between Topics and contextual targeting? In short, Topics is like contextual targeting, but “with history.” In other words, Topics is designed to deliver interest-based advertising, derived from the apps with which the user has engaged in the past, whereas standard contextual targeting is based solely on the interests derived from the current content being viewed.

Topics will be built around a taxonomy of 350+ Topics. This taxonomy will be human-curated to ensure sensitive topics are not included. Currently, Google sorts the taxonomy itself, but this might be outsourced for more objectivity down the road. For comparison, IAB’s audience taxonomy includes 1,500 objectively classified segments.

There are still a number of open questions surrounding Google’s Topics API. For example, will the amount of topics increase? If so, by how much? Will there be demographic segments? Geographic segments? So far, it’s unclear, but these will be important questions for advertisers as they evaluate the role of Topics in their go-forward strategies. 

Custom targeting via FLEDGE

Google’s FLEDGE API has two purposes. The first is its custom audience API, through which developers will be able to create custom behavior-based groups like “left an item in a shopping cart” and offer those to advertisers. These audiences will be managed entirely on-device, absent any transfer of data to a constellation of ad tech vendors.

FLEDGE’s second purpose is found in its ad selection API, which provides a framework responsible for orchestrating ad tech platforms’ ad-serving workflows. These workflows leverage on-device signals to match users with the ad that’s most likely to appeal to them based on locally stored candidate ads. Ad tech platforms today typically perform bidding and ad selection exclusively on their servers. Custom audiences and other sensitive user signals will be accessible only through the ad selection API on the device. Additionally, for the remarketing use case, candidate ads will be fetched out of band (i.e., not in the context in which ads will be shown). The platform can be configured to periodically fetch updated audience-based ads in the background. This helps keep the list of audience-based candidate ads fresh.

Here’s the sequence that the ad selection workflow follows:

1. Buy-side bidding logic execution, which determines bids for candidate ads. 
2. Buy-side ad filtering and processing, whereby buy-side platforms will be able to filter ads based on additional on-device signals available during the ad selection phase. For example, ad tech platforms can implement frequency capping capabilities here. 
3. Sell-side decision logic execution, with the scoring logic typically being provided by the sell-side platform. The purpose of the code is to determine a winning ad based on bidding logic outputs. For instance, an app publisher may block an ad campaign from showing ads in the app.

Measurement via the Attribution Reporting API

Google’s Attribution Reporting API supports the following use cases:

• Conversion reporting: Helps advertisers measure the performance of their campaigns by showing them conversion (trigger) counts and conversion (trigger) values across various dimensions, such as by campaign, ad group and ad creative.
• Optimization: Provides event-level reports that support optimization of ad spend by providing per-impression attribution data that can be used to train machine learning models.
• Invalid activity detection: Provide reports that can be used in invalid traffic and ad fraud detection and analysis.

Ad tech platforms need to undergo a lightweight enrollment process to confirm the integrity of privacy mechanisms and allow access to the Attribution Reporting API. Android has yet to detail the process and is open to feedback at this time. The enrollment process ensures that ad tech platforms don’t unnecessarily duplicate themselves to gain more information about a user’s site and app activities. 

The Attribution Reporting API will facilitate: 

• Aggregate reports that provide conversion data that’s richer in lower-funnel data (revenue, number of purchases, etc.) than event-level reports, with selected upper-funnel breakdowns (e.g. campaign level, geo). For example: “Campaign X has led to a total of 1000 conversions and a total spend of $20,000.” Noise in form or random values is also added to the count in a yet-to-be-determined scale.
• Event-level reports with a rich upper-funnel view (campaign, sub-campaign, creative, down to the click_id itself) to associate a specific view of or click on an ad with a small amount of lower-funnel conversion data (e.g., “Click ID 123456 has led to a purchase on com.app_bundle_name.”) Data is limited and noised, with random data delivered with a to-be-determined probability value.

From a campaign standpoint, the above reports are sent with a delay. The advertising vendor can set a source expiry date during setup. This expiry date can be configured, but it cannot be fewer than two days or more than 30 days. Reports are then sent one hour after the source expires. 

The API can support post-install attribution use cases, allowing ad tech platforms to set a post-install attribution period. Google is also exploring use cases to determine whether the user uninstalls and reinstalls the app. Google is also exploring other potential features, such as:

• Non-last-click attribution models
• Cross-device measurement (web to app) 
• Prevention of duplicate trigger reports, in the event that an ad tech platform registers the same trigger multiple times via a deduplication key
• Enablement of third-party measurement through daisy-chaining

What else should advertisers be tracking over at Google?

As advertisers monitor Google’s mobile shifts, they should also keep their eyes on Google’s proposal around SDK Runtime.

SDK Runtime provides assistance for app developers to more reliably account for their apps’ data access and sharing practices. It will allow for faster SDK update distribution to apps by mitigating the burden on developers and users, while also helping ad SDKs identify and address ad fraud and invalid traffic via complete control over the remote views displaying media.

What we don’t know yet is whether Google will artificially limit ad SDKs via the Play Store and declare that any app not using an ad SDK sandbox would be banned from the store. So far, Google hasn’t announced its intention to do that, but even today developers need to support a minimum Android API version.

How is Google’s approach different from Apple’s AppTrackingTransparency (ATT) framework?

Compared with the rollout of Apple’s ATT framework, Google is giving the industry more time to adapt to its changes on Android — at minimum, two years. However, while Apple still permits users to opt-in to IDFA, it’s unclear whether Google will provide such an option, versus getting rid of GAID entirely. 

That said, Google is leading a more open conversation with the industry than Apple did, and the company is already working on solving retargeting and web-to-app attribution. However, given that Google is also its own ad network, it remains to be seen how much of a competitive advantage the company will carve out for itself in this process. Establishing decentralized processes would help Google remain as neutral as possible.

It’s an important time for advertisers to be keeping pace with Google updates. You can read up on proposals on the Android Dev page here and sign up for Google’s updates on the Privacy Sandbox here. 

---

Verve Group has been preparing for a future driven by ID-less targeting for years now, and development of innovative alternative solutions to cookies and identifiers represents an important part of our growth story. Learn more about our pioneering approach to privacy-first targeting, built exclusively for in-app advertisers and publishers, here. And if you have any doubts or questions about privacy-safe monetization practices, contact us below.