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

Page: https://alidemirbas.com.tr/en/lab/ab-test-library/tests/when-to-ask-for-push-permission-mobile-app-ab-test

## 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.

## 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.

## Primary metric

**Permission grant rate**: Count permissions granted per eligible assigned user within a fixed period; also report acceptance among users asked.

## Other metrics

- **Seven-day retention**: Compare all assigned users, not only those who grant permission.
- **Notification click-through rate**: With messaging policy fixed, report responses to delivered notifications as a diagnostic.
- **First-session completion**: Make sure the permission request does not interrupt the flow.
- **Notification opt-out rate**: Track later permission withdrawals over the same follow-up period.

## What to check before and during the test

- **Timing**: Compare the prompt at launch with the prompt after one predefined value event.
- **Explanation**: Keep any pre-permission explanation and its wording the same in both arms.
- **Notification value**: Describe the same genuine notification use in both arms.
- **Decline**: Apply the same decline and re-prompt policy within each platform's supported behavior.
- **Platform**: Randomize eligible users within each platform and review results separately.

## What to watch when reading the result

- Make 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.
- Read 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.
- Check 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.
- If 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](https://alidemirbas.com.tr/en/calculators/ab-test), 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.