Practice 03.02 · Push notifications

Set frequency limits instead of increasing volume

Users experience every message as one stream, even when different teams send them. Build a shared calendar and rules that prevent repetition and competing pushes.

Practice outcomeA one-page frequency policy with message types, priorities, a shared limit, cooldowns, exceptions, and an owner.

75 minutes for the first setup

In plain language

The user has one attention budget for all teams

Communications, product, and support may each find their messages useful, but the user receives them all in one feed. A frequency policy decides how many messages are allowed, which matter more, and when the next push must be canceled.

What you will need

Shared listEvery service, product, and content message one user can receive in seven days.

HistoryA send log for test profiles or a sample of real users, with the date, scenario, and result.

OwnerOne person who resolves conflicts between teams and regularly reviews opt-outs and complaints.

Terms in plain language

When to use it

Users get several messages a day, teams launch campaigns independently, and notification opt-outs or complaints keep growing.

In plain language

Where to see the real load

Do not count only planned campaigns. Include automatic triggers and service statuses fired by events.

Send calendar

Collect manual campaigns and automated scenarios from every team into one weekly table.

If there is no shared tool, ask each owner to export the name, audience, moment, and maximum number of sends.

User history

Find the profiles that receive the most messages and reconstruct their feed hour by hour.

Create three test profiles that match several scenarios at once and watch them for a week.

Negative signals

Put notification opt-outs, complaints, uninstalls, and support requests next to the number of pushes per user.

If there is no direct link, compare high-load and normal weeks, and add an event for the notification permission being turned off.

Set up a safe frequency

Collect every scenario

Record manual campaigns, automatic triggers, and service statuses. For each, note the maximum frequency per user.

Where to do it: In the shared communications calendar.
What the result looks like: Verification — up to 2 reminders; new material — 2 a week; the weekly digest — 1 a week.

Rank by user value

Service statuses and security outrank content reasons. An internal business goal must not raise priority automatically.

Where to do it: In the policy's priority column.
What the result looks like: The transaction status goes out, and the general digest that day is canceled.

Set a shared cap

Limit the total number of optional messages and the minimum pause between them. The cap applies on top of each team's own rules.

Where to do it: In the communication platform settings.
What the result looks like: At most one optional push per 24 hours and three per seven days.

Add mutual exclusions

After a useful action, a recent visit, or a similar message, the user must leave competing scenarios.

Where to do it: In the segment conditions before the send.
What the result looks like: Finished the lesson → drop the reminder; got a personal analysis → drop the general digest for 24 hours.

Review the most loaded profiles

Once a week, look beyond the average at the users with the most messages. That is where the rules clash most often.

Where to do it: In the messages-per-user report.
What the result looks like: The average is 1.8 pushes, but 4% of users got 7+; an overlap of two triggers was found.

Practical examples

A service status cancels general content

The user received an important transaction status. The general digest that day is canceled, and the next optional push is possible only after 24 hours.

The average hid an overloaded group

The average load was 1.8 pushes a week, but 4% of users were getting 7+. After mutual exclusions the shared cap holds and repeat complaints decline.

The finished artifact

One-page frequency policy

The rules must be applied before every send — not sit in a document as a recommendation.

Type	Priority	Limit	Pause and exceptions
Security and status	1 · mandatory	Per event	Not blocked by the promo cap
Unfinished action	2 · useful	1 per scenario	Canceled after completion
Personal interest	3 · useful	Up to 2 a week	24-hour pause after another push
General content	4 · optional	1 a week	Not sent to recently active users
All optional together	Shared cap	At most 3 a week	At most 1 per 24 hours

When messages conflict, the one with the higher user value survives. Once a week the rules owner reviews the ten most loaded profiles and the negative signals.

Do not compensate for a weak scenario with frequency

If a message gives no reason to return, sending it again will not make it more useful. Fix the reason, the copy, or the route first.

Frequency checklist

The policy is ready only when the rules can be tested on a specific user profile.

One list holds the manual, triggered, and service messages of every team. Messages are prioritized by their value to the user. There is a shared cap and a minimum pause between optional pushes. Users who finished the action, were recently active, or got a similar message are excluded. An owner is assigned for the weekly review of load, opt-outs, and complaints.

How to know the frequency became safer

Load

The share of users receiving more than the shared cap per day and week is falling.

Trust

Notification opt-outs and complaints do not grow while useful scenarios keep running.

Value

Target actions per message hold or grow after competing sends are removed.

When two scenarios collide, send the one with the higher value for the user — not the higher internal business goal.