Three myths about reporting latency

The advice here is unglamorous, which is probably why it gets skipped. A few things about reporting latency that get repeated more often than they get checked.

Numbers get quoted in meetings long after anyone remembers how they were calculated. Assume whoever inherits this will have half your context and none of your patience.

“It only matters for big sites”

Decide how fresh reports genuinely need to be. That sounds obvious written down. It is still the thing most often skipped. It is the sort of thing that looks like polish right up until it costs you an enquiry.

“We can deal with it after launch”

Sometimes true, usually expensive. In practice this is a scheduling problem more than a technical one.

“Our platform handles it”

Most decisions do not need same-minute data. Getting it slightly wrong is survivable. Ignoring it entirely is not. Doing this properly once is usually cheaper than doing it approximately three times.

In practice

Data outlives the applications built on top of it, which is why the model deserves more thought than the screens. Three things worth confirming about reporting latency before you move on:

• Someone can say what the current setup is without going to look
• Real-time costs several times more than hourly — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.