Measure whether reminders work before optimizing the permission prompt

Suppose your plant-care app asks for notifications on its welcome screen. You move the request to the moment someone chooses “Remind me on Saturday.” Acceptance jumps from 30% to 50%. Should you ship it?

Start by counting the people who had a chance to benefit. In an illustrative test, give each version 200 new users who chose the same reminder-capable feature. Version A asks all 200 and 60 agree. Version B asks only the 80 who reach the scheduling screen and 40 agree. The new flow wins on permission acceptance, 40/80 versus 60/200. It reaches fewer authorized people per eligible start, 40/200 versus 60/200. Neither number tells you how many plants actually got watered.

Start with the task the person wanted to remember

Use one specific action, such as marking a watering task complete by the end of its due day. Record a task identifier, save time, due time and completion time. Keep the plant name and notification contents out of analytics. If a task is deleted or rescheduled, define beforehand how that changes the observation window.

The app can know whether the user saved the task, what authorization status it observed, and whether scheduling returned an error. A successful scheduling call does not prove that the user saw the notification. A notification tap is stronger evidence of interaction, but someone can water the plant without tapping. Label each event according to what it actually observes.

The same distinction matters beyond reminders: a successful API request is not yet a usable result. That worked example shows how to separate an intermediate milestone from the task the customer meant to finish.

Put the permission request in a decision someone recognizes

A first-time user chooses a day, sees what the reminder will say and taps “Remind me.” At that point the system’s permission request answers a question the person has just raised. Preserve the saved task if they decline. On their next visit they should still be able to see it and mark it done. Apple recommends requesting authorization in context and lets apps inspect their current notification settings. Apple’s notification authorization guide

Have a teammate run four cases on a device: allow, decline, return with permission already denied, and save a second reminder after allowing the first. Watch where the same setup screen repeats or where the app claims a reminder is scheduled despite lacking permission. Those are product fixes you can make before interpreting an experiment.

Before running the comparison, map the reminder path with Jesse Venticinque’s AI mentor ↗. Bring the eligible-user count, saved tasks and the step where people stop.

Compare only tasks that had time to come due

If you check on Friday, a reminder set for Saturday has had no chance to work. For the product decision, compare completion among eligible users after a fixed follow-up window long enough to include the chosen due dates. As a diagnostic, compare completion among saved tasks already due. Keep the user-level measure alongside it: a flow that causes fewer people to save a task can make the remaining tasks look unusually successful.

Trials need the same patience: check whether the first billing date has arrived before treating an unfinished trial as a payment failure.

If saved tasks rise and completion does too, you have a reason to keep the new flow. If permission acceptance rises alone, return to the missing step. Improving the wording of the operating-system prompt is a poor use of an afternoon when users cannot find where to choose Saturday.