Privacy Sandbox on Android: What publishers need to know

On February 16, Google announced a multi-year initiative to build the Privacy Sandbox on Android, with the goal of introducing new and more-private advertising solutions. As many in the industry pointed out, this is likely the first step on Google’s winding road to eventual deprecation of its Google Advertising ID (GAID), the company’s device identifier equivalent of Apple’s now-deprecated Identifier for Advertisers (IDFA). This can impact both publishers and marketers in numerous ways, and it’s time for everyone in the advertising ecosystem to prepare for an inevitable world without cookies and identifiers. 

In the first of a two-part series looking at the impact of Google’s Privacy Sandbox on Android in the industry, we’ll look at what publishers need to know about this pivotal move. Let’s take a deeper dive. 

Is Google getting rid of GAID?

At this time, the fate of Google’s device ID is up in the air. The company hasn’t explicitly announced plans to deprecate GAID, but this move is — and has been — implied. That said, there’s time. 

Google will support GAIDs for at least two years while the company works out alternatives. And given that the GAID deprecation is still only being implied, it’s possible this timeline might be extended quite a bit, as we’ve seen with other Google privacy-focused shifts. That said, there are hints that Google will be looking to replace GAID entirely, marking a difference in approach from its counterpart, Apple, which permits users to opt-in to IDFA.

Why is Google making this move now?

Google hasn’t given a reason as to the timing of its decision to build the Privacy Sandbox on Android. However, as we all know, the drive toward privacy-centric solutions is hot right now, and Google’s pivots in this regard have a history of taking time to develop, vet and roll out. 

Why, and how, is this 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. In addition, Google is striving for a collaborative solution, built and refined with the input of the industry at large. By contrast, Apple presented its ATT framework to the industry as a decided, immediate action. 

What remains to be seen is whether Google will implement mechanisms to restrict and regulate its own insight into and use of personal device identification, or whether this shift will yield a massive competitive advantage for Google. The company is, after all, a massive advertising network unto itself. 

What does Google’s move mean for publishers?

In terms of volume, Android runs on a lot more devices than iOS, so the impact of Google’s changes could ultimately be even larger than the impact seen when Apple deprecated IDFA. That’s why it’s important for publishers to stay up to date on the Android developer blog and raising their voices with any concerns now, while Google is still in its testing and development phases

What does it mean for gaming and performance publishers running user acquisition campaigns specifically?

Without a doubt, performance advertising will experience new challenges whenever Google’s device identifier is deprecated. As such, performance advertisers and publishers running their campaigns are going to need to get more comfortable with aggregation models.

Moving forward, publishers will need to get acquainted with the attribution API that Google will introduce. Likewise, keep in mind that first-party data is still supported, and publishers can and should make use of that unmet potential. Google still supports the publisher-provided identifier (PPID), a hashed and encrypted ID that a publisher assigns to a (logged in) user and passes on to Google. PPIDs can provide a valid solution for cross-screen frequency capping, audience segmentation and targeting, and sequential ad rotation. However, if a user opts out (e.g., on GDPR basis) then the PPID becomes useless again.

With new industry solutions such as IAB Project Rearc’s recently announced seller-defined audiences, publisher first-party data is gaining weight and being made available for the broader (programmatic) ad ecosystem.

What else do publishers need to be watching on the Google front?

Google’s move to build the Privacy Sandbox on Android is only one of a number of ongoing initiatives that publishers need to be keeping an eye on. Here are some of the other moves to be watching, in conjunction with the eventual deprecation of GAID. 

Topics instead of FLoC:

Google recently announced that it would be pivoting away from its Federated Learning of Cohorts (FLoC) plan to instead focus on Topics API. FLoC has been met with resistance from major browsers and prominent global publishers, which rightfully noted that cohorts were still prone to fingerprinting and contained sensitive data such as health and religion. Conversely, Topics uses on-device data derived from engagement with various apps, which have been classified as belonging to different topics, to target ads in a way that is not entirely based on context. Google indicates that users will be able to control the association of their app usage with topics. Additionally, its taxonomy of Topics is human-curated and allows for sensitive topics such as health and religion to be excluded from use.

Mobile version for FLEDGE

The purpose of FLEDGE is mainly created for retargeting. It allows the creation of custom audiences depending on the way they previously interacted with an advertiser’s app. These audiences are then stored on the device. Auctions will then be managed entirely on-device, absent any transfer of data to a constellation of ad tech vendors. Google indicates that users will have control over the custom audiences to which they belong, and which apps can group them into audiences. 

Attribution reporting:

Google’s attribution reporting might be thought of as the spiritual equivalent of Apple’s SKAdNetwork, but for Android. It provides coarse, noised, non-user-identifiable conversion accounting to ad click and view events. However, unlike SKAdNetwork, it does this via two different reports: event-specific and aggregated. Google’s attribution reporting covers two more use cases that ATT has not initially considered: web-to-app conversion measurement and reengagement campaigns that target known users or customers.

SDK Runtime: 

This feature is unique to the Android Sandbox and has to do with defining permissions by app, while not interfering with other apps or the OS. The first iteration of the SDK Runtime feature primarily focuses on “advertising-related SDKs” that “enable ad serving, ads measurement, ads fraud, and abuse detection.” 

This is a very beneficial feature for publishers: Through the separation of runtimes, there is an opportunity for SDKs to be distributed independently of the apps that use them. Therefore, SDKs will no longer need to be integrated as packages into their host apps. SDK devs and providers will be able to upload their SDKs to app stores, independently from any app that might integrate them. Apps that use those SDKs could then simply indicate SDK dependencies, with the relevant SDKs being downloaded along with the app at the point of user installation.

SDK Runtime beta’s release could be tied to the Android 13 release (expected for late summer, early fall of this year). Publishers should be prepared to get in on the testing phase. 

How can publishers get involved?

It’s an important time for publishers 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.