Journeys and goals

Once the state engine has built your product’s state graph, the path engine mines it to answer the question analytics is really for: what are users trying to accomplish, and where do they fail?

​

From graph to journeys

The path engine runs per project over the state graph and its real traffic weights. It looks for coherent paths through the graph: sequences of screens that many users traverse toward an outcome, such as landing page to pricing to signup to first project. Each mined journey is called a goal.

​

Steps and loops

A journey is a sequence of steps. A step is usually a single screen (state), but the engine also recognizes loops: repeated regions of the graph where users cycle through the same few screens, such as a filter-refine loop on a search page or a retry loop on a failing form. Loops are represented as a single step rather than an unreadable tangle of repeated screens.

​

Validated against real sessions

Mined paths are validated against real session trajectories before they are reported. A journey only ships if actual sessions traversed it, so you never see a “path” that is merely a plausible walk through the graph. Reported paths happened.

​

What each goal includes

For every goal, the engine produces:

• An AI-written name and summary describing what the journey accomplishes in product terms.
• Per-step analysis: what happens at each step and what role it plays in the journey.
• Drop-off rates for each step, computed from real traffic counts, not estimates.

​

Freshness

Goals are synced to the dashboard roughly daily per project. New traffic continuously reshapes the state graph, and the next mining run picks up the changes.

​

How goals are used

Goals are a primary input for the AI agents: a goal with a steep drop-off at one step is exactly the kind of evidence an agent turns into an insight, a design proposal, or a drafted ticket.