Android 13: Getting ready for the new push notification permission

This is a major event for the Mobile CRM ecosystem: with the release of Android 13 on August 15th, Android finally caught up with iOS in terms of push notification consent management.

This historic change has major consequences for Mobile CRM managers who may be worrying about the evolution of their existing push opt-in user base and their ability to contact new users in the future.

Don’t panic! We have analyzed all the changes impacting push notifications in Android 13 and prepared the list of best practices you should implement now to seize the new opportunities - because they do exist - created by the “Android 13 effect”.

Android 13: What is changing for your users?

To understand the changes brought by Android 13, here is a reading grid based on the three segments of your opt-in base:

• Effect #1: New users
• Effect #2: Existing users
• Effect #3: Inactive users

Effect n°1: New Users

New users now need to grant your app the permission to display push notifications. In short, from Android 13, push notifications are disabled by default for all new users who install your app. Google adopts an opt-in mechanism well known and mastered for years by marketers on iOS.

It is a major change on Android, for two reasons:

• First, for users, who discover a new push permission request.
• Second, for marketers, who discover that their user base will no longer be 100% reachable using push notifications.

This is not a surprising move from Google though, for two main reasons:

1. Android was the last OS that didn’t require explicit consent to display notifications, unlike iOS and web browsers, for web push notifications.
2. Over the last years, Google has added several privacy-related features to give users more control over app permissions (e.g. geolocation, advertising id, etc) and clarify the data shared with apps. Notifications were the only feature that remained untouched, until now.

Here are a few things you should know about the new push permission request:

• It can only be triggered once and cannot be customized (e.g. wording, etc).
• If users don’t allow push notifications and change their mind later, they will need to go to the system settings to turn on push notifications for your app.
• Developers can choose when the new push opt-in request will be triggered (e.g. after clicking a button in an onboarding flow existing in your app). According to Google’s documentation, the new opt-in request should be part of the onboarding sequence - designed by the CRM team - that will contextualize the request.

Fortunately, your existing users won't have to give your app back the right to show them notifications. Google has indeed planned this scenario, especially for the second case that follows.

Effect n°2: Existing Users

Good news for existing users who update to Android 13: apps installed before the update retain the right to display notifications.

A system suggestion will still be displayed after the update. This will simply enable users to view their current opt-in push choices and, optionally, modify them.

Effect n°3: Inactive Users

Since Android 11, Android automatically revokes application permissions after a long period of inactivity, especially for the geolocation permission.

From Android 13, notifications will also be affected by this automatic reset.

How many days of inactivity will trigger the automatic permission reset? For the moment, it’s impossible to say. The exact rules are not disclosed by Google (and will certainly remain so).

Android 13 means a new mandatory authorization request

The first Android 13’s visible effect is obviously the appearance of this new authorization request.

For Android 13 optimized apps, the triggering of the request is scriptable.

For apps that aren’t yet optimized for Android 13, these apps may already show the push opt-in request. One downside though: you can't control when this request appears.

This authorization request takes place in two scenarios, which entirely depend on the technical choices made by your developers:

1. The request is immediately displayed as soon as the application is opened.
2. The request display is deferred. This is triggered after the first session. This is what will happen most of the time.

Let’s briefly develop these two scenarios:

1st scenario: The request display is immediate

And this is the case from the very first session, when the application declares to the system the types of notifications to manage. This is when the app records the “channels”.

Main advantage: the request is displayed from the first session, which allows you to contact inactive users afterwards.

Main drawback: the request may be displayed above an account login screen or an ad. Without further context, this is not optimal.

2nd scenario: the request display is deferred

The application will not register notifications with the system on the first opening. This will therefore not result in the display of the new push authorization request.

It will only do so upon receipt of the first notification, in the background. The first push sent to the application will never be displayed, because the app does not yet have the right to do so. It’s only at the next opening that the push authorization request will be displayed.

There are two major drawbacks here:

1. Users will only be reachable if they reopen the app, which is not guaranteed.
2. Your non-received onboarding journeys will have no effect if the user does not return to the app to activate the notifications.

In this situation, there needs to be a joint effort of Batch’s Solutions Engineers teams and your technical teams to update your app and properly manage when the request is triggered.

In short, as we will see later in this article, it’s essential to optimize your app to control the opt-in experience specific to Android 13. This is the only way to put all the chances of your side to collect your users’ opt-in push.

Post-Android 13’s new rules: knowing how to animate a smaller, but much more qualified opt-in base

To understand Android 13’s impact on Mobile CRM strategies, let's go back to our reading grid, based on the opt-in base’s different segments.

New users: the Android opt-in rate will probably align with the iOS one (around 50%). Here, the challenge will be twofold: limit the opt-ins drop and seize the opportunity to have a more qualified audience.

Active users: The existing opt-in base will only be preserved for active users. This is an opportunity to address an engaged user base, and improve re-engagement and re-activation journeys to keep users active.

Inactive users: It’s in our best interest to combine the different in-app and non-app channels (push, web, email) in the most personalized multi-channel journeys possible to make sure inactive users are effectively reached to re-engage them.

Take the lead: adapt to Android 13 and make it your competitive edge

At this stage of the article, you probably figured it out: Android 13’s impact is significant, and this entails risks for your CRM performance if you don’t make the right moves now.

These best practices won’t just minimize the risks brought about by Android 13, but turn this update into a competitive advantage for your mobile strategy. The challenge is to get started now.

Android 13 has already been released, on August 15. Only 13.5% of devices are on Android 12. That may not seem like much.

On the other hand, based on the previous versions’ deployment rate, we can estimate that there will be at least 200M active devices on Android 13 in the next 6 months.

To give you a more precise idea of our ecosystem’s evolutions towards Android 13, here is the provisional schedule of various releases, which we’ve extracted from this Android Authority’s article.

Prepare and adapt to Android 13, on both technical and CRM levels

So what does being ready for Android 13 actually mean? Well, this implies a double update.

On the one hand, a double technical update of your App’s and Batch SDK’s. On the other hand, the implementation of new CRM tactics in your customer / user journey:

• CRM tactic n°1: Include opt-in push in your in-app onboarding sequence
• CRM tactic n°2: Re-opt-in request via Batch’s In-App campaigns

CRM tactic n°1: Include opt-in push in your onboarding sequence. This is a practice on which we also advise our clients.

This is widespread on iOS: for many of you, your developers will only have to resume on Android the paths they have already designed for iOS.

Some examples in different industries. The keys to success:

1. Demonstrate the notification value.
2. Choose a relevant timing for the user.
3. Bring comfort to the user by telling them what they will receive so that they can envision themselves using the app with notifications.

To go further into this CRM onboarding tactic, we invite you to read our Help Center’s detailed guide.

CRM tactic n°2 : Use In-App messages to convince users who are not yet opt-in to activate notifications.

This In-App campaign is part of the “starter kit” that Batch offers its customers on iOS. For example, our client 24S managed tore-engage more than 20% of their opt-out audience via these campaigns at the beginning of 2022.

To go further into this CRM In-App re-optin tactic, we invite you to read our Help Center’s detailed guide.

Android 13 update: We’re working hand in hand with our customers in this time of change

On our side, our teams have been ready for several months to support our customers in their Android 13’s adaptation, on both technical and CRM levels.

Since last April, our Tech and Product teams have released a version of Batch’s SDK with initial support for the Android 13 opt-in push request. Then in August and September, they’ve worked on all levels, the SDK, the functionalities, and the documentation levels, to support you in the transition to Android 13.

We hope this article has helped you better understand Android’s new rules, and from this, identify your Mobile CRM strategy’s top priority and adopt the best tactics.

Android 13's Frequently Asked Questions

After how many days are users considered inactive?

“Several months” according to the Google documentation which does not specify the exact time before resetting the permissions granted to the app (see documentation).

Once the notification permission has been revoked, will it be possible to send the permission request pop-in again?

No. According to the same Google documentation, automatically resetting the permissions granted to the app is equivalent to a denial.

This scenario has already been anticipated by our teams. You can now create an In-App message campaign that will target users for whom notifications are disabled (see documentation). When clicking on the button of the In-App message, Batch will automatically detect the situation in which the user finds himself:

• Request not displayed: the request will be triggered by clicking on the button of the In-App message.
• Request already displayed or revoked by the system: the user will be redirected on the form of your app to the system parameters to activate the notifications.

Does Batch detect the switch to inactive for in-app push relaunch?

Yes, the changed opt-in status will be detected as soon as the application is opened. The user will then be able to see the In-App message in their journey to reactivate notifications after several months of inactivity.

Will those who are already opt-in on our App have to opt-in again if they switch to Android 13?

No, that won’t be necessary. Android grants permission to show notifications to apps that were already installed on the user's device before updating to Android 13. After the update, your app will not have to “request” permission to send notifications.

Will the impact on these inactive users cause you to review the algorithm of your "DORMANT" smart segment?

The Smart Segments objective is to allow any marketer to understand at a glance how their audience is distributed by major segments of user activity and to simply create segmented campaigns. This segmentation feature is solely based on user behavior. It can be used for all the communication channels offered by Batch (push notifications and In-App message) and is therefore not correlated to an opt-in state.

I didn’t get why the Batch SDK had to be updated. If I add the optin / optout question in my onboarding, why updating the Batch SDK?

Because being able to completely support Android 13 and scripting the triggering of the push authorization request, two updates are absolutely necessary:

1. Configure your Android project to support what's new in Android. For your developers, this corresponds to “targeting API 33”.
2. Update Batch SDK to version 1.19.2. This version adds an action or “method” that your developers can call in your app code to trigger the push authorization request at the desired time.

Both of these changes are simple to make and can be done in the same update to be rolled out to the PlayStore.

As for the iOS system, do we only have one chance to display the Android system permission?

Yes, Android uses the same push authorization request mechanism that exists on iOS. The same existing mechanisms and perhaps already applied in your iOS app can be reused, namely:

• Set up a pre-request screen to present the system request as part of your onboarding, for example.

• Set up an In-App re-optimization campaign aimed at users who have refused notifications or whose permission has been reset by the system after several months of inactivity.