All testsAli Demirbaş - Lab

Mobile App

Testing a Permission Priming Screen Before the Prompt

An explanation before the system prompt may help users decide whether permission is worthwhile. It also adds a step where users may defer or leave. A higher acceptance rate among users who reach the system prompt may reflect selection; assess the flow by permission grants among all assigned users.

A/B test scenario. This page is a test plan, not the result of a real experiment.

  • Mobile app
  • Net permission grant rate

Control vs Variant

Absent on one side, present on the other.

Changed
Presence
Page
Mobile app
Difference
added

Hypothesis

If users see a screen explaining what a permission is for before the system prompt opens, they may weigh its benefit more easily. If the acceptance it adds outweighs the users who defer or leave at the extra step, that could raise the net permission grant rate.

Test plan

When to run this test

Heavy denials at the system prompt, support tickets asking what a permission is for, or trust concerns in surveys suggest users do not see why the app is asking, which is the gap a pre-permission screen tries to fill. If the explanation works, acceptance rises among users who pass it and more than covers the drop-off on that screen, so grants rise across all assigned users. If denials come from asking at the wrong moment, an explanation will not fix that; handle timing in a separate test. Check store rules before launch, make the screen clearly distinct from the system prompt, and leave a way to continue without granting permission.

How to measure success

Net permission grant rate

Compare permissions granted per eligible assigned user over the same follow-up period.

Also track

  • System prompt acceptance rateCheck acceptance among users who reach the prompt.
  • Pre-prompt continuation rateIdentify drop-off at the explanatory step, which appears only in the variant.
  • Permission denial rateUse the platform's available status information; do not assume every denial is permanent.
  • Seven-day retentionMake sure retention does not fall.

How to set it up

  • ExplanationAdd one fixed explanation before the existing system permission prompt.
  • TriggerKeep eligibility and the permission trigger unchanged.
  • Drop-offInclude visitors who defer or leave before the system prompt.
  • DeferralPredefine the “Not now” path and later re-prompt policy.
  • ExperienceReview eligible new and experienced users separately.

What to watch when reading the result

  1. 1Do not declare success from a higher system prompt acceptance rate, because in the variant only users who pass the explanation reach the prompt. Judge it by the net permission grant rate across all eligible assigned users, keep users who defer in the denominator, and confirm retention does not fall.
  2. 2Read this result as specific to this explanation copy and the current moment when permission is requested. Review new and experienced users separately, track denials with the platform's status information, and do not assume every denial is permanent.
  3. 3Users who defer and grant permission later can shift the result late, so with a small gap check whether the follow-up period is long enough to capture them. Put each arm's eligible users and net grants into the A/B test significance calculator to see whether the gap stands out from chance, and keep the “Not now” path unchanged throughout the test.

Frequently Asked Questions

Does higher acceptance in the system prompt prove the pre-prompt helped?

No. The explanatory screen can select who reaches the prompt. Use net grants per assigned eligible user over the same follow-up window as the primary outcome.

How should users who defer or leave be counted?

Keep them in the denominator. If they later grant permission within the same window, count them in the numerator too. Report pre-prompt progression separately.

What matters when designing the explanatory screen?

Do not impersonate the system dialog or block use after refusal. Follow applicable platform rules and keep request timing unchanged while testing the explanation.

Does a refusal permanently lose the user?

Not necessarily. Platform permission states and available recovery routes differ. Respect refusal, inspect supported status information and monitor retention without assuming every rejection is irreversible.