Notification Strategy
Deciding what deserves an interruption, and accepting the cost when it does not.
The problem it solves
Notifications are the fastest way to bring someone back and the fastest way to lose them. Teams ship them one feature at a time, and nobody owns the total volume landing on a real person.
Notification fatigue
Treat permission to interrupt as a budget rather than a switch. Each user grants a limited number of interruptions per week before they mute, disable, or uninstall. Every notification you send spends from that budget. Nothing tops it up except sending fewer and making the ones you send matter.
The three questions before any send
- 1Is this about something the user asked for, or something we want them to do? Say the answer out loud in the review.
- 2Does it decay? If it reads the same in four hours, it belongs in a digest.
- 3Who is it addressed to? A message naming this person can be pushed. A message about general activity usually cannot.
- 4What happens if we do not send it? If the honest answer is that the number goes down, that is a reason to cut it.
Then set a cap per user per day and enforce it centrally, above the feature teams. Without a cap, each team ships a reasonable notification and the user receives an unreasonable total. The cap forces the argument about priority to happen inside the company instead of inside the user's pocket.
Earns the interruption
- Someone is waiting on this person right now
- A thing they set up has finished or failed
- A deadline they chose is close
- A reminder at a time they picked
Spends the budget for nothing
- Activity somewhere in the product by people they do not know
- A feature announcement
- You have not opened us in three days
- Anything generated because a weekly number was soft
Mute is not the failure state you should optimise against. Silent tolerance is worse. A user who keeps notifications on and resents each one is churning slowly, and no dashboard shows it until they leave. Ask in research whether people feel good about your alerts, because opt-out rate will not tell you.
Give granular controls and make them findable. Per-type toggles, quiet hours, and a global frequency setting cost little and they convert a user who would have muted everything into one who keeps the channel you actually need.
Worked example
A cap in practice
Take a team that caps pushes at three a day. A slow day sends one. A busy day forces the ranking to choose, and the fourth item waits for the digest. Growth will point out that some sends are being dropped. The counter-argument is that the budget was going to run out either way, and a cap decides how it gets spent before the user does it for you.
When it fits
- The product carries genuinely time-sensitive events, like messages, bids, or job completions.
- You can rank a queue of candidate sends and drop the bottom of it.
- Users can set quiet hours and per-type preferences without hunting for them.
- One team owns total volume per user and can veto a feature team's send.
When it backfires
- Sends are triggered by your engagement numbers rather than by events. Users can tell the difference, and the reengagement push that lands on a Sunday night reads as desperation.
- Escalation is used as a tactic. Sending a second and third reminder because the first was ignored converts a soft no into a permanent block.
- Loss framing gets attached to routine alerts. Warning someone they are about to lose something in order to make them open the app is manufactured anxiety, whatever the copy says.
- Volume grows feature by feature with nobody measuring the total. By the time opt-out rates move, the users who tolerate it silently are already half gone.
Products using it
Slack
Defaults mobile push to mentions and direct messages, with per-channel overrides, a notification schedule, and a global do-not-disturb.
iOS
Offers scheduled summary delivery, which lets a user demote any app's notifications from immediate to batched without turning them off.
Headspace
Asks the user to pick a reminder time during setup, so the daily interruption is one the user scheduled.
The psychology under it
The takeaway
Permission to interrupt is a budget that only shrinks, so cap the total centrally and make every send answer to someone other than the team that wanted it.
Finished the teardown? Bank it and the day counts toward your run.