RTBlintAlpha
Menu

OpenRTB and programmatic advertising glossary

141 terms, grouped by topic. Each definition links to the page that covers the term in depth: a glossary entry, a field reference page, or a guide.

Industry and standards

AAMP
AAMP, the Agentic Advertising Management Protocols, is IAB Tech Lab's umbrella program for agentic advertising standards. It groups the work into foundations, protocols, and trust, ships buyer and seller agent SDKs, and builds on OpenRTB, AdCOM, VAST, and GPP instead of replacing them. Version 1.0 arrived in January 2026 and version 2.0 in June 2026.
Ad exchange
An ad exchange is the marketplace that runs real-time auctions for ad impressions. It receives an impression from a publisher or SSP, sends bid requests to connected bidders, applies floors and blocks, picks the winner, and returns the ad. In OpenRTB the exchange is the party that sends requests and sets the auction rules, such as BidRequest.at and BidRequest.tmax.
Ad server
An ad server is the system that decides which ad fills a slot and records that it was shown. A publisher ad server, such as Google Ad Manager, holds direct-sold campaigns, priorities, and pacing, and weighs them against programmatic demand. An advertiser ad server hosts creatives and counts impressions and clicks independently of the seller. Neither is an OpenRTB role, though both shape what bidders see.
AdCOM
AdCOM, the Advertising Common Object Model, is the IAB Tech Lab companion specification that defines objects and enumerated lists shared across its standards. OpenRTB 2.6 moved all of its value lists there, such as device types, API frameworks, and creative attributes, so the lists can change faster than the protocol. OpenRTB 3.0 also uses AdCOM as its full domain model.
AdCP
AdCP, the Ad Context Protocol, is an open protocol that lets AI agents discover, negotiate, and buy media from each other. It launched in October 2025, is governed by AgenticAdvertising.org, and runs over the Model Context Protocol with Agent2Agent as a second transport. A negotiated AdCP buy still executes in the auction as an ordinary OpenRTB request, usually as a deal.
Agentic buying
Agentic buying is media buying in which software agents, usually built on large language models, plan and negotiate campaigns on behalf of buyers and sellers. The agents mostly work at planning and negotiation time over protocols such as AdCP or IAB Tech Lab's AAMP, and what they agree on still executes as an ordinary OpenRTB bid request, typically carrying a deal ID.
ARTF
ARTF, the Agentic RTB Framework, is IAB Tech Lab's specification for running third-party agent services inside the auction path. A host exchange or DSP runs agent containers next to its auction and calls them over gRPC with Protocol Buffers, and the agents return typed mutations that change the bid request or response in flight. Version 1.0 went to public comment in November 2025.
DSP
A DSP (demand-side platform) is software that buys ad impressions for advertisers and agencies, deciding for each bid request whether to bid and how much based on targeting, budget, and the signals in the request. In OpenRTB a DSP is the bidder: it receives bid requests, returns bid responses for the seats it represents, and receives win, billing, and loss notices.
Header bidding
Header bidding is a publisher technique that asks several exchanges and demand sources to bid on an impression at the same time, before the primary ad server decides, so they compete on price instead of being called in a fixed order. It runs client-side in the browser or app, or server-side, and Prebid is the most widely used implementation.
IAB Tech Lab
IAB Tech Lab is the nonprofit technical standards body of the digital advertising industry, funded by member companies and set up by the Interactive Advertising Bureau. It maintains OpenRTB, AdCOM, VAST, ads.txt, sellers.json, the supply chain object, and the Global Privacy Platform, and more recently its agentic standards, AAMP and ARTF. Member working groups write and revise the specifications.
OpenRTB
OpenRTB is the IAB Tech Lab standard for real-time bidding: the JSON bid request an exchange sends to bidders, the bid response they return, and the win, billing, and loss notices that follow. It began as an industry pilot in 2010 and now ships as dated 2.6 snapshots, with its value lists kept in AdCOM and a separate, rarely deployed 3.0 line.
OpenRTB 3.0
OpenRTB 3.0 is a layered redesign of the protocol, first released in November 2018, that wraps a thin Request and Response in an Openrtb envelope and moves every domain object, such as placements, ads, and context, into AdCOM. It was designed with ads.cert signed requests built in. It is not backward compatible with 2.x, and most production traffic still runs 2.6.
Prebid Server
Prebid Server is the open-source server-side header bidding engine from Prebid.org, with separate Go and Java implementations. It accepts an OpenRTB bid request, splits it into one request per configured bidder, calls them in parallel, and returns the combined bids. Prebid.js, the Prebid Mobile SDKs, AMP pages, and long-form video integrations use it to move auctions off the device.
Prebid.js
Prebid.js is the open-source JavaScript library, maintained by Prebid.org, that runs header bidding auctions in the browser. Publishers configure ad units and bidder adapters; Prebid.js calls each demand partner in parallel, collects bids within a timeout, and passes the winners to the ad server as targeting keys. It can also route some bidders through Prebid Server instead of calling them from the page.
Programmatic advertising
Programmatic advertising is the automated buying and selling of digital ads, where software decides which ad to show and at what price, often through an auction that runs while a page or app loads. It covers open auctions, private marketplaces, and fixed-price deals carried over the same connections. OpenRTB is the shared message format that lets exchanges and buyers trade.
SSP
An SSP (supply-side platform) is software that sells a publisher's ad inventory programmatically, managing floors, deals, and demand connections to get the best price for each impression. Many SSPs also run their own ad exchange. In OpenRTB terms an SSP usually plays the exchange role: it builds the bid request, sends it to bidders, runs the auction, and fires the notices.
Waterfall
A waterfall is the older way of selling remnant inventory, in which the publisher's ad server calls demand partners one at a time in a fixed priority order, usually ranked by their historical average price, and passes the impression down the list until someone fills it. Header bidding largely replaced it on the web by letting partners bid at the same time.

Auction and pricing

Auction type
Auction type is the rule that sets what the winning bidder pays, carried in BidRequest.at: 1 for first price, 2 for second price plus, and 500 or higher for exchange-specific rules. The default is 2, so a first-price exchange must send 1 explicitly. A deal can override the request value through Deal.at, where 3 means the deal floor is the fixed agreed price.
Bid density
Bid density is the number of competing bids an auction receives for an impression, usually reported as an average per auction. More bids push the clearing price up and make floors matter less; thin auctions clear near the floor or not at all. It is mostly an exchange and publisher metric, because a single bidder sees only its own bid and whatever price feedback the exchange returns.
Bid floor
A bid floor is the minimum CPM a seller will accept for an impression, sent in Imp.bidfloor with its currency in Imp.bidfloorcur, which defaults to USD. Bids below it are rejected, and exchanges report that with loss reason 100. Deals carry their own floor in Deal.bidfloor, and video or audio slots can add duration-based floors or a per-second minimum in Video.mincpmpersec.
Bid multiplier
A bid multiplier is a factor a DSP applies to a base bid to raise or lower it for a slice of traffic, for example 1.2 for a valuable audience or 0.5 for a weak placement. It is buyer-side configuration, not an OpenRTB field. People often confuse it with the impression multiplier in Qty.multiplier, which says how many impressions one digital out-of-home play counts as.
Bid rate
Bid rate is the share of bid requests to which a bidder responds with at least one bid, calculated as requests bid on divided by requests received. Exchanges track it per bidder to decide how much traffic to send, and bidders track it to see whether their campaigns match the supply. A low bid rate means most requests are being passed on, for good reasons or bad ones.
Bid shading
Bid shading is a buy-side pricing technique that submits less than the buyer's full valuation, estimating the lowest bid that still wins. It became standard when exchanges moved to first-price auctions, where the winner pays its own bid. OpenRTB carries no shading field. DSPs train shading models on auction feedback, chiefly the clearing price, the ${AUCTION_MIN_TO_WIN} macro, and loss reason codes.
Clearing price
The clearing price is what the winning bidder actually pays for an impression. In a first-price auction it equals the winning bid; in a second-price auction it is set just above the runner-up, or at the floor. The exchange reports it to the winner by substituting the ${AUCTION_PRICE} macro in the win or billing notice, in the bid's currency and CPM units.
Curation
Curation is the packaging of inventory and data into a ready-to-buy deal, assembled on the sell side by a curator such as a data company, an agency, or an SSP. The buyer receives one deal ID, and the audience and inventory filters behind it are applied before the request is sent. In OpenRTB a curated deal looks like any other entry in Pmp.deals, with nothing marking it as curated.
Deal
A deal is a prearranged agreement between a seller and a buyer to trade impressions on agreed terms, such as a fixed price, a floor, a list of allowed seats, or a commitment to buy. In OpenRTB each eligible deal appears as a Deal object inside Imp.pmp, named by Deal.id, and a bid that uses the deal echoes that ID in Bid.dealid.
Deal ID
A deal ID is the string both sides agree on in advance to name a deal. The seller sends it in Deal.id inside Imp.pmp, and a buyer bidding on that deal must return the identical value in Bid.dealid. When the two differ, the deal never triggers: the bid either falls back to open-auction treatment or is rejected, often with loss reason 4 (Invalid Deal ID).
Fill rate
Fill rate is the share of a publisher's ad requests that end with an ad served, calculated as filled impressions divided by ad requests. It is a sell-side metric that an SSP or ad server reports per placement, deal, or demand partner. Low fill means bidders saw the inventory and passed, or that their bids were filtered out before any could win.
First-price auction
A first-price auction is an auction in which the highest bid wins and the winner pays exactly the amount it bid. OpenRTB signals it by setting BidRequest.at to 1. Because nothing discounts the price toward the runner-up, buyers lower their bids toward the expected clearing price, a practice called bid shading. Most open-market programmatic auctions now run this way.
Floor optimization
Floor optimization is the sell-side practice of setting each impression's minimum price from data, moving Imp.bidfloor up or down by placement, buyer signals, time, or other context to earn more than one static floor would. SSPs, publisher ad servers, and header bidding wrappers all do it. Done well, it takes more from high-value impressions without killing fill on the rest.
Loss reason
A loss reason is the code an exchange sends a bidder to explain why its bid did not win, substituted into the ${AUCTION_LOSS} macro in the loss notice URL in Bid.lurl. The list is maintained with OpenRTB 3.0 and covers exchange errors and invalid bids, auction outcomes such as floors, higher bids, and blocked seats (100 to 104), and creative filtering (200 to 215), with 500 and above left to exchanges.
Minimum bid to win
Minimum bid to win is the lowest price that would have won or tied an auction, reported to bidders through the ${AUCTION_MIN_TO_WIN} macro added in OpenRTB 2.6. A losing bidder learns how far below the winner it was; a winning bidder learns the next-closest bid, or the floor if it bid alone. Exchanges may leave it empty when their policy forbids sharing prices.
No-bid
A no-bid is a bidder's decision not to bid on a request. The usual forms are an empty HTTP 204 response or a BidResponse that carries only the request ID and a reason code in BidResponse.nbr. A no-bid is a valid, on-time answer, unlike a response that arrives after BidRequest.tmax, which the exchange treats as a timeout and discards.
No-bid reason
A no-bid reason is the integer a bidder returns in BidResponse.nbr to explain why it passed on a request. Codes 0 to 17 come from the No-Bid Reason Codes list kept with OpenRTB 3.0 and cover technical errors, invalid requests, suspected invalid traffic, unmatched users, ads.txt and supply chain failures, and insufficient auction time. Values of 500 and above are exchange-specific.
Open auction
The open auction is the public tier of programmatic, where any buyer the exchange admits can bid on an impression without a prior agreement. In OpenRTB it is the default: a request with no Imp.pmp, or with Pmp.private_auction at 0, accepts bids that carry no deal ID. The floor comes from Imp.bidfloor and the pricing rule from BidRequest.at.
Preferred deal
A preferred deal is a fixed-price agreement in which one buyer gets first look at a seller's inventory before it goes to auction, with no obligation to buy. In OpenRTB it is usually a Deal with Deal.at set to 3, so that Deal.bidfloor is the agreed price, and with Deal.guar left at 0. Exact encodings vary by exchange.
Private auction
A private auction is a closed auction in which only invited buyers, named through deals, can compete for an impression; the term is often used interchangeably with PMP. OpenRTB expresses the restriction with Pmp.private_auction: 1 means only bids for the listed deals are eligible, while 0, the default, means open bids are accepted alongside them.
Private marketplace
A private marketplace (PMP) is an invitation-only auction in which a seller offers inventory to selected buyers, usually at a higher floor than the open market. In OpenRTB it is expressed through Imp.pmp: the Deal objects listed there name the eligible deals and their terms, and Pmp.private_auction set to 1 limits bidding to those deals.
Programmatic guaranteed
Programmatic guaranteed (PG) is a deal with a fixed price and a committed volume that the buyer must purchase, executed through the bid stream instead of a manual insertion order. In OpenRTB a PG deal is typically a Deal with Deal.guar set to 1, meaning the bidder is expected to bid, and Deal.at set to 3 so the deal floor is the fixed price.
Real-time bidding
Real-time bidding (RTB) is the sale of a single ad impression through an auction that runs while the page or app is loading. An exchange describes the impression in a bid request, sends it to many bidders at once, collects priced responses within a deadline of a few hundred milliseconds or less, and picks a winner. OpenRTB is the message format most of these auctions use.
Second-price auction
A second-price auction is an auction in which the highest bid wins but pays only slightly more than the second-highest bid, or the floor when no other bid competes. OpenRTB calls this Second Price Plus and encodes it as BidRequest.at value 2, which is also the default when the field is absent. Most exchanges moved away from it toward first price as header bidding spread.
Timeout rate
Timeout rate is the share of bid requests for which a bidder's response did not reach the exchange before the auction deadline in BidRequest.tmax. A timed-out response is discarded whatever it contains, so the bidder loses the auction without the exchange counting a bid. Rising timeouts point at network distance, slow decisioning, or a deadline set too tight, not at pricing.
Win rate
Win rate is the share of a bidder's bids that win their auctions, calculated as wins divided by bids submitted. It is the main feedback signal for buy-side pricing: too low and the bidder wastes compute and misses delivery, too high and it is probably overpaying. Some reports divide wins by bid requests received instead, so check which denominator a number uses before comparing it.

Request and response

Ad markup
Ad markup is the creative payload a winning bid delivers: HTML for display, a VAST XML document for video and audio, or a native response for native ads. It travels inline in Bid.adm or as the body returned by the win notice URL in Bid.nurl; when both are present, Bid.adm takes precedence. The exchange expands substitution macros in the markup before serving it.
allimps
allimps is a BidRequest flag that tells bidders whether the impressions offered are every impression available in that context, such as all the ad slots on a page or all the breaks in a video. A value of 1 supports roadblocking, where one advertiser takes every slot; 0, the default, means no or unknown. Bidders that want all or nothing can answer with SeatBid.group set to 1.
Bid
A bid is a Bid object in a bid response: an offer to buy one impression at a stated price. It requires its own Bid.id, a Bid.impid matching an Imp.id from the request, and a CPM Bid.price. It usually also carries the markup in Bid.adm, notice URLs, advertiser domains, creative IDs, and the markup type in Bid.mtype.
Bid request
A bid request is the JSON message an exchange sends to bidders to offer one or more impressions for sale. Its top-level BidRequest object needs only an id and at least one Imp, but a useful request also describes the site, app, or DOOH screen, the device, the user, privacy signals in BidRequest.regs, and the supply path in BidRequest.source.
Bid response
A bid response is a bidder's answer to a bid request. The BidResponse echoes the request ID, groups bids by buyer seat in BidResponse.seatbid, and gives each bid a CPM price for one impression in Bid.price. A bidder that passes returns HTTP 204 or a response carrying only a no-bid reason in BidResponse.nbr.
Billing notice
A billing notice is the call an exchange makes to the URL in Bid.burl when a winning bid becomes billable under the exchange's own policy, typically when the ad is delivered or rendered. Added in OpenRTB 2.5, it separates spend from auction wins. The spec advises firing it server-side, as close as possible to where the exchange books revenue, so both parties count the same events.
Currency
Currency in OpenRTB is always an ISO-4217 alphabetic code such as USD or EUR. The request lists the bid currencies it accepts in BidRequest.cur, floors carry their own in Imp.bidfloorcur and Deal.bidfloorcur, and the response states its single currency in BidResponse.cur. Floors and responses default to USD when omitted, and a deal floor never inherits the impression's currency.
Extensions
Extensions are the ext objects OpenRTB places on nearly every object as a container for fields the spec does not define. Exchanges and bidders put agreed custom data there, and several standard fields, including GDPR consent and the supply chain, lived in ext before later versions promoted them. Readers must tolerate unknown extension content and should check the promoted location first.
Impression
An impression is one opportunity to show an ad to a viewer, and in OpenRTB it is the unit being auctioned. Each opportunity in a bid request is an Imp object with an Imp.id unique within that request, and every bid points back to one through Bid.impid. The offered impression becomes a counted, billable impression only later, when the ad actually renders under the exchange's rules.
JSON dialect
A JSON dialect is one of the two ways OpenRTB payloads get written as JSON. The specification encodes flags as the integers 0 and 1 under snake_case names, while JSON produced from the IAB protobuf schema writes many of those flags as true or false and may switch names to lowerCamelCase. Nothing in a payload says which dialect it uses, so a mismatch drops fields or rejects whole messages.
Loss notice
A loss notice is the call an exchange makes to the URL in Bid.lurl when it knows a bid lost. Added in OpenRTB 2.5, it usually carries a loss reason code through ${AUCTION_LOSS} and, where the exchange shares prices, the ${AUCTION_MIN_TO_WIN} value. Exchange policy may skip loss notices entirely or blank out the price macros in them.
Protobuf JSON
Protobuf JSON is the JSON produced when an OpenRTB message defined in a Protocol Buffers schema is serialized with the standard protobuf JSON mapping. It differs from spec JSON in ways that break parsers: flags the spec types as integers become booleans, bool fields reject 0 and 1, and names can switch to lowerCamelCase. It is common wherever OpenRTB travels over gRPC, including ARTF.
QPS
QPS (queries per second) is the rate of bid requests an exchange sends to a bidder, and the main capacity limit in an RTB integration. Bidders agree a QPS cap with each exchange based on what their infrastructure and budgets can absorb, and the exchange throttles or filters traffic to stay under it. OpenRTB does not define QPS; it is an operational term.
Seat
A seat is a buyer account, usually an advertiser or agency, on whose behalf a bidder places bids. A DSP serves many seats, each with its own budget and terms, and seat IDs are agreed between exchange and bidder in advance. In OpenRTB, seats appear in allow and block lists on the request and in SeatBid.seat on the response.
Seatbid
A seatbid is the SeatBid object in a bid response that groups one or more bids made on behalf of a single buyer seat. A response holds an array of them in BidResponse.seatbid, with at least one entry whenever a bid is made. Each names its seat in SeatBid.seat, holds its bids in SeatBid.bid, and can use SeatBid.group to require all-or-nothing wins.
Substitution macro
A substitution macro is a placeholder such as ${AUCTION_PRICE} that a bidder writes into its notice URLs or ad markup and the exchange replaces with live auction data before use. OpenRTB 2.6 defines fourteen of them, covering IDs, the clearing price, currency, loss reason, minimum bid to win, and seller discounts. A macro whose value is unknown becomes an empty string.
Test flag
The test flag is BidRequest.test, an integer that marks an auction as test traffic when set to 1. Test auctions are not billable, so both sides can exercise an integration without spending budget; the default, 0, means live. Bidders should still parse and answer test requests normally but keep them out of reported wins, spend, and delivery.
tmax
tmax is the bid request field that sets the auction deadline: the maximum time, in milliseconds, the exchange will wait for a bid response, network latency included. A response that arrives later is discarded. The value in BidRequest.tmax overrides any timeout agreed earlier, and a bidder's real compute budget is tmax minus the round trip to the exchange.
Win notice
A win notice is the HTTP call an exchange makes to the URL in Bid.nurl when that bid wins its auction, after replacing macros such as ${AUCTION_PRICE} with auction data. A win does not prove the ad was delivered or is billable; that is the billing notice's job. The win notice response can also return the ad markup when the bid did not include it.

Inventory and formats

App
In OpenRTB, an app is non-browser application inventory, such as a mobile game, a news app, or a streaming app on a connected TV, described by the BidRequest.app object. It identifies the app by its store ID and store URL and names the publisher. A request should carry exactly one of app, site, or dooh.
Blocked advertisers
Blocked advertisers are the brands a seller refuses for a request, listed by domain in BidRequest.badv, for example ford.com. Bidders compare the list with the advertiser domains they declare in Bid.adomain and should not bid on behalf of a blocked brand. A bid without Bid.adomain cannot be checked against the list at all.
Blocked categories
Blocked categories are the ad categories a seller refuses for a request, listed in BidRequest.bcat. The codes come from the taxonomy named in BidRequest.cattax, which defaults to IAB Content Category Taxonomy 1.0 with codes such as IAB25 and IAB26. OpenRTB 2.6-202309 added BidRequest.acat as an allowlist alternative, and a request should use one or the other.
Bundle ID
A bundle ID is the identifier an app store assigns to an app, carried in OpenRTB as App.bundle. On Google Play it is the package name, such as com.example.game; on the Apple App Store it is the numeric store ID; CTV stores use their own formats. Buyers use it for app-ads.txt checks, BidRequest.bapp blocklists, and brand safety.
Connection type
Connection type is the network a device uses to reach the internet, sent as an integer in Device.connectiontype from the AdCOM Connection Types list: 1 Ethernet, 2 Wi-Fi, 3 cellular of unknown generation, and 4 to 7 for 2G, 3G, 4G, and 5G. Buyers use it to choose creative weight and bitrate and to tell home traffic from mobile traffic.
Content taxonomy
A content taxonomy is a standard list of categories for describing what content is about, and in OpenRTB it usually means the IAB Tech Lab Content Taxonomy. Its codes fill fields such as Site.cat, App.cat, and Content.cat, and a matching cattax field says which taxonomy and version the codes come from, since codes differ between versions.
Device type
Device type is the class of device an ad will show on, sent as an integer in Device.devicetype from the AdCOM Device Types list: 1 mobile or tablet (general), 2 personal computer, 3 connected TV, 4 phone, 5 tablet, 6 connected device, 7 set top box, and 8 out-of-home device. Buyers use it to separate CTV, mobile, and desktop demand.
Digital out-of-home
Digital out-of-home (DOOH) is advertising on screens in public places, such as roadside billboards, transit displays, and screens in shops and venues. OpenRTB 2.6-202211 added BidRequest.dooh as a third inventory context next to site and app, with venue type fields and an impression multiplier in Imp.qty, because one play of an ad is seen by many people.
Geolocation
Geolocation in OpenRTB is the location of the device or user, described by a Geo object at device.geo, for where the device is now, and at user.geo, for the user's home base. It can carry coordinates, country, region, metro, city, and postal code, plus fields that say where the location came from and how precise it is.
Interstitial
An interstitial is an ad that covers the full screen or most of it, shown at a natural pause such as between game levels or page transitions, and closed by the user. In OpenRTB, Imp.instl = 1 marks any impression as interstitial. For video, Video.plcmt value 3 also describes interstitial placements that play without surrounding video content.
IP truncation
IP truncation is removing the lowest bits of the device IP address before a bid request goes out, so the address points to a network block rather than one household. OpenRTB 2.3 to 2.5 described it for COPPA requests: drop the last 8 bits of Device.ip and the last 32 bits of Device.ipv6. It also lowers the precision of IP-based geolocation and fraud checks.
MRAID
MRAID (Mobile Rich Media Ad Interface Definitions) is an IAB Tech Lab standard that defines how rich media ads talk to an app's ad container, so a creative can expand, resize, close, or ask whether it is visible. In OpenRTB, a seller signals MRAID support with API framework values 3, 5, and 6 (MRAID 1.0, 2.0, and 3.0) in the impression's api array.
Multi-format impression
A multi-format impression is a single Imp that offers more than one media type at once, for example a banner and a video, or a native ad and a banner, so buyers with different creative types can compete for the same slot. The exchange picks one winner, and in OpenRTB 2.6 each bid states which media type it is in Bid.mtype.
Native ads
Native ads are ads assembled from components such as a title, an image, a description, and a call to action, which the publisher renders to match the look of the surrounding content. In OpenRTB the offer is Imp.native, whose Native.request field holds a separate Native Ads request encoded as a JSON string, and the bid returns native response JSON in Bid.adm.
Native asset
A native asset is one component of a native ad, such as a title, an image, a data element like a rating or price, or a video, declared in the Native Ads request inside Native.request. Each asset has a numeric ID that the response must echo and can be marked as required. Image and data assets take a type from their own lists, for example icon or main image.
OMID
OMID (Open Measurement Interface Definition) is the interface of IAB Tech Lab's Open Measurement SDK, which lets third-party verification vendors measure viewability and ad events through one shared integration instead of each vendor shipping its own SDK. In OpenRTB, a seller signals that its environment runs Open Measurement with API framework value 7 (OMID 1.0) in the impression's api array.
Rewarded ads
A rewarded ad is one the user chooses to watch in exchange for something of value, such as an extra life in a game, a free article, or a session of ad-free listening, usually granted after the ad completes. OpenRTB 2.6 signals it with Imp.rwdd = 1. Before 2.6 the flag lived in exchange-specific extensions under imp.ext.
Seat allow and block lists
Seat allow and block lists restrict which buyer seats may bid on a request. BidRequest.wseat lists the only seats allowed, BidRequest.bseat lists seats that are barred, and a request should use at most one of them. A seat is a buyer account, such as an agency or an advertiser, whose ID the exchange and the bidder agree on in advance.
SIMID
SIMID (Secure Interactive Media Interface Definition) is an IAB Tech Lab standard for interactive video ads that leaves the media file under the player's control and runs the interactive layer separately in its own iframe. It takes over the interactivity role VPAID used to play. In OpenRTB, a player signals support with API framework values 8 (SIMID 1.0) and 9 (SIMID 1.1) in Video.api.
Site
In OpenRTB, a site is web inventory: an ad opportunity on a page rendered in a browser, described by the BidRequest.site object. It carries the page URL, the domain, content categories, and the publisher. Site is one of three inventory contexts, next to app and dooh, and a request should carry exactly one of them.
Store URL
The store URL is the address of an app's listing in its app store, carried in OpenRTB as App.storeurl since version 2.1. Buyers follow it to the developer website named in the listing, which is where app-ads.txt lives, so a missing or wrong store URL makes app inventory hard to authorize. It should describe the same app as App.bundle.
Structured user agent
A structured user agent is the Device.sua object added in OpenRTB 2.6, which describes the browser and platform as separate fields instead of one string. It lists browser brands and versions in UserAgent.browsers and the platform in UserAgent.platform, adds mobile, architecture, bitness, and model, and uses UserAgent.source to say whether the data came from client hints or a parsed UA string.
User agent
The user agent is the string a browser or app sends to identify its software, version, and operating system, carried in OpenRTB as Device.ua. Buyers parse it for device targeting and fraud checks. Chrome's User-Agent reduction froze much of that detail, so OpenRTB 2.6 added Device.sua for structured data, and the spec says to trust sua when both are present.
User-agent client hints
User-Agent Client Hints are HTTP headers, such as Sec-CH-UA, Sec-CH-UA-Mobile, and Sec-CH-UA-Platform, that Chromium browsers send in place of the detail removed from the User-Agent string. Low-entropy hints arrive by default, while high-entropy ones such as the full version list and device model must be requested. OpenRTB 2.6 maps them into Device.sua.

Video and CTV

Accompanying content
Accompanying content is Video.plcmt value 2: video ads that play before, during, or after video content in a player that sits alongside the page's main text or images instead of being the reason for the visit. Playback starts only when the player enters the viewport, and the player may float as the user scrolls. Legacy Video.placement value 2 meant in-banner, which is a different thing.
Ad pod
An ad pod is a group of ads played back to back in one break, like a TV commercial break. OpenRTB 2.6 describes pods with fields on the video and audio objects: Video.podid groups imps into one pod, Video.poddur and Video.maxseq bound a dynamic pod, Video.slotinpod targets a position, and Video.rqddurs lists exact allowed durations.
API frameworks
API frameworks are the creative interfaces an ad slot supports, listed as integers in the api arrays of Banner, Video, Audio, and Native from the AdCOM API Frameworks list: 1 and 2 for VPAID, 3, 5, and 6 for MRAID, 4 for ORMMA, 7 for OMID, and 8 and 9 for SIMID. A framework that is not listed is assumed unsupported, and bids declare their needs in Bid.apis.
Companion ads
Companion ads are display units shown alongside a video or audio ad, such as a banner next to the player or an end card after the video, that extend the same campaign. In OpenRTB they are offered through Video.companionad and Audio.companionad, arrays of Banner objects, and Video.companiontype says which VAST companion resource formats the player can render.
Connected TV
Connected TV (CTV) is video watched on a television through an internet connection, using smart TVs, streaming sticks, game consoles, and set-top boxes. OpenRTB has no CTV object. A request reads as CTV through Device.devicetype (3 for connected TV or 7 for set top box), app inventory with a CTV store bundle, and video fields for ad pods and server-side insertion.
Duration floors
Duration floors are price floors that depend on how long the creative is, so a 30-second spot can be required to clear a higher price than a 15-second one in the same slot. OpenRTB 2.6-202309 added them as durfloors, an array of DurFloors objects on Imp.video, Imp.audio, and Deal, each with a duration range and a CPM floor.
FAST channels
FAST (free ad-supported streaming television) channels are scheduled, linear channels delivered over the internet and paid for by ads, such as the channel guides inside Samsung TV Plus, Pluto TV, or The Roku Channel. Viewers tune in instead of choosing an episode. In OpenRTB, FAST ad breaks arrive as CTV app inventory with ad pods, usually stitched into the stream on a server.
Instream video
Instream video is a video ad that plays before, during, or after video content the viewer chose to watch: pre-roll, mid-roll, or post-roll. In OpenRTB 2.6 it is Video.plcmt value 1. Under the IAB video guidelines, instream also requires sound on by default or a clear intent to watch, and the video content must be the main focus of the screen.
Live event ad insertion
Live event ad insertion is ad delivery into a live broadcast, such as a sports game, where breaks start on the producer's cue and every viewer reaches the same break at once. That creates request bursts and strict timing. In OpenRTB it relies on pod fields, exact durations in Video.rqddurs, Imp.ssai, and, from 2.6-202606, Content.realtime to mark content happening live.
MIME types
MIME types are the media file formats a player can play, listed in Video.mimes as content type strings such as video/mp4 or video/webm. It is the one required field on the Video object, and the Audio object has its own required Audio.mimes. A bid whose VAST media files use none of the listed types cannot play in that player.
Outstream video
Outstream video is a market term for video ads that play outside of video content, for example in a player that opens between paragraphs of an article, inside a social feed, or as a full-screen interstitial. It is not a value in OpenRTB. Under Video.plcmt such ads are usually 4 (no content or standalone) or 3 (interstitial), depending on how much of the screen they take.
plcmt
plcmt is the OpenRTB 2.6 field Video.plcmt that classifies a video placement under the updated IAB digital video guidelines: 1 instream, 2 accompanying content, 3 interstitial, and 4 no content or standalone. It replaced the deprecated Video.placement, whose values mean different things, so a copied integer is a common bug. Newer AdCOM revisions add values such as pause and overlay ads.
Pod ID
A pod ID is the string in Video.podid (and Audio.podid), added in OpenRTB 2.6, that marks an impression as part of an ad pod. Imps in one request that share a pod ID belong to the same break, which lets a seller offer each slot as its own imp while buyers still see the pod as a whole for competitive separation and frequency.
Required durations
Required durations, Video.rqddurs in OpenRTB 2.6, is a list of the exact creative lengths in seconds that a slot accepts, for example 15 and 30. It exists for live TV and radio, where an ad that runs short leaves dead air. It cannot be combined with Video.minduration or Video.maxduration; a request uses one approach or the other.
Server-side ad insertion
Server-side ad insertion (SSAI), also called ad stitching, is a delivery method in which a server splices ads directly into the video or audio stream, so the player receives one continuous stream instead of fetching ads itself. It is standard on CTV and live streams. OpenRTB 2.6 signals it with Imp.ssai, which says how much of the ad and its tracking runs on the server.
Skippable video
Skippable video is a video ad the viewer can end early after a set time, usually by pressing a skip button. In OpenRTB the player's skip policy is described by Video.skip, Video.skipmin, and Video.skipafter, added in version 2.4. A creative that draws its own skip button is flagged separately in the bid with creative attribute 16.
Slot in pod
Slot in pod is the OpenRTB 2.6 field Video.slotinpod, which says which position in an ad pod a seller can guarantee: 1 for the first slot, -1 for the last, 2 for first or last, and 0 for any. Bids answer with Bid.slotinpod to say a creative is eligible only for that position, which buyers use for premium first-in-break placements.
VAST
VAST (Video Ad Serving Template) is the IAB Tech Lab XML format that tells a video or audio player which ad to play, where its media files are, and which tracking URLs to call. OpenRTB does not define VAST; it carries it. A request lists the VAST versions a player accepts in Video.protocols, and a winning bid returns the VAST document in Bid.adm or through Bid.nurl.
Video placement (legacy)
Video placement, Video.placement, is the legacy OpenRTB field that classified video placements before plcmt: 1 in-stream, 2 in-banner, 3 in-article, 4 in-feed, and 5 interstitial, slider, or floating. It was added in OpenRTB 2.5 and deprecated in 2023 in favor of Video.plcmt. The two lists do not map one to one, so copying the integer across changes its meaning.
Video protocols
Video protocols are the VAST versions a player accepts, listed as integers in Video.protocols from the AdCOM creative subtypes list for audio and video: for example 3 for VAST 3.0, 7 for VAST 4.0, and 6 and 8 for the 3.0 and 4.0 wrappers. A seller that lists inline versions without the matching wrapper values blocks bidders that return wrapper tags.
VPAID
VPAID (Video Player-Ad Interface Definition) is an older IAB standard that let a video ad run as executable code inside the player, so the ad could be interactive or load measurement scripts. It appears as API framework values 1 and 2 (VPAID 1.0 and 2.0). IAB Tech Lab has since moved its two jobs to SIMID for interactivity and Open Measurement for verification.

Identity and privacy

Advertising ID
An advertising ID is the resettable device identifier that a mobile or TV operating system provides for advertising, such as Apple's IDFA, Google's advertising ID, or Roku's RIDA. OpenRTB carries it unhashed in Device.ifa, added in version 2.2. When the user limits tracking, the OS returns an all-zero ID, and Device.lmt should be 1.
Buyer user ID
The buyer user ID is User.buyeruid, the bidder's own identifier for the user, which the exchange inserts into the request after looking it up in a match table built by cookie syncing. It is the ID a DSP can use directly for targeting and frequency capping. Unlike User.id, each bidder receives its own value.
CCPA
CCPA, the California Consumer Privacy Act, is a California law that gives residents rights over the personal information businesses collect about them, including the right to opt out of its sale or sharing. It took effect in 2020 and was expanded by the CPRA. In OpenRTB its signals travel in the legacy US Privacy string or in the California and US national sections of GPP.
COPPA
COPPA, the US Children's Online Privacy Protection Act, restricts collecting personal information online from children under 13. OpenRTB flags requests subject to it with Regs.coppa = 1, a field on the Regs object since version 2.2. On such requests buyers should not use behavioral targeting, and sellers should strip identifiers and coarsen location and IP data before sending.
Digital Services Act
The Digital Services Act (DSA) is an EU regulation that, among other duties, requires online platforms to show users who an ad is for, who paid for it, and why they are seeing it. OpenRTB carries DSA transparency through an IAB Tech Lab community extension: regs.ext.dsa in the request says whether disclosure is required, and bid.ext.dsa names the advertiser and the payer.
Do not track
Do Not Track is a browser setting that sends a DNT header asking sites not to track the user, carried in OpenRTB as Device.dnt since version 2.0, where 1 means the header was set. The W3C effort to standardize what sites must do with it was abandoned, so buyers treat it as a weaker signal than consent strings or GPP.
Extended IDs
Extended IDs (EIDs) are identifiers from identity providers other than the exchange, such as UID2, ID5, or RampID, carried in User.eids. Each EID object names its provider by domain in EID.source and holds one or more IDs in EID.uids, each with an agent type. OpenRTB 2.6 made eids a core field; earlier versions used user.ext.eids.
GDPR
GDPR, the General Data Protection Regulation, is the European Union's data protection law, which governs how personal data, including the identifiers in a typical bid request, may be processed. OpenRTB 2.6 flags whether it applies with Regs.gdpr (1 applies, 0 does not, absent means unknown) and carries the TCF consent string in User.consent. Before 2.6 both lived under ext.
GPP
GPP, the IAB Tech Lab Global Privacy Platform, is a single encoded string that can carry privacy signals for several jurisdictions at once, in numbered sections for the EU TCF, Canada, the US as a whole, and individual US states. OpenRTB 2.6-202211 added Regs.gpp for the string and Regs.gpp_sid for the sections that apply to the request.
GPP section ID
A GPP section ID is the number that identifies one privacy framework inside a GPP string, such as 2 for the EU TCF, 6 for the legacy US Privacy string, 7 for the US national section, and 8 for California. OpenRTB carries the applicable IDs in Regs.gpp_sid, an integer array that usually holds one value. The header and signal integrity sections, 3 and 4, need not be listed.
ID bridging
ID bridging is filling a bid request's user or device identifier with one that was not observed on that impression, for example reusing a stale advertising ID or presenting a probabilistic household match as a deterministic ID. Buyers pay for an addressable impression they did not get. The provenance fields EID.inserter, EID.matcher, and EID.mm, added in 2.6-202409, make an ID's origin inspectable.
ID5
ID5 is a shared identifier from the company of the same name, built so publishers and buyers can recognize a user across sites without third-party cookies. It combines deterministic signals such as hashed emails with probabilistic ones where they are permitted. In OpenRTB it travels as an entry in User.eids with the source id5-sync.com, next to any other providers.
Limit ad tracking
Limit ad tracking is the operating system signal that a user has restricted the use of their device for ad tracking, carried in OpenRTB as Device.lmt since version 2.3: 1 means tracking must be limited under the platform's rules, and 0 means it is not. On iOS it follows App Tracking Transparency, and a limited device usually sends a zeroed advertising ID.
RampID
RampID is LiveRamp's people-based identifier, which resolves authenticated signals such as hashed emails to a pseudonymous ID that buyers can match to their own data. Publishers expose it through LiveRamp's Authenticated Traffic Solution, and earlier integrations knew it as IdentityLink. In OpenRTB it travels as an entry in User.eids with the source liveramp.com.
Regulations object
The regulations object, BidRequest.regs, is where an OpenRTB request states which legal regimes apply to it. In OpenRTB 2.6 it holds the COPPA flag, the GDPR flag, the US Privacy string, and the GPP string with its section IDs, while the TCF consent string sits on User.consent. Extensions such as the DSA object live in regs.ext.
TCF
TCF, the IAB Europe Transparency and Consent Framework, is the industry standard for recording a user's GDPR choices about purposes and vendors in a compact encoded string produced by a consent management platform. In OpenRTB 2.6 the TC string goes in User.consent alongside Regs.gdpr = 1, and inside a GPP string it appears as section 2.
UID2
UID2 (Unified ID 2.0) is an open-source identity framework, started by The Trade Desk, that turns a hashed and salted email address or phone number into an encrypted, regularly rotated token for advertising. In OpenRTB it travels as an entry in User.eids with the source uidapi.com. Users can opt out through a central portal, and participants must honor that.
US Privacy string
The US Privacy string is a four-character IAB code, such as 1YNN, that records a California consumer's notice and opt-out-of-sale status: spec version, notice given, opted out of sale, and whether the publisher is covered by the IAB's LSPA. OpenRTB 2.6 carries it in Regs.us_privacy, formerly regs.ext.us_privacy. IAB Tech Lab has deprecated it in favor of GPP.
User ID
In OpenRTB, the user ID is User.id, the exchange's own identifier for the person behind a request, usually read from the exchange's cookie. It means little to a buyer that has not mapped it. The buyer's own ID for the same user goes in User.buyeruid, and identifiers from third-party providers such as UID2 go in User.eids.

Supply chain and trust

ads.cert
ads.cert is IAB Tech Lab's standard for cryptographically signing programmatic traffic so buyers can verify where it came from. Version 1.0 signed OpenRTB 3.0 bid requests through signature fields on the Source object. Version 2.0, announced in 2021, moved to Call Signs, public keys published in DNS, and Authenticated Connections for any server-to-server call. Production adoption remains thin.
ads.txt
ads.txt is a plain text file a publisher hosts at the root of its website, for example example.com/ads.txt, listing every advertising system authorized to sell its inventory and the publisher's account ID in each. Published by IAB Tech Lab, it lets buyers reject inventory offered through an exchange or account the publisher never named. App inventory uses the parallel app-ads.txt file.
app-ads.txt
app-ads.txt is the version of ads.txt for mobile and CTV apps. The app developer hosts it at the root of the developer website named on the app's store listing, using the same line format to list the advertising systems and account IDs authorized to sell the app's inventory. Buyers find it through the store listing rather than through the app itself.
Bidstream data
Bidstream data is the information carried in bid requests and seen by every bidder that receives them, whether or not it bids: the page or app, device details, location, user identifiers, consent signals, and the supply path. Because one request fans out to many bidders, sending a field means publishing it widely, which is why regulators and publishers scrutinize what goes into it.
Direct versus reseller
Direct versus reseller is the distinction ads.txt draws between an account the publisher controls itself, labeled DIRECT, and an account a third party controls with the publisher's permission, labeled RESELLER. Buyers read it as a signal of how many intermediaries take a cut, and use sellers.json and the supply chain object to check whether the label matches the actual path.
Invalid traffic
Invalid traffic (IVT) is ad traffic that does not represent a legitimate opportunity for a person to see an ad: bots, data-center traffic, crawlers, hidden or stacked ads, and spoofed devices, apps, or domains. The Media Rating Council splits it into general IVT, caught by lists and routine filters, and sophisticated IVT, which needs deeper analysis. Bidders try to filter it before bidding.
Inventory partner domain
An inventory partner domain is the domain of a content owner allowed to sell part of another company's ad inventory, common when a CTV app or site shares ad breaks with a programmer. OpenRTB carries it in App.inventorypartnerdomain or Site.inventorypartnerdomain, promoted from ext in 2.6-202211, so buyers know to check authorization in the partner's own ads.txt.
Made-for-advertising sites
Made-for-advertising (MFA) sites are sites and apps built to monetize bought traffic rather than to serve an audience, with heavy ad density, auto-refreshing slots, and thin or clickbait content. Nothing in OpenRTB marks a request as MFA, and such inventory usually passes ads.txt and validation, so buyers filter it with inventory lists and quality vendors, using signals such as Imp.refresh.
sellers.json
sellers.json is a JSON file an SSP or exchange hosts at its own domain, for example ssp.example/sellers.json, listing each seller account on its platform with the seller's name, business domain, and type: publisher, intermediary, or both. IAB Tech Lab published it alongside the supply chain object so buyers can learn who stands behind each account ID in a bid request.
Supply chain node
A supply chain node is one SupplyChainNode entry in SupplyChain.nodes, describing a single system that handled the bid request. It names the advertising system's domain in SupplyChainNode.asi, the seller account in SupplyChainNode.sid, and in SupplyChainNode.hp whether that node takes part in the flow of payment. The last node is always the system sending the request.
Supply chain object
The supply chain object, usually called schain, is the OpenRTB SupplyChain object in Source.schain that lists, in order, every system that handled a bid request from the inventory owner to the sender. Each node names an advertising system and a seller account, and SupplyChain.complete states whether the chain reaches all the way back to the owner. Before OpenRTB 2.6 it traveled in source.ext.schain.
Supply path optimization
Supply path optimization (SPO) is a buyer's practice of choosing which intermediaries to buy an impression through and dropping the rest. The same impression often arrives through several exchanges and resellers at different prices and fees, so buyers compare paths on cost, win rate, and how verifiable the seller chain is. The evidence comes from Source.schain, ads.txt, and sellers.json.