Activation & Usage

Onboarding Help

User gets stuck → offer help → escalate if needed → continue or exit

Help users who struggle during onboarding before the friction turns into abandonment.

  • Relationship Recovery & Intervention
  • Email
  • Push
  • In-app message

Core rule

Start with the lightest useful help. Escalate only if the user still cannot move forward.

Journey plan

When to set it up

Onboarding help is worth building when the funnel report shows users stalling at a particular step, hitting the same validation error repeatedly or taking far longer than expected, and then not coming back. Before launch, define the struggle signal per step, confirm that step completion, in-app message display and push and email permissions are tied to the same user, and map in advance which step gets which kind of help (tip, guide or FAQ). If the error logs show a technical fault at that same step, fix the fault first; a help message is no substitute for an unresolved product error.

How to measure success

Incremental step completion vs control

Some stuck users get through on their own; the journey's value is how many more of the helped group complete the step than the control group that got no help, not in-app impressions or clicks.

How it is counted: All users assigned at the struggle signal to the journey or control group form the denominator; the numerator is those who complete the onboarding step they were stuck on within the same follow-up window from assignment. Whether a message was shown, delivered or clicked does not change the denominator.

Also track

  • Return-to-app rateAmong assigned users, the share who come back to the app; track returning separately from completion, because a user who returns and gets stuck again is telling you the help was not enough.
  • Contribution by escalation stepRead completions after the in-app help, the push and the email separately; if the email tier adds no completions, try capping the escalation at two touches.
  • Result by friction typeRead the form entry, technical error, guidance need and unclear step groups separately; no gap in the technical error group means the problem is on the product side.
  • Live-support requests and permission lossWatch who asks for live support after the email, who turns push off and who unsubscribes from email; a rise in support requests says the help content falls short.

How to set it up

  • Trigger and entryThe struggle signal you defined (a stalled step, a repeated error, an unusually long time) opens the journey when it appears during onboarding. Randomly assign the user at that point to the journey group or to a control group that receives no help messages from this flow; one slow session is not a signal.
  • Who must not enterThe stuck step sets the scope, and no second flow opens for the same step. Users who have already completed that step or finished onboarding stay out, no message restarts a completed step, and help is tied only to the task the user is attempting right now.
  • Timing and channelsShort in-app help for the stuck step comes first. If the step is not completed after about 1 day, a push follows; if 2 days later there is neither a return nor a completion, an email with fuller help and a live-support option goes out. Step status is checked before each touch.
  • Exit and handoffThe journey ends, and remaining messages are cancelled, when the step is completed or when the user returns to the app at the second check. If onboarding is still not complete 3 to 5 days after the email, help stops. There is no handoff; the flow closes in its own two exits.
  • Frequency and consentOne struggle gets at most three touches: in-app, push and email. Push and email are used only where that channel's permission exists; in-app help shows only while the user is in the app. Pick the help content by the type of friction detected rather than reusing one text for every step.

What to watch when reading the result

  1. 1Equal step completion in both groups means the help was shown to users who would have moved on anyway; seeing the in-app help or tapping the push does not change that. Rising returns without rising completions do not make the journey a success.
  2. 2Whatever gap you get holds for this escalation order (in-app, push, email), these waits and the struggle signal definition you chose. With no handoff, a step completion is credited to this struggle alone, and the same user getting stuck at a later step is a new entry.
  3. 3If the gap is small, put each group's user count and step completions into the A/B test significance calculator; if it is not significant, extend the follow-up window to cover at least the final wait and rerun the read before you narrow the struggle signal.
  4. 4A gap near zero in the technical error type means the help text cannot paper over a product fault; fix the fault instead of adding messages, and pause entries for that step while you do.

Frequently Asked Questions

How can I identify users struggling with onboarding?

Look for a stalled step, repeated validation errors or unusually slow progress. Define the signal before implementation. One slow session does not prove a problem. Tie help to the task the user is attempting.

Which channel should onboarding help use first?

Start with brief contextual in-app help. In this example, lack of progress leads to push after about a day and more detailed email support two days later. Explain the obstacle rather than merely asking the person to return.

When should onboarding assistance stop?

Stop help for a step once it is completed. If progress does not resume, this example ends after its final follow-up. Track returning separately from completion. Messaging cannot substitute for fixing a product error.

Explore other journeys