Everything We Know (And You Also Should) About Android Privacy Sandbox

For the past few years, Android has been gathering industry feedback from developers, publishers, and adtech leaders to find a solution for a privacy-centric approach that will enable businesses to thrive. 

Anthony Chavez, Privacy Sandbox VP at Google, made a long-anticipated announcement on releasing the beta version of Privacy Sandbox. The beta will only affect a small group of developers and users who will be notified and can decide whether to opt-in.

What’s Android Privacy Sandbox?

The Privacy Sandbox is Android’s privacy-centric toolkit. It is simply a better way to maintain users’ privacy while still providing businesses (both advertisers and publishers) with tools to market and monetize.

There are four key APIs at the core of the Privacy Sandbox toolkit:

1. Topics
2. FLEDGE
3. Attribution reporting
4. SDK Runtime

“The Privacy Sandbox Beta provides new APIs that are designed with privacy at the core, and don’t use identifiers that can track your activity across apps and websites.”

Anthony Chavez – VP, Privacy Sandbox at Google

While there are clear similarities in the approaches for the Topics, FLEDGE, and Attribution reporting APIs for Google’s web-based and app-based privacy solutions, the technologies used to build them are fundamentally different. The SDK Runtime is a mobile app-specific solution, and we do not know much about it so far. 

Topics

Google introduced Topics for mobile apps. Topics helps advertisers display ads to the relevant user groups based on their interests. Instead of passing GAID (Google Advertising ID) to various third parties that process data and define user interests, this approach allows advertisers to granularly target users based on their topics of interest and latest interactions, determined by Google’s ML. 

The user-specific topics are stored on the device, and they are not passed to external servers—not even Google’s. 

This approach has many advantages for users:

1. The reduced risk of device fingerprinting. 
2. Control and transparency. Users now not only have access to the list of their own defined topics and interest groups, but they can also remove specific topics (or all of them together).
3. Avoiding sensitive categories. The list of topics will be public and human-curated, so any sensitive information like race or gender won’t be considered.

The Topics is not the only way advertisers can reach their audiences—it will be just one of many tools to support interest-based advertising. Another approach, based on the contextual distance between the promoted and the publisher’s bundle, can either be combined with the Topics approach or be a subject for a separate campaign setup.

The initial trial taxonomy is yet to be defined—the list is crowd-sourced and might include “somewhere between a few hundred and a few thousand topics.”

FLEDGE – Viva la re-engagement

FLEDGE allows for smooth retargeting while maintaining user privacy. User re-engagement is an essential tool for marketers, as it helps them deliver more relevant ad experiences to users who interact with their products and drive the desired outcomes. It’s also highly beneficial for users who might still be interested in a product. 

FLEDGE is a technological solution that prevents user data oversharing by keeping the data on the user’s device without passing it to any third-party services. 

With FLEDGE integrated by all parties, users that have interacted with a promoted app can be added to the Custom Audience and re-engaged.

The publisher’s app hosts an on-device auction, where the adtech provider decides which ad would be more relevant for the user based on multiple criteria. If the bid is won and the ad is displayed, the auction results are reported.

The custom audience can be defined by a publisher, advertiser, or adtech platform. Instead of sharing the remarketing list, they can create multiple audiences for different use cases. As an extra measure to preserve user privacy, FLEDGE’s in-app custom audiences are distinct from Chrome interest groups.

Like with other Privacy Sandbox solutions, custom audiences are stored on users’ devices and are not shared externally. Users have control over the audiences they are a part of and can easily remove themselves from the lists.

Attribution Reporting

Google developed this API to help track advertisers’ performance without identifying individuals as they navigate across other apps.

It preserves privacy by grouping users, randomizing and anonymizing the data, adding noise, and limiting the information that leaves the user’s device.

The Attribution reporting API is available at two levels:

• The event-level reporting provides transactional information (ad click or view that likely resulted in conversion). This approach has advantages over the SKAdNetwork reporting, as it provides more granular data on the attribution source and trigger type, which allows for campaign optimization.
• Summary reports display aggregated information, like ROAS and purchase value, but over groups of users rather than individuals.

How accurate will the attribution reporting be?

It looks like it will be pretty accurate. Google is committed to going the trial-and-error way to achieve its goal of serving both users and advertisers. This means going the extra mile to maintain user privacy while also helping advertisers navigate and build thriving digital experiences.

SDK Runtime

The proposal for SDK Runtimee is still being designed. At first glance, we can see that the whole infrastructure will change to reduce undisclosed access, tracking, and user data sharing through third-party SDKs.
“SDK developers would no longer send their SDKs directly to apps; instead, the SDK developers would use an SDK upload UI to publish their SDKs to an app store. The app store would then handle the distribution of apps, along with any SDK dependencies, to end-user devices.” – SDK Runtime developer guide

This approach will allow Google to control third-party SDKs, which is not necessarily a bad thing. It will allow Google to combat fraud by taking a closer look at the SDKs at the moment of upload to the SDK upload UI. This, in return, will help prevent malicious SDKs from being installed.

What’s Next?

The positive sign in this is that Google has not yet announced a specific release date for the global release. This indicates that Google’s team will do its best to find a solution that will be both privacy-centric and viable to supply the industry with tools to grow. This gives a lot of hope that Google will take into account the opinions of multiple stakeholders and will continue to improve the product before the wide release. 

The Privacy Sandbox adoption will definitely require the industry—developers, publishers, adtech vendors, and MMPs—to put in a lot of effort to prepare for the release. 

The key available resource that mobile dev teams should look into is The Privacy Sandbox, which covers the proposal and some specs.

Persona.ly’s Take on Privacy Sandbox

Our team is dedicated to user privacy, and we are already looking into Google’s new available APIs to ensure a smooth transition and deliver the best experiences for our clients. This will help them to run efficient programmatic user acquisition and retargeting campaigns.