← Back
How the introduction of notification runtime permissions in Android 13 affects conversion from push notifications
Mar 10, 2023

Like many Android developers, we’re used to the notification bar being the secondary point of focus after the launcher. Yet with the release of Android 13, the rules of the game have changed. 

In this article, we will reveal how our product’s retention changed following the introduction of notification runtime permissions, as well as how accurate our initial predictions on this latest release’s impact turned out to be. Is it true that push notifications are now a privilege, and that the onus has shifted to companies to prove their worth to users? Read on to find out more.

At FunCorp, we develop entertainment apps and see push notifications as a valuable means through which we can interact with our users. Our apps are available on both Apple and Android platforms, so we understand both platforms’ attitudes toward push notifications well. In the past, Apple has traditionally been more strict with their use, seeing them as more of an informative element, while Google has long been supportive of this channel, ensuring push notifications are both noticeable and interactive (for example, by giving users the option to send responses from notifications directly to messenger) and giving developers more options to manage their appearance and other features.

Google has now decided to give users more control over notifications, provoking potentially serious consequences for apps using reactivation push notifications.

Why did Android change its notification policy?

The quick answer — due to rising competition with Apple. The world has long shifted toward collecting as much data about people as possible, and this comes with certain risks attached, namely the potential for scandalous leaks to happen. That’s why companies are increasingly focused on privacy when it comes to use of their products. Privacy is also about controlling how applications can access your data.

One of Apple’s most powerful moves in this area was banning the use of IDFA something we’ve discussed previously), which has essentially resulted in the company creating a policy similar to GDPR within its ecosystem. This also proved to be a blow to Google, which made — and still makes — money from contextual advertising. The company is now taking steps towards banning access to the Google Advertising ID, but this doesn’t seem to be enough to show its commitment to the “friendliness” of its ecosystem. An explicit dynamic ban on receiving push notifications is therefore a logical next step and one that mirrors the response of its main competitor.

Users want more control. Our apps target different regions and age groups. In recent years, we’ve seen a growing preference among users in North America toward seeing only important notifications that actually give them valuable updates, as opposed to less vital, and somewhat “clickbaity” push notifications.

Android users were given control of push notifications gradually and slowly. For example, since the release of the 8.0 operating system, users have been able to disable specific types of notifications if they were implemented through dedicated notification channels. Yet until recently, doing this still involved users taking an active step by going to ‘settings’ and pressing an additional button — and let’s be honest, it’s clear that most people either didn’t know how to disable push notifications or simply couldn’t be bothered to carry out the extra steps needed to do so.

How has user behavior been affected by the need to request explicit permission to show notifications? First, we reviewed historical data on our America’s Best Pics & Videos (ABPV) app for North American audiences and then moved on to experiment with a new product for users in India and Pakistan. Read on to find out the results we obtained and the conclusions we drew.


Experiment results

What we knew at the beginning. We had historical iOS and Android data on one of our apps, namely America’s Best Pics & Videos (ABPV). The average number of permissions received was 58% for iOS and 83% for Android.

At the same time, we ran a similar test on FunXD, our new app aimed at users based in developing countries, by rolling out the update for users in India and Pakistan.

The experiment. We implemented our custom request to allow or disable push notifications and started showing a dialog box on the start screen of the Android application. At the time, we had no access to the system API or support for the new Target SDK, nor could we request user permission at the system level. However, we were able to simulate such a request, which, in our opinion, is a sufficiently approximate model for testing user preferences.

The result. Over the week, we gathered a sufficient amount of data on the approval (and denial) of displaying push notifications. In North America, with ABPV users, the permission rate dropped to 60–63%. It was a noticeable fall, but most users were still interested in the notifications.

In India and Pakistan, among FunXD users, the rate of explicit permissions to receive push notifications remained steady at 85% or higher.


What’s next?

We are waiting for changes to Android 13 from key vendors to implement a system screen for requesting permission to send push notifications. At least we have some idea of what to expect. And we also hope that users will get used to seeing this request window, stop feeling nervous about it, and start clicking “allow” more often. At the same time, however, we will continue to explore new means through which to better interact with our users.

More information about us, as well as photos and videos in our public pages:
© Copyright 2024, FUNCORP

We plan to continue our growth and development by entering new markets and finding new business niches. Take a look at open positions. Perhaps there is one that is right for you!

If you know a passionate Software Developer who's looking for job opportunities, e-mail us at job@fun.co. In case of successful recommendation you will get a $3000 reference fee.