onboarding completion rate fell after the new SSO flow but activation stayed flat: milestone event renamed
Fixes onboarding completion falling after a new SSO flow while activation stayed flat, because a milestone event was renamed, by restoring the milestone mapping. Use when one onboarding metric drops at a release. Not for a real activation drop visible in product usage.
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 renamedUse 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
- 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
- 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
- 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
- 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
- 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
- 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