iOS 14: IDFA is not dead yet, but it’s definitely on life support

 

Today at WWDC 2020, Apple announced several new privacy enhancements in iOS14 that will debut in September. We’ve been long anticipating these changes, and have been working to prepare for this since our announcement a year ago on the formation of the Mobile Attribution Privacy group. (See more details here, and join the Slack group here).

The good news for consumers: more privacy.

The good news for marketers: it’s not game over for data-driven marketing.

Some of the changes to Apple’s SKAdNetwork framework are extremely promising. Apple’s SKAdNetwork improvements suggest that not only are they listening to what app publishers need, but that we will still be able to provide tools for sophisticated marketers.

In addition, Singular has a number of upcoming privacy-preserving solutions that we will announce shortly.

Opt-In for IDFA

Starting with iOS 14, apps will need to receive permission from users in order to use the Identifier for Advertisers, the IDFA. To be clear, this is explicitly granting permission to track users across apps and services.

Straight from the documentation:
“Your app needs to request permission to track sometime before tracking occurs. This could be at first launch or when certain app features are used. For example, when signing on with a third-party SSO.”

Looking at the documentation for iOS 14, we can confirm that when the “Ask App Not To Track” button is clicked, the app will not be able to access the device’s IDFA, and receive the same value as if the Limit Ad Tracking mechanism is turned on. In short, until a user grants authorization, all identifiers will be zeroed out.

One piece of good news if you want to use the IDFA and believe it’s something that your users will want?

The message will be customizable. “App developers need to provide custom text, known as a usage description string, which is displayed as a system-permission alert request,” Apple’s documentation says.

That means you’ll be able to make the case to your users that opting in is a good thing for them.

Let’s be frank, however.

The vast majority of people who see a message like the above are not going to opt in. When they see that a publisher wants permission to track them across apps and websites owned by other companies … forget about it.

So you’re going to have to be ready to live without IDFAs.

Checking for IDFA status

Apple is deprecating the isAdvertisingTrackingEnabled function. In order to check if a user has actually enabled measurement, developers will need to check the AppTrackingTransparency framework.

Changes to SKAdNetwork

Apple has also made multiple changes to SKAdNetwork, the class that validates advertiser-driven app installations. We’re going to go in-depth on this in a follow-up blog post tomorrow — and a webinar — but here’s the quick overview:

1. Apple added timers, which likely means that the conversion notification won’t be immediate. This is probably a privacy-enhancing move.
2. Apple added a mechanism to update a conversion value. This may be an initial method to attach limited post-install KPIs to the conversion notification, which of course is crucial for optimizations.
3. Apple added Redownload/Reinstall support, which is always nice to know.
4. Apple added Source App ID to recognize the publishing app (this is huge because we can now facilitate publisher-level granularity).

There are quite a few more changes, but we’ll continue researching them and update on those later in our in-depth follow-up post.

Finally: new App Privacy section

Later this year, your app’s App Store product pages will start to feature summaries of your self-reported privacy practices, plus a link to your privacy policy. That includes both data gather via the app that is used to track users elsewhere plus data that publishers might access outside the app and link to users’ profiles in the app. Example: purchases, web browsing history, location data, and other demographic information.