· 8 min read
iOS 14 Opt-in-Rate Is Higher for Mobile Games
Earlier this year, Apple released iOS 14.5. It was the dreaded update among all app developers, studios, and publishers. It meant that if you wanted to access a user’s mobile identifier (called IDFA), you had to specifically ask for their consent.
If you’re not sure why this is important, the IDFA is basically used for advertising purposes. When Apple released the update, pretty much every user now needed to opt-in (rather than opt-out), which had a huge impact on advertising and ad revenue. (More about this here.)
But we’ve been seeing some interesting findings around the opt-in rate for mobile games. Which is what we’re going to cover in this blog.
We have data on Opt-in Rates
We’ve read tons of articles and blogs within the industry over the past few months. All speculating what they think the Consent Opt-in Rate would be – especially for games.
And for us, we don’t need to guess anymore. We have the data.
Here’s what we’ve found:
Opt-in Rate
How many % of players (who were asked) chose to consent.
Opt-in rate = 43%
You read that right. We’ve shared our findings on how we came to this result below. But to understand the full picture, we need to look a bit deeper.
iOS identifiers
To know just how impactful this update was, we first need to learn how 3rd party services track iOS users (including GameAnalytics) via device identifiers. If you’re already up-to-speed on this, then skip right on.
IDFA (identifier for advertisers)
The IDFA value is unique across all iOS apps on a device. It plays a crucial role in earning money from your ads (and does much more), as it lets you track data from different apps and services on the same device, and then later correlate all of that data to the same device/user.
This identifier would let you collect data from lots of different sources (like install attribution) which you could use in a data warehouse. And with this data, you could optimize your gameplay, monetization strategy, and more.
For every device that has iOS 14.5 onwards, you can only collect this data if the user opts-in. And with these changes, many services (including Facebook), decided not to use this identifier at all.
IDFV (identifier for vendors)
The IDFV value is unique across all iOS apps from the same vendor on a specific device (so an app developer account, for example).
You can’t use this to correlate data from different app vendors (so games from different studios or developers). As an example, you can’t use it for install attribution, as you would need to track an identifier from the specific game showing the ad, through to the advertised game being installed. It’s a bit complicated. But in this case, there are too many vendors involved, so the IDFV wouldn’t work here.
But what the IDFV does do is let you collect and correlate data across your own portfolio of games (if they’re published from the same company account). And it works fine for analytics purposes for that specific app, too. You can always get access to the IDFV value without asking for consent.
Here’s some info from Apple’s guidelines:
“The ID for Vendors (IDFV), may be used for analytics across apps from the same content provider. The IDFV may not be combined with other data to track a user across apps and websites owned by other companies unless you have been granted permission to track by the user.”
Random identifiers
Some services use a random string as the user ID which is created in the app when launched for the first time. You shouldn’t compare this to creating a fingerprint, as Apple won’t let you do this.
It’s simply a randomized string (often in a GUID format). If the user of the app were to reinstall, then an identifier will be created again and they would be seen as a new user in terms of metrics. It cannot be correlated across apps on the same device.
For GameAnalytics, we’ll use a random string user_id as a backup in certain cases, or on specific platforms where it’s used exclusively.
A lot of services still rely on IDFA
So as you know, with iOS 14.5+, all games need to ask for consent to get the IDFA. A lot of services are still using the IDFA. Adjust, for example, shared their documentation on how to increase the opt-in rate for IDFA, to try and track more users.
So these services still use IDFA data, specifically to model user behavior, and then use this to predict the non-IDFA users’ behavior. For example, if 40% of users behave in a certain way, then it’s likely that the other 60% have similar patterns.
So the higher the opt-in rate, the bigger the sample size, and the more accurate their models.
We’ve already moved to using the IDFV exclusively for the user ID. Alongside this, we now only attempt to call the IDFA value if the user has given consent. We only use the IDFA when processing or matching attribution callbacks from other services (like Adjust). Or to share the data (for a specific game studio) via our Data Services.
Introducing ATT (App Tracking Transparency)
For you to know how many of your users opted-in, we need to go over how Apple introduced ATT (App Tracking Transparency).
Apple released the ATT framework in iOS 14.0, but they waited until iOS 14.5 before you needed to ask for consent. This is important to know, as the data between 14.0 and 14.5 can be a bit misleading.
In short, the ATT framework can report the current AuthorizationStatus at all times. There’s more on this here. But to give you an idea of what this means, a device can report four different AuthorizationStatus values:
| AuthorizationStatus | Description |
| authorized | The user provided consent for this app. |
| denied
|
The user declined consent for this app via two possible scenarios.
|
| notDetermined
|
The status is not determined yet, but it is possible to ask the user.
In this state it is known, that an actual state of authorized or denied can be obtained by asking the user (it is not “restricted”).
|
| restricted
|
The device cannot show the ATT dialog to ask for consent. On restricted devices the “Allow Apps To Request To Track” setting is disabled. This can be disabled in 2 different scenarios.
|
Back to the opt-in rate details
That was a lot of info. Well done for getting this far! In the following table you can read more specific details on how we queried the data to derive the opt-in rate.
| Period | 1st July – 31st August |
| Filtering
|
Include only…
|
| Counting users
|
For each game
Sum up the counts per game into a total unique user count per AuthorizationStatus. |
| Opt-in Rate formula | authorized users / (authorized users + denied users) |
| Sample size | 121 million users |
The results
Worldwide consent status distribution
Opt-in Rate was 43% worldwide.
| Consent Status | Percent |
| denied | 39.8% |
| not_determined | 31.5% |
| restricted | 17.2% |
| authorized | 29.6% |
U.S. consent status distribution
Opt-in rate of around 36% in the U.S.
| Consent Status | Percent |
| denied | 46.2% |
| not_determined | 29.03% |
| restricted | 20.5% |
| authorized | 24.7% |
Final thoughts
So there we have it. Our numbers are much higher compared to, say, what Flurry is reporting. And there are a few different reasons as to why.
- We calculate differently. So how we calculate the results may differ slightly (what users or apps we included) to what Flurry used.
- GameAnalytics is purely focused on games. And a lot of these games are monetizing heavily via ads. They depend on efficient install attribution. And a lot of them use Adjust (who have been actively encouraging app developers to ask for consent).
- We see a higher restricted status in our data.
Consent status in GameAnalytics
You can get your hands on these numbers as well.
In GameAnalytics, it’s easy to both track and visualize your player’s consent status. Simply install the latest SDK and the consent status will be tracked automatically.
Read our previous blogpost for more details.
