Late-arriving and offline hits
Not every hit arrives when it happens. A device offline queues events and sends them on reconnect; processing pipelines add delay; and tools backfill recent data. The effect is that today's and yesterday's numbers are provisional and keep rising as late hits land. This page explains why fresh reports change under you and how to read them.
Why hits arrive late
Several mechanisms delay a hit. A device that loses connectivity can queue events and transmit them when it reconnects, sometimes hours later, carrying a timestamp from when the action occurred. Measurement protocols allow backdated hits within a window. And the tool's own processing pipeline adds latency before a hit appears in standard reports.
So the moment an event is collected and the moment it shows up in a report are not the same.
- Offline devices queue and send on reconnect
- Backdated hits arrive within an allowed window
- Processing latency delays appearance in reports
Reading provisional data
Expect the most recent day or two to be incomplete and to rise as late data settles. Avoid drawing firm conclusions from a still-filling window, and compare like-aged windows rather than a fully-settled past day against today. Know your tool's processing-latency and backdating limits so you can tell normal settling from a real anomaly.
How it appears in analytics and logs
Recent-day totals creeping upward over the following hours or days is normal late-data settling, not a measurement error.
Diagnostic use case
Treat the most recent days as provisional and let them settle before drawing conclusions, rather than reacting to numbers still being backfilled.
What WebmasterID can help detect
WebmasterID records events with their own timestamps, so you can distinguish when an event happened from when it was received as data settles.
Common mistakes
- Treating today's still-filling numbers as final.
- Comparing a settled past day to an incomplete recent one.
- Reading normal late-data settling as a data error.
Privacy and accuracy notes
Late and offline hits are ordinary events with delayed delivery; the timing carries no extra privacy implication beyond the events themselves.
Related pages
- Time-zone mismatches in reporting
Every analytics property reports against a configured time zone, and it decides which calendar day each hit belongs to. A wrong zone shifts your daily curve; two tools on different zones never match day-to-day; and daylight-saving changes create a short or doubled hour. This page explains how the reporting time zone shapes data and the artefacts to expect.
- Why two analytics tools disagree
It is normal for two analytics tools to report different numbers for the same site. The differences are structural, not bugs: each tool defines a session differently, filters bots differently, samples or does not, attributes on different windows, and fires its tag at a different moment. This page explains the recurring causes and how to reconcile them.
- Pageviews: what the metric counts
A pageview is recorded when a page is loaded (or a virtual page is rendered in a single-page app). It is the oldest web-analytics metric and the easiest to misread: pageviews count loads, not people, and modern apps and prefetching can inflate or hide them. This page defines the metric and its caveats.
- Event Explorer
See event timestamps versus when data was received.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.