Request Analyzer: What Your Bid Requests Reveal About Your Auctions

For most publishers, the bid request is invisible infrastructure. It leaves the ad server, travels through a chain of intermediaries, and either comes back with bids or it doesn’t. What it actually contained along the way, which fields were present, which were malformed, which identifiers it carried, rarely gets a second look. Yet that request is the real product being auctioned. Everything a buyer knows about your impression, they learn from it. When it’s incomplete or inconsistent, demand quietly erodes, and almost nothing in a standard revenue dashboard explains why. Request Analyzer exists to make that invisible layer legible.

How it works

At its core, Request Analyzer checks the integrity and completeness of the bid request JSON against two reference points at once: the OpenRTB standard for the relevant version, and the specific requirements of individual demand partners, for example, a DSP like Microsoft. This matters more than it sounds. A request can be perfectly valid OpenRTB and still fail a particular buyer’s expectations. By evaluating both at the same time, the tool produces output that is actionable rather than merely technically correct.

The analyzer inspects the structure, flags and categorizes every issue it finds, extracts useful metadata, and stores the resulting error list and processed metadata so the information can feed reporting over time rather than being thrown away after a single check.

What the data reveals

The single most common error isn’t a malformed supply chain, it’s a missing one. Across the requests we’ve analyzed, only about 30% included a supply chain object at all. That matters because buyers increasingly rely on supply chain data to decide what to trust and what to skip. An impression with no declared path is, to a growing share of demand, worth less or simply not worth bidding on. Of the requests that did include a chain, roughly 80% were complete and about 20% came through with the complete field set to 0, meaning the declared path was acknowledged as only partial. Incomplete beats absent, but neither is the state you want to be selling from.

Identity tends to degrade as the chain gets longer. When multiple hops are present, user.buyeruid is missing in at least 15% of requests, a clear sign that cookie syncing is silently failing somewhere along the path. Every failed sync is a lower match rate, and a lower match rate means fewer buyers able to recognize the user and put in a bid for them.

Hops, more generally, are not free. We consistently see DSPs bidding up to roughly the third hop in the chain, after which revenue declines rapidly with each additional hop added. Bid floors also lose much of their influence over the outcome as the chain grows. The practical takeaway is that supply path length has a real ceiling, and stacking intermediaries past it costs more than it returns.

Identifiers, on the other hand, clearly earn their place. Requests carrying a GPID receive GPID about 40% more bid responses on average. Requests enriched with external user IDs such as ID5, LiveRamp, and IntentIQ consistently attract more responses as well. In a market steadily moving away from third-party cookies, the requests that arrive with clean, durable identity are the ones buyers can actually act on, and they tend to win attention before the auction’s competitive dynamics even begin.

Why it’s worth looking

None of these patterns shows up in a revenue report. They live inside the request itself, in fields that are present or absent, complete or partial. That’s exactly why they go unexamined, and exactly why the gains from fixing them tend to be both real and largely uncontested. The cost of leaving these issues unaddressed is paid quietly, request after request, in demand that never materializes. If you’ve never audited what your auctions are actually sending, that is where the next increment of yield is most likely hiding.