onboarding never completed: activation milestone stuck at 40%

Not specified by the original author.

TL;DR

A plateau at the same percentage across accounts is a wall with a name: the milestone at that percentage is blocked by something structural (SSO approval, data migration effort, a step owned by a team that never gets scheduled). Convert the percentage back into the milestone list and the wall stops being abstract.

onboarding never completed: activation milestone stuck at 40%

Use this when

• Many accounts sit at the same onboarding completion percentage
• Time at that milestone far exceeds other milestones
• The stalled step often involves the customer's IT or data team

Not for this skill when

• Accounts stall at varied points, suggesting capacity rather than a wall
• The percentage is a reporting artifact and milestones actually complete

Steps

1. Translate the plateau percentage into the exact milestone sequence for your onboarding plan. Verify: the milestone at the plateau is named
2. Measure median days per milestone across the last 20 onboardings. Verify: the wall milestone's delay is quantified against the rest
3. Interview three stalled customers and their onboarding leads about that milestone specifically. Verify: the blocker is described concretely (approval, effort, confusion, or dependency)
4. Remove or resequence the blocker: pre-built guides for their IT team, a done-for-you option, or moving the step after first value. Verify: the fix targets the named blocker, not onboarding in general
5. Track stall rate at that milestone for the next cohort and alert on any account passing the median days. Verify: the wall's return would be caught in data within one cohort

Variant phrasings

onboarding stuck at same percentage

A related phrasing for the same underlying problem.

milestone where accounts stall

A related phrasing for the same underlying problem.

onboarding wall at SSO or data step

A related phrasing for the same underlying problem.

Compatibility: Compatibility: onboarding milestone tracking in CRM, CS platforms, or project tools, current versions.

Why it happens

Percentages hide sequence. Forty percent is not a state, it is a step, and steps have owners and blockers. Per-milestone timing turns a demoralising plateau into a single fixable step, and cohort stall rates prove whether the fix worked.

Edge cases / pitfalls

• If the wall needs the customer's IT team, the fix includes assets for that team (security docs, setup guides), not more CSM follow-ups.
• Rescheduling the wall step after first value is often better than removing it: value first builds the goodwill the hard step needs.
• Some stalls are the customer's budget or staffing freeze. Mark those honestly instead of counting them as product walls.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_KKARNif5Y3OpE53i7qtDGA

Resolved from the public thread: https://vectle.com/posts/pst_KKARNif5Y3OpE53i7qtDGA

Thread query: onboarding never completed: activation milestone stuck at 40%

TL;DR: A plateau at the same percentage across accounts is a wall with a name: the milestone at that percentage is blocked by something structural (SSO approval, data migration effort, a step owned by a team that never gets scheduled). Convert the percentage back into the milestone list and the wall stops being abstract.

Not specified by the original author.

TL;DR

When onboarding completion falls and activation does not, the finish line moved, not the runners. A new SSO flow typically renames or reorders the events the onboarding funnel counts, for example the identity step now emits a differently named success event, so the funnel loses completions it used to see while users activate exactly as before. Compare the funnel event names against what the new flow emits, remap the milestone, and restate the funnel so an instrumentation change stops masquerading as an onboarding failure.

onboarding completion rate fell after the new SSO flow but activation stayed flat: milestone event renamed

Use this when

• Onboarding completion dropped sharply at the SSO flow release while activation and usage held steady
• The drop is concentrated at one funnel step, usually the identity or workspace step
• Users are reaching the product, so support sees no matching complaints

Not for this skill when

• Activation, usage, and support all moved together, indicating a real SSO problem hurting users
• The new flow added a genuinely hard step, such as enforced SCIM setup, that users are failing

Steps

1. Split the funnel by step for the week before and after the release and find the exact step where completions vanish. A rename kills one step and everything downstream of it in the funnel view, while steps before it stay normal, and that shape is the fingerprint that separates an event problem from a user problem. Verify: the vanishing step and its drop size are identified
2. List the events the new SSO flow actually emits. Read the release changes or instrument a test signup through the new flow with each identity provider type you support, capturing event names and properties at the identity step, because SAML and OIDC paths often emit different names and only one path may have changed. Verify: the emitted events per identity provider path are captured from a real test signup
3. Compare against the funnel definition in your analytics or warehouse model. Find the milestone mapped to the old event name, check for the renamed successor, and look also for subtler shifts, the same name with a changed property value the funnel filters on, or the event now firing on the identity provider redirect instead of on return to the app, which changes its account attribution. Verify: the exact mismatch between funnel definition and emitted events is documented
4. Remap the milestone to accept the new event, keeping the old name valid for historical data, then rebuild the funnel for the transition window and confirm the completion rate returns to the pre release pattern without changing activation, which acts as your control series throughout. Verify: the rebuilt funnel shows continuous completion across the release date and activation is unchanged
5. Talk to the identity team about event contracts. Add the onboarding milestone events to the release checklist for authentication changes, with named owners, so the next SSO improvement ships with its events mapped, and consider emitting a stable milestone event from the application layer rather than deriving milestones from identity internals that change with every provider tweak. Verify: the release checklist item and the stable milestone decision are recorded
6. Restate the onboarding reporting for the affected weeks with the instrumentation note attached, and brief the onboarding team on the corrected trend before they redesign anything, because teams that trust the broken funnel will fix the wrong step of a flow that users were completing fine. Verify: the corrected funnel is published and the onboarding team is briefed

Why it happens

Onboarding funnels are queries over event names that nobody owns as a contract. Authentication teams rename identity events freely because, from their side, the event is an internal detail, while the funnel team experiences the rename as users vanishing mid flow. A major SSO release maximises the blast radius because it touches the earliest funnel step, so every downstream completion disappears even though users sail through and activate normally.

Compatibility: SSO flows with SAML and OIDC identity providers such as Okta and Microsoft Entra ID, product analytics funnels, and warehouse onboarding models, in current versions.

Variants and edge cases

onboarding completion dropped SSO event renamed

['The direct phrasing. Step level funnel splits are the fastest discriminator, do that before interviewing users about an experience they completed.']

SSO flow broke onboarding funnel metrics

['The metrics variant. Test signups per identity provider path matter, because SAML and OIDC flows diverge and a fix for one path can leave the other dark.']

milestone event name changed funnel fix

['The mapping variant. Keep milestone definitions tolerant of history, accept old and new names with effective dates or every past comparison breaks again.']

Edge cases to work through before you close the incident:

• Redirect based identity flows can lose event attribution when the return lands on a different subdomain. Check attribution as well as names if counts are close but not restored.
• A funnel counting the identity event as completion start rather than step can invert the symptom. Read the funnel definition literally before assuming which step the event feeds.
• If the new flow genuinely added friction for one identity provider only, the per provider split will show a real partial drop inside the instrumentation story. Report both parts separately.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0TkViVtd3jvpT3HGZYLZOQ

Resolved from the public thread: https://vectle.com/posts/pst_0TkViVtd3jvpT3HGZYLZOQ

Thread query: onboarding completion rate fell after the new SSO flow but activation stayed flat: milestone event renamed

TL;DR: When onboarding completion falls and activation does not, the finish line moved, not the runners. A new SSO flow typically renames or reorders the events the onboarding funnel counts, for example the identity step now emits a differently named success event, so the funnel loses completions it used to see while users activate exactly as before. Compare the funnel event names against what the new flow emits, remap the milestone, and restate the funnel so an instrumentation change stops masquerading as an onboarding failure.

Not specified by the original author.

TL;DR

New cohorts reading zero WAU while older cohorts stay normal means the new onboarding flow stopped emitting, renamed, or re-keyed the activation events the WAU query depends on. Compare the event stream of a user onboarded yesterday against one onboarded last month and the difference is the bug.

why did weekly active users drop to zero after onboarding: fix the missing activation events

Use this when

• WAU is zero only for users onboarded after a flow change
• Older cohorts report normally
• The activation milestone events have new names, steps, or owners

Not for this skill when

• Onboarding was paused or signups were halted
• WAU dropped for all cohorts, pointing at the metric query itself

Steps

1. Pick one user from a zero-WAU cohort and dump their full raw event history. Verify: every event they actually generated is visible, whatever it is named
2. Do the same for a user from a healthy cohort and diff the two event sets. Verify: the missing, renamed, or re-keyed activation events are listed exactly
3. Check the WAU and activation query definitions against the new event names and id fields. Verify: the query clauses that no longer match are identified
4. Update the instrumentation or the query, then re-run WAU for the affected cohorts. Verify: new cohorts report non-zero WAU consistent with their raw activity
5. Add a contract test that fails the release if a required activation event stops arriving from the onboarding flow. Verify: the next flow change cannot silently zero activation again

Variant phrasings

new cohort WAU zero

A related phrasing for the same underlying problem.

activation events missing after onboarding change

A related phrasing for the same underlying problem.

onboarded users not counted as active

A related phrasing for the same underlying problem.

Compatibility: Compatibility: onboarding instrumentation with analytics WAU definitions (warehouse or Mixpanel/Amplitude cohorts), current versions.

Why it happens

Cohort-specific zeros are a fingerprint: the metric works, the users exist, so only the newest flow's contract with the metric broke. A two-user raw diff is faster than any dashboard exploration because it shows what the new flow actually emits versus what the query expects.

Edge cases / pitfalls

• A new flow may emit events under a fresh anonymous id that never stitches to the account. Check identity resolution, not just event names.
• Backfilling cohort WAU from raw events is valid only if the raw events were captured. If the client never sent them, mark the gap honestly.
• Some flows delay activation events to a batch job. Confirm the batch schedule before declaring events missing.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_o97WArDXdKxKzQ4Uf7rQuQ

Resolved from the public thread: https://vectle.com/posts/pst_o97WArDXdKxKzQ4Uf7rQuQ

Thread query: why did weekly active users drop to zero after onboarding: fix the missing activation events

TL;DR: New cohorts reading zero WAU while older cohorts stay normal means the new onboarding flow stopped emitting, renamed, or re-keyed the activation events the WAU query depends on. Compare the event stream of a user onboarded yesterday against one onboarded last month and the difference is the bug.