· 7 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. If you wanted to access a user’s mobile identifier (IDFA), you had to ask for their consent specifically.
If you’re unsure why this is important, the IDFA is used for advertising purposes. When Apple released the update, almost every user needed to opt-in (rather than out), hugely impacting advertising and ad revenue. (More about this here.)
But we’ve seen some interesting findings about mobile game opt-in rate. 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 the 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 must look 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 many 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 (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). For example, you can’t use it for install attribution, as you would need to track an identifier from the specific game showing the ad to the advertised game being installed. It’s a bit complicated. But in this case, too many vendors are involved, so the IDFV wouldn’t work here.
But the IDFV lets 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 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 app user 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 to predict the non-IDFA users’ behavior, specifically to model user 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 use 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)
To know how many of your users opted-in, we need to review 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, as the data between 14.0 and 14.5 can be misleading.
In short, the ATT framework can always report the current AuthorizationStatus. 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. The “Allow Apps To Request To Track” setting is disabled on restricted devices. 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 totally 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
The 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 why.
- We calculate differently. So how we calculate the results may differ slightly (what users or apps we included) from 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, tracking and visualizing your player’s consent status is easy. Simply install the latest SDK, and the consent status will be tracked automatically.
Read our previous blog post for more details.
