How to measure mobile onboarding completion correctly

1. Decide what “complete” means

An onboarding completion rate is only useful when its start and end events are explicit. Choose one meaningful entry point, such as the first onboarding screen actually shown, and one completion point, such as reaching the first usable product screen. A network request for a configuration is not evidence that a person saw it.

Write the definition before changing the flow. Include the application, flow version, eligible audience, identity unit, reporting time zone and time allowed to finish. Keep existing users who reopen a setup screen separate from first-time installations. The resulting figure answers a narrow question: how many eligible starters reached the defined finish?

• Start: first onboarding screen becomes visible.
• Finish: the app reaches the defined onboarding destination.
• Window: for example, within 24 hours of the first start.
• Unit: unique installation; reinstallations may create a new installation identity.

2. Keep the numerator inside the denominator

Consider an invented cohort of 1,000 installations that first started onboarding on Monday. Within 24 hours, 800 reached the preferences step, 650 reached the final setup step and 600 completed. The overall completion rate is 60%. These figures are a teaching example, not Aplyna customer data or an industry benchmark.

For a closed ordered funnel, each later stage must belong to the original cohort and follow the required earlier stages. A user who jumps directly to the last screen should not silently enter a first-time onboarding denominator. Google Analytics distinguishes open and closed funnels for this reason; document which behavior your own analysis uses.

3. Separate overall completion from step conversion

In this example, the final step converts 600 of 650 installations, or about 92.3%. That is different from the 60% overall completion rate. Both can be useful, but a chart labeled simply “conversion” hides which question it answers.

Investigate the largest absolute loss alongside the percentage loss. The first transition loses 200 installations; the last loses 50. This can suggest where to inspect the experience, but it does not prove that a screen caused abandonment. Slow loading, eligibility rules, app crashes or missing events can produce similar patterns.

• Use step conversion for the transition between two adjacent stages.
• Use overall completion for the full start-to-finish journey.
• Inspect telemetry and product behavior before attributing a drop to design.

4. Deduplicate and wait for the cohort to mature

Count distinct installation identities rather than raw event rows. Retries and repeated screen visits should not inflate completion. Deduplicate delivery with stable event identifiers, and count each installation once for the chosen outcome. Keep organization and application filters on every query.

Do not divide all completions received today by all starts received today if completion can happen tomorrow. Group by the start cohort, evaluate the outcome within its window, and mark recent cohorts as incomplete until enough time has passed. Late offline events may require a documented reconciliation period.

Weekly unique installations must be recomputed across the week. Adding seven daily unique counts double-counts installations active on multiple days. Likewise, averaging daily completion percentages gives small cohorts the same influence as large cohorts. Recalculate the weekly numerator and denominator instead.

5. Measure activation after completion

Finishing setup is not the same as receiving value. A reader might reach the home screen without opening a book; a habit app user might finish a questionnaire without completing a habit. Define an activation event tied to the product and measure it in its own window.

Use completion as a diagnostic metric, with activation and reliability as guardrails. Removing every onboarding step could increase completion while reducing useful personalization. A controlled experiment should evaluate the downstream outcome before treating a shorter journey as an improvement.

In Aplyna, start with explicit SDK events and the documented metric definitions. A trial-start event is a journey signal, not verified payment or subscription revenue. Check current availability before building a report around an unsupported provider metric.