Why Apple should delay its iOS14 privacy features

EDIT: On September 3rd, 2020, Apple confirmed that the new privacy guidelines coming to iOS14 would be delayed into 2021. More information here.

Last week, after hearing nearly identical accounts from multiple people whose connections and judgment I trust, I posted to Twitter about the rumored possibility that Apple might delay the rollout of its IDFA-related privacy features in iOS14 by six months:

The enthusiastic, thundering response to that Tweet was not something for which I was prepared, given the limited size and specific scope of my Twitter following. Clearly this rumor struck a nerve with mobile advertisers.

What I want to accomplish with this post is to make the case for why Apple should delay the iOS14 privacy features announced at WWDC by six months. What I mean by this is that, for the six months following the release of iOS14 (which is still scheduled for September 15th, 2020, as of this writing), regardless of whether an app has instantiated the requestTrackingAuthorization method to present the ad tracking opt-in dialogue, Apple should:

  • Allow app developers to continue to access the IDFA;
  • Allow app developers to use the SKAdNetwork 2.0 API to generate postbacks that are sent directly from user devices to source ad networks;
  • Allow MMP solutions to continue to access a user’s IDFA for marketing attribution at the point of click and app open;
  • Allow app developers to continue to send IDFA-indexed in-app events to various ad platforms via integrated SDKs.

I believe that in delaying the rollout of the IDFA-related privacy features coming to iOS14, which I’ll broadly define as the limiting of access to the IDFA, Apple will be acting in the long-term best interests of advertisers, consumers, and itself, for the following reasons:

Developers aren’t ready.

Of the roughly 50 app advertisers to whom I have spoken directly since WWDC about the coming privacy changes in iOS14, I’d guess that 10% have a plan in place to transition away from IDFA-based advertising in a way that fully embraces the SKAdNetwork framework for optimized advertising spend. Of the remaining advertisers:

  • 25% are implementing SKAdNetwork conversion values into their apps, but don’t understand how these conversion values can be used to optimize campaign ad spend;
  • 50% understand what SKAdNetwork is and acknowledge that it will form the basis of advertising optimization going forward, but these developers don’t know how to accommodate it and are simply waiting until the dust settles after the launch of iOS14 in order to plan their next steps;
  • 25% don’t understand what SKAdNetwork is and, while broadly aware of the privacy changes coming to iOS14, don’t understand how their advertising campaigns will be impacted by iOS14.

Very few advertisers are prepared to accommodate SKAdNetwork. These advertisers will either reduce spend on iOS or cut it completely upon the launch of iOS14. These advertisers’ revenues will contract as a result.

This is an unfortunate outcome, especially at the onset of Q4, which is traditionally the biggest quarter for digital advertising. Is it in anyone’s best interest — that of developers or of Apple — to reduce ad spend, revenue, and engagement on iOS heading into Christmas?

Ad networks aren’t ready.

I haven’t seen a single announcement about iOS14 preparedness from any ad network apart from Facebook’s. As of this writing, ad networks have exactly two weeks to prepare for iOS14 and to communicate whatever changes they are making to advertisers. My sense is that most ad networks don’t understand yet how they’ll be able to optimize campaigns on behalf of users via SKAdNetwork.

Some of the changes that Facebook is implementing in order to optimize campaign spend on behalf of advertisers are extreme, such as requiring the creation of new ad accounts for iOS14 campaigns and limiting the number of ad campaigns within those accounts to just nine (of the 100 possible campaign IDs). As I state in this summary of Facebook’s announced changes, the campaign limit is probably part of an experimentation / exploitation approach to campaign management that very few other networks have the internal domain expertise to implement in order to achieve efficient campaign spend.

Additionally, considering the scope of changes that Facebook is requiring from advertisers in campaign management, most advertisers can expect similar such procedural changes from all of their other networks. Advertisers simply won’t have the time between today — when only Facebook has publicly published iOS14 transition recommendations — and September 15th to implement all of these changes for all of their ad network partners.

Ad tech platforms aren’t ready.

The mobile advertising ecosystem is built on an already delicate foundation of independent SDKs. Every mobile ad tech provider is currently in the process of updating its SDK for iOS14 compatibility, but few of these SDKs are available to be tested at the moment.

In the coming days, developers will be confronted with a deluge of SDK updates from their ad tech partners. Many of these SDKs will have been hastily developed; it is likely that many of them will cause crashes and / or poor performance when published into app updates, especially when integrated alongside the hastily developed SDKs of other ad tech vendors. Consumers may face the unpleasant experience of their favorite apps crashing or behaving in unintended ways after updating them ahead of the launch of iOS14.

Consumers aren’t ready.

Consumers are used to seeing ads in their favorite free apps that are personalized based on some preference profile. Putting aside the appropriateness of such a preference profile, consumers haven’t been informed of these privacy changes and will be jarred when, after updating to iOS14, they are exposed to wholly irrelevant, seemingly random advertisements.

There is an effective way to educate consumers about the role that ads personalization plays in the modern digital product landscape, and that education process hasn’t yet taken place. I think giving control over ads personalization to users at the level of the individual app is an effective means of empowering users with their own privacy, but explaining the ramifications of losing ads personalization requires a broader effort than the one line of text that developers can control with NSUserTrackingUsageDescription.

What happens when consumers’ favorite apps disappear from the App Store because they are no longer economically viable absent ads personalization?

Six months would make all of the difference.

Giving app developers and advertisers six months to fully digest the privacy changes announced at WWDC — and, more importantly, to build scaleable strategies around them — would likely mean the difference between life and death for many developers. This isn’t an exaggeration: many developers’ revenue is a direct function of ad spend. Some developers may not recover if they are forced to scale ad spend back dramatically, in Q4 no less, because they haven’t been able to devise a strategy for advertising optimization using SKAdNetwork.

I fully accept that SKAdNetwork is the future of efficient advertising spend on iOS: I think SKAdNetwork is elegantly designed and, through systematic, analytical product design, it serves as a privacy-centric mechanism for advertisers to efficiently deploy ad spend for product growth.

But most developers simply aren’t ready to fully utilize SKAdNetwork, at least not in a way that is as performant as their current measurement framework. Providing advertisers with six months to understand and implement SKAdNetwork would allow them to thoughtfully, methodically implement SKAdNetwork into their advertising regimen such that ad efficiency is mostly preserved within the broader context of increased user privacy. The positive impact on advertisers and consumers would be immense.