To communicate with iOS users through push-notifications, users must grant permission. Soon, Android devices will be updated to the 13th version, where applications will have to request similar permissions. The graphic below shows when updates will be applied for each manufacturer.
As a result of Android 13 requesting permission to use push notifications, users will likely opt out at higher rates than before, reducing the amount of users who can be reached and lowering user engagement.
Prior to the launch of Android 13, we conducted a user experiment with one of the most popular entertainment applications on Android 12??OS by imitating a push notification request. 80% of users opted into push notifications. This is a positive indicator for user engagement on Android; compared to iOS, which shows only 40-50% of users opt into push notifications. This seems pretty optimistic, considering the fact that this indicator varies from 40-50% on iOS. The amount of push-notification recipients will decrease on Android 13 by more than 20%.
I’ve conducted dozens of experiments in an attempt to improve the opt-in rate of iOS apps. In this article, I’ll describe a sequence of events, which brought me the greatest growth of opt-in rate, as well as, tricks, which didn’t work out.
Most successful experiments
1. Ask here and now
Evidence suggests that users are more likely to grant permission for push notification use after the user has recognized the worth of the product (the a-ha moment). Ideally, a user’s a-ha moment appears in the application store or landing page.
Initially, I placed a request to send push notifications to the user in an entertainment app; this request would appear after the user completed the onboarding and as soon as they scrolled through the app’s content. Then, I tried an option with the request on the first screen of onboarding and received a 15% increase in permissions granted.
Based on the results of this experiment, I believe that the permissions request should be placed within the first few steps of onboarding in order to obtain a higher level of user permissions.
2. Highlight the worth of the product
For example, when launched, the Ultimate Guitar app asks users which instrument they'd like to play and which genres do they prefer? Only after this expression of value, the user receives push-notification requests, IDFA and subscription. This approach allows users to feel like the app is customized specifically for them.
Similarly, Apple Music and many other applications use push notification requests during onboarding. By investing efforts in]making users feel that the app is tailored to their preferences the user is more likely to continue with and complete the onboarding process. This is why it can be effective to divide what would typically be a long registration form into several smaller steps.
In a cash-back application , I added a screen offering a selection of various categories for users to personalize their experience, which increased push notification opt-in by 10%. I encourage experimentation for you to find the right customization, question, or offering that clearly shows the value of the product, leads users to their “a-ha” moment, and increases permissions granted for push-notifications.
To more quickly determine which question or customization creates the most value for the user, there is no need to change the behavior of the system depending on the answers of the question.
3. Offer a choice
One more successful experiment I conducted within entertainment apps was adding a question about push notifications.I asked users “how often would you like to receive push notifications? Rarely / sometimes / often”, after which, we ask the user if they will grant push notification permissions Most users chose the “rarely” option, but this experiment improved conversion into push permission by 9%, compared to immediately asking user for push permissions.
What didn’t work
Screen with examples of push notifications
Before requesting permissions for push notifications, I added a screen to show potential examples of notifications, specifically using notifications that had gained the highest click-thru rate (CTR). I expected that users would evaluate the examples prior to responding. However, the effect was the opposite — opt-in rates decreased by 5%.
Screen with description of push-notifications benefits
I also tried to highlight the value of push notifications by adding a description before the permissions request. Similar to the previous example, this was a mistake as it forced the user to think too much about the requestOpt-in rates decreased by 7%.
Fake opt-in request
The push notifications permission request can be shown to the user only once. It does not appear after the user made their original choice. I have come across other popular apps which change the “don’t allow” button to “ask me later” so that they are able to ask the user the same question in following sessions.
iOS 12 introduced the ability to send provisional push notifications, which do not require the user’s permission. This type of h push message is complemented with buttons to “keep.. / turn off..” the feature.
At the start of the experiment, the amount of recipients was initially double the typical push notification opt-in rate on iOS (40-50%). However, later on in the experiment, I observed that twice as few users opened these notifications, despite a large database of existing users. It appears that this type of push messages repel the user.
- Don’t underestimate push-notifications. This experiment helped to double the retention rate
- Position the opt-in request at the start of onboarding to obtain the highest coverage and reach deactivated users
- Highlight the value of the product before the opt-in request and you will get even more permissions
- Allow users to minimize the amount of push-messages they receive and they will be more willing to give you permissions