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.
Why client clocks lie
Many tags timestamp events using the device's clock. Devices can have clocks that are unset, manually wrong, or drifting between time syncs. The result is events that claim to have happened in the past or future relative to reality — and there is no way for the device itself to know it is wrong.
How pipelines correct skew
Robust collection compares the client-claimed time to the server-received time. GA4's Measurement Protocol, for example, accepts a timestamp_micros but constrains how far in the past an event may be backdated, and processing reconciles against arrival time. When the gap is large, the event may be re-stamped or dropped from real-time views.
The practical effects of uncorrected skew are session fragmentation (a wrong gap looks like a timeout), broken event ordering within a session, and traffic appearing on the wrong calendar day in time-zone-sensitive reports.
- Tags often stamp events with the device clock
- Misset/drifting clocks put events in the past or future
- Pipelines reconcile against server-received time
- Symptoms: fragmented sessions, mis-ordered events, wrong day
How it appears in analytics and logs
Events with timestamps far from when they were received usually indicate a skewed client clock, not a pipeline delay; the device reported a bad time.
Diagnostic use case
Explain isolated events landing on wrong dates or out-of-order sequences, traced to a client device whose clock was set incorrectly.
What WebmasterID can help detect
WebmasterID records server-received time for events, so a misset client clock does not silently move your traffic to the wrong day.
Common mistakes
- Trusting client timestamps without bounding allowable skew.
- Mistaking clock drift for genuine late-arriving hits.
- Ignoring skew when events appear on adjacent calendar days.
Privacy and accuracy notes
Timestamps are processing metadata, not identity. This page is educational, not legal advice on data retention.
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.
- 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.
- Session fragmentation and inflation
A session is meant to represent one continuous visit, but several rules can split one journey into many. A timeout during a pause, a campaign parameter mid-visit, crossing midnight, or a self-referral each starts a fresh session. The result inflates session counts and shrinks per-session metrics. This page explains the fragmentation rules and how to read counts affected by them.
- Website Observability
Server-received timestamps resist client clock drift.
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.