Metric History and Baselines
This page covers three things you need before comparing metric figures across time: when each metric began, why a past figure is not permanently fixed, and how to read levels around a data source being switched on.
When each metric started
| Metric | Available from | Filtering before that returns |
|---|---|---|
| Data Freshness | Always (live snapshot) | n/a - Freshness is "now", not historical |
| Time to First Fix | From the point tracking-job timestamps were recorded | Empty for earlier periods |
| Confirmation Delay | 1 March 2026 | Nothing - the field did not exist |
The most common surprise is Confirmation Delay: a filter set to February (or earlier) comes back empty. That is correct behaviour, not a gap in your data. The measurement did not exist before March 2026, so there is nothing to show.
Why a past figure can move
Freshness is a live snapshot, so it only ever describes now. But TTFF and Confirmation Delay are built on milestones, and milestones are recomputed every time a tradeflow is re-evaluated - which happens whenever a new event arrives or a correction lands. When that recompute runs, the milestone values (including the ones a past month's average was built from) are rewritten.
The practical consequence: a figure you read today for, say, April may differ slightly from the same figure read next month. The drift is normally small and normally downward, as late confirmations resolve and stragglers settle.
Because a historical figure can still move, treat any number you hand onward as SLA evidence as a reading taken at a moment in time, not a permanent constant. Two safe ways to do this:
- Snapshot it. Export or screenshot the figure at the moment you report it, and reference that snapshot.
- Caveat it. State that the figure reflects the metric as computed on the date you pulled it.
This is not a weakness specific to one customer - it is inherent to any metric built on a continuously re-evaluated plan, and being explicit about it is what keeps the number credible.
Reading metrics around a source activation (MSC Direct, 18 June 2026)
When a new or upgraded data source is switched on for an account, historical events for the affected shipments can arrive in a batch (a backfill). Backfilled events describe things that happened in the past but land now.
The MSC Direct integration was activated on 18 June 2026. Around that date, expect:
- A step change in coverage for MSC shipments as the direct feed begins - more events, confirmed sooner going forward.
- A possible transient bump in some metric windows straddling the activation, caused by the one-off backfill rather than by any real decline in service. Backfilled historical events are, by construction, "old" relative to now.
How to read it cleanly:
- Compare like-for-like periods on either side of 18 June - a full month before vs a full month after - rather than a window that straddles the activation date.
- Attribute a spike in the straddling window to the backfill first, not to degradation, and confirm by checking whether the affected events cluster around the activation date.
- Judge steady-state performance from the post-activation period once the backfill has passed through - that is the real baseline for MSC going forward.
A concrete before/after comparison for this account around 18 June can be produced on request. The reading rules above hold regardless of the specific numbers.