Chrome has dominated the third-party cookie story since Google declared its deprecation intentions
Following an official halt to default blocking, advertising attention is now fixed on the new choice-centric browser experience and how web-based Privacy Sandbox adoption will pan out. However, changes set to be just as impactful for mobile are forging ahead unchanged and largely unnoticed.
A Privacy Sandbox initiative for Android has been in the works since 2022. While there is no defined timeline, tools moving into beta last year suggest development is advancing, but many industry players are yet to explore these technologies and their potential wide-ranging impact.
Given Android’s 70% share of the global mobile market, failing to understand and proactively prepare for these proposals is a major oversight that could create sizable challenges for app publishers and advertisers.
Not all sandboxes are the same
Firstly, it’s vital to recognise that the web and Android Privacy Sandbox initiatives are separate entities. Both share the mission to protect user privacy and allow businesses to maintain a thriving digital media ecosystem. While these branches share a unified vision and core components, they don’t work in the same way. This is largely due to the focus on usually cloud-centric activity for Chrome Sandbox solutions, while Android tools are designed for app software that users download and engage with via their devices.
Looking closer at the details, there are several key variations across the five main Android APIs — Topics, Protected Audience, Protected App Signals, Attribution Reporting, and SDK Runtime.
Cohorts in, IDs out
The familiar Topics API concept involves collecting on-device data to determine which topics users are interested in and putting them in cohorts that can be applied for targeting, such as ‘fitness lovers’ and ‘sci-fi fans’.
High on the list of pros for this tool is its capacity to seamlessly slot in with current trading. Topics categories can be added as another signal sent to demand-side platforms (DSPs) along existing programmatic pipes, allowing buyers to place real-time bids on app inventory that will reach relevant audiences, even if they don’t know who exactly will see their ads.
Zero reliance on identifiers is also a big plus given their diminishing scope. Google maintains an emphasis on providing options that can work without IDs, because doing so has become increasingly crucial. In the immediate aftermath of Apple’s decision to make its iOS ad ID opt-in only, many users seized the opportunity to improve their mobile privacy, with consent rates teetering at 25% at that time.
Opening the box of APIs
The Privacy-Preserving APIs provide another suite of solutions that is distinct from Topics but also intended to support ID-less operations. Within this collection are multiple building blocks designed to support use cases throughout the ad lifecycle, the main elements being Protected Audience, Protected App Signals and Attribution Reporting.
Protected Auction has two strains: Custom Audience for user segmentation in a re-marketing use case and Protected App Signals for app install (aka user acquisition) use cases without the reliance on cross-app identifiers. Crafting custom audiences is about creating groups based on interests or intentions, such as users who have abandoned an e-commerce app purchase over the last month. Local data storage that can’t be transferred between apps helps to maintain user privacy here.
Ad Selection in a protected auction follows a structure for managing bidding activity that upends standard programmatic procedure. Normally, app publishers send audience data with bid requests, allowing demand-side vendors to produce profiles that are used for refined bidding according to key advertiser targeting preferences. Protected auctions turn the tables and means that buyers have to bring their requirements and data. This is then used in an auction inside a trusted execution environment and the only information that leaves the auction room is who has won.
Safe in the knowledge that data won’t leave the auction and users cannot be identified in the absence of cross-app identifiers, participants could work with more device-level data to boost ad relevance and impact, as long as there are robust enough provisions to prevent data leakage. In effect, auction spaces could follow the principles of data clean rooms.
Finally, Attribution Reporting functions like Apple’s SKAdNetwork (now App AdAttributionKit). Ad tech vendors register attribution sources (such as clicks and ad views) and triggers (in-app conversions), and the API links the two together through event-level and aggregated summary reports. Measurement is subject to several limitations to ensure advertisers can see a clear line from campaigns to conversion actions, but not individual users.
The great unbundling
SDKs aren’t just a bridge from platforms to apps. Deep integration practices have historically weaved them so tightly into the fabric of apps that it’s difficult to tell where the dividing lines lie. This close connection has facilitated smooth interaction with external tools and services, such as monetisation SDKs that enable publishers to fuel crucial revenue with ads and mobile measurement partners (MMP). Yet the same free flow also allows SDKs to inherit privileges and data permissions, which raises concerns about privacy and the risk of unpermitted data collection.
Google hopes to tackle this with its enclosed SDK Runtime environment. By providing an isolation process that can run strains of code independently, the solution will unbundle third-party SDKs from apps. Additionally, there are further plans to cap the data SDKs can access, with initial designs suggesting a default list of four elements: internet connectivity, network information, phone state (such as network type), Google’s Privacy-Preserving APIs, and an ad ID — but only if users have granted the host app consent. These proposals have sparked anxiety about the challenges of complying with differing data requirements, especially for omni-channel campaigns. The reality is that SDK Runtime will likely mean less convolution. Just as Google can issue operating system updates to devices without disrupting apps, third-party vendors will be able to build new SDK iterations and fixes that publishers can implement without having to invest considerable time and resources in re-distributing their apps.
Why should the industry care?
It’s hard to predict precisely how Android tools will evolve or impact the industry. However, we can be sure of the need to enhance data protection. Despite a growing array of global regulations and robust ad tech policies, one fundamental issue is as thorny as ever: once data is shared, control over it tends to be lost. Google’s vision of minimising how much data is shared at every stage of ad management has the potential to address that problem and foster a better media marketplace — if all players get on board.
Those involved in testing will have a chance to feedback on and steer Android Privacy Sandbox innovation. Concurrently, they can use exclusive insight into the direction of development to get ahead of competitors by creating solutions that are ready for the privacy-first present and future.
Featured image: Denny Müller / Unsplash
