Alex joined Branch as a Developer Advocate in 2016, and helped build the company's early developer relations and long-tail adoption strategies. He works closely with teams across the organization to help shape Branch's place in the mobile ecosystem, writes the Mobile Growth Newsletter, and tweets regularly about mobile-related topics at @alexdbauer.
Feb 16, 2022
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.
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.
There are four ‘design proposals’ in Privacy Sandbox on Android:
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.
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 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:
Perhaps most importantly, the Attribution Reporting API provides two different types of reporting:
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.
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:
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.
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.
‘Bad’ is a relative term, and there are two extremes of how to look at this:
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.
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.
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.