A header bidding auction typically gives each bidder 1000 milliseconds to respond, yet a meaningful share of the demand you connect never competes at all. The bidder returns an error, an empty seat, or a response the exchange rejects, and the impression sells for less than it could. Most publishers treat these failures as noise because each individual error looks small. Aggregated across millions of auctions per day, they become one of the largest controllable revenue leaks in an ad stack. This article builds a working taxonomy of bid response failures, maps the common error codes to their causes, and describes the monitoring habit that catches chronic problems before they cost a quarter's worth of inventory.
What a Bid Response Contains Before It Fails
A valid OpenRTB bid response carries a defined payload: a seatbid object, one or more bid objects, a price in CPM terms, the creative markup (adm), the advertiser domain (adomain), a creative ID (crid), declared dimensions, and the win and loss notification URLs (nurl and lurl). Every one of these fields is a potential failure point. A response can arrive intact and still fail if the adomain points to a blocked advertiser, or if the declared width does not match the slot the bid targeted. If you want the full field-by-field breakdown, our OpenRTB guide covers the request and response objects in detail.
Failures split into two stages. Parse-stage failures mean the response never becomes a usable bid: malformed JSON, wrong object structure, empty seatbid arrays, or a timeout that arrives before the payload does. Validation-stage failures mean the bid parsed correctly but the exchange or publisher configuration rejected it: blocked advertiser domain, creative size mismatch, missing required fields, or a bid price below the floor. The distinction matters because parse-stage failures point at the bidder's infrastructure, while validation-stage failures usually point at your own blocklists, floors, or slot configuration. Diagnosing the wrong stage wastes hours on the wrong party.
The Five Failure Classes in Programmatic Bidding
Nearly every bid response failure falls into one of five classes. Classifying errors this way tells you who owns the fix and how urgent it is.
Class 1: Transport failures. The bidder never delivers a payload: connection timeouts, DNS failures, TLS errors, or responses that arrive after the auction deadline. These show up as timeouts in your auction logs, not as error codes, because there is no body to read. Chronic transport failures usually indicate a bidder with capacity problems or a network path issue between your wrapper and their endpoint.
Class 2: Parse and format errors. The payload arrives but the exchange cannot read it: invalid JSON, non-compliant OpenRTB structure, missing required attributes, or encoding problems. These errors are always the bidder's fault, and they are worth reporting immediately because they mean every request to that endpoint is wasted.
Class 3: Validation and policy rejections. The bid is readable but fails your rules or the exchange's rules. Common causes: the advertiser domain appears on a blocklist, the creative uses HTTP assets on a secure page, the declared size does not match the slot, or the creative lacks required attribution and privacy declarations. These errors are frequently fixable on your side, for example by correcting an over-broad domain blocklist.
Class 4: Auction-level no-bids. The bidder evaluated the request and declined to price it. No campaign matched the geo, the user failed a frequency cap, the floor exceeded what the bidder's inventory forecast allowed, or the deal ID in the request had no matching deal. These are not errors in the technical sense, but a bidder that no-bids 95 percent of the time functions as dead weight in your timeout budget.
Class 5: Post-win failures. The bid won the auction but the creative never rendered: VAST errors on video creatives, unreachable rendering URLs, or a creative that fired the loss URL after the win. These failures are the most expensive per instance because you burned the impression slot and possibly a viewable placement, then delivered nothing.
Standard No-Bid Reason Codes and What They Signal
The OpenRTB spec defines standard no-bid reason codes, so bidders can explain a decline without proprietary conventions. The OpenRTB no-bid reasons published by the IAB Tech Lab include codes for technical errors, invalid requests, suspected non-human traffic, unsupported devices, missing user signals, and publisher-side exclusions such as blocked advertiser domains. A bidder that returns an empty seatbid tells you nothing. The same bidder returning a no-bid reason of "publisher exclusions" tells you exactly which configuration to inspect. When you evaluate demand partners, treat support for structured no-bid reasons as a baseline requirement, not a nice-to-have.
Error codes on the demand side carry real consequences. Google's documentation on bid response error handling is explicit that bidders with chronically high error rates get throttled, which means the bidder receives fewer requests and your inventory sees less competition. The same logic applies to any exchange: an endpoint that consistently returns malformed responses gets deprioritized. This is why error rates belong in your partner reviews. A demand source with a 3 percent error rate is delivering 97 percent of its potential. A source sitting at 30 percent parse errors is effectively a third of a partner, and you are still spending timeout budget on every failed request.
On the sell side, the codes you see most often cluster around a short list. Invalid request errors usually mean a mismatch between your request template and the bidder's expectations, most often a missing or malformed supply source ID, a bad SupplyChain object, or an app request sent to a bidder that expects web inventory. Creative validation errors usually trace to size mismatches or secure-page violations. Deal errors mean the deal ID in the request has expired, paused, or changed terms. Write down which codes your stack produces most often, because that distribution becomes your prioritization list.
Reading Prebid Diagnostics for Missing Bids
Client-side diagnostics give you the fastest path from symptom to cause. When bids go missing from a placement, the Prebid troubleshooting guide lays out a structured diagnosis: enable the debug flag, inspect the bidder responses in the console, and check each stage in order, from request construction through response parsing to the final ad server call. The key discipline is to check one stage at a time rather than guessing.
Three checks catch most problems. First, confirm the bidder actually received a request with the correct ad unit code and sizes; a misconfigured size mapping means the bidder sees no compatible slot and returns nothing. Second, read the raw response in the console; a parse error there points at the bidder, while a valid bid that never reaches the ad server points at your key-value setup or the ad server line items. Third, verify the timeout value against the bidder's measured response time; a bidder that answers in 900 milliseconds will never compete in a 700 millisecond auction. That last failure is silent, common, and entirely self-inflicted.
Prebid also exposes per-bidder timing and no-bid counts in its analytics events. If you run Prebid through an SSP wrapper, ask the provider for the same telemetry. We surface bidder-level response rates, timeout rates, and bid density in our analytics reporting precisely because a bidder that quietly degrades from 60 percent bid density to 20 percent will otherwise go unnoticed for weeks while revenue drifts down.
The Monitoring Habit That Catches Chronic Errors
Chronic errors survive because nobody looks at error data on a schedule. Spot checks catch dramatic outages. Only a recurring review catches the slow rot: a bidder that starts failing 15 percent of requests, a deal that expired last month, a blocklist entry that quietly excludes a top advertiser category. The habit that prevents this is simple: a fixed weekly review of five numbers, per demand partner.
The five numbers are bid response rate, timeout rate, parse error rate, validation rejection rate, and post-win render failure rate. Bid response rate tells you how often the partner returns any payload at all. Timeout rate tells you whether your auction deadline fits the partner's real latency. Parse error rate isolates the bidder's technical health. Validation rejection rate points at your configuration and the bidder's creative quality together. Render failure rate measures the most expensive class, because those impressions were sold and then wasted. Each number needs a threshold you set in advance, for example: investigate any partner above a 5 percent timeout rate, or any parse error rate above 1 percent. Thresholds make the review fast, because a number is either inside its threshold or it triggers an action.
Two habits extend the review. Log error codes with timestamps and placement IDs, not just counts, because the distribution tells you whether an error affects all traffic or one geo, one device type, or one ad unit. And pair the sell-side review with a demand-side conversation: when you hand a partner a precise error breakdown, fixes happen in days instead of quarters. If you run inventory through us and see an error pattern you cannot decode, our help center documents the error codes our SSP emits and what each one requires from you or from the bidder.
Fixing Failures in Priority Order
Not all errors deserve equal attention, and the taxonomy gives you the order. Fix Class 2 first: parse errors mean the bidder contributes nothing, and every request to that endpoint burns timeout budget for zero return. Report the error samples to the partner, and if the rate stays high, cut the timeout for that bidder or remove it until the endpoint works.
Fix Class 5 second: post-win failures cost you a sold impression, which is worse than an unsold one. VAST errors deserve special attention on video inventory, because a failed VAST chain often means the winning creative never played and the session delivered a blank player. Track render success separately from auction success, and hold video demand partners to a strict render rate.
Class 3 comes third because validation rejections usually have the highest fix yield per hour of work. Audit your blocklists for entries that block entire categories rather than specific advertisers, confirm that your slot definitions match the creative sizes your demand partners actually run, and check that secure-page requirements reach the request so bidders filter insecure creatives before bidding. Class 4 needs periodic attention rather than urgent attention: review no-bid reason distributions quarterly to find partners whose targeting simply does not overlap your inventory, and either renegotiate or reallocate their timeout budget. Class 1 sits with the partner, but you control the deadline: measure real response latency per bidder and set the auction timeout so that partners which reliably answer within it can compete.
Error Budgets as a Partner Management Tool
The final step turns monitoring into leverage. Assign each demand partner an error budget: an agreed ceiling on the combined parse, timeout, and render failure rate, reviewed monthly against actual numbers. Partners that stay inside their budget keep full timeout allocation. Partners that exceed it get a shorter deadline, which protects your auction, and a corrective plan. This mechanism costs nothing and changes behavior, because every demand partner optimizes what the publisher measures.
Internally, we apply the same standard to our own stack. We combine Prebid, OpenRTB, Google MCM, Google AdX demand, and direct deals into a single auction, and we filter unwanted ads before they ever reach your page, which removes a whole class of validation rejections before it can occur. We pay Net 30, globally, across web, app, and CTV, and we treat bidder error rates as part of the service we owe publishers, not an externality they should absorb. The publishers who see the steadiest CPMs share one trait: they know their error rates, they review them weekly, and they act on the numbers. The taxonomy above gives you the vocabulary, and the five-number review gives you the routine. Everything else is execution.
