Reach Users with Notification Permission Disabled

Best Practices for Reaching Users with Notification Permission Disabled

When users disable app notification permission, normal notifications may be delivered to the device but not displayed in the notification tray. Continuing to rely only on notification delivery can create a gap where the server shows delivery success but the user never sees the message. A safer approach is to identify notification permission status first, then choose in-app reminders, SMS fallback, in-app channels, or permission guidance based on message importance.

This guide helps you design a low-disturbance, fallback-ready, and traceable reach strategy for users who have disabled notification permission.

Scenario Selection

Scenario	Recommended Strategy
Strongly related notifications such as orders, transactions, account security, and logistics exceptions	Send push first and enable in-app reminders; use SMS fallback if the message is not delivered in time
The user is currently using the app	Use in-app reminders, popups, or other in-app reach methods
General campaigns and content recommendations	Do not force fallback; prefer in-app messages, inbox messages, or wait until the user is active again
Users have disabled notification permission for a long time	Explain the value of notifications at appropriate business moments and guide users to enable permission
Users have disabled permission and have been inactive for a long time	Reduce push frequency and avoid continuous disturbance across multiple channels

Core Principles

Disabled notification permission does not mean users cannot be reached, but the reach method should respect their current state.
Strongly related and time-sensitive messages can use SMS fallback. General operational messages should not use SMS fallback by default.
Permission guidance should appear when users understand the value, such as after subscribing to reminders, tracking orders, or configuring account security.
Do not repeatedly show permission prompts, as this can increase user resistance.
All fallback reach should be covered by frequency control, state validation, and effect monitoring.

Recommended Flow

Integrate the Jiguang Push SDK on the client, and report Registration ID, notification permission status, mobile-number binding status, and other basic information to your own server.
Continuously monitor metrics such as notifications enabled, notifications disabled, newly enabled, and newly disabled through the Jiguang console or your data system.
When sending important notifications, enable Jiguang in-app enhanced reminders (inapp_message) for users who have disabled notification permission but are still active in the app.
For must-reach business scenarios, configure Jiguang SMS fallback so Jiguang can use SMS when push is not delivered in time.
For general operational messages, use frequency control, segmentation, and acceptable time windows to reduce disturbance.
Validate the latest state on business pages or landing pages so delayed reach does not show expired content.
Review reach results through Push Records, Report API, Callback API, and notification permission statistics.

User Identification and Segmentation

Segment users by notification permission and activity status:

User Status	Reach Recommendation
Notification permission enabled, recently active	Use normal notification reach, and optimize with frequency control and content quality
Notification permission disabled, recently active	Use in-app reminders, in-app popups, message center, and value-based permission guidance
Notification permission disabled, recently inactive	Use SMS fallback only for strongly related messages; reduce frequency for general operational messages
Notification permission disabled and guidance ignored multiple times	Pause frequent permission popups and use lightweight guidance at key business moments
Notification permission re-enabled	Resume normal notification strategy and monitor click rate and disable-rate changes

In-App Enhanced Reminders (`inapp_message`)

In-app reminders are suitable when users have disabled notification permission but are still using the app. When sending a notification, you can use an in-app message to remind target users whose notification permission is disabled.

Recommendations:

Android SDK must be 3.9.0 or later, and iOS SDK must be 3.4.0 or later.
In-app reminders are more suitable for service reminders, to-dos, transaction progress, campaign confirmations, and content that users can understand in the current context.
Reminder content should stay consistent with the original notification to avoid being perceived as a duplicate message.
After users click an in-app reminder, open the corresponding business page and validate the latest state.
General operational messages should still follow frequency control and acceptable time windows.

SMS Fallback

SMS fallback is suitable for must-reach scenarios. If the app cannot receive a push message within a period of time, or the user has disabled notification permission, is offline, is blocked from running in the background, or experiences message delay, SMS can be used as a fallback channel.

Recommended scenarios:

Verification codes, transaction reminders, account security, order exceptions, logistics exceptions, and other must-reach content.
The user did not receive the push in time, but the business still requires final reach.
Push is used first, and SMS is used as fallback to control SMS cost.

Configuration recommendations:

Enable SMS service first and complete mobile-number binding for users.
Configure SMS fallback parameters when sending push messages from the server, and set a reasonable delay.
Match the delay with business urgency to avoid push and SMS arriving almost at the same time.
SMS content must comply with template, signature, and compliance requirements.
Use SMS fallback cautiously for marketing messages to avoid complaints and opt-outs.

Permission Guidance

The goal of permission guidance is not to make every user immediately enable notification permission. It is to help users understand the value of enabling notifications when they need a specific type of reminder.

Recommended timing:

After users subscribe to reminders, track logistics, create to-dos, or set price alerts.
When users missed an important reminder and return to the app.
When users enter the message center, notification settings page, or account security page.
After users complete high-value actions such as placing an order, paying, booking, or signing up.

Design recommendations:

Explain the value first, then guide users to settings, for example: "Enable notifications to receive order and security reminders in time."
Do not show prompts frequently at cold start or repeatedly interrupt user actions.
Reduce guidance frequency for users who have rejected it multiple times.
On Android, combine notification permission detection with the ability to jump to the system settings page.
On iOS and HarmonyOS, follow system permission request and settings-page rules.

Server-Side Strategy

Important Messages

Use system-message or service-message classification, and configure vendor classification fields according to vendor rules.
Set a proper time_to_live to avoid message loss during short offline periods.
Enable in-app reminders for users who have disabled notification permission but are active in the app.
Configure SMS fallback for users who do not receive the push in time.
Integrate callbacks and reports to observe delivery, non-delivery, clicks, and SMS fallback triggers.

Operational Messages

Use operational-message classification. Do not disguise them as system messages.
Apply daily per-device frequency control and acceptable time windows.
For users with notification permission disabled, prefer in-app messages, inbox messages, message center, or other low-disturbance methods.
Do not use SMS fallback for general operational messages by default.
Continuously adjust sending frequency based on notification disable rate, click rate, uninstall rate, and complaint feedback.

Troubleshooting

When users report that they cannot receive notifications, troubleshoot in this order:

Use Device Query to confirm whether the Registration ID is valid and belongs to the current AppKey.
Check whether device notification permission is disabled.
Use Message Query to view the lifecycle for Message ID and Registration ID.
If the push is delivered but not displayed, first check notification permission, notification channel, system restrictions, and foreground display logic.
If in-app reminders are enabled, check whether the target user meets display conditions and whether the SDK version supports the feature.
If SMS fallback is configured, check whether the mobile number is bound, whether the SMS template is approved, and whether the fallback delay is reasonable.
View notification permission trends in push statistics to determine whether it is a single-device issue or an overall increase in disabled permissions.

Data Monitoring

Monitor the following metrics continuously:

Users with notifications enabled, users with notifications disabled, newly enabled, and newly disabled.
Notification delivery rate, display rate, and click rate.
In-app reminder delivery, display, and click performance.
SMS fallback trigger volume, SMS delivery volume, and conversion results.
Notification disable rate, uninstall rate, complaints, or opt-out feedback.
Permission enable rate across different guidance timing, copy, and scenarios.

Common Misunderstandings

Misunderstanding 1: Increase Sending Volume After Notification Permission Is Disabled

When notification permission is disabled, increasing sending volume usually does not improve notification-tray display. It increases invalid requests and user disturbance. Use in-app reminders, SMS fallback, or value-based permission guidance instead.

Misunderstanding 2: Use SMS Fallback for All Users with Permission Disabled

SMS fallback is suitable for must-reach business scenarios, not general operational content. Marketing SMS also requires user authorization, template compliance, opt-out handling, and complaint-risk control.

Misunderstanding 3: The Earlier the Permission Prompt Appears, the Better

Requesting permission before users understand the value can easily lead to rejection. It is better to explain the value and guide users after they subscribe, place an order, follow something, or make a booking.

Misunderstanding 4: Only Focus on Permission Enable Rate

A higher permission enable rate does not always mean better user experience. Also monitor click rate, disable rate, uninstall rate, complaints, and long-term activity.