Just under ten months ago, Google announced plans to remove advertising identifiers from Android mobile devices. With Apple’s App Tracking Transparency policy having already severely limited advertisers’ ability to track and measure mobile campaigns, the news theoretically had the potential to intensify mobile apps’ identity crisis.
Except Google maintained, as has been the case with the removal of third-party cookies from its Chrome web browser, that it wouldn’t do anything drastic before a suitable, more privacy friendly replacement was ready to go. And again as has been the case on Chrome, Google launched its own Privacy Sandbox initiative to develop those solutions.
There’s not been much noise across the industry since then – but these sandbox solutions will be very significant. Apple’s ATT restrictions are believed by many to have contributed significantly to social media apps’ stuttering ad revenues, and its own SKAdNetwork attribution solution has played a significant role in filling the gap left by its absent identifier.
So what’s actually inside the Android sandbox?
For a start, it’s more sparsely populated than its web equivalent. Third party cookies fill a wider range of roles than mobile advertising IDs (MAIDs), so there are less gaps to be filled in the mobile world.
Google breaks these down into three categories: showing relevant content and ads, measuring digital ads, and limiting covert tracking.
Ads personalisation
For this first category, Google is essentially reworking its two sandbox solutions designed for the web, to fit them into the mobile world. These are Topics API and FLEDGE, and both will work similarly to their web counterparts, but not exactly the same.
In simple terms, topics will assign apps to different interest-based categories. Whenever an Android user visits an app, their device will log the associated ‘topic’ (rather than the app itself). Over time, the device will build up a bank of topics which the user is most interested in. Some of these topics will then be made available to advertisers whenever an ad is shown to that user, enabling them to target based on these topics.
Google is working on the Topics taxonomy at the moment – something which could be more difficult to get right in the mobile world, given the prevalence of casual gaming apps which don’t necessarily give much useful context for advertisers.
FLEDGE meanwhile, as on the web, is concerned with retargeting. FLEDGE combines two existing APIs, the Custom Audience API and Ad Selection API, to enable app owners to define and target audiences based on behaviour. For example, an app which has an ecommerce function would be able to use FLEDGE to target users who have placed items in their shopping basket, but not completed the purchase.
To do this, apps place users into custom audience lists, but these lists are stored on the users’ device, limiting the spread of information. Other apps are then able to serve these ads via the Ad Selection API.
Ads measurement and tracking limitations
For measurement, Google has proposed the Attribution Reporting API, which is again a carryover from the web sandbox. It is a parallel of Apple’s own SDKAdNetwork, which similarly is designed to enable advertisers to measure ad conversions.
For Google’s solution, ad tech measurement providers complete an enrolment process with the API. They then register attribution ‘sources’, which may be ad clicks or views, with the API, and ‘triggers’, or any conversions on the app or website.
Google then does the work of actually matching the source to the trigger, though ad tech providers can customise exactly how the attribution works (in terms of how each ad is weighted, how views are valued compared with clicks, etc). Reports are then encrypted and delivered on an aggregated basis, to limit leakage of data on users; behaviour.
For the limiting of covert tracking, Google has created a whole new capability which is specific to the mobile world: SDK Runtime.
In essence, apps frequently run third-party code, but these SDKs can sometimes be used for covert tracking. These SDKs gain the same permissions which users grant their host apps, giving them access to potentially sensitive user data.
To prevent this, Android is adding new capabilities for SDKs to run in their own separate runtime environment. This means they will have their own sets of permissions and access rights. SDK owners will also have to publish their SDKs on Google’s app store, rather than just sending them to app developers. Google will then handle distribution of apps, and any SDKs which they’re dependent on.
Likely a long road ahead
These various initiatives have so far only been seen through ‘developer previews’, which have allowed app developers to play around with these tools in their developmental stages. Six of these have been released throughout the year, with the most recent arriving at the start of November.
Google says it will release these tools for full beta testing “early next year,” though an exact date hasn’t yet been given.
But unlike the web sandbox, Google has not yet published a full timeline for when it expects sandbox solutions to be fully released. And the company pledged not to cut off access to its own MAID before these solutions are ready.
Perhaps to avoid the series of deadline changes it’s made for removal of cookies in Chrome, Google seems to be avoiding committing to a strict timeline, and taking a fairly slow and steady approach. It’s likely therefore that progress on these sandbox solutions will be slow and iterative, with tweaks made over time as developers test and feedback on the various APIs.
