At the beginning of the year, Apple released iOS 14.5. It was the dreaded update among all app developers, studios and publishers. This meant that if you wanted to access a user’s mobile identifier (called IDFA), you had to specifically ask for their consent.
If you are unsure why this is important, the IDFA is generally used for promotional purposes. When Apple released the update, pretty much every user now had to sign in (instead of signing out), which had a huge impact on ad and ad revenue. (More about it here.)
But we’ve seen some interesting insights into the mobile game opt-in rate. We’ll cover that in this blog.
We have data on opt-in rates
We’ve read tons of articles and blogs in the industry over the past few months. Everyone is speculating on what they think the approval rating would be – especially for games.
And for us we no longer have to guess. We have the data.
We found the following:
Opt-in rate
What% of the players (who were asked) chose to agree.
Opt-in rate = 43%
You read that right. We have shared our insights into how we came to this conclusion below. But to understand the bigger picture, we have to look a little deeper.
iOS identifiers
To see how effective this update has been, we first need to see how third-party services track iOS users (including GameAnalytics) through device identifiers. If you are already up to date with this, then skip ahead.
IDFA (identifier for advertisers)
the IDFA The value is unique for all iOS apps on a device. It plays a crucial role in making money from your ads (and does a lot more) as you can keep track of data from different apps and services on the same device and later relate all of that data to the same device / user.
You can use this identifier to collect data from many different sources (such as the installation map) that you can use in a data warehouse. And with that data, you can tweak your gameplay, monetization strategy, and more.
For any device with iOS 14.5 or higher, you can only collect this data if the user agrees. And with these changes, many services (including Facebook) have chosen not to use this identifier at all.
IDFV (identifier for suppliers)
the IDFV Value is unique across all iOS apps from the the same provider on a given device (e.g. an app developer account).
You can’t use this to correlate data from different app providers (i.e. games from different studios or developers). For example, you can’t use it for installation mapping because you’ll need to keep track of an identifier from the specific game the ad is being viewed in to the advertised game that is being installed. It’s a bit complicated. But in this case too many providers are involved so that the IDFV would not work here.
But the IDFV lets you collect and correlate data in your own game portfolio (if they are published via the same company account). And it works well for that particular app for analysis purposes too. You can always access the IDFV value without asking for consent.
Here is some information from Apple Guidelines:
“The ID for providers (IDFV) can be used for analysis across apps from the same content provider. The IDFV may not be combined with other data to track a user across apps and websites of other companies unless the user has given you permission to track. “
Random identifiers
Some services use a random string as a user ID that is created when the app is started for the first time. You shouldn’t compare this to taking a fingerprint because Apple doesn’t allow it.
It’s just a random string of characters (often in a GUID format). If the user were to reinstall the app, an identifier would be created again and they would be considered a new user in terms of metrics. It cannot be correlated between apps on the same device.
For GameAnalytics we use a random string user_id as a backup in certain cases or on certain platforms on which it is used exclusively.
Many services still rely on IDFA
As you know, all games running iOS 14.5+ must ask for consent in order to receive the IDFA. Many services still use IDFA. For example, customize, share theirs documentation how to increase the opt-in rate for IDFA to try to track more users.
Therefore, these services still use IDFA data, specifically to model user behavior, and then use that to predict the behavior of non-IDFA users. For example, if 40% of users behave in a certain way, the other 60% are likely to have similar patterns.
The higher the opt-in rate, the larger the sample size and the more accurate the models.
We have already switched to using the IDFV exclusively for the user ID. Besides that, we now only try to call the IDFA value if the user has agreed. We only use IDFA when processing or matching attribution callbacks from other services (such as Adjust). Or the data (for a specific game studio) via our Data services.
Introduction of ATT (app tracking transparency)
So that you know how many of your users have signed up, we need to look at how Apple introduced ATT (App Tracking Transparency).
Apple published that ATT framework in iOS 14.0, but they waited until iOS 14.5 before asking for approval. 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 be the current one Authorization status at any time. Find out more here. But to give you an idea of what this means, a device can report four different AuthorizationStatus values:
| Authorization status | description |
| authorized | The user has agreed to this app. |
| disputed | The user declined to consent to this app in two possible scenarios.
|
| undecided | The status has not yet been determined, 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 display the ATT dialog to ask for consent. The “Allow apps to request tracking” setting is disabled on restricted devices. This can be deactivated in 2 different scenarios.
|
Back to the details of the opt-in tariff
That was a lot of information. Well done for getting this far! In the table below you can read more details about how we queried the data to infer the opt-in rate.
| period | July 1st – August 31st |
| Filter | Just include …
|
| Count users | For every game
Add the numbers per game to a total of unique users per authorization status. |
| Formula for the opt-in rate | authorized users / (authorized users + denied users) |
| Sample size | 121 million users |
The results
Worldwide distribution of consent status
The opt-in rate worldwide was 43%.
| Consent status | percent |
| disputed | 39.8% |
| undecided | 31.5% |
| restricted | 17.2% |
| authorized | 29.6% |
Distribution of US consent status
Opt-in rate of around 36% in the US
| Consent status | percent |
| disputed | 46.2% |
| undecided | 29.03% |
| restricted | 20.5% |
| authorized | 24.7% |
Final thoughts
So there we have it. Our numbers are much higher than what Flurry reports, for example. And there are various reasons for this.
- We calculate differently. So the calculation of the results can be slightly different from that used by Flurry (which users or apps we included).
- GameAnalytics focuses exclusively on games. And many of these games monetize heavily through ads. They depend on an efficient installation mapping. And many of them use Adjust (which app developers have actively encouraged to seek approval).
- We see a higher restricted status in our data.
Consent status in GameAnalytics
You can get your hands on these numbers too.
In GameAnalytics, it’s easy to track and visualize your player’s consent status. Just install the latest SDK and consent status will be tracked automatically.
Read our previous blog post for more details.
