Start with the journey you actually ship
Mobile onboarding analytics should tell you which step people reach, where they stop, and whether they finish. Start by naming the real screens in one onboarding flow. Record a step when it becomes visible, and completion only when the user actually finishes the flow.
A single “onboarding started” event and a single “finished” event reveal the overall gap. Step events locate it. Keep screen identifiers stable, put answers and variants in properties, and create a new flow version when the steps change. Comparing two different journeys as if they were the same can hide a regression.
A small, explicit tracking plan
| Moment | What to record | What it answers |
|---|---|---|
| First screen opens | Flow ID, version and attempt | How many attempts started? |
| A step appears | Stable step ID within the attempt | Which step loses people? |
| A person answers | Step ID and a bounded choice | How do onboarding answers differ? |
| Onboarding finishes | Completion for that attempt | How many attempts finish? |
In Appbase, the workflow helpers attach a persisted attempt and definition. Use them on actual screen transitions. Do not start a fresh attempt every time a component renders. If the app restarts midway through onboarding, the SDK’s persisted workflow state matters.
Use bounded answers such as “strength” or “running.” Avoid collecting free-form health information, email addresses or other unnecessary personal details in analytics properties.
Read the denominator before the percentage
Suppose 100 attempts start, 80 reach the goal screen, 60 reach the plan screen and 45 complete onboarding. These are synthetic numbers, not an industry benchmark.
Overall completion is 45 ÷ 100 = 45%. Progress from the goal screen to the plan screen is 60 ÷ 80 = 75%, so that transition loses 25% of the attempts that reached the goal screen. The plan screen reaches 60% of starters. Those percentages answer different questions.
Use one counting unit throughout a comparison: attempts, people or installations. A returning person can make another attempt. In Appbase’s onboarding journey, the counting unit is an attempt; a generic unique-user funnel will not necessarily match it. State the date window and flow version alongside the result.
Keep completion separate from buying
An app may complete onboarding before a paywall, after a purchase, or without a purchase. Record what the app does. Do not redefine “completed” to mean “subscribed” just to make one funnel look cleaner.
If onboarding includes a paywall, attach that presentation to its journey. Then inspect trial and direct-purchase outcomes separately. A purchase callback indicates a client outcome; verified revenue needs billing evidence. The paywall conversion guide explains the connection.
Verify before changing the experience
- Walk through every step in development and confirm its delivery.
- Background and reopen the app midway through the flow.
- Retry after going offline and confirm attempts are not multiplied.
- Compare the stored flow version with the version you just shipped.
- Check completion independently from trial or purchase outcomes.
Inspect device, app-version and flow differences before attributing a drop to copy or design. An apparent abandonment can be an event that never arrived. Observed differences also do not establish that a particular design caused the change.
Appbase separates development and production datasets. Follow the React Native / Expo guide or native Swift guide, then use the tracking definitions as the reference for report meaning.