Journeys

A journey is an ordered set of up to ten steps that walks end users through your app toward a goal, such as creating their first order. Each step opens a page of your app, points at an action or field that page lends, and shows a title and a line or two of text beside it. End users see nothing of a journey until a member publishes it.

Journeys live under a project. Open the project and choose the Journeys tab. The list shows each journey by its goal with its name under it, whether it is a draft, published, or published with unpublished changes, what starts it, a bar per published step for the share of end users who reached it, and how many end users started and completed it over the last 30 days. A step that points at something the page catalog hasn’t seen shows its warning in amber under the goal.

Write one

Press New journey, or New journey from this page on a page of the Pages tab to start with a step there. The journey’s goal is its title. On the Steps tab, the steps run left to right after a Start card, each drawn as the card end users see, with its page and what it points at above it. Select a card to edit it in the panel below. There is no Save button: the journey saves as you type, and a line under the buttons shows while it saves, or what it still needs. A new journey is saved once it has a name, a goal and one step with a title.

On Start:

• Name: lowercase letters, numbers and hyphens, unique in the project. Your code and links start the journey by this name.
• Goal: what the journey is for, in a sentence. Your team and coding agent read it; end users never do.
• Starts: what starts it by itself. See What starts a journey.

Press Add step, then pick for the step:

• Points at: a page from the project’s page catalog, the assisted pages your app has shown or your coding agent posted, and an action or field it lends or the page itself. The list groups the catalog by page; open a page to choose, or search pages, actions and fields by name. An action step passes when the end user presses it, a field step when they change it and move on, and a step on the page itself when they press Next. Every step also offers Next, which reads Done on the last.
• Title and Body: the words shown beside the step.

A step on a page with an :id in its path, such as /orders/:id, never opens that page by itself. It shows once the end user has one open, usually from the step before. A name lent by every row of a list points at the first row.

Each card’s menu moves the step earlier or later, or deletes it. Once the journey is published, the arrows between the cards show how many end users reached each step.

The project’s Pages tab lists the catalog. Select a page to see its instructions, the actions and fields it lends, when each was last seen, and which journey steps point at each one.

Steps the catalog hasn’t seen

A step shows in amber when the page catalog has no such page, the page doesn’t lend that action or field, or the catalog hasn’t seen it for 30 days. Playback waits five seconds for what a step points at, then skips the step and counts it as missed. The warning doesn’t stop you publishing, since a page reports what it lends only once your app shows it.

What starts a journey

• When an end user opens the first step’s page: the journey starts by itself the first time an end user is shown that page, once per end user. A journey they finished or closed never starts by itself again, and one they left halfway resumes where they were. If two journeys match, the older one plays first.
• Only from your code or a link: nothing starts it by itself.

Either way, your code can start it with startJourney("<name>") from useAssisted(), and a link can with ?journey=<name> on any page of your app. Both start it from the first step, even for an end user who already finished it.

Publish

End users see the published copy only. Publish copies the steps and what starts the journey to the published copy, and the badge then reads Published with when. After that, edits change the draft alone, the badge reads Unpublished changes, and Publish changes appears. A rename or a new goal applies at once.

The menu at the end of the buttons holds:

• Discard changes: while there are unpublished changes, puts the steps and the trigger back to the published copy.
• Delete journey: deletes it with its funnel and every end user’s progress, after you confirm.

Your coding agent can draft journeys through the API for you to review, signed in as you on the MCP server or with an organization key; see Set up through the API. Only a member can publish one, so an organization key can’t.

Try in app

Try in app opens your app with ?journey=<name> on the project’s first allowed origin that isn’t a wildcard, and its menu lists the others. It plays the published copy, so it waits for the first publish, and unpublished changes don’t show until you publish them. Its runs count in the funnel like anyone else’s.

The funnel

The Results tab shows how end users who started the published journey over the last 7 or 30 days got on:

• Started, Completed, Dismissed and In progress, each a count of end users.
• One bar per published step, split into those who passed it, those on it now, those who missed it because playback couldn’t find what it points at, and those who closed the journey there.
• The latest end users with where each one is, the steps they missed, and when they started and were last active.

The funnel counts by step number against the published copy, so a step you moved in an unpublished draft keeps its old numbers until you publish.