Event timestamp vs collection time
Every event carries more than one notion of time: when it happened on the client, when it was sent, and when the server received and processed it. These diverge with offline queuing, clock skew, and processing lag. Reports built on one clock will not match reports built on another. This page explains event timestamp versus collection time and which to use for which question.
Multiple clocks per event
An event has a client-side moment (when the user acted), a send moment (when the request left the device), and a server-side moment (when collection received it). GA4's export, for instance, exposes an event timestamp in microseconds; the Measurement Protocol allows a timestamp_micros override for events sent after the fact.
These clocks agree for an immediate online hit, but diverge whenever sending is delayed or the device clock is wrong.
- Client action time vs send time vs receive time
- Offline queues send events long after they occurred
- A wrong device clock skews the client timestamp
Choosing the right clock
For behavioural analysis — when did users actually do something — use the event/occurrence time. For operational questions — when did data land, when can I trust today's totals — use collection time. Mixing them produces phantom shifts: an offline event recorded against its occurrence time can backfill a past day after it already looked closed.
Decide per report which clock you mean, and document it so day-boundary surprises are explainable.
How it appears in analytics and logs
Events appearing on a different day than expected often means a report uses collection time while the action happened earlier, or vice versa.
Diagnostic use case
Choose the right time field for an analysis, distinguishing when an event occurred from when it was collected, so trends land on the correct day.
What WebmasterID can help detect
WebmasterID records precise event timing so you can reason about when something happened versus when it was received, instead of conflating the two.
Common mistakes
- Mixing occurrence time and collection time in one trend.
- Trusting a client timestamp from a device with a wrong clock.
- Assuming today's totals are final when offline events backfill.
Privacy and accuracy notes
Timestamps are technical metadata, not identity. Avoid using fine-grained timing as a fingerprinting signal; keep time fields purpose-limited to analytics.
Related pages
- Server time vs client time
An event's timestamp can come from the client (the browser's clock at the moment of the action) or the server (when the collector received the hit). The two differ because of clock skew, network delay, and offline buffering, and the choice affects ordering, attribution windows, and which day an event lands on. This page contrasts the two clocks.
- Timestamp skew and clock drift
Hit timestamps can come from the client device, whose clock may be set wrong or drift. An incorrect client clock produces events stamped minutes, hours, or even days off, which corrupts session boundaries, event ordering, and time-based reports. Platforms that adjust against server-received time mitigate this. This page explains clock drift and how analytics pipelines correct for it.
- 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.
- Event Explorer
Inspect precise event timing field by field.
Sources and verification notes
- Google developers — Measurement Protocol (timestamp_micros)
- Google — [GA4] BigQuery Export schema (event_timestamp)
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.