If you have shipped a mobile app and your notification permission acceptance rate is below 60 percent, the temptation is to redesign the pre-prompt and hope for the best. Sometimes that works. More often, the redesign moves the metric a few points and the team is surprised the gain is not bigger.
The problem is usually upstream of the pre-prompt copy. It is in the moment you chose to ask, the recovery path you skipped, or the silent deny state in the UI. Before you redesign anything, instrument what is happening so the fix is targeted.
This is a practical guide to the metrics that matter, ordered from lowest to highest effort, with what each one tells you.
Photo by freestocks.org on Pexels
Metric 1: prompt show rate by trigger
Log every place in your app where the permission system prompt or your pre-prompt fires, with a label for the trigger.
You want to know: of all users who saw a pre-prompt today, what trigger fired it? "App launch" should not be on this list at all, for any permission. "First time tapping Take Photo" should be on it. "First time tapping Share Location" should be on it. "First time tapping Find Friends" should be on it.
If "app launch" appears in your data, you have already found the headline problem. Move the prompt out of the launch path and let it fire on the feature trigger instead. This single change usually moves acceptance more than any pre-prompt rewrite.
For wider mobile analytics patterns and event tagging, Mozilla's developer site has stable references on event tracking that translate cleanly to mobile contexts.
Metric 2: pre-prompt to system-prompt conversion
For each pre-prompt show, log whether the user tapped "Yes" and the system prompt was triggered, or tapped "Not now" and dismissed.
This is the gatekeeping metric. If the conversion is below 70 percent, the pre-prompt copy or visual design is the bottleneck. If it is above 85 percent, the pre-prompt is doing its job and the issue is downstream.
Common reasons this metric is low:
- The pre-prompt is too vague. Users cannot evaluate the deal in five seconds.
- The pre-prompt asks for multiple permissions in one screen.
- The pre-prompt fires before the user has expressed intent for the underlying feature.
- The buttons are labeled "OK" and "Cancel" rather than verbs.
A redesigned pre-prompt with concrete value, single permission, and labeled buttons routinely moves this conversion from 50 percent to 85 percent. If it does not, the trigger moment is wrong and no copy will save you.
Metric 3: system-prompt acceptance rate
This is the headline number. Of users who saw the native iOS or Android dialog, what percent accepted?
Aim for 75 to 90 percent on critical permissions if your pre-prompts and timing are doing their jobs. The exact number depends on category (notification acceptance in games tends to be lower than in messaging, for example), but anything below 60 percent for a critical permission is a sign the upstream work is not done.
If this metric is high but Metric 1 shows that very few users are even reaching the prompt, your pre-prompt conversion is the issue. If this metric is low, the system-prompt is the issue, which usually traces back to mismatched trigger moments: the user said "yes" to the pre-prompt out of social default, then read the native dialog and reconsidered.
For platform-specific guidance on what kinds of acceptance rates are realistic, Apple's developer site and Google's Android developer site both have material on permission design and the rates teams typically see.
Photo by Anna Tarazevich on Pexels
Metric 4: feature attempts after denial
The metric most teams skip. After a user denies a permission, how many times do they try to use the feature that depended on it?
Every feature attempt after denial is a recovery opportunity. The user is telling you they want the feature now, even though they declined the permission earlier. If your deny-state UI is silent ("camera does not open"), the user thinks the app is broken and leaves. If your deny-state UI is loud and helpful ("Camera is off in Settings. Tap to fix."), the user gets to the recovery path.
Instrument: feature attempts on denied permissions, count of users who tap the recovery link, count of users who actually flip the Settings toggle. The conversion through each of those steps tells you which step is broken.
A common pattern: feature attempts after denial are high (users want to use the feature), but recovery taps are zero (the deny state UI is invisible). The fix is a visible banner with a deep link to Settings.
Metric 5: recovery rate over time
Of users who initially denied, what percent later granted the permission?
This is a slow-moving metric (you might need weeks to see real changes), but it is the truest measure of whether your recovery path is working. If the recovery rate is below 5 percent, your deny state is silent and your re-engagement is non-existent. If it is above 20 percent, your recovery flow is alive and well.
The fix for low recovery rate is two-fold: make the deny state visible in the UI everywhere the feature appears, and provide a one-tap deep link to the app's Settings page. Both iOS and Android expose APIs for this. Use them.
For UX research on how users perceive deny states and recovery flows, Nielsen Norman Group has practical, repeated studies on the topic.
Metric 6: permission-related support tickets
Audit your top ten support categories against the permissions in your app. If "camera not working" or "no notifications" or "can't find friends" shows up disproportionately, the metric is telling you the deny state is silent or the recovery path is broken.
This is a leading indicator. Support tickets show up before the churn does. A spike in permission-related tickets after a release means something in the permission flow broke or got harder to recover from.
How to sequence the fixes
Once the metrics are in place, the fixes generally land in this order.
First, fix the trigger moment. Move every permission prompt out of the launch flow and into the feature flow. This is the highest-impact change and usually the cheapest.
Second, fix the pre-prompt copy and structure. One promise, one cost, two labeled buttons. Most pre-prompts get rewritten down to under thirty words.
Third, fix the deny state UI. Every feature that depends on a permission needs a visible state when the permission is denied, plus a one-tap Settings deep link.
Fourth, stage permissions over time. Not every permission has to be asked for in the first session. Pick the ones that connect to first-session features, and defer the rest.
For the longer playbook that this metric set supports, the full write-up at 137Foundry covers the whole permission lifecycle from pre-prompt to recovery to staged rollout. The metrics above tell you where the gain is hiding. The playbook tells you how to capture it.
A note on instrumentation hygiene
Two things to do at the same time you add the metrics.
Tag every event with the permission name and the trigger moment. Permission flows do not have a single funnel; they have one per permission. Aggregating across permissions hides the most actionable data.
Tag the platform and OS version. iOS and Android behave differently around re-prompting, and the rules change between OS versions. A metric that aggregates across both will mask platform-specific issues.
The full 137Foundry services list covers more app development work where this kind of metric set is the starting point for retention improvement. The metrics are not the answer; they are the map that lets you find the answer with the least guessing.
Closing thought
The pre-prompt redesign that does not move the metric is one of the most frustrating outcomes in product work. The fix is to not start with the pre-prompt. Start with the metrics. Find the upstream broken step. Fix that. Then redesign the pre-prompt with the trigger moment lined up and the recovery path in place, and watch the headline acceptance rate move the way you expected the first time.
A week of instrumentation, two weeks of focused fixes, one release cycle to measure. That is the shape of the work. Most teams skip the first week and wonder why the rest takes longer than it should.
Top comments (0)