GA4 GUIDE 7 min read

Realtime Shows Traffic, Reports Show Nothing. That's GA4 Working Normally.

LastClarity

The short answer

GA4 standard reports carry 24 to 48 hours of processing latency while the Realtime report covers only the last 30 minutes. Seeing traffic in Realtime but nothing in standard reports is normal, not a tracking failure. Analyse data at least two days old for stable numbers.

You installed the tag an hour ago. Realtime shows nine people on the site. The Reports section shows nothing at all, and the natural conclusion is that the setup is broken.

It is not. You are looking at two different systems with two different jobs, and one of them is deliberately slower.

Two pipelines, not one report with a lag

Realtime is a lightweight live stream covering roughly the last 30 minutes. Minimal processing, minimal dimensions, near-instant. Its job is to answer “is anything happening right now” — and, usefully, “did my tag fire.”

Standard reports are built from batch processing with a documented latency of 24 to 48 hours. They carry the full dimension set, complete attribution, and every privacy and modelling layer.

Traffic in Realtime but nothing in standard reports is the expected state for a new property. It is also good news: it means your tag is firing, which eliminates the thing most people are actually worried about.

RealtimeStandard reports
Windowlast 30 minutesfull history
Latencyseconds24-48 hours
Attributionprovisionalfinalised
Cross-device stitchingnoyes
Consent modellingnoyes
Thresholding appliedlimitedyes
Good for”is my tag firing?“every real question

What the delay actually buys

The latency is not queueing. GA4 is doing work that is impossible to do instantly, because each step needs a reasonably complete picture of the day:

  • Batching. Events are processed in groups rather than one at a time.
  • Attribution. A session’s credited source can change when later events arrive; attribution has to settle.
  • Cross-device stitching. Joining one person’s phone and laptop journeys is post-processing by definition.
  • Consent and behavioural modelling. Estimating unconsented users requires enough consented users to model from.
  • Privacy thresholds. Applied against final user counts, which do not exist until processing completes.

Every one of these needs the day to be more or less over.

Why yesterday’s numbers moved

This is the part that erodes trust, usually because nobody explained it in advance.

You report 1,200 sessions on Tuesday. On Thursday the same date reads 1,340. Nothing was broken and nothing was double-counted — processing had not finished when you looked, and late-arriving events, finalised attribution and modelling adjusted the figure afterwards.

The rule that prevents this entire category of embarrassment: do not report on data less than two days old. Not because it is wrong, but because it is provisional, and a number you have already put in front of a stakeholder is much harder to revise than one you have not.

For weekly reporting, end the period two days before you build the report. The week is complete, the data has settled, and the numbers will still be the same next month.

When it IS actually broken

The delay explains a lot, but not everything. Suspect a real problem when:

  • Realtime shows nothing while you are actively browsing the site. That is a tagging failure, not latency — start with GTM Preview or DebugView.
  • More than 48 hours have passed with still no data in standard reports.
  • Data stops on a specific date and never resumes. Latency does not create cliffs; a broken deployment does.
  • One report has data and another does not for the same period, beyond the first day or two.

The diagnostic that separates the two: Realtime is your tag check, standard reports are your data check. If Realtime works, tagging is fine and you are waiting. If Realtime is empty, stop waiting and go debug.

The Overview tab. A green strip across the top reads 62 active now, with a live sparkline at the right, above six metric cards and a users trend chart.
The green strip is the realtime pipeline — 62 active now, refreshing on a countdown. Everything below it is the batch-processed data, which is where the 24 to 48 hours applies.

Where we sit, plainly

GA4 Simple View reads the GA4 Data API, which serves the same processed tables as the interface. It inherits the identical 24-48 hour latency, and we cache responses on top of that — usually an hour, up to a day for slow-moving figures.

So we are not fresher than GA4. We are slightly less fresh, deliberately, because caching is what makes the dashboard load in one click instead of re-querying the API every time you open a tab.

Two things we do about it rather than pretend otherwise: the refresh control shows when data was last fetched and flags when that is older than the auto-refresh interval, and the Realtime strip uses the realtime data for the live number, so “how many people are on the site now” is answered by the pipeline built for it.

Any tool claiming to show you fresher GA4 data than GA4 has finished processing is either reading the Realtime API or telling you something that is not true.

Questions people also ask

Each answer stands on its own, so it still makes sense quoted somewhere else.

How long does GA4 take to show data?

Realtime reports show activity from roughly the last 30 minutes almost immediately. Standard reports carry a documented processing latency of 24 to 48 hours. Data from today will usually be visible in some form within a few hours but should not be treated as final until that window has passed.

Why does GA4 Realtime show visitors but my reports show zero?

Because they are different pipelines. Realtime is a lightweight live stream over a short window. Standard reports are built from batch processing that applies attribution, cross-device stitching, modelling and privacy thresholds. Traffic appearing in Realtime confirms your tag is working, which rules out the most common worry.

Why do yesterday's GA4 numbers keep changing?

Because processing is still finishing. Late-arriving events, attribution being finalised, cross-device stitching and consent modelling all adjust figures after the first pass. Numbers typically settle after 48 hours, which is why day-old data should be treated as provisional.

What is GA4 doing during the 24 to 48 hour delay?

Batching events rather than processing them individually, finalising attribution across sessions, stitching journeys across devices, applying behavioural and conversion modelling for unconsented users, and applying privacy thresholds. Each step needs a reasonably complete picture of the day, which is why it cannot be instant.

How old should data be before I report on it?

At least two days. Reporting on today or yesterday means reporting on an incomplete dataset that will change after you have shared it. For weekly reporting, ending the period two days before you build the report avoids revising numbers a stakeholder has already seen.

Does the GA4 Data API have the same delay?

Yes. The Data API reads the same processed tables as the interface, so any third-party dashboard inherits the same 24 to 48 hour latency. A tool cannot be fresher than the data Google has finished processing, and any claim otherwise is either using the Realtime API or is inaccurate.

#GA4#Data Freshness#Realtime#Reporting#Troubleshooting

This is what we built instead

GA4 Simple View puts the numbers in this post on one screen, in one click, without building a report first.

Get the extension