Pre-launch
Your tours are shipping. Are they working?
cairnkit already knows every step a user saw and every one they walked away from. Cloud is where that goes: completion rates, the step that loses people, and a Slack message the moment a tour breaks in production.
New to cairnkit? Start with the library. It is MIT, and it works without any of this.
Completion
-6 pts
Tours started
+18%
Broken anchors
since Tue
Analytics
One step is usually doing all the damage.
A tour either gets people to the thing or it does not. Completion tells you which; the step-by-step view tells you what to change.
- 100%
- 94%
- 88%
- 47%
- 41%
- 38%
41 points lost in one step. Step 3 opens a settings panel that covers the button step 4 points at, so the guide spotlights something nobody can reach.
And it says what they mean
closed > skipped
More people closed this tour than skipped it. That usually means the card is covering the thing it points at, rather than that the tour is unwanted. Check the step placement before cutting steps.
fewer than 10 sessions
Counts only for now. A completion rate from 6 sessions would move by tens of points on the next one. Percentages appear at 10.
Completion rate
How many people who started a tour reached the end of it, per flow and per version.
Drop-off by step
The exact step people leave on. Usually one step is doing all the damage.
Per key
Every figure narrowed to one API key, so the marketing site and the app are separate numbers rather than one average.
Broken anchors
Tours pointing at UI that no longer renders, caught in production rather than in review.
Version comparison
Bump a flow's version, rewrite two steps, and see whether it actually got better.
Per-tenant breakdown
Completion split by account, so you can tell a bad tour from a hard customer.
How it works
Nothing changes about how you write tours.
cairnkit already emits an event every time a step is seen, a flow finishes, or an anchor goes missing. Today they go to your console. Cloud gives them somewhere to land.
- 01
Add a key
One environment variable on the provider you already mount. No new dependency, no change to a single flow file.
- 02
Ship as normal
The events cairnkit already emits get forwarded instead of dropped: step viewed, flow completed, anchor missing.
- 03
Read what happened
Which step loses people, which tours nobody finishes, and which anchor broke in production before support hears about it.
Integrations
The broken tour finds you.
Nobody opens a dashboard to check whether onboarding still works. So the signal goes to where you already are, and only the ones worth interrupting for.
Slack
Route each event to the channel that owns it. A broken anchor goes to engineering, a drop-off goes to product.
Webhooks
The same payloads over HTTP, signed, so you can put them wherever you already look.
GitHub
Open an issue when a tour breaks, with the flow, the step, and the anchor that went missing.
import { CairnProvider } from "@cairnkit/react";
<CairnProvider
flows={flows}
onEvent={(e) => posthog.capture(e.name, e.props)}
/>- PostHog
- Segment
- Amplitude
- Mixpanel
- your endpoint
Your events already go wherever you send them.
onEvent ships in the MIT package. It fires on every signal a tour emits and takes any function you write. No account, no cloud, nothing to wait for.
Cloud reads every session together. That is how it knows an anchor broke six days ago and 412 people have hit it since. Your app only ever sees one session at a time.
Waitlist
It is not open yet.
We are building this against a real product with real tours, the same way the library was built. Leave an address and we will tell you when there is something worth logging into.