Event ordering guarantees
Events that happen in one order can arrive in another: parallel transport, retries, and varied network paths reorder them. Analyses that assume arrival order — funnels, first-touch, session sequencing — then draw wrong conclusions. This page explains why ordering is not guaranteed in distributed collection and how event timestamps and partition keys let you reconstruct true order.
Why order is lost
In a distributed system, events flow through parallel producers, queues, and consumers, and any of retries, batching, or differing network latency can deliver a later event before an earlier one. Most transports guarantee ordering only within a partition, if at all, not globally. So arrival order at the warehouse is not the order things happened.
Funnels, first/last-touch logic, and session reconstruction that key off arrival order therefore misread sequences.
- Parallel paths, retries, and batching reorder events
- Ordering, if any, is per-partition, not global
- Arrival order is not occurrence order
Restoring true order
Sort by an event timestamp set as close to occurrence as possible, not by ingestion time, and account for clock skew between sources. Where strict per-key order matters — all events for one session in sequence — partition by that key so the transport preserves order within it. Reconstruct funnels by ordered timestamps within a key rather than by raw insertion order.
This is closely tied to late-arriving data and watermarking, which handle events whose timestamps lag their arrival.
How it appears in analytics and logs
A funnel where a later step appears before an earlier one, or impossible sequences, usually means events arrived out of order.
Diagnostic use case
Reconstruct true event order for funnels and sequences instead of trusting arrival order, which transport does not preserve.
What WebmasterID can help detect
WebmasterID records an event timestamp so sequences can be reconstructed by event time rather than arrival order.
Common mistakes
- Building funnels on arrival order instead of event time.
- Assuming global ordering from the transport.
- Ignoring clock skew when sorting by timestamp.
Privacy and accuracy notes
Ordering uses event timestamps and keys, not visitor identity. This page is educational, not legal advice.
Related pages
- Watermarking late data
Streaming analytics groups events into time windows, but some events arrive late — buffered offline, delayed in transit. A watermark is the pipeline's estimate of how far event time has progressed, used to decide when a window is complete enough to emit. Set it too tight and late events are dropped; too loose and results lag. This page explains watermarking and its trade-off for late-arriving data.
- 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.
- 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.
- Event Explorer
Reconstruct sequences by event timestamp.
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.