GA4 has no customer journey report, and looking for one is the first thing to give up on. What it has is an event stream and a set of exploration tools you point at it. The journey is something you define first and then reconstruct — and most of the work that decides whether that is even possible happens before anyone opens a report.
GA4 records an event stream, not a journey
Universal Analytics was built around sessions and pageviews. GA4 is built around events: every interaction is an event name plus a set of parameters, attached to an identifier for the person who triggered it. A pageview is an event. A form submission is an event. A purchase is an event with revenue attached.
That means a customer journey in GA4 is not a feature. It is a derived thing: an ordered sequence of events, belonging to one stable identity, spanning more than one session. Each part of that sentence is a configuration decision you have to have made correctly in advance.
Define the journey before you open the tool
The most common failure is not technical. It is opening Explorations and trying to find a pattern in everything, when a journey is a specific short list of milestones that mean something commercially.
Write the ladder down first. For a B2B software business it usually looks something like: first visit, pricing page viewed, documentation or demo engaged, trial started, first meaningful action inside the product, paid. For a considered service business it might be: first visit, service page viewed, case material read, contact form started, form submitted, call booked.
Six or seven steps is normally the right resolution. Track scroll depth and every button click as milestones and you will produce a diagram nobody can act on. The test for whether a step belongs on the ladder: if the number moved, would you do something differently? If not, it is a diagnostic detail, not a milestone.
This is a positioning and audience question before it is a measurement one. If you have not decided which segment you actually want more of, you will end up measuring the average of several different journeys that have been blended into one.
Four settings you cannot fix retrospectively
These are the ones worth checking today, because none of them apply backwards. Data you did not collect correctly is simply gone.
Data retention
GA4 defaults user-level and event-level retention to two months. Fourteen months is the maximum on a standard property, and it is a single dropdown in Admin. Two months makes any journey longer than a quarter impossible to analyse, and the setting is not retroactive — raising it later does not bring back what has already expired. If you change one thing after reading this, change this one.
User-ID
Without a User-ID, GA4 identifies people by device. A prospect who reads on their phone, returns on a laptop and converts weeks later is three different users, and the journey you are looking at is a fiction. Sending a stable, non-personal identifier — your own internal account or CRM id, never an email address — is the single biggest improvement most sites can make to journey accuracy.
Reporting identity
Admin lets you choose Blended, Observed or Device-based reporting identity. This changes the numbers you see, so it is worth knowing which one you are looking at. It also interacts with the next problem: when Google Signals is enabled, GA4 applies thresholding and withholds rows where the cohort is small enough to risk identifying someone. That is why a report sometimes shows a total but refuses to break it down.
Registered custom dimensions
You can send any parameter you like with an event, but until it is registered as a custom dimension it will not appear in reports — and registration is not retroactive either. Decide which parameters matter (plan tier, lead source, content type, logged-in state) and register them before you need to report on them, not after.
Retention, User-ID and custom dimensions all share the same property: they only work forwards. Every week they stay wrong is a week of journey data you cannot get back.
Name events for the journey, not for the page
GA4 limits how many distinct event names a property can have — 500 on a standard property — and teams migrating from Universal Analytics burn through that fast by recreating the old category, action and label habit as separate event names.
The pattern that works: a small set of event names describing what happened, with parameters describing which one. One form_submit event with a form_name parameter, not eleven separate events. Names in snake_case, consistent tense, agreed before implementation rather than invented per developer.
Then mark the handful that matter as key events (what GA4 used to call conversions). Marking everything as a key event is the same mistake as tracking everything as a milestone: if all of it is important, the reports cannot tell you what is.
The explorations that actually answer journey questions
Four of the exploration types earn their keep for journey work.
- Funnel exploration is the workhorse. Build it from your milestone ladder. Two options change what it tells you: closed funnels only count people who entered at step one, while open funnels count anyone joining at any step, which is closer to how people actually arrive. Turn on elapsed time to see where people stall rather than only where they leave, and use the breakdown to compare the same funnel across channels or segments.
- Path exploration is most useful backwards. Rather than starting at the homepage and watching the diagram fan out into noise, set your key event as the endpoint and walk back. The question “what did people do immediately before converting” is answerable and actionable. “What do people do after landing” usually is not.
- Segment overlap answers a question the other tools cannot: how much do your audiences actually intersect? Useful for checking whether the segments you have built for reporting are genuinely distinct.
- User explorer is for debugging, not analysis. Look at individual event streams to verify your tracking fires in the order you think it does. Almost every journey project finds at least one event firing twice or at the wrong moment, and this is where you find it.
Where GA4’s journey reports will mislead you
Knowing the failure modes is more valuable than knowing the features.
Path exploration is aggregated, not individual. It shows the most common next nodes at each step, not real end-to-end paths, and it thins out after a handful of steps. It is a good way to generate hypotheses and a bad way to describe what any actual customer did.
High-cardinality dimensions collapse into “(other)”. When a dimension has too many unique values, GA4 buckets the tail. If your page paths include ids or query parameters, the row you need is often inside that bucket.
Explorations can be sampled. Standard reports are not, but explorations over large date ranges can be, and the sampling indicator is easy to miss. Check it before you act on a number.
Attribution is not the journey. Attribution models assign credit for a conversion; a journey describes what happened in sequence. They answer different questions, and using an attribution report to describe a journey quietly hides every touch that got no credit — which is exactly the demand-creation activity that is hardest to defend internally.
GA4 stops at your website. If revenue is recognised in a CRM weeks later, GA4 knows the form submission and nothing after it. The journey you can see ends well before the journey that matters.
When to move the analysis to BigQuery
GA4’s free BigQuery export is the most underused thing in the product, and it is the honest answer to most serious journey questions. It gives you the raw event-level data: unsampled, not thresholded, not bucketed into “(other)”, and joinable to anything else you own.
You have outgrown the interface when you need any of these:
- Sequences with more than one condition, or steps that must happen in a specific order with specific gaps between them.
- Joining behaviour to revenue that is recognised in your CRM rather than on your site — the only way to see first touch through to closed-won.
- Cohort retention by acquisition source over periods longer than the interface will hold.
- Any analysis you need to reproduce identically next quarter.
Turn the export on before you need it. Like everything else here, it starts collecting from the day you enable it and gives you nothing for the period before.
A sensible build order
- Write the milestone ladder. Six or seven steps, agreed with whoever owns revenue.
- Fix retention to fourteen months and enable the BigQuery export. Both take minutes and both only work forwards.
- Specify events and parameters on paper before implementation, and keep that document as the source of truth.
- Implement, then verify in DebugView and User explorer that events fire once and in the right order.
- Register the custom dimensions you will report on.
- Implement User-ID if you have authenticated users. This is development work, not a tag-manager setting, so scope it properly.
- Mark key events, then build the funnel exploration from the ladder.
- Only then start drawing conclusions.
Common mistakes
- Tracking everything. Volume of events is not quality of measurement. It burns the event-name limit and buries the milestones that matter.
- Trusting the default two-month retention. The most expensive default in the product, and the easiest to fix.
- Reading closed funnels as if they were open ones. The two answer different questions and the difference is not visible in the chart.
- Treating a discrepancy with the ad platforms as an error. GA4 and the ad platforms count differently by design — different attribution windows, different identity resolution, platform self-reporting. Pick one as your source of truth for decisions and stop reconciling the rest.
- Building dashboards before defining decisions. A journey report nobody acts on is a slower way of not knowing. Decide what you would change at each step first, and build the reporting around those decisions.
GA4 will not hand you the customer journey. It will hold the evidence for one, if the ladder is defined, the identity is stable, the retention is long enough and the events were named by someone who knew what question they were for.