GA4 Path Analysis: Where Do Users Leave?
A product page gets attention, but purchases remain scarce. The obvious question is where shoppers go after the page. Some may open another product, some may start checkout, and some may trigger an event that says little about their intent. A total for product-page views cannot show those different routes. Before changing the page, I would look at the recorded sequence of actions and ask which branch actually needs attention.
In Google Analytics 4 (GA4), path analysis usually means using Path exploration to follow recorded events and page or screen views through a tree graph. You can begin with a selected action and look forward, or begin with an outcome and look backward. That makes the tool useful for finding routes you did not specify in advance. It does not, by itself, explain why a person took one route or show actions that were never recorded. Google’s Path exploration guide describes the graph as a view of the event stream, with each step showing actions adjacent to the selected node.
Begin with a decision, then choose the path’s direction
The useful question is narrower than “What do users do?” Suppose a team is deciding whether to revise a product page or the transition from cart to checkout. Start at the product page if the decision depends on what visitors do next. Start at purchase if the decision depends on which recorded actions precede a completed order. The same property and date range can answer those different questions, but the resulting graphs represent different groups of journeys.
A forward path begins with a starting node, such as an event name or a page path, and expands to the next recorded actions. A backward path begins with an ending node and expands toward the actions that came before it. In GA4, a single Path exploration has either a starting point or an ending point; it cannot have both. After opening the Path exploration template, Start over lets you choose which direction to build. The available starting values include event name, page title, page path, screen name, and screen class. Google documents those setup choices.
That restriction is useful to remember when framing the question. A forward view from a product page can show a branch toward cart alongside branches toward other pages. A backward view from purchase shows routes among journeys that reached that endpoint. It does not show the routes of people who did not purchase. If the concern is abandonment, start before the suspected point of difficulty and follow the branches forward; if the concern is what successful journeys have in common, work backward from the outcome. Those are interpretations of the two directions, not claims that either graph reveals a customer’s motive.
Choose a date range that fits the decision and keep it fixed while comparing paths. GA4 calculates paths from the user’s event stream using the first instance of the selected starting or ending dimension value. Depending on the date range, a path can span more than one session. Google’s explanation of path calculation matters here: a route shown beside a purchase is not necessarily a neat, single-visit trip through the site. If the decision concerns only an immediate transition, read the adjacent steps carefully rather than assuming the whole displayed route happened in one sitting.
Read a branch as a recorded sequence, not a verdict
Each column in a path graph is a step. Each node in that column is a selected event, page, or screen value, with a count attached. Expanding a node exposes the next step along that branch. GA4 initially shows the top five nodes in a step; + More can show up to 20, while additional nodes are grouped under Others. A small branch can therefore be absent from the first view without being absent from the recorded journeys. Google explains the node and expansion behavior.
Imagine, as an illustration rather than a reported finding, a route from a product page to another product page and then to a cart event. The first branch could reflect comparison shopping. It could also reflect uncertainty about the first product. The path tells you the recorded order of actions; it cannot choose between those explanations. I would use the branch to decide what to inspect next: the actual page content, the route into the cart, or a more specific segment of visitors. I would avoid treating a return to a prior page as proof that the page failed.
Node type determines what the graph names. An event-name step can expose actions such as add_to_cart; a page-path step can make movement between URLs easier to read. Selecting the type that matches the decision is part of the analysis. A page-only reading can miss an important event between page views, while an event-heavy view can obscure the route between pages. GA4 allows the node type to be changed for a step, so I would inspect both views when a sequence seems surprising. The Path exploration guide describes node types and step controls.
Repeated values deserve a second look rather than an automatic “stuck” label. Google illustrates a path that goes Home, Product A, Home, Product B. That sequence shows a return to Home, but it does not tell us whether the visitor was lost or deliberately browsing. GA4 also offers View unique nodes only, which suppresses consecutive repeats of the same page or screen value while still showing that value if the user returns after visiting another one. Use the normal view when repeated actions are the question; use the condensed view when those repeats hide the broader route. Google describes both the example and this display option.
Choose a count that matches the question
The number beside a node needs a denominator in your mind. GA4’s default Path exploration metric is Event count, the number of recorded events at that node across users and sessions in the selected period. Total users instead counts unique users who viewed the screen or triggered the event. If one person opens Home twice, an event count can reflect both occurrences while a user count represents that person once for the relevant node. Google defines the two supported metrics.
I would use Event count when repeated actions are themselves the issue, such as repeated returns to a page. I would use Total users when deciding how many people encounter a branch. Those choices can produce different looking graphs without any underlying behavior changing. In particular, do not add the user totals from separate child branches and call the result the number of people at their shared parent. One user can contribute to multiple routes while counting only once at a shared node; Google explicitly notes this property of unique-user counts.
For a concrete reading, suppose an illustrative graph shows 100 unique users at a product-page starting node, 40 at a cart branch, and 25 at another product branch. The defensible statement is that 40 of those 100 appear at the selected cart node under this path setup. It is not safe to say that the remaining 60 abandoned shopping, because some may have followed other visible or grouped branches, and some may appear in more than one branch. The example numbers are invented solely to show how to read a user count. The real decision should use the property’s recorded values and a clearly named starting population.
Keep the event stream in view when narrowing the graph
A crowded graph invites a quick cleanup: hide an event that looks irrelevant and continue reading. In GA4, excluding a node from the graph only hides it; the exclusion does not change how the underlying path is calculated. A segment, by contrast, changes the event stream before path calculation. Filters are also applied before paths are calculated. Those are materially different operations, even if all three make the display look simpler. Google explains how node exclusions, segments, and filters work.
If I want to know what people did after a checkout-start event, I would first read the unfiltered path and record the important branches. If a routine event makes the graph hard to scan, hiding its node can improve readability, but I would still remember that it occurred in the recorded sequence. If the decision is specifically about a subset, such as users on one device category, I would apply a relevant segment or filter and describe that restricted population when reporting the finding. The cost of a cleaner graph is that the result answers a narrower question.
This distinction is particularly important when a branch seems to “disappear” after a change. The disappearance may come from a display choice, from removing events before calculation, or from changing the selected population. Revisit those settings before declaring that user behavior changed. Path analysis is most useful when its setup is treated as part of the statement: a starting or ending node, node types, metric, date range, and any segment or filter.
Use a funnel when the order is already specified
Path exploration is a good first choice when the question is, “Which recorded routes occur around this page or event?” A funnel is better when the team has a specific sequence to measure, such as product view, cart, checkout, and purchase. In GA4 Funnel exploration, the analyst defines the steps and their conditions, then sees which users complete them in order. Google’s Funnel exploration guide describes this configured sequence.
The distinction changes the question, not just the chart. A path may show that visitors commonly move from a product page to a related product before cart. A funnel can ask whether users who satisfy a chosen product-view condition subsequently satisfy cart and purchase conditions in the specified order. If the product team wants to decide whether a known checkout sequence has a weak transition, I would use the funnel for that measurement and the path to inspect what recorded actions surround the transition. The funnel’s configured steps are a deliberate definition of success; the path exposes branches outside that definition.
Two funnel settings deserve explicit choices. A closed funnel requires entry at its first step; an open funnel allows entry at a later step. If some shoppers reach checkout without meeting the chosen product-view condition, an open funnel can include their later qualifying steps, whereas a closed funnel is anchored to the first step. GA4 still counts steps in the configured order; skipping a required step ends that user’s counted progress. Google explains open and closed entry with examples.
The second choice is whether one step must follow the previous step directly or may follow it indirectly. Direct means immediately next in the recorded sequence; indirect permits intervening actions. A shopper who views a product, checks another page, and then adds to cart might satisfy an indirect product-to-cart condition but fail a direct one. That is an illustrative sequence, not an observed result. I would use indirect steps when the business question allows ordinary intervening actions and reserve direct steps for a transition that truly must be immediate. GA4 also lets the analyst set a time frame for a later step. Google documents these step settings.
A poor comparison would put an open, indirect funnel beside a path and interpret the different counts as an analytics error. The two explorations can select different populations and apply different sequence rules. Before comparing numbers, write down the first qualifying action, required order, intervening-action rule, date range, and metric. The practical cost is a few minutes of setup; the benefit is knowing what each number actually describes.
Check the setup before acting on a surprising result
Even a carefully read path covers recorded behavior, not every action a visitor took. If a relevant page view or event was never instrumented, no branch can reconstruct it. If the recorded sequence looks implausible, check the event names and the page or screen values that define the nodes before redesigning a page. This is a limit of what an event-stream view can tell you, rather than a diagnosis of any particular site’s tracking.
A path count may also differ from a standard report without either screen being wrong. Google notes that reports and explorations can use different supported fields and filtering behavior. An exploration filter can be case sensitive and use a selected match type, while the report table’s Search field uses a case-insensitive “contains” match. Explorations are also limited by the property’s user and event data retention settings, and low user counts can trigger data thresholds. Google lists these reasons for differences between reports and explorations.
The newest period can be especially awkward for a quick comparison: Google says queries for the past 48 hours may differ slightly because data systems process at different times. When a decision depends on a small change, I would compare like settings and allow for that processing window before treating the difference as a change in behavior. Google explains the processing-time effect. A matching number is reassuring, but a mismatch calls first for a settings check, not an invented story about visitors.
Turn the route into a specific next move
The useful output of path analysis is a bounded decision. If the forward path from a product page shows a substantial branch to another product, I would inspect the two pages and the navigation between them before rewriting checkout. If the backward path into purchase shows a common preceding action, I would ask whether that action represents a useful route worth making easier to reach. Neither observation alone establishes cause, but each directs attention to an actual part of the recorded journey.
When the decision is about a defined conversion sequence, I would translate the candidate route into funnel steps and choose open or closed entry and direct or indirect transitions on purpose. If the path and funnel still seem inconsistent, I would check their populations, dates, metrics, filters, and step definitions before drawing a product conclusion. That sequence costs more work than reacting to the first prominent branch, but it avoids changing a page because of a count that answered the wrong question.
GA4 path analysis is strongest as a map of recorded adjacent actions: start forward to see what follows a chosen point, or work backward to see what preceded a chosen outcome. Read branches with the right metric, keep the graph’s settings attached to any claim, and move to a funnel when the question becomes how many users completed a defined sequence. The result is a clearer choice about what to inspect or change, with its limits visible.