Orderflow measurement: resets, units and information timing · 4 / 5
Orderflow lead and lag: align event time with arrival time
A trade can occur before a price move and arrive at your system after it. Sorting a downloaded dataset by exchange timestamps may create a lead signal that was unavailable in real time. Keep both event and arrival clocks when evaluating a decision.
Athenum7 minUpdated:
Preserve three different timestamps
Event time identifies when the exchange says an execution occurred. A message-generation timestamp identifies when the feed assembled an update. Local receipt time identifies when your collector received it. These fields can differ because of batching, network transit, reconnects and clock offsets.
Use exchange semantics rather than guessing from a short field name. Bybit’s public trade documentation distinguishes the execution timestamp from the message-generation timestamp. Neither is automatically your own arrival time. Record local receipt time at ingestion and retain timezone, precision and clock synchronization information.
Replay what was available to the decision
For a decision at local time t, include only observations received by t, then apply the strategy’s normal processing delay. A later correction can improve a historical display without changing what was knowable earlier. Preserve the first-seen record and subsequent versions rather than overwriting history.
Cross-venue lead-lag estimates also need clock-error bounds. A measured 20-millisecond lead is not compelling if clocks may differ by 100 milliseconds. Even reliable temporal precedence is not proof of causation or an executable opportunity after fees, latency and fill uncertainty.
Worked example: an apparent 100-ms lead arrives 200 ms late
In this constructed timeline, trade A occurs at 12:00:00.100 and reaches the collector at .400. The compared price update B occurs at .200 and arrives at .220. Event-time sorting places A 100 ms before B. The actual application receives B 180 ms before A.
A decision at .250 can see B but cannot use A. A backtest that joins A into the .100 event-time row and trades at .250 has leaked information. The first possible use of A is at or after .400 plus processing and order latency, when the opportunity and executable prices may have changed.
| Observation | Event time | Local arrival | Available at .250? |
|---|---|---|---|
| Trade A | 12:00:00.100 | 12:00:00.400 | No |
| Price B | 12:00:00.200 | 12:00:00.220 | Yes |
Open full-size diagram- .100: trade A occurs
- .220: price B reaches collector
- .250: decision sees B only
- .400: trade A finally arrives
A reconnect replay is not a fresh burst of trading
Buffered messages can arrive close together after a reconnect while describing older executions. Arrival-rate spikes may therefore be network recovery, not increased market activity. Preserve IDs, deduplicate at the correct trade identity and examine event-time distribution before interpreting the burst. Do not remove distinct trades merely because they share a message or sequence field.
Before acting
- Retain event, message and local receipt timestamps.
- Replay decisions from information received by the cutoff.
- Preserve late arrivals and revisions without moving them into earlier knowledge.
- Compare the claimed lead with clock uncertainty and executable latency.
Check your understanding
Trade X has event time .120 and arrival .310. Price Y has event time .180 and arrival .210. May a decision at .250 use X to predict Y?
Show the explained answer
No. Although X occurred 60 ms before Y, it arrives 100 ms after Y and 60 ms after the decision. At .250 the strategy can observe Y but not X. Using X there is an availability error, regardless of the event-time ordering.