In-App Messaging Guidelines Template
Everyone says to cap message frequency across teams. Nobody measures the sum first, so the cap gets set without knowing what it changes.
Free download · No account needed
Every guide on in-app messaging arrives at the same conclusion: cap frequency centrally rather than per campaign, hold a priority order, and use one or two messages per session as a ceiling. That is correct and it is the second half of the job. The first half, which none of them mentions, is measuring what a user currently receives. Adopt a cap without that and nobody in the room knows whether it removes five per cent of your messages or sixty, which one loses the slot, or who is affected by it.
So this pack starts with a replay. Take every live message's trigger conditions and run them against ninety days of real event data, which produces messages per user per week. Read it at the percentiles and never at the mean. At the fictional Halberton the mean was 1.7 a week and the worst individual week was 17. One operations lead got eleven messages from six teams over three days, because she invited four teammates, connected an integration and crossed her plan limit. Three pairs fired off one event, seconds apart.
The inventory is a finding on its own: six teams believed 31 messages were live and the replay found 47. Then the cap comes out of your own engagement-by-position curve and arrives priced, which is what survives a room with six teams in it. Send the list of systems that can interrupt a user and your event data. What comes back is the distribution, then a standard the launch, release note and sunset messages all have to work inside.
What is in the pack
Message Register
The inventory rebuilt by replay rather than by asking teams what they ship. Owning team, delivery system, surface, trigger condition, audience, its own frequency rule, and whether it references any other message. That last column is almost always no on every row, which is the problem in one field.
Frequency Cap by User
Messages per user per rolling week at the percentiles, never the mean, with the worst individual week written out timestamp by timestamp. Plus what those users were doing, because high intent is what fires the triggers.
Engagement by Message
Engagement and two-second dismissal by where a message lands in the user's week, not by which message it is. This is what separates a badly written message from a well-written one in a bad slot, and it usually rescues several.
Frequency Policy
The cap, the curve the number came from, what it costs in suppressed volume against lost engaged actions, and which team absorbs the suppression. Also the arithmetic on why a per-session cap alone is not a cap, and the standing exceptions, since a notice about a defect somebody is already living with jumps the queue rather than waiting for a slot.
Messaging Standard
Surfaces ranked by what they cost the user, six priority bands, and what every message has to carry before it ships. The GOV.UK Design System reaches the same place from the other direction: show only the highest priority one when messages cannot be combined.
Copy Guidance, plus a weekly sweep
How the words work once a message has won its slot. Plus an automation that re-derives which messages are actually live, groups cap breaches by the system that bypassed the check, and flags any action-required message whose median position has slipped past third.
How it works
- 1
Send the systems, not the list
Every path that can put something in front of a user: the messaging tool, anything hardcoded in the product, marketing automation, surveys, billing, security. Plus ninety days of event data for the active base.
- 2
Triggers get replayed
River evaluates every message's trigger conditions against the real events, respecting each message's own frequency rule, and produces messages per user per week alongside an inventory that is usually larger than the one anybody had.
- 3
Percentiles and position
The distribution is read at the ninetieth and ninety-ninth rather than the mean, and engagement is split by where each message landed, which is how a queue problem stops being mistaken for a copy problem.
- 4
The cap arrives priced
Two or three candidate caps, each with suppressed volume, users affected, engaged actions lost, and the team that absorbs it. Then it runs weekly, because both the inventory and the distribution drift upward.
Frequently asked questions
Every guide already says to cap frequency across campaigns. What is different?
They all stop at recommending a number. None of them measures what a user currently receives, so nobody knows what the cap changes. That measurement is one replay of every trigger against real events. At Halberton it found a mean of 1.7 messages a week and a worst individual week of 17.
Why not just use one or two messages per session?
Multiply it out first. A ninetieth-percentile Halberton user had 3.1 sessions per working day, so 15.5 sessions a week, which makes a two-per-session cap a permission to send 31 a week. That is nearly double the worst case that already existed. The rolling window is the real cap.
How do you find messages nobody remembers shipping?
By replay rather than by asking. A request for everyone's campaigns returns the list people remember, which is short by exactly the messages causing trouble. Halberton's teams believed 31 were live and 47 were: sixteen hardcoded in the app or sitting in a lifecycle tool nobody had opened in fourteen months.
How do you convince six teams to give up their slot?
By pricing the cap rather than asserting it. Three a week at Halberton suppressed 18.7% of all volume and cost 3.2% of engaged actions, because the volume being cut sits where the fourth message engages at 6.1% and the sixth at 1.4%. Lifecycle and Growth absorbed 79% of it, stated up front.
Is a low-engagement message just badly written?
Usually not. Split its engagement by where it landed. Every message at Halberton performed three to seven times better in the first three positions, and the security notice engaged at 8.9% overall against 29.6% when it landed early. Rewriting that one would have achieved nothing at all.
What happens to a message that loses the slot?
It moves to an ambient surface with its original copy rather than being discarded. Halberton's inbox capacity report was the highest-engaging item in the entire register at 27.4%, and it interrupted nobody. Discarding is a legitimate choice for some messages, but it should be a stated one.
Are there rules we have to meet regardless of the cap?
Yes. WCAG success criterion 2.2.4 requires that interruptions can be postponed or suppressed by the user except in an emergency, so a modal with no clear way out fails an accessibility standard as well as annoying somebody. A dismissal that is not remembered is the same failure.
Find out what one user actually receives
Send every system that can interrupt a user and ninety days of event data. The first thing back is the distribution, and the worst week in it written out in full.
Count what one user gets