iOS 14 beta 7: Important IDFA technical changes (and one massive surprise)
You probably heard that Apple has delayed implementation of all the privacy updates in iOS 14. Most critically, for mobile marketers and mobile user acquisition specialists, Apple is not immediately enforcing iOS 14’s new rules around IDFA collection.
That will instead happen in “early 2021.”
At the same time, Apple released the latest beta of iOS 14, beta 7. We immediately installed it and started testing how it treats the IDFA. There’s some very interesting new behavior here … and one massive gotcha for mobile marketers.
The biggest changes from the previous iOS 14 beta versions are:
- The IDFA is now accessible without asking the user for permission
- Calling Apple’s requestTrackingAuthorization method can restrict access to IDFA
Ultimately, therefore, you have the IDFA as an advertiser (at least for now), but if you ask for it … you could very easily lose that privilege. All of that makes sense and is in line with Apple’s updated developer documentation around delaying the implementation of iOS 14’s full planned privacy changes.
Here’s how iOS 14 beta 7 treats the IDFA
Here’s the updated screen where Apple will allow users to manage their privacy around IDFA sharing and tracking. This screen offers control over:
- Global IDFA enabling and disabling
- A record of all apps that have asked for IDFA access
- And the ability for a user to change his or her mind on any IDFA access decisions
The default global setting for “Allow Apps to Request to Track” is on, meaning apps can ask if users will share their IDFA. All apps that request this permission will then show up in a list below the global setting. For each, there will be a configurable record of the decision the user made: if they allowed tracking, it’s on. If they did not, it’s off.
(Note: this is how iOS 14 will work even when the new privacy changes are fully implemented and enforced; right now, you should not ask for permission to use the IDFA … because you already have it by default, unless the user opted out globally.)
So this screen can also be used to enable IDFA measurement on apps that a user previously denied permission to. That’s a positive for mobile marketers. But it can also be used to deny permission to apps that the user previously allowed, which would make that user unmeasurable in granular form by an advertiser.
What about “Reset IDFA?”
In iOS 13, there is a control to reset the IDFA, but that will soon no longer be available. In iOS 14, if you turn IDFA access off for all apps, your global IDFA will be reset.
That means that technically, one app can cause IDFA to reset for the entire device:
- Assuming that only one app called requestTrackingAuthorization and got permission to track
- Sometime later, the user changed his mind and revoked that setting
- Since all the apps in the settings screen lost access the IDFA gets reset
We don’t think this surprising behavior is a bug. Instead, we think it is intentional behavior. Ultimately, this setup provides the IDFA for marketing measurement, but any previously granted IDFAs can be zeroed out easily and unpredictably.
To clarify – an app called requestTrackingAuthorization and was denied immediately doesn’t cause an IDFA reset.
First, mobile marketers need to get their iOS 14 IDFA ducks in a row. That means implementing SKAdNetwork and starting to test it. See all the details why that’s absolutely critical and how to begin here.
Secondly, for your user acquisition campaigns in iOS 14 and other versions of iOS, do not ask for the IDFA permission just yet (unless you’re doing so for just a few users to run some tests). You have permission by default, as long as users have not turned it off globally, and asking only opens the door to not getting it.
In short: implement SKAdnetwork, but don’t call requestTrackingAuthorization just yet.