It’s been a couple of weeks since the Apple WWDC conference, where we learned how the IDFA will become opt-in for consumers.
Arguably this change will have a bigger and more immediate impact on advertising businesses than Chrome’s “cookie apocalypse” announcement in January as many business models and media dollars depend on the IDFA for their continued existence.
However, since the IDFA’s future is largely dependent on Apple’s technical decisions as well as those of app developers, for non-technical people the details can feel a bit opaque. So I’ve put together a factual layout of what we know and what we don’t know about the upcoming “IDFA Apocalypse.”
IDFA Basics
IOS 14 is the next version of Apple’s mobile operating system. When it is installed on a user’s device, apps that wish to use the IDFA must request access from the user. The user is then shown a dialog like this sample provided by Apple:
If the user does not opt in the app will not get access to the IDFA thereafter. This policy applies to all iOS devices, including iPhones, iPads and, sadly, Apple TVs.
Thanks @dlackty for this screenshot of AppleTV:
As a side note, in a recent study done by my company, less than 2% of all connected TV ad auctions on open exchanges included an IDFA as an ID.
IDFA Change Rollout
Based on previous releases and the prevalence of auto-updates, the first non-beta customers will get iOS 14 in September, and more than 50% of all Apple devices will have the latest version by the end of 2020.
Since the app requires a new API call to ask for permission for the IDFA, all older apps on users’ devices (which don’t have this API call) will stop getting the IDFA as soon as the new iOS rolls out and until the developers ship a new iOS 14-compatible version. This likely means that we will see a very significant drop-off in IDFA presence right away after the OS is released, and then a bounce-back as more ad-supported apps start asking for permission.
IDFA User Experience
Each app controls when the user gets asked for permission by making an API call. Smart app developers will manage the user experience to try to maximize the opt-in rate by either explaining the need for this data prior to showing the dialog or otherwise restricting functionality to users who opt out. Apps that pop-up the notification on first load are likely to get low opt-in rates.
Apps are only allowed to change a sentence in the opt-in dialog as described in the documentation, though the length of this sentence is undocumented as far as I can tell.
Importantly, apps cannot ask (“nag”) users to change the permission after the first ask. The user’s decision holds for the length of the app install (as described in the documentation). However, there is a screen in the systems menu where a user could update their permissions, so some degree of indirect nagging may be possible, though the user would have to do the work of navigating to the right screen, etc.
IDFA Enforcement and Alternatives
The biggest area of unknowns relate to policy enforcement by Apple. While the IDFA availability is enforced by the operating system itself, Apple’s statements on its developer page raise questions about whether there are likely to be anti-advertising enforcement activities that go well beyond the IDFA opt-in. The page says, in part:
… you will need to receive the user’s permission through the AppTrackingTransparency framework to track them …Tracking refers to the act of linking user or device data collected from your app with user or device data collected from other companies’ apps, websites or offline properties for targeted advertising or advertising measurement purposes. Tracking also refers to sharing user or device data with data brokers.
And …
Examples of tracking include … Sharing a list of emails, advertising IDs or other IDs with a third-party advertising network.
This text raises a lot of questions that Apple’s API documentation does not address:
- If a user provides their email but does not opt in to IDFA-level tracking, is the app prohibited from using that email for advertising purposes?
- How will Apple monitor or enforce this type of restriction? Will they block network calls with hashed emails or other personal data?
- Will Apple deem certain ad network SDKs as noncompliant with their policies and potentially force their removal?
Further, Apple says prohibited tracking includes:
… using an analytics SDK that repurposes the data it collects from your app to enable targeted advertising in other developers’ apps.
This seems clearly like a shot at Facebook and Google, where an app might use their tech for single sign-on, “likes,” analytics or other non-advertising use cases, but within a larger ad-supported ecosystem. How will this be enforced?
Finally, while Apple and Google have publicly talked about their efforts to prevent fingerprinting, there was no new news on this subject as part of the iOS 14 release. Ad SDKs have access to a large number of system variables that make fingerprinting fairly effective, so this loophole raises even more enforcement questions.
SKAdNetwork and attribution
Typical app-install attribution matches the IDFA from the app in which the ad was shown to the app that was installed. Thus, in the new iOS 14 world this type of tracking requires two separate opt-ins to work. If you think the overall opt-in rate will be X, the attribution opt-in rate is X2. (For example, 40% opt-in rate on the ad * 40% opt-in rate for the install = 16% attribution measurement rate.)
Just when the ship is sinking and all is lost, Apple throws you a life preserver called SKAdNetwork. Unfortunately, your new boyfriend froze and drowned.
Well, at least, unlike some solutions … cough … Chrome Sandbox … cough … we don’t have to wait two years to see if it works.
SKAdNetwork is an extremely limited postback attribution scheme that tells an “ad network” (Apple’s term, not mine) when a user has installed an app after clicking on an ad. The system intentionally provides very little data to the ad network, limited to the installed app, a campaign number between 1 and 100, the app on which the ad was shown and the date the ad was shown within 24 hours. Importantly, it only gives one entity credit for the click, which is determined by the SDK that serves the ad.
SKAdNetwork’s design largely ignores the existing value chain for digital advertising outside of mobile ad networks, and as such has raised numerous practical questions about implementation:
- Will mobile measurement partners serve as the “ad networks” and get the conversion data to retain their value proposition to advertisers, or will the SDK owners (the actual ad networks) claim the mantle as the owner of the conversions?
- How will the flow of information work in an RTB environment such that a DSP can assure that the upstream SDK registers them for conversion attribution properly?
- How can fraud detection work with this little data to track down fake installs?
- Given the limitation of 100 “campaigns” per app or platform, how will complex search and social campaigns adapt?
There are probably a lot more questions than answers here.
What will the opt-in rate be?
This is the billion dollar question, and one no one can answer it right now. Some folks are saying it will be 1%, others think it will be as high as 50%.
We know that according to The Wall Street Journal, after Apple began asking consumers to verify whether apps really needed their location data, 70% of that data disappeared. Will the same pattern hold for IDFA?
The good news is that all of our questions will be quickly answered come September, one way or another.
Follow Ari Paparo (@aripap), Beeswax (@BeeswaxIO) and AdExchanger (@adexchanger) on Twitter.
