Onboarding completion rate measures the percentage of sessions that finish your onboarding flow after starting it. The formula: sessions with onboarding_completed ÷ sessions with onboarding_started × 100. This guide shows you how to design the events, instrument your app, and use funnel analysis and automated drop-off detection to find exactly where users abandon the flow.
🎯 Why Onboarding Completion Rate Is Your Most Important Activation Metric
A user who never finishes onboarding never reaches your core feature. They never see the value of your app. They churn silently—often within the first session. Onboarding completion rate is the gateway metric that determines whether all your acquisition spending translates into active users.
Yet most teams ship onboarding without measuring it. They know their overall retention numbers are low, but they can't pinpoint where in the first-run experience users give up. Without step-by-step tracking, you're guessing which screen needs work.
What Onboarding Tracking Tells You
- • Overall completion rate — What percentage of new sessions finish onboarding?
- • Per-step conversion — Which specific step loses the most users?
- • Time between steps — Are users hesitating at a particular screen?
- • Platform differences — Does onboarding perform differently on iOS vs Android?
- • Impact of changes — Did removing a step actually improve completion?
The good news: with session-based analytics and just 5 stored fields (event_name, session_id, timestamp, platform, country), you can measure all of this without collecting personal data.
📐 Step 1: Design Your Onboarding Event Taxonomy
Before writing a single line of code, map your onboarding flow on paper. Identify every screen and decision point. Then assign an event to each meaningful step.
Use the onboarding_ namespace prefix with snake_case naming. This groups all onboarding events together in your dashboard and makes them easy to filter. Follow the object_action pattern with past-tense verbs.
Minimum Viable Onboarding Events
Every onboarding flow needs at least these two events:
| Event Name | When to Fire | Purpose |
|---|---|---|
onboarding_started |
First onboarding screen appears | Denominator for completion rate |
onboarding_completed |
User reaches main app screen | Numerator for completion rate |
Full Onboarding Event Set (Recommended)
For deeper insight, add intermediate step events:
| Event Name | When to Fire |
|---|---|
onboarding_started |
Onboarding flow begins |
onboarding_profile_completed |
User finishes profile setup (name, avatar, etc.) |
onboarding_preferences_set |
User selects preferences or interests |
onboarding_permission_granted |
User grants a system permission (notifications, location) |
onboarding_permission_denied |
User declines a system permission |
onboarding_tutorial_viewed |
User views a feature walkthrough or tooltip |
onboarding_tutorial_skipped |
User skips a walkthrough |
onboarding_completed |
User reaches the main app experience |
💡 Naming Tip
Use descriptive names for each step rather than numbered steps like onboarding_step_1. When you reorder or add steps, onboarding_profile_completed still makes sense—onboarding_step_2 doesn't. See our full event naming guide for more patterns.
⚡ Step 2: Instrument Your Onboarding Flow
With your event taxonomy defined, add track() calls at each step. The SDK has 3 methods: configure(), track(), and flush(). For onboarding, you only need track().
Swift Example
// When onboarding screen first appears
Respectlytics.track("onboarding_started")
// When user completes profile setup
Respectlytics.track("onboarding_profile_completed")
// When user sets preferences
Respectlytics.track("onboarding_preferences_set")
// When user grants notification permission
Respectlytics.track("onboarding_permission_granted")
// When user reaches the main app
Respectlytics.track("onboarding_completed")Kotlin Example
// When onboarding screen first appears
Respectlytics.track("onboarding_started")
// When user completes profile setup
Respectlytics.track("onboarding_profile_completed")
// When user sets preferences
Respectlytics.track("onboarding_preferences_set")
// When user grants notification permission
Respectlytics.track("onboarding_permission_granted")
// When user reaches the main app
Respectlytics.track("onboarding_completed")Flutter Example
// When onboarding screen first appears
Respectlytics.track('onboarding_started');
// When user completes profile setup
Respectlytics.track('onboarding_profile_completed');
// When user sets preferences
Respectlytics.track('onboarding_preferences_set');
// When user grants notification permission
Respectlytics.track('onboarding_permission_granted');
// When user reaches the main app
Respectlytics.track('onboarding_completed');React Native Example
// When onboarding screen first appears
Respectlytics.track('onboarding_started');
// When user completes profile setup
Respectlytics.track('onboarding_profile_completed');
// When user sets preferences
Respectlytics.track('onboarding_preferences_set');
// When user grants notification permission
Respectlytics.track('onboarding_permission_granted');
// When user reaches the main app
Respectlytics.track('onboarding_completed');
Important: Place track() calls inside action handlers—button taps, form submissions, navigation callbacks. Never call track() inside view rendering methods (SwiftUI body, React Native render, Flutter build) or you'll get duplicate events on every re-render.
📊 Step 3: Calculate Completion Rate from Your Dashboard
Once events are flowing, calculating your onboarding completion rate is straightforward:
Completion Rate = onboarding_completed sessions ÷ onboarding_started sessions × 100
In your Respectlytics dashboard, you can see event counts filtered by time range, platform, and country. The overview dashboard shows total event counts, and you can compare onboarding_started against onboarding_completed to get your rate.
For example, if you see 1,000 sessions with onboarding_started and 420 sessions with onboarding_completed in the same period, your completion rate is 42%.
Use segment comparison to break this down by platform. You might find that iOS completion is 55% while Android is 30%—pointing to a platform-specific UX issue.
🔍 Step 4: Find Drop-Off Points with Automated Detection
Knowing your overall completion rate is useful, but knowing where users drop off is actionable. This is where automated drop-off detection becomes invaluable.
The algorithm works by calculating the termination rate for each event—how often a given event is the last event in a session. When an onboarding event has an abnormally high termination rate compared to the baseline, it means users are leaving your app at that step.
How It Works
- 1. The system calculates a baseline termination rate across all events (typically around 10-15%)
- 2. Each onboarding event's termination rate is compared against this baseline
- 3. Events that exceed the baseline by +25% or more are flagged as critical drop-off points
- 4. Events exceeding by +15-25% are flagged as warnings
For example, if onboarding_permission_granted has a 48% termination rate while your baseline is 12%, that event is flagged as critical. It means nearly half the sessions that reach the permission prompt end there—the permission request is killing your onboarding.
💡 No Manual Setup Required
Unlike manual funnels, automated drop-off detection works on all your events automatically. You don't need to configure which events to watch—the algorithm surfaces anomalies across your entire onboarding flow. Read more about how the algorithm works.
🔧 Step 5: Build a Custom Onboarding Funnel
For detailed step-by-step analysis, build a custom funnel with your onboarding events in sequence. This gives you per-step conversion rates, timing data, and visual drop-off percentages.
Example Onboarding Funnel
In this example, the biggest drop happens at the permission step (65% → 38%)—a 27-percentage-point loss. The funnel analysis also shows median time between steps, so you can see if users are hesitating (long dwell time) or immediately leaving (short dwell time).
The funnel builder lets you select events in order and see proportional step widths, per-step conversion rates, drop-off counts, and timing statistics (median, mean, P25, P75). This data tells you not just where users drop off but how—whether they're thinking about it or immediately leaving.
🔒 Why Session-Based Tracking Works for Onboarding
You might wonder: can you measure onboarding completion without persistent user IDs? Yes—and for onboarding, it's actually the natural fit.
Why Sessions Map to Onboarding Naturally
- ✓ Onboarding happens in a single session — Users either complete onboarding in one sitting or abandon it. Cross-session onboarding is rare and usually indicates a fundamental UX problem.
- ✓ Session boundaries are clear — Each app launch starts a fresh session. Session IDs are generated in memory and rotate every 2 hours, giving you natural grouping of onboarding events.
- ✓ No identity complexity — You don't need to decide when a "user" starts or stops. A session has a clear beginning (app launch) and end (app close or timeout).
- ✓ Privacy by design — Session IDs are stored only in RAM and never written to disk. There's nothing to persist, nothing to delete, and nothing to audit.
The key insight: onboarding is inherently a single-session journey. If someone closes the app during onboarding and comes back later, they get a new session—and in most apps, they see the onboarding again. So session-based measurement captures onboarding completion accurately without needing persistent user tracking.
📱 Onboarding Event Examples by App Type
Different app categories have different onboarding patterns. Here are event taxonomies tailored to common app types:
🛒 E-Commerce App
onboarding_started→ Welcome screen shownonboarding_categories_selected→ User picks interest categoriesonboarding_notification_granted→ Push notification opt-inonboarding_completed→ User reaches storefront
🏋️ Fitness / Health App
onboarding_started→ First screen after installonboarding_goal_selected→ User picks fitness goalonboarding_experience_set→ User selects experience levelonboarding_schedule_set→ User picks workout scheduleonboarding_completed→ User reaches main dashboard
💼 SaaS / Productivity App
onboarding_started→ Welcome screen after signuponboarding_workspace_created→ User creates first workspace/projectonboarding_invite_sent→ User invites a team memberonboarding_tutorial_viewed→ User completes product touronboarding_completed→ User reaches main workspace
🎮 Gaming App
onboarding_started→ Tutorial beginsonboarding_tutorial_level_completed→ Guided level finishedonboarding_controls_learned→ Controls tutorial passedonboarding_completed→ User reaches main game
For a complete event taxonomy across all app categories—not just onboarding—see our guide on the analytics events every mobile app should track.
🚫 5 Onboarding Tracking Mistakes to Avoid
1. Tracking only start and complete
If you only track onboarding_started and onboarding_completed, you know your completion rate but not where users drop off. Add 3-5 intermediate events at key decision points. The extra events cost nothing—they use the same track() call—and give you actionable data.
2. Using numbered steps instead of descriptive names
onboarding_step_1, onboarding_step_2 break the moment you reorder, add, or remove steps. Use onboarding_profile_completed, onboarding_preferences_set instead—names that describe what happened, not their position.
3. Firing onboarding_started on every app open
If you fire onboarding_started every time the app opens (not just during actual onboarding), your completion rate denominator is inflated and meaningless. Only fire this event when the onboarding flow is actually presented.
4. Forgetting to track the "skip" path
If your onboarding has skip buttons, track them: onboarding_tutorial_skipped, onboarding_permission_denied. Users who skip are still progressing through onboarding—they just took a different path. Without skip events, you can't distinguish between users who abandoned the flow and users who chose to skip optional steps.
5. Not testing before release
Broken analytics are silent. If onboarding_completed never fires because of a typo, you won't know until you check the dashboard weeks later. Test your onboarding events using the pre-release testing checklist before every release.
🧩 Putting It All Together
Here's the complete workflow for tracking onboarding completion rates:
- 1. Map your flow — Identify every screen and decision point in your onboarding
-
2.
Design events — Use the
onboarding_prefix with descriptive names - 3. Add track() calls — Place them in action handlers, not view renderers
-
4.
Test before shipping — Walk through the full onboarding flow, call
flush(), and verify events in your dashboard - 5. Monitor automated drop-off detection — Let the algorithm surface high-termination events
- 6. Build a funnel — Get per-step conversion rates and timing data for detailed analysis
- 7. Iterate — Improve the worst step, release, measure again
You can also use conversion intelligence to see if completing onboarding acts as a conversion booster. If onboarding_completed is defined as a conversion event, the system automatically calculates lift scores for each onboarding step—showing you which steps most strongly correlate with downstream conversion.
❓ Frequently Asked Questions
How do you calculate onboarding completion rate?
Divide the number of sessions containing onboarding_completed by sessions containing onboarding_started, then multiply by 100. With session-based analytics, each app launch is an independent session, so you're measuring how many sessions that begin onboarding also finish it.
What is a good onboarding completion rate for mobile apps?
It depends heavily on your onboarding length and complexity. Apps with short 2-3 step flows often see 50-70% completion. Longer flows with account creation and permissions may see 20-30%. Rather than targeting a universal benchmark, focus on measuring your baseline and improving it incrementally.
How many onboarding events should I track?
At minimum, track 2 events (onboarding_started and onboarding_completed). For actionable drop-off data, track 4-8 events covering each major step. Avoid tracking every micro-interaction—focus on steps where users make decisions or where you suspect friction.
Can you measure onboarding completion without user IDs?
Yes. Onboarding typically completes within a single session, making session-based measurement a natural fit. The session ID groups all onboarding events from the same app launch together. No persistent identifiers are needed—session IDs are generated in memory and rotate every 2 hours.
How do I find where users drop off during onboarding?
Two approaches: automated drop-off detection automatically flags onboarding events with unusually high termination rates, requiring no configuration. Funnel analysis lets you build a step-by-step funnel to see exact conversion rates, drop-off counts, and timing between each step.
Disclaimer:
Onboarding benchmarks and patterns vary significantly across app categories, user demographics, and markets. The examples in this guide are illustrative—adapt the event taxonomy and funnel design to match your specific onboarding flow. Test all tracking changes before release.
Related Resources
- Event Naming Best Practices for Mobile Analytics — Design a consistent event taxonomy
- The Analytics Events Every Mobile App Should Track — Full event lists by app category
- Testing Your Analytics Implementation: A Developer's Checklist — Pre-release QA checklist
- Automated Drop-Off Detection: The Algorithm Explained — How termination rate analysis works
- Funnel Analysis Feature — Custom funnel builder with per-step metrics
- SDK Documentation — Integration guides for Swift, Kotlin, Flutter, React Native