Consensus opinion within the mobile advertising ecosystem suggests that Google will follow Apple’s lead with IDFA deprecation and deprecate its own proprietary, device-level advertising identifier, the GAID. Google has mostly stayed in lockstep with Apple regarding privacy:
- Google added its “Ads Personalization” setting to Android approximately one year after Apple introduced Limit Ad Tracking in 2016;
- Earlier this year, Google announced that it would phase third-party cookies out of its Chrome browser over the course of two years, three years after Apple introduced Intelligent Tracking Prevention (ITP) for Safari, although Safari only fully blocked third-party cookies via ITP in March of this year.
Assuming that Google does emulate Apple’s strategy with respect to device identifiers, it’s interesting to consider whether Google’s platform policy change will differ substantively from Apple’s. In How might IDFA deprecation have minimal impact?, I consider whether Google might institute privacy controls that don’t mechanically mirror those announced by Apple at WWDC. If Google implements privacy controls that are functionally different from Apple’s, what might they look like?
Before attempting to answer that question, it’s first important to consider two other aspects of the situation:
- Why does Google have to take any action? The short answer: because it historically has taken direction from Apple on privacy (or, at least, it has tried to match its initiatives), and because Google is almost certainly facing an imminent anti-trust lawsuit from the US Justice Department focusing on the company’s Search and Advertising businesses. The optics of falling behind Apple on privacy controls would be troublesome for Google;
- Why might Google not simply institute the exact same privacy control mechanics as Apple has? Google is, first and foremost, an advertising company. It has to preserve the efficacy of its advertising engine, and the implications on its other businesses are problematic if it completely deprecates the GAID. Note that Google granted itself a two-year timeline for eliminating third-party cookies in Chrome: taking a softer approach than Apple on privacy-related issues is not unprecedented for Google.
So what might GAID deprecation look like on Android? I think a good place to start in contemplating that is Firebase, Google’s mobile analytics suite. Firebase natively offers ad campaign attribution, although the adoption of that functionality has been relatively limited given the inherent conflict in having an ad platform manage measurement for an advertiser. But nonetheless, that functionality exists: it seems like an excellent foundation on which to build privacy controls in a form that mirrors Apple’s SKAdNetwork framework but retains more information. Google could implement privacy controls by preventing any SDK except Firebase from accessing the GAID and forcing developers to use Firebase as a measurement solution.
As a platform-owned measurement solution that sits on the device via SDK, Firebase could send GAID-indexed event streams to ad networks while only making aggregated campaign-level data available to advertisers via API. This would allow ad networks to continue to optimize campaigns based on user-level event streams while withholding the GAID from advertisers and publishers and preventing campaign-level attribution.
Firebase can access the GAID even if it isn’t available to the advertiser or the advertising app given that Firebase is owned by Google and its SDK sits on the device. Firebase could capture the GAID from the publisher’s app and the advertiser’s app, manage attribution exactly as it does now, and transmit GAID-indexed events to source ad networks while withholding the GAID from both the publisher and the advertiser — and from other SDKs installed in both apps.
The GAID-indexed postback sent to ad networks, containing event identifiers and event values, might look like the below:
What’s interesting about this approach is that no real information is lost, and the data relationship remains specifically between Firebase and the ad network. For advertisers, event-level data isn’t needed if the advertising network is capturing it: the ad network knows how much revenue is generated per user, and it can aggregate that revenue data at the campaign level in reporting to allow the advertiser to calculate campaign-level ROAS. Yet the ad network has access to the full device-indexed events stream and can continue to build device-level behavioral profiles for targeting purposes.
And this approach solves an important problem with Apple’s privacy controls that is particularly acute for Google: that of view-through attribution, which is impossible with Apple’s SKAdNetwork. Ad impressions are able to be linked to specific GAIDs via the Firebase SDK on the publisher’s app in this framework: the publisher itself won’t see GAIDs because that access is restricted, but Firebase will, and so it will be able to attribute views on the advertiser’s app via the Firebase SDK integrated there.
The lack of view-through attribution in the new privacy paradigm on iOS is painful for Google. I understand that a very large proportion of the conversions that Google’s UAC attributes are for ad views (absent clicks) on YouTube; without view-through attribution, Google is unable to monetize much of its most valuable inventory. In the above configuration, Google the publisher (YouTube) would lose access to the GAID, and the advertiser would lose access to the GAID, but Google the measurement platform (Firebase) wouldn’t, and so view-through attribution would still be feasible for Google the ad network. And Google the ad network would retain the GAID-indexed events stream — provided by Google the measurement platform — allowing it to continue to aggregate monetization data for users for the purpose of optimizing ad campaigns, even if advertisers have no direct access to that data.
The above framework is slightly convoluted, and Google could likely find a more elegant way to institute additional privacy controls. But this framework accomplishes:
- Removing intermediaries from the advertising process. Firebase would replace MMPs for attribution, and data custody would be reduced to just Firebase (Google the measurement platform) and ad networks;
- Withholding GAIDs from advertisers. Advertisers would no longer be able to “track” users on the basis of their GAIDs — for instance, with re-targeting campaigns or through programmatic advertising targeting. Of course, ad networks would retain access to the GAID and would continue to be able to aggregate user events;
- Continuing to optimize ad campaigns for advertisers. None of the complicated logic present in SKAdNetwork is needed here (eg. the timer system, limited conversion values) because Firebase handles all attribution and event triggering, and the ad network receives all events. If SKAdNetwork is perfectly designed to harm ad networks, then this framework is perfectly designed to preserve the efficiency of ad delivery and targeting without allowing the advertiser to build user profiles;
- Streamlined, consolidated reporting. As the nexus of ad campaigns, Firebase could make all campaign-level data, across all traffic sources, available to the developer via an API. This would eliminate the need for advertisers to ingest campaign performance data from a number of different sources.
Note that I think the above solution (or something similar to it, with Firebase sitting between advertisers and publishers and managing measurement) is what Google is likely to pursue out of self preservation. But I don’t think it’s the best solution for the mobile ecosystem: I have called device-specific advertising identifiers the hydrocarbon of mobile advertising, and I think the industry at large should move past them in a way that fundamentally preserves user privacy and inspires trust while facilitating effective advertising.