Tremors from Apple’s bombshell revelation at WWDC last week that the IDFA will effectively be killed continue to reverberate. iOS 14 will be released in September, and if past iOS releases are any indication, more than half of all iOS devices will run iOS 14 by October. WWDC 2020 featured Apple’s Thanos moment: with a snap of its fingers, Apple obliterated a large proportion of the mobile ad tech ecosystem.

A brief overview of the IDFA-related changes that will be introduced in iOS 14:

Device IDFAs will be made available to specific apps on the basis of user opt-in via a pop-up at app open. LAT as a setting will continue to exist at the device level, meaning no apps will have access to the device IDFA if LAT is turned on;
Apple will use the SKAdNetwork API to receive meta data from ad clicks and to send postbacks from the app client to advertising networks that drive app installs. As of iOS 14, new parameters will be added to SKAdNetwork that provide information around the source publisher, and a conversion event;
The postbacks to ad networks can include ad campaign IDs, but only 100 values (labels 1-100) per ad network are available to be mapped;
The postbacks to ad networks can also include up to 64 conversion event IDs via a 6-bit conversion value;
The postbacks to ad networks will also include a “Redownloaded” flag that indicates whether the app is being downloaded by a user for the first time or not;
Postbacks will be sent based on a sequence of timers (the logic is somewhat complicated — more information on this below) and will include just one conversion event per attributed install. This means that advertisers won’t get absolute counts of events but rather counts of highest value events that users complete within the conversion measurement period;
IDFV, or ID For Vendors, will continue to be made available for publishers per device for all of their apps. What this means is that a publisher will have a unique device identifier available to it across its apps on any given single device. That is, if a user has installed three of my apps on her iPhone, I will have access to a unique IDFV for that user that is the same as accessed from all three of my apps.

In Apocalypse Soon, which I published in February, I outlined a hypothetical chain of events that began with Apple deprecating the IDFA at WWDC 2020. The IDFA has been living on borrowed time since the introduction of Limit Ad Tracking; its elimination was wholly foreseeable. I posted my thoughts on how the death of the IDFA will impact the mobile advertising ecosystem in this Twitter thread, which still represents my latest understanding. Below is more detail on the topics covered in the thread, as well as a few additional topics.

Lots of FUD being dispensed regarding IDFA deprecation. Here's what I think changes in the post-IDFA world: (1/X) pic.twitter.com/q2EXpJj7w5
— Eric Seufert (@eric_seufert) June 25, 2020

Opt-in rates for IDFA access

My belief is that user opt in rates for IDFA access will fall between 10-20%. Opt in rates will dictate the impact of these privacy changes on all aspects of the mobile advertising ecosystem, but with opt-in rates at the 10-20% level, the IDFA is effectively dead.

In an informal poll conducted in the Mobile Dev Memo Slack team, the majority of respondents indicated that they believe opt in rates for ad tracking will fall between 0-20% (see below). The language presented within the opt-in popup is intimidating: App X would like permission to track you across apps and websites owned by other companies (note that a second string of text underneath this one can be customized by the developer). This verbiage seems specifically designed by Apple to deter users from accepting tracking.

Attribution

I believe that deterministic, user-level app attribution will cease to exist once SKAdNetwork adoption reaches critical mass — likely by the end of the year or throughout Q1 2021.

I’ve heard the argument that some advertisers might continue to use MMPs to attribute the small (10-20%) subset of users that opt into ad tracking, because that sample of users could be used to extrapolate composition ratios to the broader set of acquired installs. For instance, if 30% of the opt-in users were acquired via Facebook ads, then that ratio might be applied to the cohorts of opt-out users whose provenance is unknowable — this knowledge could help advertisers budget ad spend, and would justify MMP tracking for the opt-in users.

But there is sampling bias inherent in this: the group of users that opt into tracking are unlikely to behave like those that don’t. We see this now with LAT users: LAT users for many advertisers tend to monetize better than non-LAT users, with the hypothesis being that they are more technically savvy (because they managed to find the LAT setting).

And even if the opt-in subset of users was useful for the purpose of extrapolating ratios, this small volume of attributions would not support the MMP industry at the scale that it currently exists: either dramatic consolidation would take place or a few of the major firms would simply fail as MMP budgets evaporate to 10-20% of their current level.

Another factor that will determine the fate of user-level ad attribution is Google’s adoption of opt-in tracking for Android. If Google doesn’t create an opt-in tracking mechanism for Android, then install attribution could continue to exist to serve the Android market. But this seems unlikely: Google and Apple operate more or less in lockstep with respect to privacy. Google introduced its LAT equivalent (Ads personalization) one year after Apple introduced LAT. Furthermore, Google has had attribution services in its crosshairs since at least 2017, when it introduced install attribution to Firebase.

It seems possible that MMPs adapt to this change by serving as auditors: receiving install receipts from ad networks, aggregating them, and reconciling campaign and event identifiers against naming conventions and revenue values, and using cost data to present probabilistic ROAS reporting.

This functionality would be useful and is almost certainly something that few advertisers want to build themselves, but it’s also mostly administrative: an accounting service of sorts that doesn’t unlock much value. Put another way: this isn’t a service that advertisers would be willing to pay tens of thousands of dollars per month for, and it wouldn’t support the current size and scope of the mobile ad attribution market. MMPs will need to pivot into lines of business that provide commercial insight if they want to continue to charge MMP prices.

Re-targeting and Custom Audiences / Lookalike Audiences

Re-targeting on mobile is currently done via advertising identifiers: an advertiser provides Facebook or a re-targeting DSP with a list of advertising identifiers that it wants to target, and those channels serve ads to those devices when a matching impression or bid request surfaces.

Without an advertising identifier to use in serving a specific device, it seems unlikely that re-targeting DSPs will be able to function as they currently do: they simply won’t be able to accurately identify a given device. Facebook will be able to facilitate re-targeting, since it can use any number of user-specific (versus device-specific) identifiers to target individuals: email addresses, phone numbers, etc. Back in 2014, I posited that Facebook acquired WhatsApp specifically to amass a large bank of phone numbers, which are perfect identifiers because they rarely change and are tied exclusively to a device (versus an email address, which is tied to an account that can be accessed from any number of devices).

This reality is likely to impact product design: developers will seek to either incentivize or simply require users to register accounts using their email addresses or phone numbers so that those identifiers can be stored and used for re-targeting and lookalike list construction. The ad platforms that don’t already offer lookalike and custom audience construction directly from lists (notably, Google UAC) will also likely roll these products out to compete with Facebook.

Of course, all of this assumes that Apple and Google are amenable to email being used as a proxy for the advertising identifier when users have explicitly opted out of ad tracking. A user might be horrified to know that they restricted an app’s access to their advertising identifier — which can be reset — only to have their email address, which is attached to many other aspects of their life, used for the same purpose. Note that Apple introduced its privacy-centric Sign in with Apple authentication service at last year’s WWDC; it could potentially enforce use of it as an alternative for user registration in apps to prevent exactly this scenario.

Managed DSPs

In discussing mobile DSPs in the new, IDFA-less environment, a distinction must be drawn between in-housed or self-serve DSPs, which facilitate advertiser-led programmatic media buying, and managed DSP services, which are utilized by advertisers essentially as ad networks.

As discussed in the recent MDM Podcast, How a bid becomes a DAU, the core value proposition of managed DSPs are their device graphs, or their lists of device advertising identifiers paired with knowledge around which of those devices have monetized, and in what apps. Once these device graphs become irrelevant, managed DSPs will lose competitive advantage over other programmatic solutions, even in-house DSPs. My former colleague Nebojsa Radovic summarized this dynamic in a Twitter thread:

One of the frequent questions I got regarding IDFA removal is whether DSPs will be able to survive?
— Nebojsa Radovic (@eniac) June 26, 2020

It’s unclear what path forward exists for managed DSPs without advertising identifiers. Managed DSPs can of course optimize advertising campaigns at the publisher and placement level, but that level of granularity tends to not be efficient for advertising optimization: programmatic supply suffers from an adverse selection bias as most programmatic inventory is backfill. And if advertisers can in-house programmatic spend and be on equal footing with managed DSPs, why would they pay hefty fees to managed services?

updateConversionValue(_:)

The Conversion flag in an SKAdNetwork postback will allow the advertising network to receive notification that some conversion event has taken place from within traffic acquired by a campaign. This flag will allow ad networks to count events at the level of the campaign cohort, eg. Campaign X generated 15 counts of Event Y. But this is worth clarifying further.

Advertisers will be able to map up to 64 in-app events to identifiers (via the 6-bit conversion ID parameter in the SKAdNetwork postback) that will be sent to SKAdNetwork via the updateConversionValue method when executed. Whenever an install is attributed by SKAdNetwork, a rolling 24-hour postback timer begins counting down to 0, and each time a mapped event is fired, the timer resets. Once the timer reaches 0, the postback is fired to the ad network that supplied the install.

A mapped event identifier will only be recorded for the postback if either no conversion event has yet to be recorded for the attributed user or if the identifier is larger than that which is previously recorded for the attributed user. According to the SKAdNetwork documentation, it seems that the postback timer can be reset up to 64 times, so long as increasing event identifiers are being recorded. Once the initial timer completes, Apple begins another timer on a random length of time between 0 and 24 hours to obfuscate the source of the event, and the postback is fired when that second timer completes.

This postback logic will dramatically alter app monetization design: advertisers will aspire to strike a meaningful balance between minimum elapsed time between install and postback receipt and maximum monetization and / or engagement signal contained within the postback (ie. higher values of the conversion event carrying important information about the value of the user).

Developers will strive to instrument their apps such that the most valuable users fire as many of the 64 events as possible within the first few sessions of app use to facilitate the postback being received in a timely manner. This new dynamic will accelerate the existing trend of integration between app monetization and user acquisition: the user acquisition team of the very near future will play a central role in designing the content path that users take before a conversion event is fired via SKAdNetwork.

Event-optimized campaigns

Since networks receive conversions, they can optimize campaigns against them, albeit not at the granularity level of individual user identifiers, and not with exact event counts: if a network receives a conversion identifier, it will only know that the event mapped to that identifier executed at least once, but it won’t know whether that event executed more than once or if any other events with lower identifier values were executed.

Facebook, for instance, could use these conversion receipts to optimize targeting with broad demographic features as well as to build correlations between targets and app types. This won’t be as efficient as its current method, which uses the features of individual users — especially monetization history — to hone targeting for the App Event Optimization (AEO) campaign strategy, but it will still allow for event-optimized targeting.

The Value Optimized (VO) campaign strategy is harder to execute without advertising identifiers because it relies on the magnitude of monetization expected from an individual user — if the advertiser is unable to post all revenue events back to Facebook with user identifiers attached, and Facebook can only receive the one event signal per user per campaign (absent any revenue data), then Facebook has no way of gauging magnitude of monetization or engagement. All of this similarly applies to tCPA / tROAS campaigns on Google’s UAC.

I believe that the shift to SKAdNetwork-tracked conversions might actually benefit ad networks that compete with the Self Attributing Networks (SANs). Currently, many advertisers withhold conversion events from non-SAN ad networks in an attempt to hide the identities of their most valuable users from them: if an ad network knows that User X monetized in App A, the network might specifically target User X for App B‘s campaigns in order to improve their conversion efficiency. Given that revenue context is excluded from the SKAdNetwork postbacks, there’s no reason for any advertiser to withhold that information from ad networks, and they are put on equal footing with Facebook and Google.

In-app ad monetization

In-app monetization is governed by the same forces that change the economics of DSP advertising. Header bidding especially will be fundamentally impacted by a lack of advertising identifiers: header bidding provides for a programmatic unified auction that allows advertisers to bid on inventory at the ad level (versus ad waterfalls, which bid on CPM values that are set intermittently based on historical averages).

It seems likely that the eradication of advertising identifiers depresses CPMs across the board because performance will only be measurable at the campaign level. It is very difficult to make the economics of programmatic buying work if individual users can’t be targeted based on proprietary information. If bid logic reverts back to historical campaign performance (via the conversions logged with SKAdNetwork postbacks), then header bidding — which, again, provides the ability to bid at the level of an individual impression — won’t really confer any advantage over CPM-based waterfall ad mediation.

Cross promotion

One interesting tidbit found in the updated SKAdNetwork documentation is the fact that the Identifier For Vendors (IDFV) will remain accessible regardless of whether a user has opted into ad tracking. The IDFV is a unique device identifier available to app developers across its own apps on a given user’s device. For example, a User X might have three of Developer A‘s apps installed on her phone: App 1, App 2, and App 3. In this case, Developer X would have access to a unique IDFV for User X within its own apps on User X‘s phone: it could use this to store engagement and monetization data for User X across all three of its apps.

The IDFV cannot be used for acquisition attribution, but it can be used to great effect for cross promotion, which might provide a competitive advantage to developers that oversee portfolios of apps that feature large MAU. And the IDFV might become an important vector of M&A: a developer might not be able to transparently acquire high-value users, but it can acquire developers with large but declining user bases and cross promote those users across its existing portfolio on the basis of monetization history. I discussed the power of an intelligent cross promotion mechanism for developers with large portfolios in my 2016 GDC presentation about my efforts in building an internal ad network at Rovio.

What’s the net impact?

More important than how the privacy changes to iOS announced at WWDC 2020 impact the mobile ad tech ecosystem is how they impact consumers. My personal opinion here is that an app-level tracking opt in mechanism provides users with an even more granular level of control over their personal data, and in that respect, this is a welcome and positive change to the ecosystem.

I think the net impact of these privacy changes to advertisers is neutral to slightly negative. Advertisers won’t have attribution transparency at the user level, but as I argued in the beginning of this piece and in Media mix models are the future of mobile advertising, that transparency in the current paradigm is, to a large degree, a facade: last-click attribution provides advertisers with the veneer of control and measurability, but the reality is that the pool of users swirling throughout the overlapping fields of vision of the major ad networks has rendered value attribution impossible. And Google and Facebook had an unfair advantage in poaching the last click for most ad interactions, anyway.

Many sophisticated advertisers have been moving towards top-down, macro-level incrementality models over the past 12-24 months. The loss of device-level identifiers will hasten that transition out of necessity, but that doesn’t also mean it’s not the most prudent approach to advertising. Fast forwarding two or three years, I don’t think the mobile advertising ecosystem — from an advertiser’s perspective — looks meaningfully different now than it would have if Apple had announced business as usual for the IDFA at WWDC 2020. This trajectory had already been established.

Obviously the impact of tracking opt-in on much of the mobile ad tech terrain will be more severe, and the outlook for companies residing in those outposts is not as rosy.

Caveat lector

Apple’s privacy announcement from WWDC 2020 is only one week old, and the documentation they have released about the updates coming to SKAdNetwork are, in many places, incomplete or vague. The above represents my best guess at what will happen to the mobile advertising ecosystem, which is complex and multi-faceted, over the next 6-24 months. My opinion has been informed by exhaustive study of Apple’s documentation and through talking to a large number of people across the ecosystem, but my perspective is limited by the amount of information available. I believe that I approach this topic objectively and without any inherent bias, but readers should judge that for themselves.

Thank you

I have gained very valuable perspective around the changes coming to iOS 14 by speaking with people over the past few months whose opinions and insight I value greatly. Thank you to: Gadi Eliashiv, Nebojsa Radovic, Thomas Petit, David Barnard, David Philippson, Dick Filippini, Maor Sadra, and John Koetsier.