20 Sep 2022 • Rédigé par Baptiste Guerre
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”.
To understand the changes brought by Android 13, here is a reading grid based on the three segments of your opt-in base:
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:
This is not a surprising move from Google though, for two main reasons:
Here are a few things you should know about the new push permission 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.
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.
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).
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:
Let’s briefly develop these two scenarios:
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.
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.
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.
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.
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 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.
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.
If you have any questions and you’re already one of our customers, feel free to contact your Customer Success. In any case, you can contact our experts at: firstname.lastname@example.org
“Several months” according to the Google documentation which does not specify the exact time before resetting the permissions granted to the app (see documentation).
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.
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.
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.
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.
Because being able to completely support Android 13 and scripting the triggering of the push authorization request, two updates are absolutely necessary:
Both of these changes are simple to make and can be done in the same update to be rolled out to the PlayStore.
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.
Fresh news on modern CRM in your inbox !