The GA4 Realtime Report: What It Shows and Its Limits

This guide is based on Google's Analytics Help pages on the Realtime report, data freshness and comparisons, and the Google Analytics Data API guide to realtime reports, as published in November 2026. Where we give our own advice, we say so.

What the Realtime report is for

Google's one-line description is that Realtime lets you "monitor activity on your website or app as it happens." You open it from Reports, then Realtime. If it is missing from the menu, Google notes it may have been removed from the default navigation, and Editors or above can add it back.

Google lists four uses: seeing whether a one-day promotion is driving traffic, watching the immediate effect of a blog or social post, checking whether new or changed content affects traffic, and verifying that the measurement code works. The last one overlaps with testing. If your aim is to check a new tag or event in detail, our guide to checking GA4 tracking with DebugView, Tag Assistant and Realtime covers that workflow. This page is about reading the Realtime report itself.

The cards and what each one answers

Google describes the layout as a set of cards that show "how users enter the conversion funnel, and how they behave once they're in the funnel." Each card answers one question:

Card	Question it answers
Active users in the last 5 and 30 minutes (per minute)	How many people are here right now, and is that rising or falling?
Active users by first user source, medium, source platform or campaign	Where these users originally came from
Active users or new users by audience	Who they are, by the audiences you defined
Views by page title or screen name	Which pages or app screens they are looking at
Event count by event name	Which events they trigger
Key events by event name	Which key events (enquiries, sign-ups, purchases) they complete
Active users by user property	How they split by the user properties you collect

One detail changes how you read the source card. Google says the report shows "user-scoped dimensions and metrics", which means they are "about how you first acquire users." So the source card tells you how these people first found you, not what brought them to this visit. A returning visitor who first came from Google search and today clicked your newsletter still shows under the search source. If you want to see who came in from today's newsletter, look at the page they landed on, or check the session-based acquisition reports later.

The key events card only lists events you have marked as key events. How to choose and mark them is in our GA4 key events guide.

Why the numbers look low or odd

Google's page lists several processing limits. In plain terms:

• Active users leaves some people out. Google says "New users and returning users who haven't been processed are excluded from the Active users count." A first-time visitor appears under New users, not Active users.
• The first user source card is incomplete. It shows "information only for established users", ones that have already gone through normal processing. Brand-new visitors are missing from it because GA4 has no first source for them yet. On a launch day, when most visitors are new, this card can look almost empty.
• Attribution is limited. Realtime "performs limited attribution analysis to ensure responsive reporting", and Google recommends the Acquisition reports "for the most accurate attribution information."
• Busy cards are cut off. Cards show at most 700 rows on desktop and may group the rest as (other). Google warns this can cause differences in metrics such as event count.
• App data comes in batches. Apps send data in batches to save battery, so expect delays "on the order of minutes."
• No guarantee. Google calls Realtime a "best effort" service with no formal Service Level Objective, so short delays are normal.

And if the report is empty, Google's first explanation is the simplest: there may be no active users. On a small business site at 3 a.m. that is often the answer.

Comparisons in Realtime

Comparisons let you split the report into groups side by side, for example mobile against desktop, or one country against everyone. You add one with the comparison button at the top of the report. In Realtime there is also a shortcut: click a bubble on the map and GA4 compares all users with users in that city.

Comparisons are built from dimension conditions. Google's comparisons page explains that several values in one condition are joined with OR, separate conditions are joined with AND, and you can add up to four more conditions after the first. Google also includes prebuilt saved comparisons for direct, organic, web and mobile traffic. Where your property has saved comparisons, Editors and above can create them under Admin, Data display, Comparisons, up to 200 per property; Google notes that saving comparisons is rolling out gradually.

The catch for Realtime: if a report does not support a dimension used in the comparison, GA4 shows a blank card for it, and Google says this "is most likely to occur in the Realtime report." A blank card here usually means the comparison uses a dimension Realtime does not have, not that nobody matched it. Pick a different dimension, such as platform, country or stream.

User snapshots

Click View user snapshot at the top of the report to see one user at a time: their device, app version and location, the top events they triggered and their user properties. Arrows in the first card move you from one user to the next. Google's comparison table notes that the snapshot shows data for a random user, so you cannot pick a particular visitor.

In our experience the snapshot is most useful for a quick sense check. If events are firing in the wrong order or a user property never fills in, it often shows up here. For step-by-step checks on your own device, DebugView is the better tool. Google's table puts the difference simply: Realtime covers the last 30 minutes for everyone with access to the property, while DebugView lets you select a single debug device and is "usually used by web or app developers."

Realtime vs the reports you see tomorrow

Realtime numbers rarely match the standard reports for the same hour, and Google's data freshness page explains why. GA4 processes data in three intervals:

Interval	Typical processing time (standard property)	What it covers
Realtime	Typically a few minutes	A few dimensions and metrics only
Standard intraday	2 to 6 hours	All reports and API queries, with some exceptions
Daily	12 hours at standard data limits	All reports and API queries

Google says realtime data "covers fewer features than other intervals." Intraday data can have temporary gaps in source, medium and campaign, and "Data in reports and API queries may change after the daily data becomes available." For the previous day, Google's typical timeline has daily data ready in Reports around 3:30 pm in the property's time zone, and some data can arrive up to 7 days late. Google is clear that these times are typical, not guaranteed.

Our advice: use Realtime to see that something is happening, and use the standard reports a day or two later to say how much. Do not screenshot Realtime for a client report.

Realtime data through the API

The same kind of data is available through the Google Analytics Data API with the runRealtimeReport method. Google's developer guide says realtime reports cover "the present moment to 30 minutes ago (up to 60 minutes for Google Analytics 360 properties)" and suggests uses "such as live counters of visitors on your website."

• The API supports "a limited subset of dimensions and metrics" compared with normal reporting.
• A request can use up to two minute ranges, for example 0 to 4 minutes ago and 25 to 29 minutes ago. Without one, the last 30 minutes is used.
• Pagination, dimension filters and user properties work the same as in normal API reports.

This is how a live visitor counter on an office screen or an internal dashboard is usually built. It needs a developer and access to the property; the GA4 interface is enough for most small businesses.

Good and bad uses

From our own work, these are the jobs Realtime does well:

• Right after a site launch or migration: open the site on a phone and confirm you appear, and that page titles look right.
• When an email, social post or ad goes live: watch whether people arrive and which page they open.
• After a form or checkout change: complete it once and check the key event appears in its card.
• During a live event or a sale with a fixed start time.

And the jobs it does badly: judging which channel brought the visit, counting conversions for a report, comparing days, or deciding a campaign worked. Those belong in the standard reports, ideally once daily data is in. If GA4 itself is new to you, start with our GA4 guide for small business websites.

Frequently asked questions

How far back does the GA4 Realtime report go?

The report shows activity in the last 30 minutes, with a separate count for the last 5 minutes. Through the Data API, 360 properties can query up to 60 minutes.

Why does Realtime show fewer active users than I expect?

Google excludes new users and returning users who have not been processed yet from the Active users count. New visitors show under New users instead.

Why is the first user source card empty?

That card only shows established users who have already gone through normal processing. Brand-new visitors have no first user source yet, so they are not in it.

Why do my Realtime numbers differ from the standard reports?

Realtime uses limited processing and attribution, and covers fewer dimensions. Standard reports use intraday and then daily data, which can still change once the daily data is complete.

Is Realtime the same as DebugView?

No. Realtime shows everyone on the site or app in the last 30 minutes. DebugView shows events from devices in debug mode, one device at a time, and is mostly used by developers.

Want a website where every enquiry is tracked and easy to analyse? See our website development service and all our services, or email [email protected].