GA4 Path Exploration: Mapping User Journeys Forward and Backward (2026)

How does GA4 Path Exploration work?

GA4 Path Exploration shows the sequence of events or page views before or after a specified starting point. Forward paths show what users do after your chosen starting event. Backward paths show what users did before your chosen ending event. Each node in the path tree represents an event or page view; the branch width indicates relative volume.

The most important configuration choice: event-scoped vs session-scoped paths. Event-scoped paths follow the exact event sequence across sessions; session-scoped paths reset at session boundaries, making them more useful for understanding within-visit journeys. For most e-commerce and content analysis, session-scoped paths give more actionable answers.

Forward vs backward paths

Forward path — "what did users do next?"

Starting from: page_view on your homepage → what do users navigate to? Starting from: add_to_cart → how many users proceed to checkout vs abandon? Starting from: sign_up → what is the first action users take after registering?

How to build:

1. Explore → Path Exploration
2. Step 1: select Event name as the node type (or Page title / screen name for page-based paths)
3. Starting point: select your starting event (e.g., begin_checkout)
4. The tree builds forward automatically

Reading the tree: Each level shows the next event/page, with percentages showing the share of users who took that path. Nodes with dotted borders indicate the path ends there (user session ended or no further events).

Backward path — "how did users get here?"

Most powerful use case: backward path from purchase shows the last events before purchase. This reveals:

• Which page views immediately precede purchase (last-touch page analysis)
• Which events signal purchase intent (users who view size guides or review sections before buying)
• Whether users who call customer service (if tracked as an event) have higher purchase rates

How to build:

1. Ending point: select purchase (or any key conversion event)
2. The tree builds backward from purchase

Important interpretation: The backward path shows the most recent event before the endpoint, not the full session history. Don't confuse "most common last event before purchase" with "causal path to purchase."

Event-scoped vs session-scoped paths

Event-scoped paths

Follow events across session boundaries. A user who visited yesterday and returned today — both visits are included in the same event sequence.

Use when:

• Analysing multi-session onboarding flows (users who complete registration across multiple days)
• Mapping the full lifetime journey to a high-value event (first purchase after multiple return visits)

Limitation: Event sequences across sessions can span weeks. The path tree becomes very wide and hard to interpret because every return visit adds branches.

Session-scoped paths

Reset at session boundaries. Only events within a single session are included in each path.

Use when:

• Understanding within-visit navigation behaviour
• Diagnosing checkout abandonment (which events precede abandonment within the same session)
• Analysing landing page bounce paths (what happened in the session where the user bounced)

Recommendation: Start with session-scoped paths for most analysis. Switch to event-scoped only when you explicitly need cross-session journey data.

The four most useful path questions

1. What do users do after viewing a key product page?

Starting event: page_view with page_location parameter containing the product page URL

What you're looking for: What share proceed to add_to_cart vs navigate to related products vs exit? If more users navigate to a related product page than add to cart, the product page may need a stronger CTA or the related product links are cannibalising conversion intent.

Typical finding: 15–25% of product page viewers add to cart in a healthy e-commerce implementation. Lower rates point to price friction, product page content gaps, or shipping/returns concerns.

2. What do users do after a failed payment?

Starting event: Add a custom event payment_error or use begin_checkout with a parameter indicating payment failure (depends on your implementation)

What you're looking for: Do users retry payment? Navigate back to cart? Leave entirely? The split between retry and exit informs whether the payment error experience needs UX work vs whether the underlying issue is price sensitivity.

3. What pages do users visit before submitting a lead form?

Ending event: generate_lead or form_submit

What you're looking for: Which pages appear most frequently in the 3–5 events before form submission? These are your highest-influence pages for lead intent. Ensure they're optimised for conversion and internally link to the form.

4. What do new users do in their first session?

Segment applied: New users

Starting event: session_start

What you're looking for: First-session navigation patterns for new users vs returning users. If new users immediately navigate to pricing but returning users convert — new users need a clearer value proposition before the pricing page.

Filtering path trees for readability

Unfiltered path trees on large properties are unreadable — thousands of branches, tiny percentages everywhere. Techniques for filtering:

Filter by page path: Switch node type to Page title and screen class instead of Event name. This collapses multiple events on the same page into a single node, reducing tree width dramatically.

Set a minimum node volume: In Path Exploration settings, increase the minimum sessions required to show a node. This hides low-volume branches that add noise without insight.

Apply a user segment: Restrict the path to a specific acquisition segment (e.g., paid search users only) to understand channel-specific journey behaviour.

Limit path steps: Default is 5 steps. For most questions, 3 steps is sufficient and produces a much cleaner tree.