Bid Request (OpenRTB)

A Bid Request is the atomic unit of supply in programmatic advertising. When a user loads a page or app, the publisher’s ad server calls the exchange, which broadcasts an OpenRTB BidRequest object to all connected DSPs.

Key components inside a Bid Request

• Imp objects — each describes one ad slot: size, floor price, allowed creative types, and optional Banner, Video, or Native sub-objects.
• Site/App object — publisher domain, content category, and inventory type.
• Device object — OS, browser, IP, device model, and geolocation.
• User object — anonymized ID (cookie, device ID, or PPID) and optional segments.
• Regs object — regulatory flags like COPPA, GDPR, or CCPA.

A single request can bundle multiple Imp objects (e.g., a 300×250 banner plus a 728×90 leaderboard). The DSP must decide which, if any, to bid on and return a response per Imp.id.

So what: The Bid Request is the raw material for every auction. Its richness determines how well a DSP can value the impression. Sparse or inaccurate requests lead to poor bid decisions.

A Bid Request is not calculated — it is constructed by the exchange from publisher supply signals. The count of Bid Requests is simply the number of BidRequest messages the exchange sends to bidders over a given period.

Bid Requests = count of BidRequest messages sent

Important caveats

1. Multi-Imp requests — A single BidRequest with 3 Imp objects is still 1 Bid Request, not 3. If you need slot-level volume, count Imp objects instead.
2. Duplicate requests — Some exchanges send the same impression to multiple bidders (multi-plexing). Each transmission is a separate Bid Request. This inflates the request count relative to actual ad calls.
3. Filtered requests — Requests that fail validation (e.g., missing required fields) are typically logged as errors, not Bid Requests. Check your exchange’s definition.
4. Timeout discard — A Bid Request that expires without a response is still counted as a request. The DSP’s response is what gets discarded.

So what: Comparing Bid Request volume to Bid Response volume reveals how many opportunities the DSP actually evaluated. A large gap often points to timeout or throttling issues.

Bid Request volume is a top-of-funnel metric. A high number means the DSP is seeing many opportunities; a low number may indicate connectivity issues, low traffic, or throttling.

What to pair it with

• Bid Response rate — Bid Responses / Bid Requests. A low rate means the DSP is skipping many requests (throttling, poor data, or slow processing).
• Win Rate — Won impressions / Bid Responses. If request volume is high but win rate is low, the bidding strategy or price is off.
• Average latency — Time from receiving the request to sending the response. If latency approaches the timeout, responses get discarded, lowering the effective response rate.

Common dashboard misread

A sudden spike in Bid Requests is often celebrated as “more supply.” But if the spike comes from low-quality inventory (e.g., MFA sites, invalid traffic), the DSP wastes compute cycles without winning valuable impressions. Always segment by inventory tier.

So what: Treat Bid Request volume as a health signal, not a success metric. The real question is: how many of these requests lead to a profitable win?

Bid Request volume is primarily controlled by the exchange connection and traffic quality filters. The DSP cannot increase publisher supply, but it can influence how many requests it receives and processes.

Levers that increase Bid Request volume

• Connect to more exchanges — Each new exchange integration adds a stream of requests.
• Enable more supply types — Open exchange, PMP deals, and direct inventory all generate different request flows.
• Reduce throttling — If the DSP caps QPS (queries per second), raising the cap lets more requests in.
• Broaden targeting — Removing geo, device, or category restrictions allows more requests to pass pre-bid filters.

Levers that decrease Bid Request volume

• Traffic quality filters — Blocking MFA, made-for-advertising, or low-viewability domains reduces request count but improves average quality.
• Supply path optimization (SPO) — Preferring direct SSP connections over resellers can reduce duplicate requests.
• User-consent restrictions — GDPR/CCPA opt-outs reduce the pool of addressable requests.

Tradeoffs

• More requests ≠ more revenue. Flooding the bidder with low-quality inventory increases compute cost and may degrade model accuracy.
• Aggressive throttling protects infrastructure but can miss valuable impressions. Balance QPS limits with expected win value.
• Filtering too early (before the bid model runs) may block high-value impressions that look cheap on paper. Use layered filtering: cheap pre-bid checks first, expensive model evaluation second.

So what: Optimize for valuable request volume, not raw volume. A DSP that processes 500K high-quality requests often outperforms one drowning in 5M low-quality ones.

The Bid Request is the raw signal that feeds every programmatic auction. Its volume matters, but only when paired with response rate, win rate, and quality segmentation.

• Count requests, but value impressions. High volume without quality is noise.
• Watch latency. A fast model that misses the timeout is useless.
• Segment by source. Not all exchanges or inventory types are equal — measure separately.