How to diagnose latency in a header bidding wrapper — in order

How to diagnose latency in a header bidding wrapper — in order

Header bidding (publishers auctioning inventory to multiple SSPs in the browser before calling the ad server) lives or dies on timeout. Here's how a buyer pinpoints where it's bleeding.

1. Establish the wrapper's auction timeout — the window each demand partner has to respond. Bids arriving after it are simply discarded, and you may be one of them.

2. Pull your own response-time distribution per SSP from your logs. Compare your p95 latency against each wrapper's timeout.

3. If your p95 exceeds the timeout, you're winning fewer auctions than your bids deserve — the loss is timeout, not price.

4. Decompose your latency: time-in-network versus time-in-decisioning. Geographic distance to the SSP's data center often dominates; a US bidder responding to an EU auction may structurally miss the window.

5. Check whether the SSP uses server-side header bidding (the auction moved from browser to a server-to-server call) for that publisher, which changes the timeout budget entirely.

6. Prioritize SSPs where you're fast and the timeout is generous; deprioritize structurally slow paths.

Why it matters: A buyer can have the highest bid and still lose every impression to a 100-millisecond timeout, and the dashboard reports it as a normal auction loss. Reading latency against the wrapper's timeout reveals win-rate loss that no amount of bidding up will fix.