Earning push permission back

A quarterly review that goes like this is common. Push sends are up year on year. Push-driven sessions are flat. Push-driven revenue is slightly down. Somebody proposes sending more.

The number nobody put on the slide is reach: the share of installed users who can actually receive a notification. In the programmes we audit it has usually been falling for several quarters, quietly, because the dashboard reports sends and opens rather than the denominator underneath them.

This matters more than the equivalent decline on email, because push permission does not come back on its own. There is no re-permission campaign, no second prompt, no clever subject line that fixes it. Once someone turns notifications off, the operating system stops asking on your behalf, and the only route back runs through the app itself.

Reach is the number that fell, and sends hid it

Start by reconstructing the denominator. For each week, take installed users who opened the app at least once in the period, and split them three ways: permission granted and reachable, permission never asked, permission denied or revoked.

Those three groups need different work and they are usually reported as one. A programme with a large "never asked" group has an onboarding problem. A programme with a large "revoked" group has a content and frequency problem. Treating them the same way produces a fix aimed at the wrong half of the audience.

Then add a fourth line that matters more than the other three: reachable users who have not opened a push notification in ninety days. Technically reachable, practically gone. They are counted in every reach figure and they respond to nothing, which makes every rate you calculate look worse than it is and every volume look better.

Report those four numbers weekly, alongside sends. When reach is on the same chart as volume, the conversation about sending more tends to end without an argument.

Opting out is a verdict on your last ten notifications

People do not disable notifications because they dislike the app. They disable them because of a specific recent experience. In our experience it is nearly always one of four things.

• A notification at an unreasonable hour, because the send window followed a marketing calendar rather than a local time zone.
• Several in one day, usually from different systems that did not know about each other.
• A promotional message dressed as an operational one, where the notification implied something had happened to their account and it had not.
• A notification with nothing behind it, opening to a generic home screen rather than to the thing it mentioned.

The fourth is the most damaging and the least discussed. A notification is a promise about what is on the other side of the tap. Break that promise twice and the permission is gone, regardless of how good the copy was.

All four are preventable at build time. None is fixable afterwards, which is why prevention work on the remaining permissioned base is a better investment than any recovery campaign.

There is no second prompt, so the route back is in-app and email

The mechanics are worth stating plainly, because they shape the whole strategy. On both major platforms, the system permission prompt is a one-time opportunity. Once a person declines, or turns notifications off later, the app cannot ask again. It can only direct them to the settings screen and hope.

So a recovery journey has exactly two entry points. The first is the app itself, through an in-app message shown to someone who is already there. The second is email, which can bring someone back to the app where the in-app message can run.

That is a narrow route and it demands a high bar. Do not ask on the first screen after launch, and do not ask in the abstract. The ask has to be attached to a moment where a notification is obviously the right mechanism for something the person already wants.

Good moments look like this. A person places an order and wants to know when it ships. A person saves an item that is out of stock. A person starts something they will come back to. In each case the notification is the delivery mechanism for a thing they just asked for, and the request reads as a service rather than as a favour to marketing.

The wording follows from that. Name the specific notification the permission enables, not the category of notifications in general. "Tell me when this is back" works. "Enable notifications to stay up to date" is what people are declining.

For the group that has revoked permission at the system level, the in-app message has to do something more awkward: explain that the switch lives in the device settings and take them there directly. Expect a low completion rate and set expectations accordingly. This is a slow rebuild, measured over quarters.

Give the permission a job before you ask for it

The pattern that works is to make the permission request the second step of a feature, never the first step of onboarding.

Build at least one notification type that is unambiguously a user request: a back-in-stock alert, a price watch, a booking reminder, a delivery update. Let people opt into that specific thing. Ask for the system permission at that moment, on the back of their action.

Then honour the narrow scope for long enough that the permission is worth having. A person who granted permission for delivery updates and receives a weekend sale notification the following Saturday has learned that granting permission means something different from what they were told. The revocation is usually immediate and it is deserved.

Once someone has held a permission for a while and engaged with it, a broader ask becomes reasonable, and it can be made in-app where there is room to explain. That sequencing is the whole method: narrow, honoured, then widened with consent.

Two supporting disciplines make it hold. First, cap across channels rather than within them, since a person receiving push, email and SMS from three systems experiences one programme and not three. The rules we use for that sit in the piece on choosing between email, push and SMS, and frequency capping only works when it is evaluated centrally at send time.

Second, price the channel honestly. Push looks free, which is exactly why it gets overused, but the real cost is the permission it consumes. Treating that permission as a depleting asset with a replacement cost, as we argued when recosting the messaging mix, changes which messages clear the bar.

Measure the rebuild over quarters, not campaigns

Set the target as permissioned reach among monthly active users, reported quarterly. It moves slowly and it is the only figure that reflects whether the programme is accumulating or spending permission.

Alongside it, track the share of permissioned users who engaged with at least one notification in ninety days. A reach figure that grows while engagement falls means you are collecting permissions that will be revoked later.

Watch churn by permission state as well, and read it carefully. Permissioned users usually retain better, and the causal direction is mostly the other way round: engaged people grant permission. Use the comparison to spot a sudden divergence, not to claim that notifications caused the retention.

Pick one user-requested notification type your app does not yet offer, build it, and move the permission prompt onto the back of it. That single change does more for reach than any rewrite of the copy in the existing prompt.