Real time visitor tracking

Real time reporting is the feature people demo and then rarely open, with three exceptions where it is the most useful screen in the product: a launch, an outage, and the hours after something of yours is posted somewhere large.

It is also the feature where the privacy differences between tools are starkest, because the obvious way to build it is to follow individual sessions around, and the better way is not to.

When live data earns its place

During a launch or send. You published, or the email went out, and you want to know within two minutes whether the link works, whether the page renders, and whether people are reaching the thing you wanted them to reach. A daily report cannot tell you that in time to fix it.

During an incident. Traffic falling off a cliff is often the first signal that something broke, ahead of your monitoring, because it measures the user's experience rather than the server's opinion of itself.

When something takes off. A post reaching the front page of a large aggregator produces a traffic pattern you want to watch rather than read about later, partly because it tells you which follow-on pages people are finding and partly because it tells you whether your site is holding up.

Outside those three, live traffic is a slot machine. It feels like information and it mostly is not.

Two ways to build it, and why it matters

The traditional approach, which Clicky and Statcounter have used for close to two decades, is a visitor log: a chronological list of individual sessions with referrer, path, location and duration, updating live. It is genuinely useful and it is individual tracking by design, which means cookies and a consent banner in the UK and EU.

The modern approach shows the same live picture in aggregate: how many people are on the site now, which pages they are on, where they came from, arriving over the last hour. You lose the ability to follow one person around, which is the point rather than a limitation, and you keep the operational value almost entirely.

Almost everything the live screen is actually used for during a launch or an incident is answered by the aggregate view. If you find yourself needing the individual log, it is worth asking what decision it is informing.

What real time actually means per tool

Vendors use the phrase loosely, so check the refresh interval. Plausible's realtime dashboard updates every thirty seconds. Others push updates continuously. Google Analytics 4 has a realtime report covering the last thirty minutes, though it is one of the parts of GA4 that survived the transition well.

For the launch use case, thirty seconds is fine. For the incident use case, continuous is better, because the thing you are watching for is a sudden change and you want to see it as it happens rather than at the next tick.

What to watch, in order

During a launch, in this order: are people arriving at all, are they arriving at the right URL, is the referrer the one you expected, and are they reaching the second page. A campaign that sends people to a URL with a broken redirect looks identical to a campaign nobody clicked, for about ten minutes, and the live view is what distinguishes them.

During an incident, watch the arrival rate against its own recent shape rather than against an absolute number, and watch whether the pages people land on are changing. A drop confined to one path is a different problem from a drop across everything.

The rest of the field

Common questions

Related guides