Google launched its Privacy Sandbox initiative on Chrome to prepare for life after third-party cookies. The Chrome Privacy Sandbox contained proposals to maintain digital advertising features already established on the web supported by third-party cookies.
After rival web browsers Safari and Firefox ditched third-party cookies, Google had their back against the wall. Their competitors framed third-party cookies as a scourge requiring extermination to protect users from unwanted tracking. Google had to plan to end support for third-party cookies in Chrome to stay in the good graces of privacy advocates, users, and regulators.
Now we find ourselves watching a similar story unfold on mobile devices in native environments. Instead of cookies, Google's only rival for mobile operating system dominance, Apple, has effectively removed device identifiers from their iOS operating system.
Once Apple started asking all iOS users in a pop-up dialog if they want an app "to track you across apps and websites," the writing was on the proverbial wall — just like third-party cookies, device IDs needed to go.
Apple, already known for its privacy assurances, pivoted its brand marketing to highlight its renewed focus on privacy. With Apple promising privacy providence with their iOS devices, Android users wondered if a company that derives most of its revenue on advertising (Google) has users' best interests in mind.
Google had no choice but to follow suit and remove device identifiers. So now Google has introduced the Privacy Sandbox on Android, a set of proposals that will nullify the need for device identifiers on Android.
What is a device identifier?
Device IDs, much like cookies, give app developers a unique alphanumeric identifier that they can store to track users to support several core advertising use cases. The Apple device identifier is called IDFA (identifier for advertisers), and the Google device identifier is called GAID (Google Advertising ID) and sometimes AAID (Android Advertising ID).
What can you do with a device identifier?
The charged language Apple uses in its scary pop-up is not entirely wrong. Advertisers can track you using your device identifier. Ad platforms use device identifiers to perform three main functions of advertising:
Audience Targeting
Data brokers can collect your device identifier as you use different apps, package it together with other identifiers and sell those groups of identifiers to advertisers for targeting purposes. Data brokers, DMPs, or advertisers typically group device identifiers by demographics, interests, or behavior like:
- Net worth > $500k
- Auto-purchase-intender
- Politically-left-leaning
For example, if you use a sports app to check scores on Android, that app or even a third-party service embedded in that app can extract your GAID to package it with millions of other GAIDs into a "Sports Enthusiast" audience segment. A data broker could drop this list of GAIDs into a DMP, and that DMP can push the massive list of GAIDs into a DSP as a targetable audience segment.
Whenever a DSP receives an ad request with a matching GAID from an audience segment, they can match that up to targeting applied by an advertiser. Advertisers can target audience segments by paying a set rate based on the number of impressions delivered using that segment (typically somewhere between $0.50 - $2 per thousand impressions).
This exchange of data without the user's knowledge is what Apple wants to prevent by limiting access to the device identifier. Even though all companies involved perform legal gymnastics in the terms and conditions to make everything kosher, this underworld of data sharing happens without the user knowing the true scope of how their identity is bought and sold.
Retargeting
Much like audience targeting, retargeting relies on packaging together groups of identifiers and turning those identifiers into targetable segments. The difference is that the users in these segments are more narrowly defined based on specific actions.
We have all encountered retargeting ads that always seem to pop up at the wrong time. They are those ads around the video you beckoned a coworker to watch on your screen, urging you to come back and buy those Harry Potter robes you always wanted.
When you visit a specific product page in an app, ad platforms can put your device identifier into a targeting segment for that product. When you read a news article on your Android phone, and that news publisher makes an ad request with your GAID, an advertiser can see you are the same Harry Potter nerd who never checked out with the Hufflepuff robes in your cart, and gently remind you to do so, wherever your browse.
Attribution
Device identifiers provide a straightforward method of tracking the effectiveness of digital ads.
When you view or click an ad, an advertiser's ad tech partner logs your device identifier in their database. When you buy a product on a mobile device, an advertiser or their ad tech platform also records your device identifier. Advertisers or their ad tech providers only need to compare these two data sources to attribute which device IDs viewed/clicked an ad and bought a product.
Advertisers can then direct more spend towards ads that deliver a higher number of purchases.
What is in the Android Privacy Sandbox?
So now you know why device identifiers are a critical piece of the current digital advertising ecosystem. Device identifiers provide straightforward and time-tested methods to target audiences and measure attribution.
So how in the holy hell will we survive without them?
The good news is that Google is not as unforgiving as Apple. Google promised that it will not pull the plug on device identifiers for at least two more years — giving time to us plebeians to provide feedback and test the privacy sandbox proposals.
Google will also take less of an IDGAF approach than Apple and try to provide alternatives for each use case device identifiers solved. To be fair, Apple did provide SKAdNetwork, a halfhearted effort to provide attribution tracking without device identifiers. But Google is looking to cover all of the holes left in the wake of the loss of GAID.
Let's quickly review each proposal and how they will supplant each of the core use cases that device identifiers facilitated. We will also explore a new proposal meant to curtail a nefarious form of tracking that even Apple has no answer for yet.
Now grab your shovel and pail because we are diving in the sandbox, friend.
Topics API
Topics API on Android is very similar to the Topics API on Chrome. The proposal allows interest-based audience targeting without tracking, selling, or exchanging device identifiers.
The operating system will store human-readable topics from a predefined list on an Android user's device. Advertising SDKs can then call the Topics API to receive a list of Topics assigned to that user, which advertisers can target.
Like the Chrome version, Google wants to implement rules to ensure that they are not adding any new functionality that device identifiers provided. For example, an advertising SDK can only receive a specific topic back if that SDK is installed in an app assigned to that topic. So if SDK1 is not installed in any sports apps, SDK1 will never see the sports topic.
Otherwise, advertisers would be gaining even more information about users with Topics API by doing less work. They could glean that a user is interested in sports without even having any first-party relationship with the apps that provided the Topics API with that information.
FLEDGE
FLEDGE on Android is also analogous to FLEDGE on Chrome. FLEDGE replaces device identifier-based retargeting.
Advertisers will partner with ad tech platforms to store users into custom audiences on devices based on actions they perform in advertiser apps. So for example, if a user adds items to a cart but never checks out, they may be stored in the didNotCheckOut custom audience for an advertiser by an ad platform SDK.
The custom audience will live in private storage on an Android device. Ad platforms will not store any information about the user on their servers, a stark contrast to how retargeting works today.
When an ad platform registers the didNotCheckOut custom audience on a device, it will also provide other information to conduct retargeting. The ad platform will store a set of advertisements that will possibly display to a user later with optional custom bidding logic.
If the same user in the didNotCheckOut custom audience is browsing a separate app where the advertiser has an SDK installed, that SDK can see that they belong to a custom audience that the SDK created. The ad SDK can then run a contextual ad or check the bidding logic stored with the custom audience to decide whether they want to run one of the previously-stored didNotCheckOut retargeting ads.
The funny thing is that users will probably still perceive these ads as overly-invasive since they will reflect past browsing activity or behavior. Will users ever understand how FLEDGE enhances their privacy relative to old retargeting methods? Probably not. But FLEDGE is a step in the right direction from a privacy standpoint.
Attribution Reporting
Attribution reporting will occur on-device and behave similarly to other privacy-focused reporting proposals like SKADNetwork or Interoperable Private Attribution (IPA). If you read my IPA explainer, you would know that aggregate reporting systems can be complex. I will not explain how Google attribution reporting works in this article, but I will give you some highlights.
Ad platforms will need to register both ad events (views/clicks) and conversion events on-device when they occur. The device will do the job of matching ad events to conversions. Ad platforms can then receive report events as they happen, or request more advanced aggregate reports. Aggregate reports can include things like conversion values or extra reporting dimensions.
The industry seems to be rallying behind aggregated reporting as the privacy-compliant attribution reporting method of choice, and Google is following suit. Snapchat has demonstrated success with aggregated reporting solutions, and Facebook is trying to play catchup with their similar solution.
By offloading the job of matching events on-device, no user information has to wind up in the hands of ad platforms, therefore ensuring user privacy. Google will also introduce other methods of privacy-preservation like time-delays and differential privacy noise — eliminating the ability to match users by time correlation or by gaming the system.
SDK Runtime
Google was not shy about addressing the side-effects that Apple's brute-force eradication of their IDFA caused:
We realize that other platforms have taken a different approach to ads privacy, bluntly restricting existing technologies used by developers and advertisers. We believe that — without first providing a privacy-preserving alternative path — such approaches can be ineffective and lead to worse outcomes for user privacy and developer businesses.
Google referenced a study, performed by a third-party privacy app company founded by ex-Apple engineers, that illustrates how Apple has not been very forthright about the privacy assurances they parrot in their commercials.
Some of the Apple App Store's most popular apps along with their advertising technology partners, appear to be partaking in a practice known as fingerprinting.
These apps call external servers to pass information not necessary for any reasonable advertising business practice. The apps collect information about your battery level, screen brightness, free storage space, and other information that an advertising company would never need for any purpose other than tracking you.
How do they track you with your battery level, you ask? When you combine unique signals like battery level with your IP address, ad platforms can create a very accurate fingerprint to track you wherever you go on a particular device.
Your digital fingerprint is unique to you, just like your physical fingerprint. A digital advertising platform can assign an alphanumeric identifier to your digital fingerprint to use in place of a device identifier.
Fingerprinting is a pernicious tracking method since users have zero control over said tracking. With device identifiers, users can reset their ID at any time. Resetting a device identifier breaks the association between their device and any data stored about them. Users cannot reset their fingerprints.
Google is rightfully calling out Apple because effectively killing IDFA gave ad tech platforms even more reason to fingerprint users. Apple has allowed this behavior to go unchecked even though they position their ecosystem as the most private option.
Google has introduced the SDK Runtime proposal with the Privacy Sandbox on Android to curtail fingerprinting practices in mobile app environments.
The idea is that mobile advertising SDKs will run in a self-contained environment within an app — restricting access to only necessary permissions to conduct advertising functions.
SDKs will then not be able to access superfluous information like battery level, and they can only access reserved portions of memory and storage space. Limiting the signals that an advertising SDK can access will reduce its capability at fingerprinting effectiveness.
In addition to boxing SDKs in a self-contained environment, Google will introduce a new application store review process specifically for ad SDKs.
Separating the review process will remove the need for developers to submit an entirely new app build if an ad platform partner updates their SDK. It will also allow Google to review ad SDKs individually and pay closer attention to any nefarious activity like fingerprinting.
Advertising SDKs can submit updates that will push out to apps that use them as long as they don't contain any breaking changes. App developers could receive SDK updates without pushing an entirely new build to the application store.
Between Android and Chrome, Google has their work cut out for them. In addition to the technical challenges, Google will have to shepherd these proposals across the finish line while wrestling competitive business interests and regulatory concerns.
Google technically does not have any hard external deadlines to meet— but they have self-imposed timelines to get everything done.
Two years should be enough time to completely rewrite a few core functions underpinning an entire digital advertising industry, right?