OpenRTB Bid Request Explained: Key Objects and Auction Flow

The top-level request: the auction container

A bid request is best understood as an auction container. It identifies the request and provides the objects that describe the opportunity.

The request usually has an identifier so the seller and buyer can correlate responses with the correct auction. It can carry one or more impression opportunities depending on the integration and media environment. It can also include context objects such as site, app, device, user, source, regulations, and other implementation-specific information.

A buyer should treat the top-level request as untrusted external input. Even when a partner is approved, production code should validate types, required identifiers, allowed values, supported extensions, and size limits. Invalid or unexpected data should fail safely rather than causing the bidding service to crash or produce an uncontrolled response.

The buyer should also know which OpenRTB versions and extensions are supported by the integration. The protocol evolves, and partners may use optional fields or extensions differently. A good integration contract documents exactly what is expected instead of relying on assumptions.

The impression object: what can actually be bought

The impression object is central because it represents the auctionable advertising opportunity.

An impression can describe one or more supported media types. For display inventory, it can carry banner-related information such as dimensions or allowed formats. For video, it can include player and media requirements. For native, the transaction can use structured native assets or a supported native request format. Other media types or extensions may be supported depending on the integration.

The impression object can also include pricing information such as a bid floor, deal references, placement identifiers, secure-delivery requirements, and other fields that help buyers understand the opportunity.

Buyers should not treat every field as authoritative without validation. A placement can claim a size that the creative cannot actually fit. A floor can use a currency the buyer is not prepared to interpret. A deal ID can be unknown. A media object can contain combinations the buyer does not support.

A robust DSP checks compatibility before bidding. If the campaign has a 300×250 display creative, it should not bid on an opportunity that only permits an incompatible format. If the request is video, a display-only campaign should be excluded before bid valuation.

Banner and display opportunities

Display is one of the easiest media types to visualize, but the request still needs careful interpretation.

A display opportunity can specify one or more accepted widths and heights, position information, blocked creative types, supported APIs or secure delivery, depending on the request and implementation. Buyers use those fields to determine whether an available creative can render correctly.

The system should distinguish between “the request contains a size” and “the creative is actually eligible.” Campaign-side rules may impose additional requirements. The advertiser may only approve certain placements. The publisher may block specific advertisers or categories. The creative itself may have file-size, animation, click, or security constraints.

Responsive display adds another layer. A platform may support several sizes or adaptable formats, but the buyer and seller must agree on how the creative is declared and rendered.

For AdExchange.bd, the Display Advertising page can own broad commercial and format intent, while this article remains focused on the technical bid-request interpretation.

Native requests

Native advertising often uses structured assets rather than a single image or HTML block.

A native request can tell the buyer which components the publisher needs, such as a title, image, body text, call-to-action, brand name, or other asset types. The publisher controls how those assets are rendered so the ad can fit the surrounding content experience.

That means a native buyer needs more than a campaign that says “native.” It needs creative assets that satisfy the required fields and any size or length limits. The buyer should avoid bidding when required assets are missing.

Native also requires careful disclosure and measurement. The fact that an ad visually fits a content feed does not remove the need for clear advertising disclosure. The transaction should preserve the information needed for tracking and policy enforcement.

When the native request contains a nested structure or versioned specification, both sides should validate that they are interpreting it consistently. An integration that silently ignores required native assets can produce broken ads even if the auction itself succeeds.

Video requests

Video opportunities can contain richer technical constraints than simple display.

The request may describe whether the placement is in-stream or outstream, accepted media types, duration limits, player dimensions, protocols, playback methods, placement context, and other media requirements. Buyers should use those fields to ensure that the video creative is compatible.

A common mistake is bidding with a video asset just because the request says “video.” The player may not support the asset or protocol. The creative duration may be outside the allowed range. Autoplay expectations may conflict with the publisher environment. Measurement requirements may not match.

Video is also latency-sensitive. Large creatives, redirects, or slow decisioning can degrade the user experience. The buyer should therefore consider both eligibility and delivery performance.

Broad search intent around video belongs on the Programmatic Video Advertising page. This article should remain specifically about how a bid request describes an auction opportunity.

Site and app context

A request can include a site object for web inventory or an app object for application inventory.

These objects help buyers understand where the ad may appear. They can include domain, page or app identifiers, publisher information, content categories, store URLs, and other contextual data depending on the transaction.

Domain and app identity are important for brand suitability, campaign inclusion or exclusion, fraud checks, and supply-path analysis. Missing or inconsistent information should be handled carefully. A buyer should not silently invent a domain when the request does not provide one.

Context also matters for campaign performance. An advertiser selling accounting software may value a business article differently from a gaming page even if the same display size is available. Contextual targeting systems can use permitted page and content signals to evaluate that difference.

However, context should be treated as one signal among many. A category label can be wrong. A page URL can be misleading. Automated classification can make mistakes. Quality systems should combine protocol fields with partner trust, content analysis, and policy rules where appropriate.

Device and connection data

The device object can provide information about the environment in which the ad will render.

Possible data can include user agent, operating system, device type, language, screen information, network or connection information, IP-derived data, and other permitted signals. The exact fields vary by platform, privacy rules, browser behavior, and integration.

Buyers use device signals for compatibility and targeting. A mobile-only campaign should not buy desktop inventory. A creative that depends on a capability unavailable in the environment should not be served. Device information can also support fraud detection and measurement.

At the same time, device data can be sensitive or restricted. Buyers should process only what is permitted and necessary. They should respect privacy signals and avoid building unsupported identity inferences from incomplete technical data.

The safest approach is to separate “available signal” from “allowed use.” A field can be present but still subject to consent, policy, regional law, or contractual restrictions.

User, identity, and privacy signals

The user object and related privacy signals require especially careful handling.

Programmatic systems historically relied heavily on identifiers, but modern advertising increasingly uses first-party data, contextual signals, publisher-provided data, privacy-preserving identity approaches, and transactions that do not depend on cross-site identity.

A buyer should not assume that a user identifier is always present. It should also not assume that a present identifier can be used for every purpose. Consent and regional privacy rules may limit processing.

Privacy frameworks can provide signals that help platforms decide whether certain data uses are permitted. The buyer should implement those signals explicitly rather than treating privacy as a post-processing step.

This is also where audience targeting and contextual targeting diverge. Audience targeting depends on eligible audience-related signals. Contextual targeting can often operate using page or environment information without identifying an individual user. The article Contextual Targeting vs Audience Targeting covers that distinction in more depth.

Bid floors and currency

A bid floor can indicate the minimum price the seller is willing to accept for an impression under the relevant transaction rules.

Buyers need to interpret floors carefully. The currency must be known. The floor may interact with deal pricing. The marketplace may have additional business rules. A DSP should not assume that “bid above the floor” guarantees eligibility or victory.

Floors are also not a universal truth about inventory value. Publishers can set them too high and reduce demand participation. They can set them too low and weaken price discipline. Dynamic or segmented floor strategies should be evaluated with revenue and fill data rather than intuition alone.

From the buyer side, a floor is an input to the decision, not the final clearing price. The DSP still needs to estimate how much the impression is worth for the campaign.

When no floor is present, the buyer should follow the agreed integration behavior. It should not invent a floor unless its own bidding logic uses an internal minimum or risk rule.

Deals and private marketplace information

A bid request can carry information about private marketplace opportunities.

Deals allow buyers and sellers to attach specific commercial rules to inventory. A deal can define access, pricing, priority, inventory scope, or other conditions. The request may include deal identifiers that eligible DSP campaigns can recognize.

The DSP must match the deal to the correct campaign. Bidding on an unknown or ineligible deal can create reconciliation problems. The seller must also verify that the responding buyer is allowed to use that deal.

A PMP can still use real-time bidding. The difference from an open auction is that participation is controlled. This is why “deal” and “RTB” are not opposites.

The article Private Marketplace vs Open Auction should own the commercial comparison, while this section explains only how deal context appears in the request.

Supply-chain information

Buyers increasingly care about the path between publisher and buyer.

Supply-chain information can help identify the sequence of sellers and intermediaries involved in making inventory available. When combined with ads.txt, sellers.json, and other transparency mechanisms, it can support supply-path analysis and help buyers avoid unauthorized or unnecessarily complex routes.

A supply-chain object does not automatically prove that an impression is good. It is one transparency signal. Buyers still need to validate seller declarations, publisher identity, fraud risk, domain or app quality, and commercial trust.

The buyer should also distinguish between missing data and deceptive data. A new or limited integration may not provide every field. That is different from a partner intentionally misrepresenting a seller relationship. Policy can treat those situations differently.

Supply-path optimization should be evidence-driven. The goal is not simply to choose the shortest path; it is to choose paths that provide legitimate value, quality, efficiency, and transparency.

Regulations and consent

Programmatic advertising operates across different privacy and regulatory environments, so the request can carry regulatory and consent-related signals.

The correct behavior depends on applicable law, the parties’ roles, the user’s choices, and the integration contract. A technical field alone does not replace legal or policy analysis, but the bidding system should be built to honor the signals it receives.

A DSP should be able to exclude campaigns or data uses when required consent is absent. It should also avoid using unsupported data simply because a partner sends it. Sellers should not send unnecessary personal data.

This is one reason production OpenRTB Integration integrations need more than schema validation. They need policy-aware processing.

What a buyer should validate before bidding

A practical buyer-side validation sequence can include:

1.      Request identifier exists and is usable.

2.      At least one supported impression opportunity exists.

3.      Media type and dimensions are compatible with available creatives.

4.      Site or app information meets supply policy.

5.      Device and environment signals are parseable.

6.      Privacy and consent requirements are satisfied.

7.      Currency and floor information are understood.

8.      Deal IDs are recognized where relevant.

9.      Supply-chain information passes applicable quality rules.

10.   Campaign targeting and budget rules are satisfied.

11.   The request is still within the allowed response window.

12.   The response can be generated safely and within size limits.

The exact sequence varies, but validating early helps avoid wasting compute on opportunities that can never produce an eligible bid.

A simplified auction example

Suppose a publisher exposes a 300×250 display placement on a technology article.

The request identifies the impression, display format, site domain, page context, device type, floor, and privacy state. The DSP receives it and checks active campaigns.

Campaign A targets technology content, supports 300×250, has available budget, and permits the supply source. Campaign B is video-only, so it is immediately excluded. Campaign C supports display but is restricted to another geography, so it is also excluded.

The DSP evaluates Campaign A’s value, calculates a bid, selects an approved creative, and returns a response. The seller validates the response and compares it with other eligible bids. If Campaign A wins, delivery proceeds.

The bid request did not “choose” Campaign A. It supplied the structured information that allowed the DSP to make that decision.

Common bid-request mistakes

One common mistake is assuming every optional field is always present. Production code should be tolerant of valid sparse requests.

Another is treating fields as trustworthy just because the message parses. Fraudulent or low-quality inventory can still send syntactically valid data.

A third mistake is applying audience logic without checking privacy signals.

A fourth is bidding on formats that the creative cannot render correctly.

A fifth is ignoring currency and deal context.

A sixth is allowing unexpected extensions to break the parser.

A seventh is doing too much expensive processing before basic eligibility checks. In a low-latency bidding environment, efficient validation matters.

These mistakes can increase no-bid rates, invalid responses, latency, policy risk, and financial discrepancies.

How this fits with AdExchange.bd

AdExchange.bd’s OpenRTB page should own broad OpenRTB commercial and integration intent. The OpenRTB glossary should own the concise definition. This article owns the deeper technical search intent around OpenRTB bid requests.

That separation avoids cannibalization. Someone searching “what is OpenRTB” should reach the core or glossary content. Someone searching “OpenRTB bid request objects” or “how to parse an OpenRTB bid request” should find a technical guide like this.

The next logical article is OpenRTB Bid Response Explained, which covers what the buyer returns and how the seller validates the response.

What to remember when reading bid requests

An OpenRTB bid request is not just a bag of fields. It is the structured description of an advertising opportunity.

The impression object tells the buyer what can be purchased. Site or app data describes the environment. Device signals help with compatibility and targeting. Privacy information controls permitted processing. Deals can define private commercial rules. Supply-chain data helps explain how inventory reached the buyer. Floors and currencies influence valuation.

A good DSP does not blindly bid on every valid-looking message. It validates the request, applies privacy and policy rules, checks campaign eligibility, evaluates supply quality, confirms creative compatibility, calculates value, and responds within the required time.

That disciplined interpretation is what turns a protocol message into a reliable programmatic buying decision.

The request terminology developers actually encounter

An OpenRTB bid request explained for implementation work has to cover more than the top-level JSON object. OpenRTB request objects describe the impression and its context, while RTB bid request fields carry pricing, privacy, device, deal and supply information. In an OpenRTB auction request, a buyer still decides whether the opportunity is eligible and valuable enough to bid on.