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.

Tracking Push Permission Status at a User Level

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.

Tracking Changes in Push Permission at a User Level

The following are the events for Android Push permission changes:

Name Description Platform
Subscribed to Push Tracked when a user subscribes to Push Notifications. Android
Unsubscribed to Push

Tracked when a user changes push permission for a device from Subscribed to Unsubscribed

Note: This event will not be generated for devices where the permission is denied by default.

Android

 

info

Information

These events will be generated only when the Opt-in status of a device changes or a user explicitly confirms the permission. The default state of a device will not trigger a Subscribed/unsubscribed to push event.

Example - For Android 12 and below devices, the device is opted-in by default. This will not trigger a Subscribed to push event. For Android 13, the user is opted out by default and it will not trigger an Unsubscribed to push event. However, if you request push permission to the user via the native prompt and the user blocks permission, you will get an Unsubscribed to push event.

Tracking Push Permission Trends Over Time

The Reachability Dashboard at MoEngage shows you the reachability trends of all users who opted in to receive your Push notifications and those who have not. You can access the Reachability Dashboard by navigating to Dashboards > Reachability.

For more information, refer to Push Reachability 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 belowd.

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.
  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.

Aggressive Balanced Conservative Use Case Only
Target audience

Apps that rely heavily on Push notifications as an engagement channel.

Implementation

Use the following implementation:

  • First permission method: Refers to the opt-in or permission request that is sent to users the very first time they log in. Depending on the strategy you choose, the way you seek the first permission may differ.
    Use 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 until the user clicks Don’t allow twice.
  • Follow-up method: Follow-up in-app notifications are sent as a nudge to encourage users to grant push permission or opt-in to receive push notifications from the app. To use this method, you must space out a two-step opt-in campaign regularly with a few days delay between campaigns. You can set up the campaign by adding the push notification to a navigable screen. After the user clicks the notification, you can trigger a single-step opt-in push notification. The follow-up campaign should follow these conditions:
    • Segmentation: All users
    • Trigger: Homepage screen
    • Minimum delay between 2 campaigns: 10 days
  • Use case-based: This is 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.

For more details, refer to Implementation Details.

Insights from early data

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 must go to settings to give push permission.

Was this article helpful?
1 out of 6 found this helpful

How can we improve this article?