Your Monday morning review starts the same way it always does: open the bid performance report, check win rates against the weekly baseline, and flag anything outside the normal range for the stand-up.
This week, you notice something is off.
Win rates on two major exchanges have dropped 8% from the prior Monday. Thatâs not enough to trigger an alert, but it is enough to pull it out of the report and double click into.
You notice bid volume is steady, campaign budgets are intact, and no exchange connectivity issues were flagged over the weekend. So the next check is bid response time.
The average is sitting at 62 milliseconds on the primary bidding path, and the dashboards show green. p99 on the same path is 94 milliseconds, up from 81 four days ago.
In real time bidding, every auction has a finite response window. Average latency describes the typical request, but exchanges evaluate each bid against that deadline individually. That makes tail latency (p99) a far better indicator if bids that arrive too late to participate, even when the average looks healthy.
That 13-millisecond shift at the tail is enough to get everyoneâs attention. Average latency is fine, but win rates aren't.
On the bidding side, you see nothing has changed: no algorithm updates, no new integrations, or configuration changes. The bid logic is exactly where it was when win rates were 8% higher.
You check the algorithms first, then the data pipeline, and bid models. Infrastructure is the last place you look, because average latency still says 62 milliseconds, and the dashboards are still green.
The only number that doesnât fit is p99.
The pattern starts showing up in bid logs, then in response time distributions, then in comparisons between exchanges. Eventually, your investigation gets where it always gets when everything has been ruled out: the execution environment.
The issue is at the tail end of the distribution, not in the average response time. Bids that complete in 94 milliseconds instead of the usual 81 arenât just slightly slower. On enough requests, they cross the exchange timeout, turning valid bids into bids that never get considered.
By the time the average says everything is fine, the auction window could be closed.
In a shared environment, that kind of shift can happen without any change to the bidding logic. Another workload competes for CPU time, memory bandwidth, or network resources, and most requests still complete comfortably inside the auction window. But a growing number drift into the tail, and win rates move before the dashboards catch up.
Nothing in the average latency number explains it.
The win rate report is still open on the same screen it was an hour ago. The bid logic hasn't changed, average latency still says 62 milliseconds, and none of it explains why win rates are down.
None of it was going to show up in the average. The tail was always the place this would surface first, and it will again, on a different exchange, the next time another tenant's workload runs hot at the same moment yours does.
Bradley Lewington , AdTech Infrastructure Account Executive
Bradley Lewington is an AdTech Infrastructure Account Executive at servers.com by Nexcess, where he works with performance-sensitive businesses to evaluate infrastructure strategies that support both technical and commercial goals.