PostHog has confirmed it’s retiring its built-in product tours feature on 26 September 2026, redirecting engineering effort to other parts of the platform. For teams that leaned on it to walk new users through a first-run experience, the tool going away is a product decision they didn’t make but now have to react to — and the bigger issue isn’t the tour UI itself, it’s the analytics that came bundled with it. Step-by-step completion and drop-off data for a guided tour is exactly the kind of thing teams build once, trust implicitly, and never re-instrument, because the platform was doing it for them by default.
That’s the real exposure here. If your only record of onboarding step completion lived inside PostHog’s product tours reporting, that visibility ends the same day the feature does — not gradually, not with a fallback, just gone. Teams that migrate to a third-party tour library or roll their own tooltips often get the UI back within days, but silently lose the underlying event data unless someone deliberately rebuilds it as part of the migration rather than treating it as a UI-only swap.
Data Points to Track
- Tour step reached and step completed, logged as discrete events with a step index and step name, independent of whichever tour rendering library ends up in place
- Time spent per step, to distinguish a step users read carefully from one they’re stuck on or trying to dismiss
- Skip and dismiss events, separated from natural completion, since a high skip rate on an early step is a different problem to a high skip rate near the end
- Tour completion rate segmented by entry point, since users triggering a tour from onboarding versus from a help menu later behave very differently
- Downstream feature adoption for tour-completers versus skippers, to confirm the tour is still doing its job of driving activation, not just running
Setup Steps
- Decouple onboarding event tracking from the tour rendering library before you migrate, so step-completion events are fired by your own code regardless of which UI tool displays the tour.
- Export PostHog’s historical product tours data before 26 September 2026, so you retain a baseline to compare against once the replacement is live.
- Pick a replacement tour library or build a lightweight in-house version, and wire the same step-index event schema into it from day one rather than inventing a new one.
- Backfill a manual QA pass through every tour step after migration, confirming events fire in the same order and at the same points as the old implementation did.
- Set a short-term dashboard alert on tour completion rate, watching for an unexplained drop in the weeks after migration that would indicate an instrumentation gap rather than a genuine behaviour change.
Actionable Insights
Rebuilding onboarding event tracking as its own layer, independent of whatever renders the tour, means a future tool change — vendor sunset or your own redesign — never again costs you the underlying data. In the shorter term, comparing pre- and post-migration completion rates tells you whether the new tour implementation is functionally equivalent or whether it’s introduced friction (a slower load, an extra click to dismiss) that the old one didn’t have. That comparison is only possible if the event schema stayed consistent across the switch, which is the main reason to treat this as an instrumentation project and not just a UI replacement.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert