In a developer update last week, Apple disclosed that the new privacy changes announced for iOS14 at this year’s WWDC would be postponed until “early next year.” The disclosure, which confirmed a rumor that began circulating two weeks ago, was welcomed by app developers: while many see the IDFA as something of an anachronism in the modern marketing environment, complying with and adapting to the new privacy protections coming to iOS14 was a more onerous task than most developers could complete by iOS14’s September 15th release date.
So many developers breathed a sigh of relief on Thursday, when Apple granted them a few months’ reprieve on compliance with the new privacy changes. But this respite raises a question: what now?
The IDFA will be deprecated; that isn’t changing. Developers have a few additional months to not only accommodate IDFA deprecation but to fully embrace Apple’s SKAdNetwork framework. The SKAdNetwork framework is the future of measurement on iOS; the primary difficulty in transitioning away from the IDFA is implementing a measurement strategy that provides for marketing efficiency without requiring a persistent, device-centric identifier (although I argue that the persistent, device-centric horse left the barn a while ago). Building out the infrastructure required to integrate with SKAdNetwork is easy; re-orienting all marketing analytics around the data provided through SKAdNetwork is difficult and demanding.
So how should developers make the most of the time that has been granted by Apple to fully incorporate SKAdNetwork into their marketing operations? How can developers avoid simply kicking the compliance can down the road and scrambling at the beginning of 2021 to execute against an impending deadline, as most have been doing since WWDC — despite SKAdNetwork having been introduced in 2018, and industry premonitions as late as the beginning of this year that Apple might deprecate the IDFA at WWDC?
I think developers should focus their attention — starting right now — into three broad strategic activities to prepare for the upcoming privacy restrictions that will be instated at some point in 2021:
- Architect a new, SKAdNetwork-centric advertising tech stack;
- Optimize in-app content for advertising efficiency;
- Prepare for a world in which ads personalization is limited.
Architect a new, SKAdNetwork-centric advertising tech stack
Advertisers will need to understand how their data is aggregated, and from which sources, in the post-IDFA environment. My sense is that many advertisers believe that this function will be fulfilled by MMPs going forward, but one passage from Facebook’s recent iOS14 Advertiser FAQ calls that into question:
My interpretation of this statement is that Facebook doesn’t want MMP SDKs integrated in advertiser apps, and to dissuade advertisers from integrating them, it is only making App Event Optimization (AEO) campaigns available when an advertiser integrates the Facebook SDK for activating the updateConversionValue method in their app.
Many MMPs are now pivoting to data aggregation and analysis services, which map SKAdNetwork conversion values to in-app events and trigger the updateConversionValue method via in-app SDK when those events are observed. This allows developers to simply map in-app events to conversion values and to not have to institute any other in-app logic for firing the updateConversionValue method.
But it appears that Facebook doesn’t want that to happen: it wants its SDK to fire the updateConversionValue method, and it is incentivizing developers to allow for that by only making AEO campaigns available when Facebook manages SKAdNetwork logic. Additionally, upon release of its iOS14 SDK, Facebook is planning to define a list of conversion values that should be used for very specific in-app events, similar to how AEO events are defined now. Facebook currently utilizes 15 “standard events” for the AEO campaign strategy: it remains to be seen how many “standard events” it will require advertisers to map to SKAdNetwork conversion values.
This means that advertisers need to decide whether to include an MMP SDK at all for their iOS traffic — since mapping in-app events to conversion values potentially won’t require dynamic interpretation (as Facebook is defining those mappings) and because Facebook will trigger the updateConversionValue method via its SDK. And if an MMP SDK isn’t included in the app — should the advertiser build its own aggregation tool to connect to each ad network partner and aggregate all SKAdNetwork postback data?
Optimize in-app content for advertising efficiency
In How to scale and optimize marketing spend with SKAdNetwork, I discussed a framework for thinking about conversion value usage in producing actionable, credible insights around potential user monetization and engagement. Going through that process will be critical in scaling advertising campaigns in the post-IDFA environment.
But building those triggers in the app requires specifically engineering “moments” that produce predictive power. It’s not enough to exhaustively instrument the existing user experience with very many events that can be used to gauge monetization or engagement potential; that approach utilizes the “measure everything” paradigm that is dying with the IDFA. Now, developers should aim to curate experiences that are predictive themselves.
Expounding upon this idea: the current event-optimized advertising paradigm allows advertisers to outsource all personalization to ad platforms by sending them every in-app event that is triggered by a user. The platforms collect this data, build very specific segments out of the users that trigger different events (especially purchases) using shared characteristics, and then find other users that fit those profiles and target them with ads. In the process of doing that, advertising is optimized because ad creative variants are tested at the level of the sub-groups, meaning each different segment is seeing the ad creative to which it is most likely to respond:
In the new, post-IDFA paradigm, ad platforms will be unable to build specific segments of users that are likely to engage or monetize based on shared characteristics at the individual level because, with the event stream broken, the ad platforms won’t know which users actually monetize or engage. Ad platforms will only know which campaigns produced conversion values, and those campaigns will be targeted broadly based on demographic and platform features (eg. US iPhone). This means that segmentation will no longer take place at the advertising layer, and so advertisers will need to do it at the content layer:
Put another way: since advertisers will no longer receive vetted, qualified traffic based on the ad platforms’ abilities to segment users, the advertisers will have to do that segmentation themselves within the app based on early behavioral signals. An advertiser will need to observe a user’s first few interactions with in-app content and come up with an estimate of their future “value” (either in terms of engagement or monetization) to the app. Even better than that: specifically designing experiences in the app that allow those estimates to be made with even more predictive power.
This is deep product work, but it leans into the SKAdNetwork framework by producing conversion values that deliver powerful insight into the performance of ad campaigns. One of the themes I have repeatedly emphasized over the past two years as event-optimized ad campaigns rose to prominence is that of the tail wagging the dog in terms of advertising events informing (or dictating) product design, especially the early product experience. Ironically, with the event stream dying along with the IDFA, this dynamic becomes even more important because advertising networks only receive one feedback event via the SKAdNetwork postback. All possible signal around user value must be captured with that one conversion value.
Prepare for a world in which ads personalization is limited
This is a mostly philosophical exercise. Developers should expect that their ability to reach highly targeted audiences for their mobile products will be extremely curtailed going forward (on Android as well as iOS). Acknowledging this likely means answering the following question:
What products should I build if I know I can’t reach a very specific audience with targeted advertising?
What Facebook, Google, and some other ad networks became very good at over the past few years was routing users to the apps that could monetize them to the greatest possible extent via ads. That ability is being diminished with the deprecation of the IDFA. Users will be exposed to ads that are less laser-targeted to them on the basis of their monetization potential, and they’ll likely also revert to more organic discovery. What kind of apps thrive in that environment? What kind of apps die?
I discuss this idea in How iOS14 might change consumer behavior on mobile: when ads are less targeted, apps need to be more broadly appealing. It’s probably not possible, post-IDFA, to build a very successful business that thrives with tens or low-hundreds of thousands of DAU that all monetize very heavily: reaching the specific audiences that respond to niche products won’t be as efficient. App developers should consider how these changes are going to impact the viability of their product catalogue. In the aforementioned article, I talked about a “move to the middle” for gaming, but all app categories will be affected.
“Early next year”
Apple didn’t provide much guidance around timing in its announcement of the privacy delay. What if “early next year” means January? That would give developers just three months to achieve the above. Although Apple’s announcement was universally received with great enthusiasm across the mobile landscape, it’d be unwise for any advertiser to appreciably relax the intensity with which they were progressing towards iOS14 compatibility. Apple isn’t likely to have much sympathy for unpreparedness next year.
Recent