Guides / Lab scenarios

Test lab / Exchange testing

OpenRTB No-Bid Lab Scenario: Protocol vs Business Rules

A no-bid response is not automatically an integration defect. The test must separate protocol validity from demand eligibility.

Last reviewed: October 7, 2026 · Illustrative scenario

Transparency: This is a synthetic, reproducible lab scenario created for education. It is not presented as a client result, Google result, DSP result, or production measurement.

Scenario setup

Create a sanitized request fixture with a known impression, media type, publisher context, geography, currency, and floor. Keep a second fixture with one intentionally invalid field for negative testing.

Protocol test

Send the valid fixture through the test integration and validate the response contract. Then send the malformed fixture and confirm that the exchange rejects it predictably rather than creating an unexplained downstream failure.

Business-rule test

For the valid fixture, vary one eligibility condition at a time: geography, format, floor, creative eligibility, or campaign budget. A no-bid under an intentionally ineligible condition can be a correct outcome.

Finding

If the valid opportunity receives a no-bid while all eligibility conditions are satisfied, inspect the DSP's decision evidence and exchange filters. If the malformed request fails validation as designed, that is a passing negative test.

Regression case

Retain valid, invalid, boundary, timeout, and business-ineligible fixtures. Record the expected outcome for each so a future adapter or exchange change does not turn a legitimate no-bid into a mysterious failure.

About this guide

Prepared by the Skills Labs Tech Editorial Team · Reviewed for technical clarity October 2026

Skills Labs Tech publishes practical AdTech education for publishers, buyers, exchanges, product teams, and QA engineers. Examples on this site are illustrative unless explicitly identified as a documented test or source-backed observation.

Learn about our editorial approach and expertise →

Case study: An OpenRTB request returns no bid

A synthetic exchange sends a valid-looking OpenRTB 2.6 request for a banner impression and receives HTTP 204 from a bidder. The lab distinguishes a legitimate no-bid decision from a malformed transport or business-rule rejection.

Evidence ledger: what to capture

Capture HTTP status, request ID, imp IDs, format dimensions, site or app context, device signals, bidfloor and currency, consent fields, and bidder-side eligibility logs if available.

Controlled experiment and expected observations

Send one baseline fixture known to be eligible, then vary only the floor, format, or blocked category. Check JSON schema and field types separately from campaign targeting and budget.

Reading the result without overclaiming

HTTP 204 can be a valid no-bid response; it does not by itself mean the bidder endpoint failed. HTTP 400, 5xx, malformed JSON, or timeouts belong in separate error classes.

Correction, retest, and monitoring

Maintain a reproducible request corpus with expected status classes. Fix malformed payloads first; then ask demand partners for a reason code or targeting explanation using a sanitized request ID.

Important edge case

A well-formed bid request can still produce no bid because of consent, creative format, geo, budget, frequency, or campaign eligibility. Avoid assuming every no-bid is an integration bug.

Hands-on verification worksheet

Write a falsifiable hypothesis for this scenario: an openrtb request returns no bid. State what observation would disprove it.
Collect the minimum evidence before changing configuration. Capture HTTP status, request ID, imp IDs, format dimensions, site or app context, device signals, bidfloor and currency, consent fields, and bidder-side eligibility logs if available.
Create an isolated negative test and a positive control. Send one baseline fixture known to be eligible, then vary only the floor, format, or blocked category. Check JSON schema and field types separately from campaign targeting and budget.
Classify the outcome using a precise event boundary. HTTP 204 can be a valid no-bid response; it does not by itself mean the bidder endpoint failed. HTTP 400, 5xx, malformed JSON, or timeouts belong in separate error classes.
After any correction, run the same fixture and retain before/after evidence. Maintain a reproducible request corpus with expected status classes. Fix malformed payloads first; then ask demand partners for a reason code or targeting explanation using a sanitized request ID.
Include a note about alternative explanations. A well-formed bid request can still produce no bid because of consent, creative format, geo, budget, frequency, or campaign eligibility. Avoid assuming every no-bid is an integration bug.

Practical investigation notes and worked methods

Use paired fixtures to isolate eligibility

Create two OpenRTB fixtures that are identical except for one controlled field. For example, hold impression ID, media type, site context and currency constant while changing the bid floor from a permissive value to a deliberately restrictive value. The expected result is not that a DSP must bid on the first fixture: bidding remains a commercial decision. The test instead verifies that the exchange forwards the correct floor and that any filtering is explained by observable policy or adapter behavior. Repeat the approach for geography, format support and blocked advertiser categories.

Distinguish valid no-bid from invalid response

A valid request may produce no bid because the DSP has no eligible campaign, the floor is too high or its pacing rules exclude the opportunity. Separately, malformed JSON, missing required fields or unsupported protocol values should trigger documented validation behavior. Treat these as separate test classes. Log the request ID, HTTP status, response body, timeout threshold and exchange rejection reason when available. A blank response body, HTTP 204 and a structured no-bid response are not automatically equivalent across integrations; use the specific endpoint contract.

Inspect the request before blaming demand

Verify that the impression array is populated and each impression has a usable ID. Check that the declared banner, video or native format matches the inventory actually offered. Validate currency assumptions, bid floor units, site or app identity and the presence of required privacy signals. A request can be syntactically valid but commercially unusable because a critical context field is absent. Preserve a sanitized fixture and compare it against a known-good integration sample. Do not paste real device identifiers, IP addresses or consent strings into a public troubleshooting article.

Build a response classification table

For every test request, record one of five outcomes: valid bid, intentional no-bid, timeout, protocol rejection or transport failure. Then attach evidence: returned bid ID and price for a bid, configured eligibility rule for an intentional no-bid, elapsed time for a timeout, validator error for a protocol rejection, or network error for transport failure. This prevents the catch-all label no-bid from concealing defects. Compare exchange-side and DSP-side logs when both are available, because an exchange may reject a bid after the DSP returns it.

Regression tests that survive adapter upgrades

Save boundary fixtures for zero floor, high floor, missing optional field, unsupported format, malformed JSON and timeout. State the expected classification for each fixture and make the assertion resilient to legitimate DSP campaign changes. A useful deterministic regression environment uses a mock bidder with explicit rules rather than a live DSP whose budget and targeting fluctuate. Once protocol behavior passes in the mock environment, run a limited live smoke test and treat business no-bids as observations, not automatic failures.