Analysing User Paths: Where Visitors Leave the Trail

Paths, not page lists: the edge is the metric

A user path is the ordered sequence of pages a session has touched: entry, intermediate steps, last view. What is interesting about it is rarely the sequence as a whole - what matters are the transitions between any two pages. Every transition is an edge with three properties: which page it comes from, which page it leads to, and how many sessions take it. Place all the edges of a week side by side and a transition matrix emerges - a table in which every row is a source page and every column a target page, with the number of moves in each cell. That table holds the answer to the question of where a journey ends that ought to have continued.

The common metrics stay one level above this. Page views count visits, the exit rate counts how often a page was the last one in a session, the bounce rate counts sessions with exactly one view. All three are properties of a single page. They answer the question of where, but not the question of where to - and without the where to, every measure remains guesswork. A product page with a high exit rate may be a weak page. It may equally be a good page whose only onward link has been sitting behind a collapsed panel since the last rebuild. Both cases produce the same metric and call for opposite interventions.

Which edges can exist at all is decided by internal linking. For 2024, the HTTP Archive Web Almanac counts a median of 41 internal links per page across all pages surveyed (HTTP Archive Web Almanac); among the thousand most visited sites it is 129 internal links (HTTP Archive Web Almanac). That sounds like ample choice, but it is distributed very unevenly: a large share sits in navigation and footer, which look the same on every page and therefore barely distinguish journeys. The editorially intended links that actually carry a path are far rarer - and a page with no incoming link cannot appear in any path at all. How to track down such orphan pages is covered in a separate article.

Entry and exit pages tell only half the story

Entry and exit pages appear in almost every report. The entry page is the first page of a session, the exit page the last. Both lists are useful, and both are incomplete because they suppress direction. From the statement "page X was the last page 1,200 times" it follows neither where visitors reached X from nor whether X is the expected end of a path. On a confirmation page a high exit count is the desired outcome. On a pricing page the same figure is a finding. The metric does not distinguish the two cases; the path does.

On top of that comes a measurement property that is frequently overlooked: the last page of a session is also the page for which no time on page is produced. If you derive time on page from the gap to the next view, the last view has no next one - the duration is zero or missing entirely. Exit pages therefore drag the average time on page down systematically, without visitor behaviour having changed at all. Anyone unaware of this effect reworks pages that have nothing wrong with them. Time on page remains a coarse measure in any case: the average page visit lasts a little less than a minute (Nielsen Norman Group 2011).

The last row is the actual point. As soon as the transition share per edge is available, a list turns into a map: you see not only that a page is losing, but which route away from it is still being used and which one has gone quiet. The same applies on a smaller scale to search on your own site - the search query is an intermediate step with its own success rate, as the article on analysing internal site search shows.

How a transition comes into being technically

A transition is not a data field the browser sends along. It is reconstructed, from three building blocks: a session assignment, the order of events and the referrer information. If one of them is missing, a gap appears - and in a report a gap looks exactly like an abandonment. That is the most important difference between page counting and path analysis: counting tolerates gaps because it treats every view individually. Path analysis does not tolerate them, because every gap either invents an edge or makes a real edge disappear.

The referrer information usually comes from the Referer header or from document.referrer. How much of it survives is determined by the referrer policy. Chrome moved its default from no-referrer-when-downgrade to strict-origin-when-cross-origin in version 85 (Chrome for Developers). For that policy the specification describes that a full URL is sent as referrer information on same-origin requests, whereas cross-origin requests only carry the serialisation of the origin - that is, scheme, host and port without a path (W3C). For your own site that means internal transitions keep the path and remain analysable, while transitions from outside deliver only the domain.

The third building block is the session assignment. Traditionally an identifier stored on the device handles this, staying the same across several views. That very identifier, however, triggers the consent requirement discussed further below. Without it, the assignment has to be formed from ephemeral attributes and a time window, as described in the article on measuring without cookies. For path analysis that is sufficient, because it needs sequences within one visit and no recognition across weeks.

Soft navigation: the transition that triggers no request

In an application that swaps content in the browser instead of loading new documents, a change produces no server request, no new header and no new entry in navigation timing. For the visitor it is a page change; for measurement it is initially nothing at all. If that is not compensated for, the report shows a session with a single view and a long time on page - and thus a path of length one, although the visitor moved through six views. How such changes can be detected at all and what that means for loading metrics is covered in the article on Core Web Vitals under soft navigation.

The opposite error is just as common: views nobody ever saw end up as edges in the matrix. Prerendered pages produce a complete request before anyone has clicked at all; how to separate that cleanly is shown in the article on speculation rules and prerendering. Automated access behaves similarly but follows a different pattern: it walks links in order and thereby creates edges no human would have taken. Without the separation described in the article on filtering bot traffic, the most frequent edge in the matrix is often simply the order of the menu.

Six patterns that cause paths to snap

When an edge loses substantially over several weeks, new visitor behaviour is rarely behind it. In practice the causes fall into a handful of patterns that can be read off the transition itself - and that make themselves felt over quite different time frames.

1. The severed connection: the link that carried the edge has disappeared or slipped behind a collapsed panel. Typical after a navigation rebuild or after a switch to narrow layouts in which supplementary links were hidden. Recognisable by the edge losing abruptly rather than gradually.
2. The redirect chain: two or three redirects now sit between two pages. The transition still works but costs time, and depending on the type of redirect the referrer information is lost. The matrix then shows an edge with an unknown starting point. The article on redirect chains describes how to measure this.
3. The silent error code: the target page answers with status 200 and displays an error message. As far as measurement is concerned the transition happened; for the visitor the journey ends. Such cases only surface when status code and content are checked together, as the article on soft 404 pages shows.
4. The skipped level: a menu leads straight to the deepest level and skips the overview page. Its views collapse although its content is unchanged. That is not a defect, but it does demand a decision: either the level is given up or it is given a job of its own within the path.
5. The break at the origin boundary: the journey moves to a different subdomain, into a booking area or on to a payment step. Without shared measurement a new session begins there and the old one ends as an exit. The apparent loss is a measurement artefact - but it looks exactly like a real one.
6. The form abandonment: the transition fails not between two pages but within one. A mandatory field, an unclear error message or one extra step is enough. Which fields are involved only becomes visible through field-level analysis, as described in the article on form abandonment.

For prioritising the work, what counts is not the percentage drop but the absolute loss. An edge falling from 8 to 4 percent has halved and costs eight visitors across 200 sessions. An edge falling from 61 to 54 percent looks harmless and costs more than six hundred across 9,000 sessions. So sort your edge list by lost sessions first and only then by share.

Abandonment does not equal abandonment

Not every exit is a defect, and this is where most path analyses fail. The Baymard Institute surveyed the reasons for cart abandonment and found that 42 percent of the US online shoppers surveyed left a cart because they were only browsing and not ready to buy (Baymard Institute). No rebuild can remove that share; it belongs to the behaviour of comparing and bookmarking. Subtract it and a considerably smaller set remains - and that set is the one that is addressable at all. Anyone who fails to separate it out works away at a figure that is largely beyond influence.

Within the addressable set sits one reason that is purely a question of paths: 17 percent of the US online shoppers surveyed abandoned an order because the checkout process was too long or too complicated (Baymard Institute). That is neither a content nor a pricing problem but a problem of step sequence - precisely what a transition matrix makes visible. For context: the documented cart abandonment rate, averaged across 50 individual studies, stands at 70.22 percent (Baymard Institute), and part of it is a question of routing rather than of the offer.

Analysing paths without collecting consent

Path analysis needs a session assignment, and that is exactly where the legal question begins. Section 25(1) of the German TDDDG permits the storage of information in the end user's terminal equipment and access to information already stored there only if the end user has consented on the basis of clear and comprehensive information (TDDDG). The wording covers more than cookies: any storage and any access falls under it, including an entry in the browser's local storage or session storage. For an identifier that holds a path together across several views, that is the decisive hurdle.

Section 25(2) no. 2 exempts what is strictly necessary for the provider of a digital service to supply a digital service expressly requested by the user (TDDDG). Plain audience measurement is not covered by that under the prevailing reading. The workable route is therefore not consent but forgoing access: if no storage and no reading takes place on the device, section 25 does not apply and what remains to be assessed is the processing itself. That is measured against the GDPR, which in Article 5(1)(c) requires personal data to be adequate, relevant and limited to what is necessary (GDPR). Where the requirements for consent banners are heading is set out in the article on the 2026 cookie banner reform.

• Form the session from ephemeral attributes: a server-side key derived from a truncated address, header attributes and a daily rotating random value is enough to order views within a visit, and cannot be reversed once the time window has passed.
• Time window instead of a persistent identifier: a window of 30 minutes of inactivity reflects the usual notion of a session. Recognition after days is dispensable for path analysis and only increases the depth of the intrusion.
• Store sequence, not identity: what lands in storage is the edge - source page, target page, timestamp, counter. Once aggregated, nobody needs the individual session any more.
• Resolve referrers only within your own origin: internal transitions carry the full path, external referrers are stored truncated to the domain. That matches what the default policy supplies anyway.
• Aggregate early: daily and weekly totals per edge answer the questions that are still asked months later. Raw data with individual sessions needs a short retention period and a documented purpose.

The price of this route is known and manageable: visitors arriving from several devices appear more than once, and a return visit two weeks later goes unrecognised. For the question of which edge a journey ends on, neither matters much, because that question is answered within a single visit. If you also want to know which source started a path, you need clean campaign parameters rather than longer retention - the article on campaign parameter hygiene describes what else this attribution founders on.

Building a transition matrix in seven steps

The analysis itself is less laborious than it sounds. It needs an ordered list of events per session and a notion of which journeys are actually meant. The following procedure has proven itself and can be reproduced in a spreadsheet just as well as in a query against your own storage.

1. Group pages into templates: a thousand product addresses do not make a readable matrix. Group by template - overview, detail, form, confirmation - and keep only the twenty individual pages that play a role of their own.
2. Check the completeness of measurement: an edge is also missing when the target page is not measured at all. A reconciliation between the address inventory and the measured pages exposes that, as described in the article on monitoring coverage.
3. Order sessions and form edges: sort the events per session by time and count every consecutive pair as an edge. Self-transitions - the same page twice in a row through a reload - are discarded.
4. Give exits their own target column: the last view of a session gets an artificial target page called "exit". That way every row of the matrix adds up to one hundred percent, and the exit stands there as a competitor to the remaining routes.
5. Mark the expected edges: define in advance which transition is the desired one per template. Without that definition, every shift becomes retrospective confirmation of whatever you already suspected.
6. Work with a comparison period: an edge is not judged in absolute numbers but against the same week of the previous month. Otherwise seasonal effects and campaigns skew every interpretation.
7. Tie findings to events: record rebuilds, migrations and outages with their date and overlay them on the edge trends. Most drops then explain themselves in minutes rather than in meetings.

A sensible rhythm is weekly for the ten most important edges and monthly for the full matrix. Looking more often produces noise; looking less often lets rebuilds and their consequences drift apart until attribution no longer succeeds. Combine the analysis with the technical findings of the same week - an edge that collapses on exactly the day a redirect was set up is rarely a coincidence.

Setting up path analysis with XICTRAQ

XICTRAQ measures page views first-hand through its own script, without accessing the device and without passing anything to an external service. From the ordered events of a session it derives entry and exit pages, sequences and the transitions between pages. Because processing takes place in Germany and the session assignment works without a persistent identifier, the consent banner falls away as a prerequisite for measurement - and with it the share of sessions that a banner-based setup does not record at all.

For regular presentation within the team or to a client, the metrics can be issued as a recurring report or shown on a shared page, as described under reporting and status page features. If you would rather see the analysis on a populated data set first, the views are available in the demo with sample data. And if you want to translate transitions into revenue, the follow-on is the article on measuring conversions without third-party scripts.

A dependable path analysis is in the end not a report but a habit with four parts: a small number of named edges, a fixed comparison period, a separation between humans and machines, and a note on what was changed during the week. Hold those four together and you spot a break in the week it happens - not in the quarterly report, by which time the cause is buried under three further rebuilds.