The first article I wrote about Trailguide was about why tours should live in your repo as JSON files. The engineering case: version control, CI testing, no vendor lock-in. This one is about what happens after you ship a tour. The part most teams skip You add an onboarding tour. Users start seeing it. You move on to the next feature. Three months later someone asks "is that tour still working?" and nobody actually knows. That is the default state for most teams. You built the tour, you have no data on it, and the only signal you get is the absence of complaints. What you actually want to know is pretty simple: how many people start the tour, how many finish it, and which step is where most of them leave. What the analytics actually show Trailguide Pro tracks this without any setup. No events to wire up, no analytics SDK to configure. When you open the dashboard for a trail you see a completion funnel. Each step has a bar showing what percentage of sessions made it that far, color coded by health.…