Ask for notification permission after the product has delivered value
Aliases: ask after value · notification opt-in timing · delayed notification prompt
What it is
Notification permission has no in-the-moment task anchor like "I am taking a photo," so at launch people cannot judge what will arrive later. Ask after the product has already delivered value in-app once: an order exists, a conversation has a reply, followed content has an update. This entry is only about when the authorization is requested. It is not about writing push copy, how many pushes per day, or how alerts are bundled—those are notification patterns, not this permission card.
Why it happens
The system notification switch is a master valve: on, and later interruptions of many kinds can enter; off, and the channel is often hard to reopen. Asking at launch demands that someone accept unknown interruption before they have seen a single useful message. Even a decent allow rate is polluted by "tap now, decide later," followed by a system-level shutoff or habitual ignore. Asking after value attaches the grant to a result that just happened—"tell me when this order changes"—so necessity comes from a feature just experienced, not from a brand promise. Unlike camera, notifications have no "this step cannot complete" pressure; asking early only burns the first-denial channel.
Studying it
Compare "request notification permission on first launch" with "request after a task that produced a result." Measure quality of the grant, not allow rate alone.
Independent variables: position of the ask relative to the first value event, whether that event matches the type of notification that will follow. Dependent variables: allow rate, share still on at the system layer after seven days, clicks on the first notification after the grant, uninstall or global shutoff attributed to notifications.
The lab never delivers real later pushes, so Allow is not tolerance for interruption. Product logs have to show retention and shutoff after the grant. Do not treat allow rate as success—high allow at launch and high shutoff three days later is a timing failure.
Where it stops holding
Time-critical tools (one-time codes, incoming calls, ticket drops) can ask right after the binding succeeds; they need not wait "several days." The ask should still follow the moment the person saw "this information will arrive as a notification." Enterprise device-management push is not this consumer authorization. An app with no account and no notifiable event yet should not demand notification permission on an empty state for growth.
Applying it
- Name one notifiable value event (order submitted, first human reply received) and hang the system notification permission request on that event's confirmation screen—not on launch or the end of registration.
- On that screen, first show the same information in-app, then ask whether to deliver later ones as notifications. People can take this instance and still refuse the grant.
- Before a value event, do not call the notification permission API, and do not use a full-screen gate that pretends the app cannot continue.
- Verify: the funnel from install to the notification permission dialog must pass through at least one value event. Sample the share still enabled seven days after Allow; if many are turned off in system Settings, move the ask later rather than decorating the dialog's adjectives.