On February 16, Google announced a multi-year initiative to build the Privacy Sandbox on Android. Their goal is to introduce new and more privacy-first advertising solutions. As many in the industry pointed out, this is likely the first step on Google’s winding road to eventually deprecating Google Advertising ID (GAID). (GAID is the company’s device identifier equivalent of Apple’s now-deprecated Identifier for Advertisers, or IDFA.) This can impact both publishers and marketers in many ways, and it’s time for everyone in the advertising ecosystem to prepare for an inevitable world without cookies and identifiers. So, what do publishers need to know about this pivotal move? Let’s take a deeper look.
Is Google getting rid of GAID?
For now, the fate of Google’s device ID is up in the air. The company hasn’t explicitly announced plans to deprecate GAID. But this move is — and has been — implied. That said, there’s time. Google will support GAIDs for at least two years while the company works out alternatives. And, given that the GAID deprecation is still only being implied, it’s possible Google may extend this timeline quite a bit. (We’ve seen with other Google privacy-focused shifts.) That said, there are hints that Google will be looking to replace GAID entirely. This marks a difference in approach from Apple, which permits users to opt-in to IDFA.
Why is Google making this move now?
Google hasn’t given a reason as to the timing of its decision to build the Privacy Sandbox on Android. As we all know, the drive toward privacy-centric solutions is hot right now. Google’s pivots in this regard have a history of taking time to develop, vet, and roll out.
Why, and how, is this different from Apple’s AppTrackingTransparency (ATT) framework?
Google is giving the industry more time to adapt to its changes on Android, compared to the rollout of Apple’s ATT framework. They’ve suggested at least two years. Also, Google is seeking a collaborative solution. They’re looking for refinement and input from the industry. In contrast, Apple presented its ATT framework to the industry as a decided, immediate action.
Of course, there are still some unknowns. Will Google implement mechanisms to restrict and regulate its own insight into and use of personal device identification? Or, will this shift yield a massive competitive advantage for Google? The company is, after all, a massive advertising network in and of itself.
What does Google’s move mean for publishers?
In terms of volume, Android runs on a lot more devices than iOS. As a result, the impact of Google’s changes could be even larger than the impact seen when Apple deprecated IDFA. That’s why it’s important for publishers to stay up to date on the Android developer blog and raise their voices with any concerns now, while Google is still in testing and development phases.
What does it mean for gaming and performance publishers running user acquisition campaigns specifically?
Without a doubt, performance advertising will experience new challenges whenever Google’s device identifier is deprecated. As such, performance advertisers and publishers running their campaigns are going to need to get more comfortable with aggregation models.
Moving forward, publishers will need to get acquainted with the attribution API that Google will introduce. Likewise, keep in mind that first-party data is still supported, and publishers can and should make use of that unmet potential. Google still supports the publisher-provided identifier (PPID), a hashed and encrypted ID that a publisher assigns to a (logged in) user and passes on to Google. PPIDs can provide a valid solution for cross-screen frequency capping, audience segmentation and targeting, and sequential ad rotation. Of course, if a user opts out (e.g., on GDPR basis) then the PPID becomes useless again.
With new industry solutions such as IAB Project Rearc’s recently announced seller-defined audiences, publisher first-party data is gaining weight. First party data is gradually becoming available for the broader (programmatic) ad ecosystem.
What else do publishers need to be watching on the Google front?
Google’s move to build the Privacy Sandbox on Android is only one of a number of ongoing initiatives that publishers need to be keeping an eye on. Here are some of the other moves to be watching, in conjunction with the eventual deprecation of GAID.
Topics instead of FLoC:
Google recently announced that it would be pivoting away from its Federated Learning of Cohorts (FLoC) plan to instead focus on Topics API. Major browsers and prominent global publishers met FLoC with resistance, rightfully noting that cohorts were still prone to fingerprinting and contained sensitive data such as health and religion. Conversely, Topics uses on-device data derived from engagement with various apps, which have been classified as belonging to different topics, to target ads in a way that is not entirely based on context. Google indicates that users will be able to control the association of their app usage with Topics. Additionally, its taxonomy of Topics is human-curated. This allows for exclusion of sensitive topics, such as health and religion, from use.
Mobile version for FLEDGE
The purpose of FLEDGE is mainly created for retargeting. It allows the creation of custom audiences depending on the way they previously interacted with an advertiser’s app. These audiences are then stored on the device. Auctions will then be managed entirely on-device, absent any transfer of data to a constellation of ad tech vendors. Google indicates that users will have control over the custom audiences to which they belong, and which apps can group them into audiences.
Attribution reporting:
Google’s attribution reporting is a sort of spiritual equivalent to Apple’s SKAdNetwork, but for Android. It provides coarse, noised, non-user-identifiable conversion accounting to ad click and view events. Unlike SKAdNetwork, however, it does this via two different reports: event-specific and aggregated. Google’s attribution reporting covers two more use cases that ATT has not initially considered: web-to-app conversion measurement and reengagement campaigns that target known users or customers.
SDK Runtime:
This feature is unique to the Android Sandbox and has to do with defining permissions by app, while not interfering with other apps or the OS. The first iteration of the SDK Runtime feature primarily focuses on “advertising-related SDKs” that “enable ad serving, ads measurement, ads fraud, and abuse detection.”
This is a very beneficial feature for publishers. Through the separation of runtimes, there is an opportunity for SDKs to be distributed independently of the apps that use them. Therefore, SDKs will no longer need to be integrated as packages into their host apps. SDK developers and providers will be able to upload their SDKs to app stores, independently from any app that might integrate them. Apps that use those SDKs could then simply indicate SDK dependencies, with the relevant SDKs being downloaded along with the app at the point of user installation.
SDK Runtime beta’s release could be tied to the Android 13 release (expected for late summer, early fall of this year). Publishers should be prepared to get in on the testing phase.
How can publishers get involved?
It’s an important time for publishers to keep pace with Google updates. You can read up on proposals on the Android Dev page here and sign up for Google’s updates on the Privacy Sandbox here.
Of course, we’re also here to help. If you have questions about how to ensure compliance with ever-shifting privacy laws, check out our most recent trend report. In this report, we dive into the privacy topic in depth. Or, get in touch with us here.
A version of this post originally appeared on Verve Group’s website. Verve Group and Smaato are both subsidiaries of Media & Games Invest (MGI).
