A push notification opt-in is the moment a user grants your app permission to send alerts to their device, and the opt-in rate is simply the percentage of app installs (or eligible users) who say yes. Get this one moment right and everything downstream, from retention to campaign ROI, gets easier.
The single highest-impact lever is a pre-permission soft ask: an in-app message, shown at a genuine value moment, that explains what notifications you'll send and why, before the native system prompt appears. This preserves your one-shot iOS permission dialog and gives Android users a reason to say yes on the first try.
The numbers back this up decisively:
- iOS opt-in rates can rise by roughly 15 to 20 percentage points when a pre-permission dialog precedes the system prompt, versus firing it cold on first launch.
- Android 13 and above shows better baseline opt-in than older Android versions, but timing and a soft ask still improve opt-in rates.
Pro Tip: Never ask before you've shown a reason to care. A soft ask fired on session one, before a user has done anything, performs no better than the system prompt alone.
Key Takeaways
Push notification opt-in rate improves most reliably through a pre-permission soft ask timed to a genuine value moment, not through prompting earlier or more often.
| Point | Details |
|---|---|
| Lead with a soft ask | Show your own in-app prompt before the native system dialog to preserve iOS's one-shot permission. |
| Time it to value | Wait until session two or three, or the first completed value moment, never session one. |
| Use provisional notifications first | Let iOS users see real notification content before asking for full permission. |
| Build recovery separately | Segment "Not now" from "No" responders and deep-link decliners to settings with context. |
| Pocket App builds this in from discovery | Pocketapp designs and instruments permission flows as part of the product, not an afterthought. |
Table of Contents
- What are the platform rules for push notification opt-in?
- How does the pre-permission soft ask actually work?
- Should you use provisional notifications on iOS?
- How do you win back users who declined notifications?
- What copy and visuals actually improve opt-in?
- How do you measure and benchmark opt-in rate?
- What has Pocket App learned from building permission flows?
- Three priorities I'd push product teams to fix first
- How Pocket App builds opt-in into every app we ship
- Sources
- FAQ
What are the platform rules for push notification opt-in?
Every platform treats opt-in differently, and that difference should shape your entire prompting strategy. Get the mechanics wrong and you'll burn your best opportunity before you've earned it.
iOS gives you a single native permission dialog. If a user taps "Don't Allow," you cannot programmatically trigger that system prompt again; the only route back is the user manually changing settings, or you convincing them to re-engage through your own UI. This is why treating the system prompt as a one-shot opportunity rather than a routine ask matters so much. iOS also offers provisional notifications, which sidestep this constraint entirely (more on that below).
Android historically auto-granted notification permission, but Android 13 introduced a genuine runtime opt-in, requiring apps targeting SDK 33 or above to explicitly request POST_NOTIFICATIONS. Crucially, apps upgraded from an earlier install behave differently to fresh installs on Android 13+, so your team needs to test both upgrade paths, not just clean installs. There's also a lesser-known edge case: Play Protect can revoke notification permission from apps it judges to be misbehaving, which is worth monitoring if you see unexplained opt-out spikes.
Web push sits well below both. Desktop browsers typically see 7 to 15% opt-in, mobile browsers closer to 3 to 8%, and subscribing a user requires registering a service worker and calling the browser's subscription API before permission is even requested. A denied web prompt is effectively permanent until the user digs into browser settings themselves.
| Platform | Re-ask after decline | Typical baseline opt-in |
|---|---|---|
| iOS (system prompt) | Not possible programmatically | Improves 15–20 points with soft ask |
| Android 13+ | Possible via in-app request flow | Better than pre-13, still timing-sensitive |
| Web push (desktop) | User must change browser settings | 7–15% |
| Web push (mobile browser) | User must change browser settings | Low opt-in rates |
The practical takeaway: design your prompt sequence around iOS's scarcity, not Android's relative flexibility, because that's the constraint that will cost you the most if you get it wrong.
How does the pre-permission soft ask actually work?
A soft ask is your own in-app UI, not the operating system's dialog, so you have complete freedom over wording, visuals, and timing. Because it doesn't touch the native permission API, a user can decline it and you can ask again later without any technical penalty.
What separates a soft ask that converts from one that doesn't usually comes down to three specific elements the copy needs to cover:
- What you'll send — be concrete ("order updates and delivery alerts," not "important updates").
- How often — state frequency honestly; vague copy reads as evasive.
- How to opt out — reassure users they control this later, in settings or in-app.
Research consistently shows that soft asks explaining notification type, user value, and opt-out control convert better on the subsequent system prompt than generic asks, precisely because users no longer face a blind decision.
Timing matters as much as wording. Never show a soft ask on session one; a brand-new user has no context for why alerts matter yet. The stronger pattern is waiting until session two or three, or better still, tying the ask to the first moment the user experiences real value:
- Ecommerce: immediately after the first completed checkout, when "track your order" is a tangible benefit.
- Messaging apps: right after a user sends their first message, when "get notified when they reply" solves an obvious problem.
- Content or media apps: after a user finishes their first article, video, or episode, when "we'll tell you when there's more like this" lands naturally.
The common thread across all three: the ask follows an action, it doesn't precede one. A user who has just done something meaningful understands instantly why notifications would help them do it again.
Pro Tip: Build your soft ask as a dismissible in-app card or modal, never a full-screen blocker. A user forced to choose before they can continue using the app associates notifications with friction, not value, and that association follows them into the system prompt decision.
Should you use provisional notifications on iOS?
Provisional notifications let you deliver real content straight to a user's Notification Centre without ever touching the system permission dialog, and they solve a genuine problem: proving value before asking for commitment.
Unlike a standard push, provisional notifications arrive quietly and don't trigger banners or sounds, so users can see what your notifications actually look like before deciding whether they're worth full permission. OneSignal's documentation on prompting strategy frames this as a way to demonstrate value immediately, rather than asking users to take a decision on trust alone.
The sequence that tends to work best runs in three stages:
- Enable provisional notifications early, so relevant content starts arriving with zero friction.
- Follow with a soft ask once the user has seen two or three provisional notifications land, framed around "you've seen what these look like, want the full experience?"
- Only then trigger the full system prompt, ideally straight after the soft ask is accepted, while intent is still fresh.
Track provisional-to-full conversion as its own funnel metric, separate from your headline opt-in rate. A gap between strong provisional delivery and weak full conversion usually signals your soft ask copy, not your notification content, needs work.
How do you win back users who declined notifications?
A decline isn't necessarily permanent, but recovering it requires a different playbook than your first ask. On iOS, since you can't re-trigger the native dialog, the honest route is deep-linking users to their device settings from within your own app, alongside a brief explanation of what they're missing.
The most effective recovery flows combine a few tactics:
- An in-app banner or settings screen that explains, in plain language, what notifications the user is missing and links directly to the relevant OS settings page.
- Behavioural triggers rather than calendar-based nagging: re-ask context after a user completes an action that notifications would clearly benefit (a second purchase, a returned visit after a long gap).
- A meaningful distinction between "Not now" and "No" in your own soft-ask UI, so you can re-approach "Not now" users sooner than users who gave a harder no.
- Cross-channel recovery via email or SMS when in-app reach is limited, particularly useful for lapsed users who haven't opened the app in weeks. Worth remembering: consent for one channel doesn't transfer to another, so an email opt-in never substitutes for a genuine push opt-in.
Set realistic expectations for recovery campaigns. Reclaiming a meaningful share of decliners over a quarter is a reasonable goal; treating recovery as a one-off blast rarely moves the needle.
Pro Tip: Segment your "Not now" users separately from day one. They're your highest-probability re-ask audience, and lumping them in with hard "No" responders wastes your best remaining opportunity.
What copy and visuals actually improve opt-in?
Good soft-ask copy is specific, honest, and short enough to read in three seconds. Here's what that looks like across a few common categories:
- Ecommerce: "Get notified the moment your order ships. We'll only message you about deliveries, never marketing spam."
- Finance apps: "Turn on alerts for large transactions and low balances. You control which alerts you get, any time."
- Messaging platforms: "Never miss a reply. We'll notify you when someone messages you, nothing else."
- Gaming apps: "Know when your energy refills or a friend challenges you. Adjust or turn off anytime in settings."
Every example names the specific trigger, states the boundary ("nothing else," "never marketing spam"), and signals control. That combination is what pre-permission dialogs that explain type, value, and control are shown to do well.
Visually, keep mock-ups close to the real system dialog's tone: a clean icon, one short headline, one line of supporting copy, and two clear buttons. Avoid anything that could read as a dark pattern, such as disguising the decline button as lower-contrast text, or pre-selecting "allow" visually before the user has chosen anything.
Worth A/B testing before you commit to one version:
- Value-led copy versus feature-led copy (benefit first vs. list of notification types).
- Modal soft ask versus inline banner soft ask.
- Icon-led visual versus text-only prompt.
Small wording changes routinely shift conversion by several points, so treat this copy with the same rigour you'd apply to a checkout flow, not as an afterthought bolted on after the build.
How do you measure and benchmark opt-in rate?
Opt-in rate is calculated as (users who granted permission) ÷ (users who saw or were eligible for the prompt) × 100. That sounds simple, but the denominator trips teams up constantly: are you measuring against total installs, against users who reached the soft ask, or against users who saw the native system prompt? Pick one definition and use it consistently, or your A/B tests will compare apples to oranges.
Beyond the headline rate, track a small set of supporting metrics: reachable users (opted-in and still subscribed), enabled rate over time (subscriptions decay), and full-funnel conversion from install through soft ask through system prompt.
| Segment | Typical opt-in range | Primary lever |
|---|---|---|
| iOS with pre-permission soft ask | Meaningfully higher than cold prompt | Timing and copy specificity |
| iOS, cold system prompt | Lower baseline | Provisional notifications first |
| Android 13+ | Improves versus pre-13, still variable | Runtime request timing |
| Web push (desktop) | 7–15% | Pre-qualification before prompt |
| Web push (mobile browser) | 3–8% | Value demonstration pre-ask |
Run A/B tests on timing (session 1 vs session 3 vs first value moment), copy (feature-led vs benefit-led), and CTA wording, and don't call a test until you've got a sample large enough to trust; a 200-user test swinging 4 points either way tells you nothing. The payoff for getting this right compounds: apps with stronger opt-in and engagement strategies typically see the gain show up directly in retention curves and campaign reach, since every additional opted-in user is one more person your retention campaigns can actually touch.
What has Pocket App learned from building permission flows?
Across more than 300 mobile projects, spanning charity clients like WWF, healthcare and pharma work with Dechra, and consumer engagement builds across retail and recruitment, permission design shows up in nearly every brief. Notification strategy isn't an afterthought bolted on at launch. It's part of the discovery conversation from day one.
In client projects, Pocketapp typically builds permission flows around three fixed principles:
- Map the value moments in the user journey first, then decide where a soft ask fits, rather than defaulting to "ask on first launch."
- Design the soft ask UI as a proper product screen, not a system dialog clone, so it can be A/B tested and iterated without touching native code.
- Instrument opt-in and re-optin funnels from day one, so clients can see conversion by segment rather than a single blended number.
Teams working through their own permission flow can find broader tactical detail in Pocketapp's guide to push notification strategy, and product managers designing the softer in-app side of this will find the in-app messaging strategy guide directly useful for building the re-ask flows covered above.
Three priorities I'd push product teams to fix first
If you take one thing from this guide, make it this: stop treating the permission prompt as a technical checkbox and start treating it as a product decision with a measurable outcome.
My first priority would be timing over urgency. Teams default to asking early because it feels efficient, but early is exactly when a user has the least reason to say yes. Wait for a value moment; it costs you nothing and it's the single biggest lever in this whole guide.
Second, opt-in rate deserves the same scrutiny as your activation or retention metrics, not a one-off dashboard tile you check after launch and forget. A/B test it as relentlessly as you'd test onboarding screens.
Third, permission flow is onboarding. It shapes trust and sets expectations for how your app behaves. Design it with the same care you'd give the first screen a user sees.
— Paul
How Pocket App builds opt-in into every app we ship
Pocketapp is the alternative to bolting notification permission onto a finished build as an afterthought. We design the soft ask, the timing framework, and the measurement plan into the product from the discovery phase, so opt-in isn't something you retrofit after launch and hope improves.
A typical engagement covers discovery workshops to map your app's genuine value moments, UX design for soft-ask screens and provisional notification sequencing, full implementation across iOS, Android and web, and post-launch analytics support so you can see opt-in and re-optin performance by segment rather than a single blended figure. We also run the A/B tests themselves, comparing timing, copy, and CTA variants against real user cohorts rather than guesswork.
If you're planning a new build or reworking notification strategy in an existing app, the place to start is a conversation about your mobile app development project, where we can scope discovery, design, and the permission flow together from the outset.
Sources
For primary technical detail, see Android's notification permission documentation, Web, and OneSignal's prompting strategy documentation. For growth context beyond permission flows, Cult Media's guide to scaling consumer apps covers acquisition systems worth pairing with a strong opt-in strategy.
- Push Notifications Statistics (2026)
- Prompt for push permissions | OneSignal documentation
- Notification permission for opt-in notifications | Android documentation
FAQ
Should push notifications be turned on or off by default?
Push notifications should never be turned on by default without explicit user consent; every major platform requires an opt-in, and defaulting them on without permission isn't technically possible on iOS or Android 13 and above.
Where do I find push notification settings on my device?
On iOS, go to Settings, then Notifications, then select the app. On Android, go to Settings, then Apps, select the app, then Notifications. Both let users toggle permission after an initial decline.
What are the disadvantages of push notifications?
Overused or poorly timed notifications drive users to disable them entirely or uninstall the app, and a denied prompt on iOS can't be re-triggered programmatically, making a wasted first ask costly.
What does it mean when a push notification is enabled?
An enabled push notification means the user has granted your app permission through the system dialog, generating a device token your backend can use to send alerts to that specific device.
How do GDPR and CCPA affect push notification opt-in?
Both frameworks require clear, informed consent before processing personal data tied to a device identifier, so your soft ask copy explaining notification types and control isn't just good UX, it supports the consent standard these laws expect.