Earlier today, Google announced Privacy Sandbox on Android. This is the much-anticipated counterpart to Apple’s iOS 14 privacy changes (AppTrackingTransparency and SKAdNetwork), but there are a number of things about Privacy Sandbox that will hopefully make this situation different from the IDFA Apocalypse of 2020.
In this blog post, I’m going to recap what Privacy Sandbox is, share some early thoughts on what it means for mobile linking and measurement, and give you a preview of what to expect over the next few months.
What is Privacy Sandbox on Android?
Google first introduced Privacy Sandbox several years ago. This original version focused on Chrome, with the intention of developing replacements for third-party cookies on the web, and is what gave us proposals like FLoC (recently revised into Topics).
Privacy Sandbox on Android is an expansion of that original initiative to also cover native Android apps. Now, it’s no longer just about third-party cookies — the Google Advertising ID (GAID) is also in scope, and this starts to look a lot like the privacy updates Apple introduced with iOS 14.
Google is eager to note that none of these changes are coming imminently: the current techniques (including GAID access) won’t change for at least the next two years, and beta releases of the new technologies aren’t expected until late in 2022. There’s no need for immediate concern, and we’ll all have plenty of time to prepare.
Screenshot from Privacy Sandbox on Android website, February 16, 2022
There are four ‘design proposals’ in Privacy Sandbox on Android:
- SDK Runtime. This is a new framework designed to provide a safer way for apps to integrate with third-party SDKs.
- Attribution Reporting. This is an API for measurement of ad performance without the need for user-level identifiers (like the GAID).
- Topics. This facilitates interest-based ads personalization, also without relying on user-level identifiers.
- FLEDGE. This makes it possible to show customized ads to users based on their prior app activity, without needing to share data with third parties.
The latter two proposals deal primarily with ad targeting, so I won’t go into them in depth with this post — if you’re interested, you can find a great rundown of the details here.
SDK Runtime
The SDK Runtime is the only component of Privacy Sandbox on Android that doesn’t have a parallel in the web version of Privacy Sandbox. It’s an ingenious solution that will effectively isolate the execution of SDK code from the rest of the app.
On iOS, one of the challenges Apple has had with enforcement of the AppTrackingTransparency policy is finding a way to prevent bad actors from collecting too much data. So far, the only option for this has been policy enforcement. But by isolating the SDK code from the app itself, Google will be able to sidestep those challenges with a technical solution that makes it impossible for an SDK to collect data it shouldn’t need.
There are also other benefits to this approach: a big one is that SDKs can be distributed and updated separately from the app itself. This will make it possible for vendors to roll out minor updates (bug fixes, security patches, etc.) without requiring developers to issue a new version of the app each time.
Look for a deep-dive blog post on this proposal in the coming weeks.
Attribution Reporting API
Attribution Reporting is Google’s solution for private, aggregate-level ad attribution. This API also exists in the web version of Privacy Sandbox, but for apps, you can think of it as basically equivalent to SKAdNetwork…except with a lot more functionality.
We’ll also have a deep-dive blog post on this proposal soon, but here are a few of the highlights:
- Does not require deterministic, user-level identifiers like GAID.
- Allows configurable attribution window length (anywhere from 2-30 days).
- Can be configured to support either true last-touch attribution or install-touch attribution.
- Supports all combinations of cross-platform user conversion paths (app-to-app, but also web-to-app, app-to-web, and web-to-web).
- Allows reporting on additional in-app events that happen after the install. This reporting has limits (1-2 additional events in the current proposal, depending on ad touch type) so there is still going to be an adjustment from what is possible today with GAID-based attribution, but it’s a significant improvement on SKAdNetwork.
- Supports re-engagement attribution. This means it’s possible to measure conversions (like registrations or purchases) from ads that are shown to users who already have the app installed. The lack of re-engagement support has been a major pain point with SKAdNetwork.
- Allows custom segmentation dimensions for aggregated reports. This will make it possible to report on things like geographic regions and campaign creatives, which has also been a major challenge with SKAdNetwork.
- Allows multiple ad tech platforms to register to receive data. This means no need to build additional complicated infrastructure to forward data around behind the scenes, as was necessary for SKAdNetwork.
Perhaps most importantly, the Attribution Reporting API provides two different types of reporting:
- Aggregate-level reports. These give richer, higher-fidelity data, but only in aggregate format. This is equivalent to SKAdNetwork reporting with more detail.
- Event-level reports. These make it possible to associate conversion events back to specific ad touchpoints, though with only a limited amount of detail. Event-level reports won’t be a replacement for the log-level data that is currently available via GAID-based attribution, but will provide important, granular input for purposes like training ML models.
There are obviously still some gaps in the proposal. For example, there doesn’t currently appear to be support for anything that would enable multi-touch attribution, but the documentation contains a note about potential exploration of more advanced attribution models. Perhaps this will be added in the coming months.
Other top questions
Was this expected? Yes. Most observers agreed that Google would eventually make changes to match Apple’s iOS 14 privacy updates. Google is clearly aware of how their moves impact the broader mobile ecosystem, and they obviously intend Privacy Sandbox to be seen as a contrast to the ivory-towerish strategy Apple took with ATT.
Is GAID really going away? Google hasn’t specifically addressed this…and it’s possible they haven’t made a final decision yet. However, it’s clear that things will be significantly different two years from now.
Will there be an ‘ATT prompt for Android’? Google also hasn’t specifically addressed this. We can assume that if these design proposals are successful, there won’t need to be universal, user-level identifiers (like GAID) for attribution on Android in future, which could make a platform-level permission prompt like ATT unnecessary.
Is it truly good for user privacy? Yes. Once rolled out, these changes will significantly improve privacy for Android users. Universal platform identifiers (like GAID, IDFA, and third-party cookies) are very useful for many legitimate purposes, but they also form a significant tracking vector. The issue is that brute-force removal of those techniques can simply push the behavior underground, into a sort of ‘tracking black market’, which is what we’re currently seeing on iOS. However, I’m hopeful that Google’s proposals are substantial enough that this will not happen on Android.
Will this actually DO anything? Isn’t Privacy Sandbox still basically ‘stuck in committee’? The web version of Privacy Sandbox seems to be progressing fairly slowly (in part, due to attention from the UK’s antitrust authorities), but there are some reasons to think things could move faster on Android: for one, Google has already run this playbook for the last three years on the web, so they’re not starting from zero on Android. Also, while Chrome is the biggest browser globally, it has real competition and the web is built on shared standards. In contrast, the Play Store absolutely dominates Android app distribution in most of the world, so it will likely be much easier for Google to make a change happen.
How does this map into other upcoming Android privacy changes? In Android 12, Google has already been making several other privacy-related changes:
- Removing access to the GAID when users opt out of ads personalization. This is basically equivalent to Limit Ad Tracking, as introduced on iOS years prior to ATT.
- Requiring a new permission to access GAIDs at all, even for users that did not opt out. This is purely a technical implementation change for developers, and has no other impact.
- Adding a Data Security section to the Play Store. These are essentially ‘privacy nutrition labels’ to give users more visibility into what data an app is collecting and how it will be used.
Like Privacy Sandbox, these other changes were announced with plenty of lead time over the past year, but are all more tactical, catch-up developments. Privacy Sandbox is much bigger in scope, which likely explains Google’s major focus on community collaboration and collecting feedback.
What does this mean for you?
The good news is you can relax for a while. Even if you wanted to, right now there’s pretty much nothing you can do other than reading the documentation: these proposals won’t be available for testing until later in 2022.
Looking forward a few years, the obvious questions are around what this will mean for measurement and linking on Android, so let’s look at these two separately.
Will Privacy Sandbox be ‘bad’ for ad attribution?
‘Bad’ is a relative term, and there are two extremes of how to look at this:
- One extreme is ‘the good old days’ of unfettered access to attribution via universal platform IDs like GAID. Compared to that, you could objectively say this future is ‘worse’. Data will be more limited, and getting it will be complicated than before.
- The other extreme is the complete removal of existing attribution methodologies without replacement. Compared to that, what Google announced today is like Christmas in February. Yes, it’s still early, but I’m optimistic that these solutions will allow mobile advertisers to continue measuring the performance of their campaigns in a way that allows them to run their businesses, without risks to user privacy.
However, there is another, more important way to think about these changes: if the last two years have taught us anything, it is that most mobile users now view their privacy as a very legitimate concern. This means that in tech, protecting privacy is now equivalent in stature to guarding against security breaches: yes, building with privacy in mind often requires more work and might seem ‘harder’, but it’s a non-negotiable requirement.
Privacy concerns are not something that will go away, and finding ways to balance these needs with responsible attribution is the key to the future. Apple may have made the first really big move with iOS 14 — and their move arguably accelerated the timeline for everyone else — but the landscape has been shifting for years.
Will Privacy Sandbox impact linking and owned/organic channels?
At this point, there is no indication that this will have an impact on linking (including deep linking), or measurement of owned and organic channels. In fact, some changes (like the auto-update functionality coming with SDK Runtime) could be quite helpful for allowing Branch to catch and solve new edge cases even more quickly, and with less work from you.
What happens next?
So far, the reaction to Privacy Sandbox on Android in the mobile industry has been almost surprisingly quiet, especially after the chaos of iOS 14. It’s possible this reflects general exhaustion with the pace of recent ecosystem changes, or it could simply be the priced-in expectation that something like this was inevitably coming for Android.
At Branch, we’ve already got multiple teams digging into all of the new design proposals in Privacy Sandbox, and we’ll be working closely with Google to incorporate them into our platform. Thanks to the collaborative communication and extended rollout timeline from Google, we’re not expecting any major disruptions, and we look forward to sharing more information in the coming weeks.
Branch provides the industry’s leading mobile linking and measurement platforms, offering solutions that unify user experience and attribution across devices and channels. Branch has been selected by over 100,000 apps since 2014 including Adobe, BuzzFeed, Yelp, and many more, improving experiences for more than 3 billion monthly users across the globe. Learn more about Branch or contact sales today.