Product tours
Guided walkthroughs, running inside your app
A product tour steps a new user through your interface until they reach the thing that made them sign up. Here’s what they are, what makes one work, and how to ship one without writing a tour engine.
$19/mo flat — no per-user pricing. No credit card required.
Types
Five patterns that all get called “product tour”
It's a category, not a single pattern. Most SaaS products end up shipping at least three of these.
- Next
Welcome tours
The first tour a new user sees, on their first sign-in. Get them from sign-up to the first action that delivers value.
- Trigger
- First sign-in
- Length
- 3–5 steps
- Reports
- AutomationsNew
- Settings
1 of 1Got itFeature announcements
Triggered when you ship something new. Tells existing users about a feature they'd otherwise miss — frequency-capped so power users don't see it twice.
- Trigger
- You ship something
- Length
- 1–2 steps
- Create a project
- Invite the team
Secondary onboarding
Runs after activation to introduce depth — advanced settings, integrations, team features. Triggered by user state, not by a timer.
- Trigger
- Post-activation
- Length
- Varies
- role = adminNext
Training tours
Aimed at admins, power users, or new hires inside a customer account. Longer, and role-targeted so only the right people see them.
- Trigger
- Role or plan
- Length
- 5–10 steps
- Usage alerts?
Activation nudges
Single-step prompts — a tooltip, a contextual hint, an empty-state CTA. Most platforms ship them under the same SKU as full tours.
- Trigger
- A single moment
- Length
- 1 step
Definition
What is a product tour?
The short answer, then the parts it's made of.
A product tour is a guided in-app walkthrough that highlights features or onboards new users to a SaaS product. Tours appear as overlays, tooltips, or modals anchored to UI elements, stepping users through a path. They’re triggered by user state — first sign-in, feature release, plan upgrade — and dismissed once completed.
Done well, a tour helps a new user reach their first meaningful action faster. Done poorly, it’s a forced sequence of blue dots people dismiss without reading. The rest of this page is about the difference.
- Overlay
- Dims the rest of the page so one element is obviously the subject.
- Spotlight
- The cut-out around the target element, positioned from a CSS selector at runtime.
- Popover
- Copy, step counter, and controls — anchored to the target and repositioned when it moves.
Terminology
Tour vs. walkthrough vs. demo vs. tooltip
Three of these four words get used interchangeably. Only one of them names something genuinely different.
| Surface | Sequenced? | Trigger | Lifespan | Best for |
|---|---|---|---|---|
| Product tour | Yes — ordered steps | User state (sign-in, upgrade, release) | Dismissed once completed | Walking someone through a workflow in order |
| Walkthrough | Yes — often used interchangeably | Same as a tour | Same as a tour | The same thing. In practice the two words name one pattern; pick one and stay consistent |
| Interactive demo | Yes | A link you send | Lives outside the product | Prospects who have not signed up — a clickable replica, not your live app |
| Tooltip | No — one element | Hover, click, or first encounter | Stays available indefinitely | Contextual help that should still be there in six months |
If you need a single-element hint rather than a sequence, that’s an in-app tooltip. If you need to reach people who haven’t signed up yet, that’s an interactive demo, and it lives outside your product.
Judgement
When to use a product tour — and when not to
The most useful thing this page can tell you is when the answer is “don't” — a tour is sometimes a crutch for UX you should fix instead.
Reach for one when
- Your product has workflows that aren't obvious from the screen alone.
- Onboarding drop-off is measurably high, and you know at which step.
- You ship features users keep missing — shipped, but nobody clicked.
Skip it when
- The product is self-evident — a tour would explain what the buttons do.
- Your audience is technical and resents hand-holding.
- A better empty state, or one good CTA, would do the same job for less.
Would the screen itself make the next step obvious with a better empty state or one clear CTA?
Fix the screen firstIs the workflow genuinely multi-step — something no single screen can make self-evident?
The hardest case to call is the tour as a crutch. If you’re reaching for one because users keep getting stuck somewhere, ask whether you’d still need the tour if the screen made the next step obvious. If the answer is no, fix the screen first.
Best practices
What separates a finished tour from a dismissed one
Six habits, and the anti-pattern each one replaces.
- Plays on every page load until the user rage-quitsRuns once per user, or once per meaningful state change
- Nine steps explaining what every button doesThree to five steps ending at the first real action
- Skip hidden, or only on the first stepSkip visible on every step — it raises completion, not lowers it
- Anchored to a CSS class the next redesign renamesAnchored to a stable `data-tour-target` attribute
- The same tour for admins, end users, and free plansTargeted by role, plan, and page before it ever plays
- Shipped, then never looked at againPer-step views and drop-off tracked, so step 3 gets rewritten
Ends before attention does. Everything past the activation moment belongs in a second tour.
The grey dots are the ones most people never see. Length is the most common reason a tour is abandoned.
- Brevity
- First-run tours work best at 3–5 steps. Past five, completion falls off sharply. A sixth step usually belongs in a separate secondary-onboarding tour triggered after the first activation milestone.
- Skippable, always
- Make Skip visible on every step, not just the first. Counter-intuitively, an obvious skip button increases completion, because it removes the “is this thing going to end?” anxiety.
- Triggered by state
- A tour should run once per user, or once per state change such as a plan upgrade. Implement frequency capping at the platform level so individual tour authors never have to think about it.
- Targeted
- A tour aimed at admins shouldn’t play for end users, and a Pro-plan feature tour shouldn’t play for free users — that’s a paywall, not onboarding.
- Anchored to stable selectors
- The biggest cause of tour breakage in production is anchoring to elements whose CSS classes or DOM position change during a redesign. Use stable test IDs where you can, and audit tours before each release.
- Measured
- Without analytics you only know a tour exists, not whether it works. Track per-step views, completion rate, and drop-off point.
Capabilities
Everything a tour needs to actually ship
Rendering the overlay is the easy part. These are the pieces around it — all configured in the dashboard, none of them your engineers' problem.
Point-and-click builder
Build tours visually in the dashboard, then edit the copy the same way. Non-engineers ship and change tours without filing a ticket.
Targeting
Role, plan, page URL, custom attributes — combined with AND. “Only admins on Pro” is a checkbox, not a custom JS function.
Page-level visibility
URL pattern rules decide where a tour is even eligible to play, before targeting narrows it further.
Frequency capping
Show-once-per-visitor is the floor. StepsKit caps at the platform level, so a tour author never has to think about it.
Themed to your brand
Match your colours in a theme editor rather than fighting CSS overrides, with per-step overrides where you need them.
<script
async src="https://cdn.stepskit.com/stepskit.latest.js"
data-api-key="sk_live_a3f...">One script tag
A single async script, no bundler required. Or install the typed npm package if you already have a build step.
Measurement
How to tell whether a tour is working
Three numbers. A tour with 80% completion and no downstream lift is decorative, not effective.
Drop-off by step
The shape that tells you which step to rewrite. A cliff at step 3 of 5 means step 3 is the problem — not step 5.
Completion rate
What share of the people who started reached the final step. Useful only next to the drop-off step that explains it.
And the one that actually decides it: time to first action
Completion and drop-off tell you whether the tour was watched. Neither tells you whether it worked. Compare how long people who finished the tour took to reach your activation event against people who skipped it. If the two cohorts look the same, the tour is decorative — a tour with 80% completion and no downstream lift is a tour worth deleting.
For how these numbers map to real goals, see user onboarding and feature adoption.
Build
How to build a product tour
Four steps in the dashboard — or a rendering library and a quarter of glue code. The break-even is usually around three or four tours.
- 1
Install the embed
One async script tag, or the typed npm package if you already have a build step. Tours, tooltips, and announcements all ride the same install.
- 2
Anchor steps to your live UI
Build the tour in a point-and-click builder against your real app — each step anchors to an element by its CSS selector.
- 3
Set targeting and frequency
Decide who sees it — plan, role, URL pattern — and cap it to once per visitor so nobody sits through it twice.
- 4
Publish — no deploy
The tour goes live on the domains you choose, straight from the dashboard. Copy edits never wait for a release train.
Hand-coded with a JavaScript library
Open-source rendering libraries such as Shepherd.js or react-joyride handle the overlay, popover, and keyboard navigation. Around them you still have to build:
- targeting — which user sees which tour
- frequency capping — so the same tour doesn't replay
- analytics — per-step engagement
- a content surface — so non-engineers can edit copy
Fine for one or two tours with a spare engineer. It stops being fine the moment a marketer wants to ship a tour without filing a ticket.
No-code platform
Platforms including StepsKit, Appcues, Pendo, ProductFruits, and Userpilot ship rendering, targeting, frequency capping, a content editor, and analytics as one product. You do a one-line install and build tours visually in a point-and-click tour builder. The trade-off is a recurring subscription instead of one-time engineering time.
<script
src="https://cdn.stepskit.com/stepskit.latest.js"
data-api-key="YOUR_API_KEY"
async
></script>Weighing a specific incumbent? See how StepsKit compares to Pendo, UserGuiding, and WalkMe, or the full roundup of the best product tour software.
Built for real apps
Engineering you don't have to do
The embed is the part of a tour platform you live with in production, so it's the part worth checking first.
- Under 15 KB, loaded async
- One script tag or the typed npm package, under 15 KB gzipped and loaded asynchronously — no impact on page load or Core Web Vitals.
- Works in single-page apps
- Steps are positioned from CSS selectors at runtime and repositioned when the target moves, so tours run in React, Next.js, Vue, Angular, or plain HTML.
- Show-once, enforced server-side
- An identified visitor who completed or dismissed a show-once tour has it filtered out before the payload ever reaches the page — capping survives cleared cookies and new devices.
- Published, not deployed
- Tours are content, not code. Authoring, edits, and rollout all happen in the dashboard, scoped to the domains you allow — your app never redeploys for a copy change.
Buying
How to choose product tour software
Roughly in the order these affect your bill and your day-to-day.
| Criterion | What to check | StepsKit |
|---|---|---|
| Pricing model | Most platforms price per MAU — the number you're trying to grow is the number that grows the bill. | $19/mo flat, no per-user fee |
| No-code authoring | Can a non-engineer build a tour without filing a ticket? If not, you're paying for convenience you aren't getting. | Point-and-click visual builder |
| Targeting | Role, plan, page URL, custom attributes. “Only admins on Pro” should be a checkbox, not a custom JS function. | Attribute rules, combined with AND |
| Frequency capping | Show-once-per-user is the floor. Better: show-once-per-state-change, so a tour can re-run when something shifts. | Show-once per visitor |
| Analytics depth | Minimum: per-step views, completion rate, drop-off step. Bonus: event funnels you can pipe into your own tool. | Per-step funnel + drop-off |
| Theming | Can you match your brand without writing CSS overrides? If not, you'll spend hours fighting the defaults. | Full theme editor, per-step overrides |
| Web vs. mobile | Most product tour software is web-only. A native mobile app shortens the shortlist considerably. | Web (including SPAs) |
The one that bites hardest later is the first row. Most platforms price per monthly active user, so the number you’re trying to grow is the number that grows the bill. StepsKit is $19/mo flat, which decouples the cost from your success.
AI agents
Author tours from your codebase
StepsKit ships an MCP server, so an agent that already reads your components can write the tour that walks through them.
Claude Code, Cursor, and any other MCP client can create, list, update, and delete tours — picking real selectors out of your own JSX instead of guessing at them. Agents create tours unpublished, so nothing reaches your users until you publish it in the dashboard.
$ npx -y @stepskit/mcp
✓ StepsKit MCP connected
> point out the new CSV export
✓ Tooltip created on #export-btnStop losing users before they see the value
Build your first tour in 5 minutes. No engineering ticket, no credit card required.