All testsAli Demirbaş - Lab

Mobile App

When to Ask for Push Permission: Mobile App A/B Test

An opt-in prompt at launch reaches users before they have experienced the value of notifications. Waiting for a defined first-value event may make the request more relevant, though fewer users may reach that point. Report permission grants both among everyone assigned and among users actually shown the prompt.

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

  • Mobile app
  • Permission grant rate

Option A vs Option B

The moment is the variable, not what appears.

Changed
Timing
Page
Mobile app
Difference
changed

Hypothesis

If the prompt waits for a first-value event, users who see it may accept more readily, while asking at launch puts the request in front of more people. Which timing comes out ahead on permission grant rate per assigned user depends on whether higher acceptance among those asked makes up for the users who never reach that point.

Test plan

When to run this test

Funnel data showing users leaving right after the permission dialog, low first-session completion, or users turning notifications off later suggest the prompt's timing is costing you; the test is also a sound starting point while timing is still undecided. If asking after first value comes out ahead, users who reach that point grant permission more willingly; if asking at launch wins, reaching more people makes up for lower acceptance. First pin down what notifications will genuinely deliver and write the pre-permission explanation around that; if the copy overpromises, you end up measuring exaggeration rather than timing.

How to measure success

Permission grant rate

Count permissions granted per eligible assigned user within a fixed period; also report acceptance among users asked.

Also track

  • Seven-day retentionCompare all assigned users, not only those who grant permission.
  • Notification click-through rateWith messaging policy fixed, report responses to delivered notifications as a diagnostic.
  • First-session completionMake sure the permission request does not interrupt the flow.
  • Notification opt-out rateTrack later permission withdrawals over the same follow-up period.

How to set it up

  • TimingCompare the prompt at launch with the prompt after one predefined value event.
  • ExplanationKeep any pre-permission explanation and its wording the same in both arms.
  • Notification valueDescribe the same genuine notification use in both arms.
  • DeclineApply the same decline and re-prompt policy within each platform's supported behavior.
  • PlatformRandomize eligible users within each platform and review results separately.

What to watch when reading the result

  1. 1Make the call on permission grant rate per eligible assigned user at the end of a fixed period; looking only at acceptance among users asked can flatter the first-value arm, since fewer users reach that point. Compare seven-day retention across all assigned users too; more permissions with lower first-session completion or retention is not enough to choose that timing.
  2. 2Read the result for each platform separately, because the permission dialog and re-prompt limits differ by platform. A different first-value event or explanation copy could change the outcome; track the notification opt-out rate for the full follow-up window to see whether granted permissions last.
  3. 3Check in both arms that users who decline can keep using the app. A flow that punishes a decline, or asks again in ways the platform does not support, can inflate acceptance and leave you with a result you cannot interpret.
  4. 4If the arms come out close, the gain in acceptance may be melting away because fewer users are asked. First confirm that each arm received the share of users you planned (sample ratio mismatch). If assignment is balanced, test the gap in permission grant rate with the A/B test significance calculator, and do not shorten the follow-up period.

Frequently Asked Questions

Which population should define permission acceptance?

Use permission granted per assigned eligible user over a fixed window. Acceptance among prompted users is diagnostic because different timing reaches different populations.

Why not compare retention only among permission grantors?

Grantors are self-selected and can differ by arm. Compare retention across assigned users, and check whether the request disrupts the first session.

How should users who decline permission be treated?

Respect refusal without blocking app use. Randomize within a common eligible pool and balance groups if needed. Preserve the same re-request policy within platform limits and track later revocation equally.