# Set frequency limits instead of increasing volume

- **Canonical URL:** https://playbook.affpartners.io/en/practices/push-frequency/index.html
- **Markdown version:** https://playbook.affpartners.io/en/practices/push-frequency/index.md
- **Module:** Push notifications
- **Time:** 75 minutes for the first setup

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.

## Outcome

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

## 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 list:** Every service, product, and content message one user can receive in seven days.
- **History:** A send log for test profiles or a sample of real users, with the date, scenario, and result.
- **Owner:** One person who resolves conflicts between teams and regularly reviews opt-outs and complaints.

## Terms in plain language

- **Push notification — A short app message shown outside the app:** Definition: It appears on the device and can return a user to one specific useful action. It is sent only when the user has granted notification permission. Example: A message about a new item in a saved topic opens that item through a deep link.
- **Segment — Users sharing a behavior or characteristic:** Definition: A segment groups people by platform, market, interest, or action so the team does not send the same message to everyone. Example: Android users who started but did not complete registration in the past 24 hours.
- **Analytics event — A record of a specific user action:** Definition: The app sends an event when a user opens a screen, taps a button, or completes an action. Example: registration_started and registration_completed reveal how many people abandon registration.

## When to use it

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

## Where to see the real load

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

- **Send calendar**
  - **Source:** Collect manual campaigns and automated scenarios from every team into one weekly table.
  - **If access is unavailable:** If there is no shared tool, ask each owner to export the name, audience, moment, and maximum number of sends.
- **User history**
  - **Source:** Find the profiles that receive the most messages and reconstruct their feed hour by hour.
  - **If access is unavailable:** Create three test profiles that match several scenarios at once and watch them for a week.
- **Negative signals**
  - **Source:** Put notification opt-outs, complaints, uninstalls, and support requests next to the number of pushes per user.
  - **If access is unavailable:** 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

1. **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.
   - **Example:** Verification — up to 2 reminders; new material — 2 a week; the weekly digest — 1 a week.
2. **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.
   - **Example:** The transaction status goes out, and the general digest that day is canceled.
3. **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.
   - **Example:** At most one optional push per 24 hours and three per seven days.
4. **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.
   - **Example:** Finished the lesson → drop the reminder; got a personal analysis → drop the general digest for 24 hours.
5. **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.
   - **Example:** 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.

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

## Safety and constraints: 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.

## Key rule

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

---

- [HTML version](https://playbook.affpartners.io/en/practices/push-frequency/index.html)
- [All practices](https://playbook.affpartners.io/en/)