We need to see where people fall out of the onboarding conversation, which means an event at each point where they could.
Rough shape of the funnel:
- onboarding opened
- first question answered
- workspace provisioned
- plan presented
- plan approved
- flows built
- deployed
- connection instructions delivered
Plus the exits: took the way out, and abandoned without doing either.
Done when
- A single signup can be followed end to end in PostHog.
- Each drop-off point is distinguishable from the others.
- Leaving via the way out is distinguishable from just abandoning.
Worth knowing
There's an existing pattern to follow. Product.capture is already used for the tour (ff-tour-start, ff-tour-cancel, ff-tour-step-forward and so on), and the education modal captures on its links, so naming and shape can follow those rather than inventing a convention.
A couple of the events aren't purely frontend. "Workspace provisioned" and "deployed" both happen elsewhere, so it's worth deciding whether the browser reports them when it learns about them, or whether the backend captures them via app.product.capture. Mixing both makes the funnel harder to reason about, so probably better to pick one.
Worth agreeing what counts as the success event before building this, because it's the number the epic gets judged on. "Opened the editor" is the old measure and it doesn't really fit a flow where the Expert does the building. Something closer to "the thing they asked for is running" is truer but harder to detect.
Being able to tell the two cohorts apart in the data is the sibling task's job, but this needs to carry whatever identifies them on every event or the comparison won't be possible after the fact.
We need to see where people fall out of the onboarding conversation, which means an event at each point where they could.
Rough shape of the funnel:
Plus the exits: took the way out, and abandoned without doing either.
Done when
Worth knowing
There's an existing pattern to follow.
Product.captureis already used for the tour (ff-tour-start,ff-tour-cancel,ff-tour-step-forwardand so on), and the education modal captures on its links, so naming and shape can follow those rather than inventing a convention.A couple of the events aren't purely frontend. "Workspace provisioned" and "deployed" both happen elsewhere, so it's worth deciding whether the browser reports them when it learns about them, or whether the backend captures them via
app.product.capture. Mixing both makes the funnel harder to reason about, so probably better to pick one.Worth agreeing what counts as the success event before building this, because it's the number the epic gets judged on. "Opened the editor" is the old measure and it doesn't really fit a flow where the Expert does the building. Something closer to "the thing they asked for is running" is truer but harder to detect.
Being able to tell the two cohorts apart in the data is the sibling task's job, but this needs to carry whatever identifies them on every event or the comparison won't be possible after the fact.