OpenRTB Bid Response Explained: Price, Creative and Auction Flow

The relationship between bid request and bid response

The bid response only makes sense in the context of the original request.

A bid request describes an advertising opportunity. The buyer evaluates it. The response refers back to that opportunity so the seller can determine exactly what the buyer wants to purchase.

Identifiers are therefore important. The request ID, impression ID, deal ID, and other transaction identifiers help both systems correlate the response with the correct auction.

If a response references an impression that does not exist in the request, the seller should not try to “guess” what the buyer intended. It should reject the response.

The same principle applies to deal context. If a buyer claims a deal that was not offered, or uses a deal for which the buyer is not eligible, the response should fail validation.

Strong programmatic systems are strict about transaction identity because silent mismatches become financial and reporting problems later.

The response container

A bid response can contain one or more seat-level or buyer-level bid groups depending on the transaction design.

The exact object names and supported fields depend on the OpenRTB version and implementation. The important concept is that the response groups bids in a structured way so the seller can understand which buyer or seat submitted them.

A seller should validate:

·        the response ID;

·        buyer or seat information where required;

·        each bid object;

·        pricing and currency expectations;

·        impression mapping;

·        media and creative data;

·        deal information;

·        notification fields;

·        supported extensions.

A syntactically valid JSON message is not automatically a valid bid response.

Production systems should also enforce size limits and parsing safety. A malformed or unexpectedly large response should not be allowed to consume excessive resources.

Price: what the bid actually offers

The bid price is one of the most visible response fields because it determines the buyer’s willingness to pay under the agreed pricing convention.

But price needs context.

The seller must know:

·        the currency;

·        the pricing unit;

·        whether the bid satisfies the floor;

·        whether a deal-specific price applies;

·        whether the response is eligible for the auction;

·        how the auction determines the final clearing amount.

A buyer that sends a very high numeric value in the wrong currency has not submitted a useful bid. A buyer that bids above the floor with an invalid creative has not submitted an eligible bid.

The seller should also protect against absurd or malformed values. Negative prices, non-numeric values, extreme outliers, or unsupported currency behavior should be handled explicitly.

Price is important only after the bid passes technical and policy validation.

Impression mapping

Every bid needs to map to an impression opportunity.

If the request contains multiple impressions, the response must make clear which one the buyer is bidding on. That mapping is essential because different impressions can have different formats, floors, deals, placements, or policies.

For example, a request could theoretically include both a display and a video opportunity. A display creative cannot be applied to the video impression simply because the overall request ID matches.

Sellers should therefore validate the impression identifier before performing price ranking.

Buyers should also preserve the request context internally so the response generator can use the correct impression data rather than rebuilding it from incomplete campaign state.

This is one of the simplest controls in an RTB system, but it prevents a large class of delivery errors.

Creative markup and creative references

The response needs to provide enough information for the seller to validate and eventually render the advertisement.

Depending on the media type and integration, the response can carry markup directly or provide structured assets or references.

For display, the creative may include HTML or other supported markup.

For native, the response can include structured assets such as title, image, body text, brand, and call-to-action.

For video, the response may include video ad markup or a reference to compatible media under the agreed protocol.

The seller should validate that the creative matches the requested media type.

A display response to a video-only request should be rejected. A creative with incompatible dimensions should be rejected or handled according to explicit supported rules. A native response missing required assets may be invalid.

Creative compatibility is not optional simply because the price is attractive.

Creative security

Creative delivery introduces security risk.

HTML5 and rich-media creatives can include scripts, external assets, click behavior, redirects, and interactive logic. Video markup can reference external resources. Native assets can include URLs and tracking pixels.

The seller should therefore have creative security controls appropriate to the format.

Possible checks include:

·        HTTPS requirements;

·        blocked domains;

·        redirect limits;

·        malware scanning;

·        script restrictions;

·        file-size limits;

·        asset-type validation;

·        click-destination policy;

·        sandboxing;

·        CSP or runtime isolation;

·        prohibited behavior detection.

A real-time auction may not have enough time to perform deep analysis on every new creative from scratch. Platforms often combine pre-approval, caching, creative IDs, asynchronous scanning, and runtime controls.

The important point is that the auction must not treat “buyer says this is a creative” as sufficient evidence that the creative is safe.

Advertiser and campaign metadata

Bid responses can include metadata that helps the seller understand who is advertising and which creative or campaign is involved.

This can support:

·        advertiser blocking;

·        category blocking;

·        competitive separation;

·        creative review;

·        reporting;

·        policy enforcement;

·        frequency or duplication analysis where supported.

The exact fields vary. Sellers should define which metadata is required.

If a publisher blocks a sensitive category, the marketplace needs enough information to enforce that rule. If the buyer omits required advertiser information, the bid may be ineligible.

Buyers should also avoid sending misleading metadata. A creative domain or advertiser identifier should correspond to the actual campaign.

Programmatic quality depends on both sides representing the transaction accurately.

Deal IDs in the response

When the request offers private marketplace opportunities, the buyer may bid under a specific deal.

The response can identify the deal so the seller knows which pricing, priority, and eligibility rules to apply.

Deal validation should answer:

1.      Was this deal offered in the request?

2.      Is the buyer or seat eligible?

3.      Is the bid price compatible with the deal?

4.      Is the inventory actually part of the deal?

5.      Is the creative allowed?

6.      Is the deal active?

7.      Does the deal have special priority?

A mismatch should not be silently converted into an open-auction bid unless the integration explicitly defines such behavior.

Deal errors can create serious commercial disputes because buyers and publishers may believe different pricing or priority rules applied.

The Private Marketplace vs Open Auction article explains the business context in more depth.

Win, loss, billing, and impression notifications

Programmatic integrations often use notifications to communicate auction and delivery outcomes.

It is important to keep the events distinct.

A win event can indicate that the buyer won the auction.

An impression event can indicate that the creative was actually rendered or counted according to the measurement contract.

A billing event can indicate the event that triggers payment under the commercial agreement.

A loss event can sometimes communicate that the bid did not win and may include a reason.

Not every integration uses the same notification model. Buyers and sellers should agree on which events are authoritative.

A win does not always mean a billable impression. A rendered ad does not always mean a click. A click does not automatically mean a conversion.

Clear event semantics are necessary for reconciliation.

Why valid responses can still lose

A valid response can lose for normal competitive reasons.

Another bidder may offer more. A direct campaign may have higher priority. A private deal may outrank open demand. A floor or pricing rule may affect eligibility. An ad server may make a final decision using additional campaign priorities.

This should be distinguished from rejection.

Examples of rejection:

·        malformed response;

·        unknown impression ID;

·        unsupported currency;

·        invalid price;

·        late response;

·        creative mismatch;

·        blocked advertiser;

·        policy violation;

·        deal mismatch.

Examples of valid losses:

·        another eligible bid ranks higher;

·        a higher-priority direct campaign wins;

·        a preferred or guaranteed transaction takes precedence.

These should have different log reasons.

Timeout behavior

RTB systems have strict time constraints.

A buyer can return the perfect response, but if it arrives after the seller’s deadline, it is not useful for that auction.

Timeout behavior should be measured by partner and geography. Network latency, server location, processing time, DNS, TLS, and buyer compute can all contribute.

Buyers should optimize the bidding path:

·        parse efficiently;

·        reject ineligible requests early;

·        avoid slow external dependencies;

·        cache campaign and creative data;

·        precompute where possible;

·        keep logging asynchronous;

·        enforce internal deadlines shorter than the seller timeout.

Sellers should choose timeouts based on revenue and user experience, not arbitrary values.

A slow bidder that rarely makes the deadline may look valuable in offline logs but produce little real revenue.

Currency handling

Currency mistakes can create severe financial errors.

The request and response should follow the integration’s currency rules. If multiple currencies are supported, both sides need clear conversion behavior.

A seller should never assume a price is in a default currency if the protocol or partner contract says otherwise.

Buyers should also avoid performing slow external exchange-rate lookups inside the auction path. Currency conversion rules should be predictable and operationally safe.

Reporting should preserve the original transaction currency where useful and clearly identify converted values.

Small currency errors can produce large accounting discrepancies at scale.

Native bid responses

Native advertising is structured differently from a basic display creative.

The response can contain the assets requested by the publisher: title, image, body, brand, icon, call-to-action, and other supported fields.

The buyer needs to satisfy required assets and length limits.

The seller needs to validate:

·        required assets are present;

·        image sizes are acceptable;

·        URLs are valid;

·        tracking is supported;

·        disclosure can be rendered correctly;

·        the creative fits the native template.

Native creative should not assume control of the page layout. The publisher typically determines presentation.

The broad format belongs on the Native Advertising page, while this article remains focused on the bid-response mechanics.

Video bid responses

Video responses require careful format matching.

The buyer may return compatible video markup or media information. The seller must check duration, protocol support, player environment, media type, and policy.

Video errors are expensive because the assets are larger and user experience is sensitive to delay.

The seller should reject responses that cannot play in the requested environment rather than attempting unsafe fallback behavior.

Buyers should also ensure that tracking and click behavior match the agreed video specification.

Video programmatic buying is therefore a good example of why a high price is only one part of bid quality.

Display and HTML5 bid responses

Display responses can be simple image creatives or more complex HTML5 and rich-media experiences.

For HTML5, the seller may need stronger controls around scripts, external resources, dimensions, click handling, and sandboxing.

A buyer should not send a creative designed for one size into a placement that cannot support it.

Platforms that host immutable creative packages can reduce ambiguity by tying delivery to a verified creative revision. The auction then references a known creative rather than accepting arbitrary code at the last moment.

This can improve security and reproducibility.

Broad HTML5 creative topics belong on the HTML5 Advertising page and Creative Studio content. The response article should explain only how the creative enters the auction transaction.

Seller-side validation sequence

A practical seller can validate in this order:

8.      Did the response arrive before the deadline?

9.      Does the response parse?

10.   Does it correspond to the current request?

11.   Does each bid reference a valid impression?

12.   Is the buyer/seat eligible?

13.   Is the price valid?

14.   Is the currency supported?

15.   Does the bid satisfy the floor or deal?

16.   Is the creative compatible?

17.   Is the advertiser allowed?

18.   Does the creative pass security and policy controls?

19.   Is the deal valid?

20.   Can the bid enter ranking?

This ordering avoids comparing bids that should never have been eligible.

Buyer-side response quality

Buyers should also monitor the quality of their own responses.

Useful metrics include:

·        bid response rate;

·        invalid response rate;

·        timeout rate;

·        seller rejection reasons;

·        creative rejection rate;

·        deal mismatch rate;

·        bid price distribution;

·        win rate;

·        billable impression rate;

·        discrepancy.

A DSP that sends many invalid bids wastes compute and damages partner trust.

No-bidding cleanly is better than submitting a response the seller cannot use.

Auction ranking after validation

Once the seller has a set of valid bids, ranking can begin.

The exact auction logic varies by platform and deal model.

Possible factors include:

·        bid price;

·        direct campaign priority;

·        guaranteed commitments;

·        preferred deal priority;

·        private marketplace rules;

·        floor logic;

·        buyer quality;

·        creative or policy constraints;

·        commercial rules.

The result should be deterministic enough to audit.

If an advertiser or publisher disputes an outcome, the platform should be able to explain which rule applied.

Opaque ranking creates operational and financial risk.

Reporting rejected bids separately from losses

This is one of the most valuable analytics practices.

A rejected bid tells you something is wrong with the response or eligibility.

A valid loss tells you the buyer simply lost competition or priority.

If the two are mixed together, optimization becomes confused.

For example, a DSP may see a low win rate and increase bids. But if most “losses” are actually creative rejections, bidding higher will not help.

Similarly, a publisher may believe a buyer is weak when the actual problem is a misconfigured deal ID.

Reason codes and structured logs turn auction outcomes into actionable data.

Example transaction

A publisher sends an OpenRTB display request for a 300×250 placement with a floor and an optional private deal.

Buyer A returns a $2.10 open-auction bid with an approved display creative.

Buyer B returns a $2.50 bid but references the wrong impression ID.

Buyer C returns a $2.30 bid under the private deal and is an eligible deal buyer.

Buyer D returns a $3.00 response after the timeout.

The seller rejects Buyer B because the impression mapping is invalid. Buyer D is late and cannot participate. Buyer A and Buyer C are valid.

The seller then applies deal and auction rules. Depending on deal priority, Buyer C may win even if Buyer A’s open bid is close in price.

This example shows why sorting all responses by price would be wrong.

How AdExchange.bd should structure this topic

The OpenRTB page should own broad protocol and integration intent.

The OpenRTB glossary should own the short definition.

OpenRTB Bid Request Explained should own request-side technical intent.

This article should own OpenRTB bid response technical intent.

The separation creates a clear learning path:

OpenRTB definition → bid request → bid response → auction and delivery.

That is better than creating several generic “OpenRTB guide” pages competing for the same query.

A response is more than a price

An OpenRTB bid response is the buyer’s structured offer for an advertising opportunity.

A good response does four things well:

21.   maps correctly to the request;

22.   offers a valid price under the correct commercial rules;

23.   supplies a compatible, safe creative;

24.   arrives on time with accurate deal and tracking information.

The seller then validates before ranking.

Price matters, but validity, policy, creative compatibility, deal correctness, and timing determine whether the price is even allowed into the auction.

That is the core principle behind reliable bid-response processing.

What makes a response usable, not just valid JSON

An OpenRTB bid response explained for operations must connect the returned price with the exact impression, deal and creative. RTB bid response fields are useful only when the seller can validate them consistently. The OpenRTB response object also carries information needed for creative and tracking, so programmatic bid response validation should happen before auction ranking rather than after an invalid creative has already won.