What is priming for push?
Used in a sentence: Let's prime for push right after the first order is placed, when delivery updates actually mean something to the user.
How it works
On iOS, and on recent Android versions, an app must ask the operating system for permission to send notifications. Once a user declines that dialog, the app usually cannot show it again.
Priming adds a step before that dialog. The app shows its own screen, often a bottom sheet, explaining what notifications the user will get and why. If the user taps “Allow”, the app then triggers the system prompt. If they tap “Not now”, the system prompt is saved for later.
The priming screen is triggered by a relevant event, such as placing an order or setting a price alert, rather than on first launch.
Example
A stock trading app asks for notification permission on first launch and most users decline. The team moves the request. Now, when a user adds a stock to their watchlist, a bottom sheet appears: “Get an alert when this stock moves sharply.” Users who tap “Turn on alerts” see the system prompt. Users who skip it are asked again only after adding another stock.
Primed vs unprimed permission requests
| Primed request | Unprimed request | |
|---|---|---|
| When it appears | After a relevant action | Often on first launch |
| What the user sees first | The app’s own explanation | The generic system dialog |
| Cost of a “no” | System prompt is kept for later | Permission is usually lost for good |
Priming protects the one system prompt and spends it on users likely to say yes.
Best practices
- Trigger priming after an action that makes notifications useful, not on the first screen.
- Describe concrete notifications, such as delivery status or price alerts, instead of vague promises.
- Give a visible “Not now” option and respect it with a cap on how often the screen returns.
- Track opt-in rate at both steps, priming accept and system accept, to see where users drop.
How to do this with Digia Engage
A growth team designs the priming screen in Digia’s visual builder, often as an in-app bottom sheet, and triggers it on an event already tracked in CleverTap, MoEngage or WebEngage, such as a first order. The accept button calls the system permission prompt. Frequency limits and exclusions for users already opted in sit in the same campaign, and copy or timing changes go live without an app release. See other formats on the Nudges product page.
Frequently asked questions
- What should a push priming screen say?
- It should name the specific notifications the user will get and why they help, such as order updates, price drops or payment reminders. Keep it to a short headline, one or two lines of benefit, a clear accept button and an honest 'Not now'. Avoid generic lines like 'Stay updated', which give no reason to agree.
- Can you show the priming screen again after a user says no?
- Yes, if they declined the priming screen rather than the system prompt. Wait for a later moment where notifications clearly help, such as tracking a first order, and cap how often it reappears. If the user declined the system prompt itself, the app can only point them to device settings.
Related terms
Read more
Part of the In-app engagement glossary.