Operational Push Frequency Control and User Disturbance

Operational Push Frequency Control and User Disturbance Best Practices

The goal of operational push is not to send as many messages as possible. It is to send valuable content to the right users, at the right time, with the right frequency. Excessive push can cause users to disable notifications, uninstall the app, trigger vendor throttling, reduce click rates, and consume resources that should be reserved for important messages.

This guide combines JPush frequency control, vendor operational-message policies, message classification, delivery strategies, and data monitoring to help you build a safer operational push governance process.

Core Principles

Classify messages first: orders, transactions, and account security are important messages; campaigns, recommendations, content updates, and platform announcements are usually operational messages.
Operational messages should be subject to frequency control by default. Whether important messages are restricted should be evaluated separately based on business risk.
Android vendor operational messages are affected by vendor quota, per-device limits, QPS, and JPush frequency control.
Do not set marketing content as system messages, as this may cause vendor review failure, channel restrictions, or user complaints.
Frequency control is not only "N messages per day". It should also include acceptable time windows, user segmentation, content deduplication, priority, and opt-out mechanisms.

What to Control

Control Target	Purpose	Recommended Configuration
Daily count per device	Control how many operational pushes a user receives each day	Enable per-device delivery limit in console frequency control
Acceptable time window	Avoid disturbing users late at night or at inappropriate times	Configure user-acceptable push time windows; messages outside the window are discarded
System message restriction	Avoid affecting important notifications	Restrict operational messages by default; decide separately whether to restrict system messages
Vendor operational-message policy	Adapt to Android vendor per-user limits	Set vendor operational-message limits less than or equal to the JPush per-device push limit
Content deduplication	Avoid repeatedly sending the same content to the same user	Use business-side deduplication, mutually exclusive segments, and push-record review
Audience filtering	Improve relevance and reduce invalid reach	Use tags, aliases, user attributes, segmentation, and A/B testing

Recommended Governance Flow

Classify pushes into important notifications, operational notifications, test notifications, and silent notifications.
Set a unified daily per-device limit and acceptable time window for operational notifications.
Configure Android vendor operational-message policies according to vendor rules.
When sending from the server, explicitly set options.classification: use 0 for operational messages and 1 for system messages.
Establish priorities for operational campaigns. Low-priority messages should be dropped when frequency limits are exceeded.
Use tags, user attributes, segmentation, and A/B testing to reduce irrelevant reach.
Monitor delivery rate, click rate, and non-delivery changes through Push Records, Report API, and Callback API.

Console Frequency Control

Go to Push Settings > Frequency Control to configure the following capabilities.

Push Frequency

After enabling this setting, you can set the daily push delivery limit per device. Each user can receive at most N messages per day. Messages exceeding the limit are discarded directly.

Recommendations:

Operational messages must be included in daily per-device frequency control.
Important messages can be excluded based on business risk, but system-message classification should not be abused.
When multiple operational campaigns run at the same time, prioritize them on the business side first so low-value campaigns do not consume quota for high-value campaigns.

Acceptable Time Window

After enabling this setting, you can configure when users can receive pushes. Messages outside the specified time window are discarded directly.

Recommendations:

Avoid night and early-morning periods by default.
Design separate exception strategies for highly time-sensitive messages such as finance, transaction, security, and logistics exceptions.
For users across time zones, send based on the user's location or business region.

Restricted Message Type

After frequency control is enabled, it applies to operational messages by default. You can choose whether to restrict system messages. Developers must actively specify the message type when sending pushes. If not specified, the default is operational message.

API fields:

options.classification=0: operational message, default value.
options.classification=1: system message.

JPush does not judge or correct the message type specified by developers. Make sure the field value matches the actual business content.

Android Vendor Operational-Message Policy

Android vendor channels usually apply stricter restrictions to operational messages, such as Xiaomi public messages, OPPO public messages, vivo operational messages, and Huawei/Honor information and marketing messages. We recommend enabling vendor operational-message policies in the console and setting the daily operational-message limit per user.

Key rules:

Vendor operational-message policies and JPush per-device frequency control can both take effect.
The vendor operational-message limit should be less than or equal to the JPush per-device push limit.
When one user's daily operational-message count exceeds the vendor limit, JPush uses the JPush channel to deliver the message where possible.
Vendor quota and QPS limits cannot be bypassed, even for VIP users.
Operational-message per-device limits, total quota, and QPS rules for OPPO, vivo, Xiaomi, and other vendors may vary by app category.

Operational Push Tiers

Manage operational messages by value and urgency:

Tier	Examples	Recommended Strategy
High-value operation	Membership benefits expiring, subscribed content updates, reminders strongly related to recent user behavior	Precise segmentation, low frequency, high-quality copy and click path
Regular operation	Content recommendations, campaign reminders, platform announcements	Daily frequency control, A/B testing, and batched sending
Low-value operation	Broad promotions, low-relevance recommendations, repeated exposure	Lower frequency; prefer in-app messages, inbox messages, or no push
Test message	Internal verification, gray release checks	Use test devices or test identifiers to avoid affecting real users and production data

Server-Side Sending Recommendations

Specify Message Classification

Operational message example:

{ "platform": "android", "audience": { "tag": ["active_user"] }, "notification": { "android": { "alert": "This week's selected content has been updated", "title": "Content recommendation" } }, "options": { "classification": 0, "time_to_live": 3600 } }

          {
  "platform": "android",
  "audience": {
    "tag": ["active_user"]
  },
  "notification": {
    "android": {
      "alert": "This week's selected content has been updated",
      "title": "Content recommendation"
    }
  },
  "options": {
    "classification": 0,
    "time_to_live": 3600
  }
}

This code block is shown in the floating window

Control Offline Retention

Operational messages usually should not have a long offline retention time:

For highly time-sensitive campaigns, set a short time_to_live to avoid reaching users after the campaign ends.
For regular content recommendations, set several hours to one day based on content validity.
For expired campaigns, the landing page must validate campaign status.

Batch and Stagger Sends

Send large-scale operational pushes in batches to avoid reaching all users at the same time.
For vendor channels, monitor vendor QPS and quota changes.
For marketing messages that are not time-sensitive, stagger sends according to business strategy.

User Disturbance Control

Before sending, check whether the user has been active recently, is likely interested in the content, and has already received similar messages.
For the same campaign, avoid repeatedly hitting the same user across multiple tags or audience packages.
Exclude users who have already clicked, converted, or completed the task from follow-up pushes.
Reduce frequency for users who rarely click, disable notifications, or show uninstall risk.
Use in-app messages, inbox messages, SMS fallback, or other channels for different priority levels instead of putting everything in the notification tray.
For continuously updated status messages, use message override to reduce notification stacking.

Data Monitoring

Track the following by campaign and audience:

Sent count, delivered count, clicks, delivery rate, and click rate.
Android vendor-channel accepted count and delivered count.
Ratio changes between JPush channel and vendor channels.
Frequency-control discard, insufficient vendor quota, QPS queueing, and related exceptions.
Notification permission disable rate, uninstall rate, complaints, or opt-out feedback.
A/B test results across copy, send time, and audience strategy.

Common Misunderstandings

Misunderstanding 1: JPush Frequency Control Alone Is Enough

Android vendor operational messages are also subject to vendor-side per-device limits, total quota, and QPS limits.

Misunderstanding 2: Since System Messages Are Less Restricted, All Operational Messages Should Be Sent as System Messages

System messages usually have clear business boundaries. Misusing system-message classification for marketing, campaign, or recommendation content can affect vendor review and channel stability.

Misunderstanding 3: Send Another Message After Frequency Control Blocks One

The purpose of frequency control is to reduce disturbance. Sending again through another channel after a message exceeds frequency limits can worsen user experience. Unless the message is important, it should be dropped.