This morning, Google announced plans to bring a Privacy Sandbox effort to Android. Google’s original Privacy Sandbox initiative was introduced in 2019, and its stated purpose was to create a collaborative, open-source environment in which privacy technologies could be developed as web standards. The initative was undertaken shortly after Google announced that it would deprecate third-party cookies in the Chrome browser; the Privacy Sandbox was presented as a means of building tools and tehcnological approaches to preserving advertising efficacy while safeguarding user privacy in a way that third-party cookies didn’t.
Most mobile app marketers can be forgiven for a lack of familiarity with the Privacy Sandbox and the sometimes cryptically-named tools and frameworks that comprise it: FLoC, TURTLEDOVE, the Topics API etc. The Privacy Sandbox was designed to solve a specific problem that mostly is irrelevant to app advertisers: replacing third-party cookies with a privacy-preserving yet effective apparatus for targeting advertising. In large part, mobile app advertisers aren’t concerned with cookie deprecation because they primarily advertise within apps, and not on the web. Apple’s App Tracking Transparency (ATT) privacy framework, rolled out last year, created frictions for mobile app advertisers (and mobile web advertisers) through the deprecation of the iOS device identifier, the IDFA, as a form of consumer privacy protection.
I speculated when Apple first introduced ATT that Google would follow suit, albeit with a more moderated and controlled approach. The Privacy Sandbox for Android appears to be that: it’s a collaborative effort that invites participation from the industry in replacing the existing system for ads targeting on Android with something that is more mindful of consumer privacy. Although Google recently introduced some new privacy initiatives on Android, including the reanimation of its mostly-dormant “Opt Out of Ads Personalization” system setting as an Android-equivalent of Apple’s Limit Ad Tracking setting, it obviously wants to introduce further privacy controls to Android. And it aims to accomplish that with a Privacy Sandbox process for the platform.
Google states in the blog post announcing the Privacy Sandbox for Android that, while its goal with the initiative is to ultimately replace various platform advertising features — but most notably, the Google Advertising ID (oftentimes referred to as GAID) — it will continue to support those features for “at least two years.” This sits in stark contrast with Apple’s ATT policy, which was devised without (to my knowledge) any input from the advertising ecosystem and rolled out within a year of being announced, although its original, intended introduction was earlier than that.
The technical specifications for Google’s Privacy Sandbox for Android currently are currently comprised of two components: an SDK Runtime, and a set of Privacy-Preserving APIs. Below, I’ll provide a broad overview of each.
SDK Runtime
The Android operating system uses a technique called ‘app sandboxing‘ to isolate the operating environment of each app from the environments of other apps, and to limit apps’ access to the OS. This approach prevents malicious apps from being able to access data from other apps and from interfering with the OS, and each app is granted specific permissions in its own operating environment.
When a developer wants to implement the functionality of a third-party service, such as an ad network or a CRM product, it must integrate what’s known as an SDK (software development kit) into its app. Currently, an SDK integrated into an app operates within that app’s sandbox and is granted the same permissions as the encompassing app. In some cases, app developers might not be aware of the data or device parameters that third-party SDKs access, which creates security and privacy vulnerabilities.
As a component of the Privacy Sandbox for Android, Google plans to introduce an SDK Runtime in Android 13: this is a separate, dedicated runtime environment for third-party SDKs within apps that can be granted permissions that differ from the app’s, allowing the app to control the data to which these third-party SDKs have access. Google notes in its Privacy Sandbox for Android documentation that the first iteration of the SDK Runtime feature will be scoped primarily for “advertising-related SDKs,” which it describes as the SDKs for services that “enable ad serving, ads measurement, ads fraud, and abuse detection.”
One interesting aspect, and beneficial feature, of the SDK Runtime approach is that, through the separation of runtimes, it creates an opportunity for SDKs to be distributed independently of the apps that they service, meaning that SDKs will no longer need to be packaged into and “statically linked” to host apps. Service 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. This would allow the developers of SDKs to commit non-breaking changes without requiring app developers to integrate updated SDKs.
Privacy-Preserving APIs
The Privacy Sandbox for Android proposal includes a set of privacy-preserving APIs that mostly mirror what has been established with the initial Privacy Sandbox for web. These APIs, per Google, “protect user privacy through a combination of techniques such as retaining selected private data and processing on-device, aggregation and randomizing of data, and on-device ad selection.” The three core use cases identified in the initial design proposal are captured with:
- Topics, which is similar to the Topics API for the original Privacy Sandbox that was revealed in late January. This concept creates coarse signals of user interest based on engagement with apps that have been classified into a standardized taxonomy, and allows those interests to be targeted against;
- FLEDGE for Android, which is equivalent in practice to FLEDGE for web. FLEDGE for Android allows app developers to define custom audiences within their apps and facilitates the targeting and serving of ads on-device;
- Attribution Reporting, which allows campaign performance to be measured on-device and reported to ad networks and advertisers.
I’ll provide more color for each of the concepts below.
Topics
The Topics concept proposal for the Privacy Sandbox on Android very closely resembles the Topics API that was recently introduced for the original Privacy Sandbox, the GitHub project for which can be found here (I wrote a simple simulation which estimates the number of permutations of topics combinations possible given the topics selection logic, which can be found here).
The details of the system are less interesting than the general objective, which is to use 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. The idea behind Topics is that the usage of a particular app might correlate with some interest on the part of the user, and that interest can be targeted by an advertiser through this topics classifier in a way that wouldn’t be available or computable, given a much narrower field of vision, to the advertiser.
The Topics system, on both web and Android, attempts to prevent cross-app identification by 1) introducing random noise into the topic selection process (in each case, 5% of the time a topic is assessed for a property, a random topic is selected) and by 2) assigning several topics to a property.
The implementation of the Topics concept for mobile apps is fairly straightforward: the different advertising SDKs integrated into the apps on any user’s phone could use the topics associated with any given app, but only for that app, to fill inventory in that app. This approach is more helpful than simply using the context of the app for targeting because Android is able to make associations about interests related to that app that aren’t visible or perceptible to any SDK owner, but personally-identifiable information (such as a device ID) isn’t used as the basis for targeting.
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 to be excluded from use.
FLEDGE for Android
Similar to the Topics concept, FLEDGE for Android mirrors the proposal that was made for the web in the original Privacy Sandbox. FLEDGE is an evolution of the TURTLEDOVE concept, which I discuss in detail in this episode of the MDM podcast. FLEDGE essentially allows for re-targeting and custom audience creation without the need to syndicate data across a set of third-party ad tech vendors. FLEDGE allows advertisers to put users into targeting groups based on those users’ interactions with their properties, and to allow publishers to run ad auctions to fill inventory on their properties without needing to invoke an external service. The purpose of FLEDGE is to allow for users to be organized into groups and for auctions to be managed entirely on-device, absent any transfer of data to a constellation of ad tech vendors.
As with the Topics concept, Google indicates that users will have control over the custom audiences to which they belong, and which apps can group them into audiences. Ultimately, FLEDGE flips the directionality of data flow in the ad serving process: audience classification happens on the device, and buy-side platforms submit their bidding logic to the device to be received by SSPs operating on the device. In the case of Privacy Sandbox for Mobile, the auction takes place within an app, and both the buyer (successful bid) and the seller can report auction outcomes to their own services via the FLEDGE API.
Attribution Reporting
The Attribution Reporting concept is, similarly to the two previous concepts, a mobile app analog to an existing proposal for the web. Attribution reporting might be thought of as the spiritual equivalent of SKAdNetwork on Android: it provides coarse, noised, non-user-identifiable conversion accounting to ad click and view events, although, unlike SKAdNetwork, it does this via two different reports (event-specific and aggregated).
The purpose of Attribution Reporting in the Privacy Sandbox for Android initiative is to allow for custom audience creation and re-targeting without using an advertising ID that can be (and must be) shared across various ad tech vendors.
By keeping all matching data on the device and only revealing successful conversions at the level of the campaign (assuming adequate noise is applied to the event-level reporting such that individual events can’t be matched based on timing), a system like the Attribution Reporting concept (and similar implementations of the same logic, such as SKAdNetwork and PCM from Apple and AEM from Facebook) attempts to allow for conversion accounting without revealing the underlying attributions that make it possible.
Noise or motion?
The original Privacy Sandbox initiative has produced a cacophony of theory and opinion but, as of yet, no substantive improvements to user privacy. The SDK Runtime component of the Privacy Sandbox for Android certainly offers real promise on a concrete timeline (Android 13), but the other components are merely reproductions of ideas that haven’t gained traction in the original Privacy Sandbox. My thoughts on Apple’s approach to privacy aren’t difficult to parse, but Apple can’t be accused of having dithered on it.
