1. User Guide
  2. Campaigns and channels
  3. Mobile Push
  4. Getting started with Mobile Push
Android Push Permission and Reachability

Overview - Push Permission

Push notifications permission is an app-level permission that your app gets on a user's device. This permission is required to display push notifications on users' notification trays. If this permission is turned off, the notifications that you send will not be visible to the user; they will get delivered in the background to your app silently. 

PushPermissions.png

How does Push Permission work?

While apps are automatically granted permission to send notifications for Android 12 and lower versions, Android 13 and higher OS versions require the apps to request permission from users before sending notifications.

      • Android 12 or lower OS version devices - Apps are automatically granted permission to send notifications. This means that users do not have to give explicit permission for apps to send them notifications, and they are, by default, opted-in.
      • Android 13 or higher OS version devices - Push notification permission is a new feature in Android 13 that requires apps to request permission from users before they can send notifications. When a user installs an app on a device with Android 13 or higher, the app will not be able to send notifications until the user grants permission.

        Android has introduced runtime permission for users to grant the push permission

        • If the user grants permission, the app will be able to send notifications to the user.
        • If the user denies or ignores the permission, the app will not be able to send notifications to the user.

        The image illustrates how Push permissions are requested from users by an app (Trip Planner).

        Users can still go to the app's notification settings and change the permission, similar to the older Android versions. 

        		 A13_PushPermissionExample.png

        Here's how Push permissions work on various Android versions:

        Apps targeting Android 13 or higher Apps targeting Android 12 (compatibility mode)

        Apps that target Android 13 or higher have higher control over how this grant works.

        Here's how push notification permission works in Android 13 compatibility mode:

        • Apps can control when and where the prompt to grant permission is displayed to a user.
        • If the user grants permission, the app will be able to send notifications to the user.
        • If the user denies or ignores permission, the app will not be able to send notifications to the user.
        • If the user explicitly denies permission twice, the app will not be able to prompt the user again unless the user reinstalls the app

This permission is reset on every reinstall and clear data. This permission is retained on OS upgrades with one exception. When the user upgrades the device from Android 12 to Android 13

  • If the app did not have permission in Android 12 then after upgrading to Android 13 the app will not be able to send notifications until the user grants permission.
  • If the app had permission in Android 12 then after upgrading to Android 13 the app will be able to send notifications via a temporary grant which remains till the user opens the app for the first time after the upgrade. After the user opens the app, the permission resets, and the app will not be able to send notifications until the user grants permission.

Tracking Push Permissions

To enable Android to push notification Opt-in/Opt-out tracking, upgrade to MoEngage Core SDK version 12.3.01 and above. MoEngage SDK tracks the device's opt-in status by default. The opt-in status of the user’s devices will be can be tracked by the “Reachability Push Android” user attribute.

Reachability Push Android attribute value Reachability Description
202 - Not reachable due to Opt-out

This is the reachability value for any user who has opted out of receiving push notifications on all of their Android devices eligible for Push.


These users are no longer considered reachable and will not be targeted for campaigns. 
201 - Reachable and opted in This is the reachability value for any user who has opted in to receive push notifications on at least one of their Android devices.
200 - Reachable and opt-in status unknown This is the reachability value for users whose opt-in/opt-out preferences are not being tracked because these users are on the older SDK version. These users will be considered reachable and will be attempted for sending push notifications, but some of these users may be opted-out and will not be able to see notifications.

Opt-in/opt-out tracking is supported on MoEngage Core SDK version 12.3.01 and above.

You can query the Reachability Push Android attribute using a segmentation query to get counts of each of these users independently bu navigating to Segment -> Create Segment on the MoEngage Dashboard.

Tracking Opt-in rate of Android 13 users

Since the users have multiple devices, data for a specific OS version is not available.

The steps to track the Opt-in rate for users who are active on your app in the last 60 days are described below.

Reachability

      1. Navigate to Analytics -> Behavior on the MoEngage Dashboard,
      2. In the Events & filters section, select users who did an App/Site Opened event and whose OS version is 33, as shown below.
      3. In the Filter Users section, select the Filter users by option.
      4. Select the filter condition for the User property Reachability Push Android as in the following [201-Reachable and opted in,  202- Reachable but opted out].
      5. In the Behavior Options, choose the Analysis type as Unique users, Compare by as Reachability Push Android, and the Duration as last 2 months.
      6. Select the Pie Chart visualization in the Behavior Chart section. A sample image for the filter conditions chosen is shown below. The percentage of users with 201 as the ratio should give you the Opt-in rate for Android 13 users only. You can modify the query to get the opt-in rates for users on other OS versions.PieChart.png

Improving Opt-in Rates

We highly recommend that you target Android 13 or higher as soon as possible to benefit from the additional control and flexibility of this feature. If you continue to target 12L (API level 32) or lower, you lose some flexibility with requesting permission in the context of your app's functionality.

Opt-in Methods

The following are the various methods to obtain opt-ins from users:

Two Step Opt-in One Step Opt-in Self Handled Opt-in


Screenshot
A double opt-in or a two-step opt-in involves asking the user's permission in two steps. You set the context first in the first step and then take the user to the notification settings to enable push notifications from your app. The prerequisites and campaign setup for the two-step opt-in are discussed below.

Prerequisite for two-step opt-in

Integrate In-app notifications in Moengage SDK 12.6.00 and above and InApp version 6.5.0 or above, refer to the release notes for compatible version of the core SDK.

Pre-permission messages

Using In-app notifications, you can create pre-permission messages that can give the context to the user on why they should allow Push notifications for your app. Since you cannot trigger the Android native push prompt if the user explicitly denies permission twice, this method also helps you avoid showing the Android native push prompt unnecessarily, and you can reach out to the user again.

 

Campaign setup for showing the two-step opt-in prompt

Actions

  • Request notification permission
    If the user is eligible, this action triggers the Android native notification permission. If the user is not eligible because they have already declined the prompt multiple times or are on a lower OS version, they will be redirected to the application notification settings screen where the user can manage notification permission
  • Navigate to Notification Settings
    This action takes the user to the application notification settings screen, where the user can manage notification permission

Segmentation

Unless there is a specific use case to filter out a segment of users, we recommend using “All users” as the segmentation condition. Moegnage automatically manages the following cases:

  • Irrelevant users
    For In-app notifications that contain any of the above actions, Moengage will automatically filter out irrelevant users e.g. 
      • Users who are already opted-in
      • Users who are on older SDK version where Opt-in permissions actions is not supported
  • Android 12 or lower users
    These actions automatically select the right behavior for opted-out users based on the OS version. Android 12 or lower users would be taken to the application notification settings screen, where the user can manage notification permission

Priority

Campaigns with the above actions are automatically set to Critical-functional priority, which prioritizes them over other campaigns with the same trigger condition

Minimum delay

You can choose to add a minimum delay to nudge the users every few days instead of asking them for permission in every session

Recommended Strategies

You can employ any of the methods mentioned below to request permission to send Push notifications to users. Here are a few recommended strategies that you can implement to get the optimal number of users for Push notifications.

Strategy Who is this meant for?

How to implement it?

 Insights from early data
Usecase Only For apps that use Push notifications for only functional use-cases for users who opt-in. 
  • The user taps an "alert bell" button.
  • The user chooses to follow someone's social media account.
  • The user submits an order for food delivery.
 You can use the use-case-based method described above to implement this strategy. For more details, refer to Implementation Details. We observed that this will lead to a low opt-in rate because you’re only reaching out to the user who performs the use case actions.
Conservative For apps where most users are sensitive about giving permissions and require a rationale for opt-in in.

You can use:

  • A conservative First opt-in method for first-time users
  • Follow-up method to capture any users who did not accept in the first attempt
  • Use-case method for functional users

For more details, refer to Implementation Details.

 We observed that 30-60% of users accept push prompts in the first session with or without a rationale.
Balanced

For apps where most users are not sensitive about permissions. 

With this flow, you will get a

  • direct prompt on the first install 
  • sporadic follow-up two-step campaigns.

You can use:

  • A balanced First opt-in method for first-time users with a direct prompt
  • Follow-up method to capture any users who did not accept in the first attempt
  • Use-case method for functional users

For more details, refer to Implementation Details.

 We observed that 30-60% of users accept push prompts in the first session with or without a rationale.
Aggressive

For apps that rely heavily on Push notifications as an engagement channel. This flow attempts to show a Push prompt on every app open till it is blocked by the system. 

You can use:

  • A balanced First opt-in method for first-time users with a direct prompt
  • Follow-up method to capture any users who did not accept in the first attempt
  • Use-case method for functional users

For more details, refer to Implementation Details.

We observed that this gives the highest opt-in rate for some apps. However, this has a tendency to annoy users leading to uninstalls, and follow-up campaigns have poor performance because the user has to go to settings to give push permission

Implementation Details

First permission method - opt-in or permission request sent to the user the very first time they log in. Based on the strategy of your choice (refer to the table below for details), the manner in which you seek the first permission from the users will differ, as described below.

  • Conservative - Uses a two-step opt-in method. Create an in-app campaign with the segmentation criteria as All users, trigger the campaign only when users are on the Home screen, and set the maximum number of times the campaign can be shown to a user as one
  • Balanced - Uses a one-step opt-in method. Create an in-app campaign with the trigger event as the first app open, install, re-install, or clear data. Display the prompt to the user once, and if the user denies/ignores it, do not send any further follow-up messages
  • Aggressive - Uses a self-handled opt-in method to trigger notifications requesting push permission directly on every app open. In this approach, the notification prompt is displayed till the user clicks on “Don’t allow” twice.

Follow-up method -

Follow-up In-app notifications are sent as a nudge for users to grant Push permission or opt-in to receive Push notifications from the app. The follow-up method requires you to space out a two-step opt-in campaign regularly by setting a minimum delay between campaigns to a few days. You can set up the campaign by adding the Push notification to a navigable screen. Once the user clicks on the notification, you could trigger a single-step opt-in Push notification. Follow-up campaigns could have the following conditions:

  • Segmentation - All users

  • Trigger - Homepage screen

  • Minimum delay between 2 campaigns - 10 days 

Use case-based - a trigger-based two-step opt-in campaign. For example, you could set up an in-app campaign that is triggered on certain events such as the “Checkout complete” event, Thank-you screen, Upcoming events screen, and “Subscribed to program”. You can select the event trigger based on the event of your choice and add the segmentation criteria as All users.

Similar Use Cases
Was this article helpful?
1 out of 2 found this helpful

How can we improve this article?