Visitor journeys and retention, aggregate-first

"How do people move through the site?" and "do they come back?" are the two questions where analytics tools usually reach for the creepy toolbox: session replay, persistent user IDs, cross-site profiles. Tracely answers both, and the design constraint was doing it without any of that.

Journeys

The Visitor journeys view shows recent browsing trails: for each session in the selected period, the ordered sequence of pages, collapsed so a refresh doesn't render as /pricing → /pricing → /pricing. Each trail carries only coarse context — device, country, language, viewport — and is labeled with a short anonymous id derived by hashing the session, not a persistent person identifier. Trails cap at 40 steps, because past that point you're not reading a journey, you're rubbernecking.

You can filter the session list by country, source, device, browser, OS, or by "sessions that touched this path," and the filters are session-level: a session qualifies if any pageview in range matches, but you still see its full trail.

The part I use most isn't the individual trails, though — it's the aggregates layered on top:

Journey stats. For the filtered population: sessions, pageviews, average pages per session, the single-page share, average session duration, and a depth distribution (one page, 2–3, 4–7, 8+). This tells you the shape of engagement before you look at a single trail.

Top transitions. The most common consecutive page-to-page steps, computed from a sample of the most recent few hundred sessions. This is the "how do visitors actually move" answer in one table — which pages feed your pricing page, where readers go after the post that's ranking — without a Sankey diagram or a graph database.

Retention

Retention is cohort-based and visitor-bucket-based, nothing more. Every first-time visitor joins the cohort for the calendar day of their first pageview, and the report shows how many of each cohort returned within 1, 7, and 30 days. That's the whole model: "of the people who first showed up Tuesday, how many came back within a week?"

When the marketing toggles are on, cohorts can also be sliced by aggregate segments carried in client signals — first-touch campaign, source, and medium, plan tier, affiliate code — so you can compare whether visitors from one campaign return better than another. The docs are honest about the failure mode here: thin new sites show jagged, sparse grids. Retention needs volume and time; there's no fixing that with UI.

The obvious caveat applies and I'd rather state it than hide it: a "visitor" is a hashed bucket for a browser context, not a human. Clear your cookies and you're a new visitor. Retention numbers built this way modestly undercount true return rates, which is the right direction for an error to point.

The visitor profile, framed carefully

There is a visitor profile page — a drill-down from journeys or pages showing recent views and paths for one hashed visitor bucket. I went back and forth on whether it belonged in a privacy-first tool at all, and the deciding factor was the support workflow: "a user says checkout broke around 3pm" is a real question, and finding the matching trail answers it.

So the profile exists, but the framing is deliberate. It shows paths, timestamps, and coarse aggregates for one bucket on one site. It does not show names, emails, or account IDs unless you deliberately sent them in custom events (please don't). There is no session replay, no recordings, no cross-site anything — those are documented non-goals, not missing features. And the docs push you back toward aggregates for anything beyond debugging: one profile explains one thread, never a trend.

That's the pattern across both features: individual-level data exists briefly and coarsely where a debugging workflow demands it, and every question about behavior at large gets answered from aggregates. If you're weighing this against tools that lead with replay, the comparison pages lay out where Tracely sits.