From df714d0c8fa3444b607eb4c900802e2a0fe48112 Mon Sep 17 00:00:00 2001 From: Romain Date: Sat, 27 Apr 2024 18:41:59 +0200 Subject: [PATCH] Update 2.6.md Fix typo Fix tables Improve consistancy in the doc --- 2.6.md | 1299 +++++++++++++++++++++++++++++--------------------------- 1 file changed, 669 insertions(+), 630 deletions(-) diff --git a/2.6.md b/2.6.md index 98e89cb..afedd5c 100644 --- a/2.6.md +++ b/2.6.md @@ -2,22 +2,32 @@ The IAB Technology Laboratory is a nonprofit research and development consortium charged with producing and helping companies implement global industry technical standards and solutions. The goal of the Tech Lab is to reduce friction associated with the digital advertising and marketing supply chain while contributing to the safe growth of an industry. The IAB Tech Lab spearheads the development of technical standards, creates and maintains a code library to assist in rapid, cost-effective implementation of IAB standards, and establishes a test platform for companies to evaluate the compatibility of their technology solutions with IAB standards, which for 18 years have been the foundation for interoperability and profitable growth in the digital advertising supply chain. Further details about the IAB Technology Lab can be found at www.iabtechlab.com + + ### Significant Contributors to the 2.6 version specification Stanislav Belov, Software Engineer, Google; Allen Dove, CTO, Magnite; Steven Katz, Senior Principal Architect, Yahoo!; Curt Larson, Chief Product Officer, Sharethrough; Dr. Neal Richter, Director of Science, Amazon Advertising; Jud Spencer, Principal Software Engineer, The Trade Desk; Ian Trider, VP, RTB Platform Operations, Basis Technologies; Rob Hazan, Sr. Director Product Management, Index Exchange; James Wilhite, VP Product, Publica; Jean-Luc Wasmer, VP Partnership Operations, Triton Digital; Sam Mansour, Principle Product Manager, Oracle; Scott Kay, Engineering Manager, Xandr; Emma Fenlon, Sr. Manager, Exchange Quality, Yahoo!; Liam Whiteside, Head of Ad Technology, Global; Don Marti, VP Ecosystem Innovation, Raptive; Aron Schatz, Director Product Management, Double Verify; Jake Jolly, Product Manager, Google; Amit Shetty, VP Product, Pixalate; Tim Harvey, Founder, Knitting Media; Jason Shao, CTO, Place Exchange; Chris Coupland, Platform Operations Manager, Basis Technologies; Simon Trasler, SVP, Magnite; Patrick McCann, SVP Research, Raptive; David Dabbs, Director of Platform Architecture, Epsilon; + + ### IAB Tech Lab Lead: Hillary Slattery, Director of Product, IAB Tech Lab + + ### License This specification is licensed under a Creative Commons Attribution 3.0 License. To view a copy of this license, visit creativecommons.org/licenses/by/3.0/ http://creativecommons.org/licenses/by/3.0/ or write to Creative Commons, 171 Second Street, Suite 300, San Francisco, CA 94105, USA. + + ### Disclaimer THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE “PRODUCTS AND SERVICES”) ARE PROVIDED “AS IS” AND “AS AVAILABLE,” AND IAB TECHNOLOGY LABORATORY, INC. (“TECH LAB”) MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME, INCLUDING, BUT NOT LIMITED TO, DATA PROTECTION LAWS, SUCH AS THE PERSONAL INFORMATION PROTECTION AND ELECTRONIC DOCUMENTS ACT (CANADA), THE DATA PROTECTION DIRECTIVE (EU), THE E-PRIVACY DIRECTIVE (EU), THE GENERAL DATA PROTECTION REGULATION (EU), AND THE E-PRIVACY REGULATION (EU) AS AND WHEN THEY BECOME EFFECTIVE. + + # TABLE OF CONTENTS - [About the IAB Tech Lab](#techlab) @@ -36,9 +46,9 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [1.3 - Version History](#versionhistory) - - [OpenRTB Real-Time Bidding API](#realtimebidding) + - [OpenRTB Real-Time Bidding API](#realtimebidding) - - [OpenRTB Display Block List Branch](#displayblock) + - [OpenRTB Display Block List Branch](#displayblock) - [1.4 - Resources](#resources) @@ -70,75 +80,75 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [3.2 - Object Specifications](#objectspecs) - - [3.2.1 - Object: BidRequest](#objectbidrequest) + - [3.2.1 - Object: BidRequest](#objectbidrequest) - - [3.2.2 - Object: Source](#objectsource) + - [3.2.2 - Object: Source](#objectsource) - - [3.2.3 - Object: Regs](#objectregs) + - [3.2.3 - Object: Regs](#objectregs) - - [3.2.4 - Object: Imp](#objectimp) + - [3.2.4 - Object: Imp](#objectimp) - - [3.2.5 - Object: Metric](#objectmetric) + - [3.2.5 - Object: Metric](#objectmetric) - - [3.2.6 - Object: Banner](#objectbanner) + - [3.2.6 - Object: Banner](#objectbanner) - - [3.2.7 - Object: Video](#objectvideo) + - [3.2.7 - Object: Video](#objectvideo) - - [3.2.8 - Object: Audio](#objectaudio) + - [3.2.8 - Object: Audio](#objectaudio) - - [3.2.9 - Object: Native](#objectnative) + - [3.2.9 - Object: Native](#objectnative) - - [3.2.10 - Object: Format](#objectformat) + - [3.2.10 - Object: Format](#objectformat) - - [3.2.11 - Object: Pmp](#objectpmp) + - [3.2.11 - Object: Pmp](#objectpmp) - - [3.2.12 - Object: Deal](#objectdeal) + - [3.2.12 - Object: Deal](#objectdeal) - - [3.2.13 - Object: Site](#objectsite) + - [3.2.13 - Object: Site](#objectsite) - - [3.2.14 - Object: App](#objectapp) + - [3.2.14 - Object: App](#objectapp) - - [3.2.15 - Object: Publisher](#objectpublisher) + - [3.2.15 - Object: Publisher](#objectpublisher) - - [3.2.16 - Object: Content](#objectcontent) + - [3.2.16 - Object: Content](#objectcontent) - - [3.2.17 - Object: Producer](#objectproducer) + - [3.2.17 - Object: Producer](#objectproducer) - - [3.2.18 - Object: Device](#objectdevice) + - [3.2.18 - Object: Device](#objectdevice) - - [3.2.19 - Object: Geo](#objectgeo) + - [3.2.19 - Object: Geo](#objectgeo) - - [3.2.20 - Object: User](#objectuser) + - [3.2.20 - Object: User](#objectuser) - - [3.2.21 - Object: Data](#objectdata) + - [3.2.21 - Object: Data](#objectdata) - - [3.2.22 - Object: Segment](#objectsegment) + - [3.2.22 - Object: Segment](#objectsegment) - - [3.2.23 - Object: Network](#objectnetwork) + - [3.2.23 - Object: Network](#objectnetwork) - - [3.2.24 - Object: Channel](#objectchannel) + - [3.2.24 - Object: Channel](#objectchannel) - - [3.2.25 - Object: SupplyChain](#objectsupplychain) + - [3.2.25 - Object: SupplyChain](#objectsupplychain) - - [3.2.26 - Object: SupplyChainNode](#objectsupplychainnode) + - [3.2.26 - Object: SupplyChainNode](#objectsupplychainnode) - - [3.2.27 - Object: EID](#objecteid) + - [3.2.27 - Object: EID](#objecteid) - - [3.2.28 - Object: UID](#objectuid) + - [3.2.28 - Object: UID](#objectuid) - - [3.2.29 - Object: UserAgent](#objectuseragent) + - [3.2.29 - Object: UserAgent](#objectuseragent) - - [3.2.30 - Object: BrandVersion](#objectbrandversion) + - [3.2.30 - Object: BrandVersion](#objectbrandversion) - - [3.2.31 - Object: Qty](#objectqty) + - [3.2.31 - Object: Qty](#objectqty) - - [3.2.32 - Object: DOOH](#objectdooh) + - [3.2.32 - Object: DOOH](#objectdooh) - - [3.2.33 - Object: Refresh](#objectrefresh) + - [3.2.33 - Object: Refresh](#objectrefresh) - - [3.2.34 - Object: RefSettings](#objectrefsettings) + - [3.2.34 - Object: RefSettings](#objectrefsettings) - - [3.2.35 - Object: DurFloors](#objectdurfloors) + - [3.2.35 - Object: DurFloors](#objectdurfloors) ## [4. Bid Response Specification](#bidresponsespec) @@ -147,23 +157,23 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [4.2 - Object Specifications](#objectspecs) - - [4.2.1 - Object: BidResponse](#objectbidresponse) + - [4.2.1 - Object: BidResponse](#objectbidresponse) - - [4.2.2 - Object: SeatBid](#objectseatbid) + - [4.2.2 - Object: SeatBid](#objectseatbid) - - [4.2.3 - Object: Bid](#objectbid) + - [4.2.3 - Object: Bid](#objectbid) - [4.3 - Ad Serving Options](#adservingoptions) - - [4.3.1 - Markup Served on the Win Notice](#markupservedonwin) + - [4.3.1 - Markup Served on the Win Notice](#markupservedonwin) - - [4.3.2 - Markup Served in the Bid](#markupservedinbid) + - [4.3.2 - Markup Served in the Bid](#markupservedinbid) - - [4.3.3 - Comparison of Ad Serving Approaches](#comparisonofapproaches) + - [4.3.3 - Comparison of Ad Serving Approaches](#comparisonofapproaches) - [4.4 - Substitution Macros](#substitutionmacros) - - [4.4.1 - Notes on the macro ${AUCTION_MIN_TO_WIN}](#notesonmacro) + - [4.4.1 - Notes on the macro ${AUCTION_MIN_TO_WIN}](#notesonmacro) ## [5. Enumerated Lists Specification](#enumeratedlistsspec) @@ -173,31 +183,31 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [6.2 - Bid Requests](#6.4bidrequests) - - [6.2.1 - Example 1 – Simple Banner](#simplebanner) + - [6.2.1 - Example 1 – Simple Banner](#simplebanner) - - [6.2.2 - Example 2 – Expandable Creative](#expandablecreative) + - [6.2.2 - Example 2 – Expandable Creative](#expandablecreative) - - [6.2.3 - Example 3 – Mobile](#example3mobile) + - [6.2.3 - Example 3 – Mobile](#example3mobile) - - [6.2.4 - Example 4 – Video](#example4video) + - [6.2.4 - Example 4 – Video](#example4video) - - [6.2.5 - Example 5 – PMP with Direct Deal](#pmpwdirectdeal) + - [6.2.5 - Example 5 – PMP with Direct Deal](#pmpwdirectdeal) - - [6.2.6 - Example 6 – Native Ad](#example6nativead) + - [6.2.6 - Example 6 – Native Ad](#example6nativead) - [6.3 - Bid Responses](#6.3bidresponses) - - [6.3.1 - Example 1 – Ad Served on Win Notice](#ex1adservedwin) + - [6.3.1 - Example 1 – Ad Served on Win Notice](#ex1adservedwin) - - [6.3.2 - Example 2 – VAST XML Document Returned Inline](#vastxml) + - [6.3.2 - Example 2 – VAST XML Document Returned Inline](#vastxml) - - [6.3.3 - Example 3 – Direct Deal Ad Served on Win Notice](#directdealadonwin) + - [6.3.3 - Example 3 – Direct Deal Ad Served on Win Notice](#directdealadonwin) - - [6.3.4 - Example 4 – Native Markup Returned Inline](#nativemarkupreturnedinline) + - [6.3.4 - Example 4 – Native Markup Returned Inline](#nativemarkupreturnedinline) ## [7. Implementation Notes](implementation.md#implementationnotes) -- [7.1 - No-Bid Signaling](implementation.md#nobidsignaling) +- [7.1 - No-Bid Signaling](implementation.md#nobidsignaling) - [7.2 - Impression Expiration](implementation.md#impressionexpiration) @@ -219,7 +229,7 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [7.11 - Guidance on the Use of Floors](implementation.md#floors) - + ## [Appendix A. Additional Information](#appendixa) ## [Appendix B. Specification Change Log](#appendixb) @@ -239,8 +249,11 @@ Some optional attributes are denoted "recommended." As that term is used herein Description - Examples of required attributes.
Grouped at the tops of tables for convenience -id + + Examples of required attributes.
+ Grouped at the tops of tables for convenience + + id string;
required ... @@ -250,8 +263,11 @@ Some optional attributes are denoted "recommended." As that term is used herein ... -Examples of recommended attributes.
Grouped after required attributes. -site + + Examples of recommended attributes.
+ Grouped after required attributes. + + site object;
recommended ... @@ -261,11 +277,14 @@ Some optional attributes are denoted "recommended." As that term is used herein ... -Examples of optional attributes with and without defaults.
Attributes are assumed optional unless explicitly qualified as required or recommended. + + Examples of optional attributes with and without defaults.
+ Attributes are assumed optional unless explicitly qualified as required or recommended. + test integer;
default 0 ... - + at integer;
default 2 ... @@ -284,8 +303,10 @@ Some optional attributes are denoted "recommended." As that term is used herein *Example of how Required, Recommended and Optional attributes are presented.* -**IMPORTANT:** Since **recommended** attributes are not required, they may not be available from all supply sources. It is suggested that all parties to OpenRTB trasnaction develop an integration checklist to identify which attributes the supply side supports in the bid request, and which attributes the demand side requires for ad decisioning. - +**IMPORTANT:** Since **recommended** attributes are not required, they may not be available from all supply sources. It is suggested that all parties to OpenRTB transaction develop an integration checklist to identify which attributes the supply side supports in the bid request, and which attributes the demand side requires for ad decisioning. + + + # 1. Introduction ## 1.1 - Mission / Overview @@ -296,16 +317,20 @@ This document specifies a standard for the Real-Time Bidding Interface that grew The overall goal of OpenRTB is and has been to create a *lingua franca* for communicating between buyers and sellers. The intent is not to regulate exactly how each business operates. It aims to make integration between parties easier, so that innovation can happen at a deeper-level at each of the businesses in the ecosystem. + + ## 1.2 - History of OpenRTB OpenRTB was launched as a pilot project between three demand-side platforms (DataXu, MediaMath, and Turn) and three sell-side platforms (Admeld, PubMatic, and The Rubicon Project) in November 2010. The first goal was to standardize communication between parties for exchanging block lists. Version 1.0 of the OpenRTB block list specification was released in December 2010. -After a positive response from the industry, Nexage approached the OpenRTB project with a proposal to create an API specification for OpenRTB focusing on the actual real-time bid request/response protocol and specifically to support mobile advertising. The mobile subcommittee was formed between companies representing the buy-side (DataXu, Fiksu, and [X+1]) and companies representing the sell- side (Nexage, Pubmatic, Smaato, and Jumptap). This project resulted in the OpenRTB Mobile 1.0 specification, which was released in February 2011. +After a positive response from the industry, Nexage approached the OpenRTB project with a proposal to create an API specification for OpenRTB focusing on the actual real-time bid request/response protocol and specifically to support mobile advertising. The mobile subcommittee was formed between companies representing the buy-side (DataXu, Fiksu, and [X+1]) and companies representing the sell-side (Nexage, Pubmatic, Smaato, and Jumptap). This project resulted in the OpenRTB Mobile 1.0 specification, which was released in February 2011. Following the release of the mobile specification, a video subcommittee was formed with video ad exchanges (BrightRoll and Adap.tv) collaborating with DataXu and ContextWeb to incorporate support for video. The goal was to incorporate support for display, video, and mobile in one document. This effort resulted in OpenRTB 2.0, which was released as a unified standard in June 2011. Due to very widespread adoption by the industry, OpenRTB was adopted as an IAB Tech Lab standard in January 2012 with the release of version 2.1. + + ## 1.3 - Version History **OpenRTB Real-Time Bidding API** @@ -334,9 +359,13 @@ Due to very widespread adoption by the industry, OpenRTB was adopted as an IAB T 1.0 - Original Release of OpenRTB block list specifications. + + ## 1.4 - Resources Updates to the specification are made through the IAB Tech Lab’s [Programmatic Supply Chain Working Group](https://iabtechlab.com/working-groups/programmatic-supply-chain-working-group/). Contact techlab@iabtechlab.com to join the working group and participate in Slack discussions. + + ## 1.5 - Terminology The following terms are used throughout this document specifically in the context of the OpenRTB Interface and this specification. @@ -344,8 +373,8 @@ The following terms are used throughout this document specifically in the contex - - + + @@ -378,14 +407,15 @@ The following terms are used throughout this document specifically in the contex
Term        Definition                    TermDefinition
RTB
+ ## 2. OpenRTB Basics The following figure illustrates the OpenRTB interactions between an exchange and its bidders. Ad requests originate at publisher sites or applications. For each inbound ad request, bid requests are broadcast to bidders, responses are evaluated under prevailing auction rules, and a winner is selected. The winning bidder is notified of the auction win via a win notice. Ad markup can either be included in the bid prospectively or in response to the win notice. A separate billing notice is also available to accommodate varying policies enacted by exchanges which are beyond the scope of the OpenRTB specification (e.g., billing on device delivery, viewability, etc.). The win notice informs the bidder’s pricing algorithms of a success, whereas the billing notice indicates that spend should actually be applied. A loss notification is also available to inform the bidder of the reason their bid did not win. The URLs for win, billing, and loss notices and the ad markup itself can contain any of several standard macros that enable the exchange to communicate critical data to the bidder (e.g., clearing price). - + ![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/864a56706b106eda94c03abefaa01dd43544864c/assets/Figure1%20OpenRTB.png) - + *Figure 2: Reference Model - Request Sequence.* This specification focuses on the real-time interactions of bid request and response and the win, billing, and loss notices. Related specifications include: @@ -395,6 +425,8 @@ This specification focuses on the real-time interactions of bid request and resp Other interactions (e.g., block list synchronization, traffic control, etc.) are candidates for future OpenRTB initiatives or alternate projects. + + ## 2.1 - Transport The base protocol between an exchange and its bidders is HTTP. Specifically, HTTP POST is required for bid requests to accommodate greater payloads than HTTP GET and facilitate the use of binary representations. Win notices may be either POST or GET at the discretion of the exchange. @@ -404,41 +436,49 @@ Invalid calls (e.g., a bid request containing a malformed or corrupt payload) sh **BEST PRACTICE**: One of the simplest and most effective ways of improving connection performance is to enable HTTP Persistent Connections, also known as Keep-Alive. This has a profound impact on overall performance by reducing connection management overhead as well as CPU utilization on both sides of the interface. + + ## 2.2 - Security HTTPS is not technically required for a functioning OpenRTB implementation. However, HTTPS is increasingly customary. It is strongly recommended that exchanges and bidders use only HTTPS. + + ## 2.3 - Data Format JSON (JavaScript Object Notation) is the suggested format for bid request and bid response data payloads. JSON was chosen for its combination of human readability and compactness. The data payloads are described in Section 3 and Section 4. Optionally, an exchange may also offer binary representations (e.g., compressed JSON, ProtoBuf, Avro, etc.), which can be more efficient in terms of transmission time and bandwidth. The IAB Tech Lab may offer reference implementations for these or other formats. When available, the use of these reference implementations is highly recommended to reduce exchange-specific variations. -The bid request specifies the representation as a mime type using the Content-Type HTTP header. The mime type for the standard JSON representation is “application/json” as shown. The format of the bid response must be the same as the bid request. +The bid request specifies the representation as a mime type using the `Content-Type` HTTP header. The mime type for the standard JSON representation is `application/json` as shown. The format of the bid response must be the same as the bid request. ```Content-Type: application/json``` -If alternative binary representations are used, the exchange or SSP should specify the Content-Type appropriately. For example: “Content-Type: avro/binary” or “Content-Type: application/x-protobuf”. If the content-type is missing, the bidder should assume the type is application/json, unless a different default has been selected by an exchange. +If alternative binary representations are used, the exchange or SSP should specify the Content-Type appropriately. For example: `Content-Type: avro/binary` or `Content-Type: application/x-protobuf`. If the content-type is missing, the bidder should assume the type is application/json, unless a different default has been selected by an exchange. As a convention, the absence of an attribute has a formal meaning. In most cases, this indicates that the value is unknown, unless otherwise specified. + + ## 2.4 - Data Encoding Compressing data sent between exchanges and bidders can be very beneficial. Compression greatly reduces the size of data transferred and thus saves network bandwidth for both exchanges and bidders. To realize these savings fully, compression should be enabled for both the bid request sent by the exchange and the bid response returned by the bidder. -Compression can be enabled on the bid response using standard HTTP 1.1 mechanisms. Most webservers already support gzip compression of response content and as such it is an ideal choice. For an exchange to signal they would like the response to be compressed, it should set the standard HTTP 1.1 Accept-Encoding header. The encoding value used should be “gzip”. +Compression can be enabled on the bid response using standard HTTP 1.1 mechanisms. Most webservers already support gzip compression of response content and as such it is an ideal choice. For an exchange to signal they would like the response to be compressed, it should set the standard HTTP 1.1 `Accept-Encoding` header. The encoding value used should be “gzip”. ```accept-encoding: gzip``` -This header represents to bidders an indication by the exchange that it is capable of accepting gzip encoding for the response. If the bidder server supports this and is correctly configured, it will automatically respond with content that is gzip encoded. This will be indicated using the standard HTTP 1.1 Content-Encoding header. +This header represents to bidders an indication by the exchange that it is capable of accepting gzip encoding for the response. If the bidder server supports this and is correctly configured, it will automatically respond with content that is gzip encoded. This will be indicated using the standard HTTP 1.1 `Content-Encoding` header. ```content-encoding: gzip``` -To enable compression on the bid request, it must first be agreed upon between the exchange and the bidder that this is supported. This is similar to when a custom data format is used since the exchange has to know both format and encoding before sending the bid request. If the bidder supports it, the exchange should indicate it is sending a gzip compressed bid request by setting the HTTP 1.1 Content- Encoding header. The encoding value used should be "gzip". +To enable compression on the bid request, it must first be agreed upon between the exchange and the bidder that this is supported. This is similar to when a custom data format is used since the exchange has to know both format and encoding before sending the bid request. If the bidder supports it, the exchange should indicate it is sending a gzip compressed bid request by setting the HTTP 1.1 `Content-Encoding header. The encoding value used should be "gzip". ```content-enconding: gzip``` -If this header is not set then it is assumed that the request content isn’t encoded. In HTTP 1.1, the Content-Encoding header is usually only used for response content. However, by using this header for the request content as well we are able to indicate a request is compressed regardless of the data format used. This is useful since even binary data formats can benefit from being compressed. +If this header is not set then it is assumed that the request content isn’t encoded. In HTTP 1.1, the `Content-Encoding` header is usually only used for response content. However, by using this header for the request content as well we are able to indicate a request is compressed regardless of the data format used. This is useful since even binary data formats can benefit from being compressed. + + ## 2.5 - OpenRTB Version HTTP Header @@ -450,6 +490,8 @@ Additionally, it is recommended albeit optional that bidders place an identicall This version should be specified as `.` (e.g., 2.6). + + ## 2.6 - Versioning Behavior As of OpenRTB 2.6-202211, OpenRTB's version number is only incremented on breaking changes. In other words, OpenRTB 2.7 should be considered a distinct version from OpenRTB 2.6 when there is a need for distinguishing versions. For example, a demand source might regard the version header when parsing a bid request received from a supply source. See OpenRTB Principles. @@ -467,7 +509,7 @@ This means: For example, if a new field or object is introduced in a future version of OpenRTB 2.6, exchanges should immediately start transmitting it to bidders, if the exchange chooses to implement support for that field. Bidders should start consuming it at their discretion, if it is relevant to them. Neither party needs to explicitly negotiate an "upgrade" to the latest release, but rather should discuss specific fields of interest as they become available. New minor versions of OpenRTB 2.6 may introduce additional optional ways of handling things. For example, burl field was introduced in OpenRTB 2.5. Use of `burl` (instead of including a pixel in markup in `adm` field) is a breaking change for a specific exchange <> bidder integration, but this is a result of a decision between these parties to switch impression counting methodology and not a result of OpenRTB 2.5 itself. Partners should discuss such situations before making breaking changes to their integrations. - + ## 2.7 - Privacy Without limiting the scope of the Disclaimer, the OpenRTB specification does include several features to support implementer’s communication of information regarding consumer privacy, including, but not limited to: @@ -495,8 +537,8 @@ RTB transactions are initiated when an exchange or other supply source sends a b ## 3.1 - Object Model -Following is the object model for the bid request. The top-level object (i.e., in JSON the unnamed outer object) is denoted as `BidRequest` in the model. Of its direct subordinates, only `Imp` is technically required since it is fundamental to describing the impression being sold and it requires at least one of `Banner` (which may allow multiple formats), `Video`, `Audio`, and `Native` to define the type of impression (i.e., whichever one or more the publisher is willing to accept; although a bid will be for exactly one of those specified). An impression can optionally be subject to a private marketplace. - +Following is the object model for the bid request. The top-level object (i.e., in JSON the unnamed outer object) is denoted as `BidRequest` in the model. Of its direct subordinates, only `Imp` is technically required since it is fundamental to describe the impression being sold, and it requires at least one of `Banner` (which may allow multiple formats), `Video`, `Audio`, and `Native` to define the type of impression (i.e., whichever one or more the publisher is willing to accept; although a bid will be for exactly one of those specified). An impression can optionally be subject to a private marketplace. + ![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/a29f4b1060c04813270dbf13607bba0403409068/assets/ORTB%20ERD.png) *Figure 3: Bid Request object model.* @@ -508,11 +550,10 @@ Not shown in the model figure is an extensions object. This is an object of unde The following table summarizes the objects in the Bid Request model and serves as an index into the detailed definitions in the subsections that follow. - - - + + @@ -538,7 +579,7 @@ The following table summarizes the objects in the Bid Request model and serves a - + @@ -553,7 +594,7 @@ The following table summarizes the objects in the Bid Request model and serves a - + @@ -664,40 +705,34 @@ The following table summarizes the objects in the Bid Request model and serves a - - - + - - - -
Object        Section                    ObjectSection Description
Metric 3.2.5A quanitifiable often historical data point about an impression.A quantifiable often historical data point about an impression.
Banner
Audio 3.2.8Container for audio impression..Container for audio impression.
NativeBrandVersion 3.2.30 Name and version information for a browser or similar software component.
Qty 3.2.31 A means of passing a multiplier in the bid request, representing the total quantity of impressions for adverts that display to more than one person.
DOOH 3.2.32 Details of the Digital Out of Home inventory calling for the impression.
+ # 3.2 - Object Specifications ### 3.2.1 - Object: BidRequest The top-level bid request object contains an exchange unique bid request or auction ID. This `id` attribute is required as is at least one impression object (Section 3.2.4). Other attributes in this top-level object establish rules and restrictions that apply to all impressions being offered. -There are also several subordinate objects that provide detailed data to potential buyers. Among these are the `Site`, `App` and `DOOH`objects, which describe the type of published media in which the impression(s) appear. These objects are highly recommended, but only one applies to a given bid request depending on whether the media is browser-based web content, a non-browser application, or Digital Out of Home inventory respectively. - +There are also several subordinate objects that provide detailed data to potential buyers. Among these are the `Site`, `App` and `DOOH`objects, which describe the type of published media in which the impression(s) appear. These objects are highly recommended, but only one applies to a given bid request depending on whether the media is browser-based web content, a non-browser application, or Digital Out-of-Home inventory respectively. - - + + @@ -723,7 +758,7 @@ There are also several subordinate objects that provide detailed data to potenti - + @@ -783,17 +818,23 @@ There are also several subordinate objects that provide detailed data to potenti - + - + - + @@ -808,19 +849,17 @@ There are also several subordinate objects that provide detailed data to potenti - + - + - -
Attribute        Type                    AttributeType Description
dooh objectThis object should be included if the ad supported content is a Digital Out-Of-Home screen. A bid request with a DOOH object must not contain a site or app object.This object should be included if the ad supported content is a Digital Out-Of-Home screen. A bid request with a DOOH object must not contain a site or app object.
device
acat string arrayAllowed advertiser categories using the specified category taxonomy.
The taxonomy to be used is defined by the cattax field. If no cattax field is supplied IAB Content Taxonomy 1.0 is assumed. Only one of acat or bcat should be present.		 + Allowed advertiser categories using the specified category taxonomy.
+ The taxonomy to be used is defined by the cattax field. If no cattax field is supplied IAB Content Taxonomy 1.0 is assumed. Only one of acat or bcat should be present. +
bcat string arrayBlocked advertiser categories using the specified category taxonomy.
The taxonomy to be used is defined by the cattax field. If no cattax field is supplied IAB Content Taxonomy 1.0 is assumed. Only one of acat or bcat should be present.		 + Blocked advertiser categories using the specified category taxonomy.
+ The taxonomy to be used is defined by the cattax field. If no cattax field is supplied IAB Content Taxonomy 1.0 is assumed. Only one of acat or bcat should be present. +
cattax integer; default 1The taxonomy in use for bcat. Refer to the AdCOM 1.0 list List: Category Taxonomies for values.The taxonomy in use for bcat. Refer to the AdCOM 1.0 list List: Category Taxonomies for values.
badv
source objectA Source object (Section 3.2.2) that provides data about the inventory source and which entity makes the final decision.A Source object (Section 3.2.2) that provides data about the inventory source and which entity makes the final decision.
regs objectA Regs object (Section 3.2.3) that specifies any industry, legal, or governmental regulations in force for this request.A Regs object (Section 3.2.3) that specifies any industry, legal, or governmental regulations in force for this request.
ext object Placeholder for exchange-specific extensions to OpenRTB.
@@ -830,10 +869,11 @@ There are also several subordinate objects that provide detailed data to potenti This object describes the nature and behavior of the entity that is the source of the bid request upstream from the exchange. The primary purpose of this object is to define post-auction or upstream decisioning when the exchange itself does not control the final decision. A common example of this is header bidding, but it can also apply to upstream server entities such as another RTB exchange, a mediation platform, or an ad server combines direct campaigns with 3rd party demand in decisioning. + - - + + @@ -860,16 +900,16 @@ This object describes the nature and behavior of the entity that is the source o - -
Attribute        Type                    AttributeType Description
ext object Placeholder for exchange-specific extensions to OpenRTB.
+ ### 3.2.3 - Object: Regs This object contains any legal, governmental, or industry regulations that the sender deems applicable to the request. See Section 7.5 for more details on the flags supporting Coppa, GDPR and others. + @@ -905,21 +945,22 @@ This object contains any legal, governmental, or industry regulations that the s - -
Attribute        ext object Placeholder for exchange-specific extensions to OpenRTB.
+ + ### 3.2.4 - Object: Imp This object describes an ad placement or impression being auctioned. A single bid request can include multiple `Imp` objects, a use case for which might be an exchange that supports selling all ad positions on a given page. Each `Imp` object has a required ID so that bids can reference them individually. The presence of `Banner` (Section 3.2.6), `Video` (Section 3.2.7), and/or `Native` (Section 3.2.9) objects subordinate to the `Imp` object indicates the type of impression being offered. The publisher can choose one such type which is the typical case or mix them at their discretion. However, any given bid for the impression must conform to one of the offered type. + - - + + @@ -960,12 +1001,18 @@ The presence of `Banner` (Section 3.2.6), `Video` (Section 3.2.7), and/or `Nativ - + - + @@ -1031,16 +1078,12 @@ The presence of `Banner` (Section 3.2.6), `Video` (Section 3.2.7), and/or `Nativ - - - -
Attribute        Type                    AttributeType Description
displaymanager stringName of ad mediation partner, SDK technology, or player responsible for rendering ad (typically video or mobile). Used by some ad servers to customize ad code by partner.
Recommended for video and/or apps.		 + Name of ad mediation partner, SDK technology, or player responsible for rendering ad (typically video or mobile). Used by some ad servers to customize ad code by partner.
+ Recommended for video and/or apps. +
displaymanagerver stringVersion of ad mediation partner, SDK technology, or player responsible for rendering ad (typically video or mobile). Used by some ad servers to customize ad code by partner.
Recommended for video and/or apps.		 + Version of ad mediation partner, SDK technology, or player responsible for rendering ad (typically video or mobile). Used by some ad servers to customize ad code by partner.
+ Recommended for video and/or apps. +
instlrefresh object Details about ad slots being refreshed automatically. (Section 3.2.33)
ext object Placeholder for exchange-specific extensions to OpenRTB.
@@ -1049,10 +1092,11 @@ The presence of `Banner` (Section 3.2.6), `Video` (Section 3.2.7), and/or `Nativ This object is associated with an impression as an array of metrics. These metrics can offer insight into the impression to assist with decisioning such as average recent viewability, click-through rate, etc. Each metric is identified by its type, reports the value of the metric, and optionally identifies the source or vendor measuring the value. + - - + + @@ -1074,12 +1118,11 @@ This object is associated with an impression as an array of metrics. These metri - -
Attribute        Type                    AttributeType Description
ext object Placeholder for exchange-specific extensions to OpenRTB.
+ ### 3.2.6 - Object: Banner This object represents the most general type of impression. Although the term “banner” may have very specific meaning in other contexts, here it can be many things including a simple static image, an expandable ad unit, or even in-banner video (refer to the `Video` object in Section 3.2.7 for the more generalized and full featured video ad units). An array of `Banner` objects can also appear within the `Video` to describe optional companion ads defined in the VAST specification. @@ -1089,13 +1132,13 @@ The presence of a `Banner` as a subordinate of the `Imp` object indicates that t - - + + - + @@ -1111,12 +1154,14 @@ The presence of a `Banner` as a subordinate of the `Imp` object indicates that t - + @@ -1162,12 +1207,11 @@ The presence of a `Banner` as a subordinate of the `Imp` object indicates that t - -
Attribute        Type                    AttributeType Description
formatobject array;
recommended		object array; recommended Array of format objects (Section 3.2.10) representing the banner sizes permitted. If none are specified, then use of the h and w attributes is highly recommended.
btype integer arrayBlocked banner ad types.
- Values:
-1 = XHTML Text Ad,
-2 = XHTML Banner Ad,
-3 = JavaScript Ad,
-4 = iframe.
 + Blocked banner ad types.
+ Values:
+ 1 = XHTML Text Ad,
+ 2 = XHTML Banner Ad,
+ 3 = JavaScript Ad,
+ 4 = iframe.
+
battrext object Placeholder for exchange-specific extensions to OpenRTB.
+ ### 3.2.7 - Object: Video This object represents a video impression. Many of the fields are non-essential for minimally viable transactions, but are included to offer fine control when needed. Video in OpenRTB generally assumes compliance with the VAST standard. As such, the notion of companion ads is supported by optionally including an array of `Banner` objects (refer to the `Banner` object in Section 3.2.6) that define these companion ads. @@ -1177,8 +1221,8 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - - + + @@ -1214,7 +1258,7 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + @@ -1234,12 +1278,12 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + - + @@ -1260,11 +1304,11 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + - + @@ -1289,7 +1333,7 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + @@ -1298,9 +1342,9 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + - + @@ -1315,7 +1359,7 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + @@ -1324,12 +1368,12 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + - + @@ -1346,7 +1390,7 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + @@ -1360,12 +1404,11 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - -
Attribute        Type                    AttributeType Description
protocols integer array; recommendedArray of supported video protocols. Refer to List: Creative Substypes - Audio/Video in AdCOM 1.0.Array of supported video protocols. Refer to List: Creative Subtypes - Audio/Video in AdCOM 1.0.
w
podseq integer; default 0The sequence (position) of the video ad pod within a content stream. Refer to in AdCOM 1.0 for guidance on the use of this field.The sequence (position) of the video ad pod within a content stream. Refer to List: Pod Sequence in AdCOM 1.0 for guidance on the use of this field.
rqddurs integer arrayPrecise acceptable durations for video creatives in seconds. This field specifically targets the Live TV use case where non-exact ad durations would result in undesirable ‘dead air’. This field is mutually exclusive with minduration and maxduration; if rqddurs is specified, minduration and maxduration must not be specified and vice versa.Precise acceptable durations for video creatives in seconds. This field specifically targets the Live TV use case where non-exact ad durations would result in undesirable ‘dead air’. This field is mutually exclusive with minduration and maxduration; if rqddurs is specified, minduration and maxduration must not be specified and vice versa.
placementskip integer Indicates if the player will allow the video to be skipped, where 0 = no, 1 = yes.
If a bidder sends markup/creative that is itself skippable, the Bid object should include the attr array with an element of 16 indicating skippable video. Refer to List: Creative Attributes in AdCOM 1.0.
skipmin integer; default 0Videos of total duration greater than this number of seconds can be skippable; only applicable if the ad is skippable. Videos of total duration greater than this number of seconds can be skippable; only applicable if the ad is skippable.
skipafter
battr integer arrayBlocked creative attributes. Refer to List: Creative Attributes in AdCOM 1.0.Blocked creative attributes. Refer to List: Creative Attributes in AdCOM 1.0.
maxextended
minbitrateinptegerinteger Minumim bit rate in Kbps (kilobits per second).
maxbitrate integerplaybackmethod integer array Playback methods that may be in use. If none are specified, any method may be used. Refer to List: Playback Methods in AdCOM 1.0. Only one method is typically used in practice. As a result, this array may be converted to an integer in a future version of the specification. It is strongly advised to use only the first element of this array in preparation for this change.
playbackend integer
delivery integer arraySupported delivery methods (e.g., streaming, progressive). If none specified, assume all are supported. Refer to List: Delivery Methods in AdCOM 1.0. Supported delivery methods (e.g., streaming, progressive). If none specified, assume all are supported. Refer to List: Delivery Methods in AdCOM 1.0.
pos integerAd position on screen. Refer to List: Placement Positions in AdCOM 1.0.Ad position on screen. Refer to List: Placement Positions in AdCOM 1.0.
companionadinteger array Supported VAST companion ad types. Refer to List: Companion Types in AdCOM 1.0. Recommended if companion Banner objects are included via the companionad array. If one of these banners will be rendered as an end-card, this can be specified using the vcm attribute with the particular banner (Section 3.2.6).
poddedupe enum array PROVISIONAL Indicates pod deduplication settings that will be applied to bid responses. Refer to List: Pod Deduplication in AdCOM 1.0.ext object Placeholder for exchange-specific extensions to OpenRTB.
+ ### 3.2.8 - Object: Audio This object represents an audio type impression. Many of the fields are non-essential for minimally viable transactions, but are included to offer fine control when needed. Audio in OpenRTB generally assumes compliance with the VAST standard. As such, the notion of companion ads is supported by optionally including an array of `Banner` objects (refer to the `Banner` object in Section 3.2.6) that define these companion ads. @@ -1375,8 +1418,8 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th - - + + @@ -1438,7 +1481,7 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th - + @@ -1452,8 +1495,8 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th - - + + @@ -1473,7 +1516,7 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th - + @@ -1498,7 +1541,7 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th - + @@ -1508,8 +1551,6 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th - -
Attribute        Type                    AttributeType Description
mincpmpersec float Minimum CPM per second. This is a price floor for the “dynamic” portion of an audio ad pod, relative to the duration of bids an advertiser may submit.
battr integer array
minbitrate integerMinumim bit rate in Kbps (kilobits per second).
Minimum bit rate in Kbps (kilobits per second).
maxbitrate integerapi integer array List of supported API frameworks for this impression. Refer to List: API Framworks in AdCOM 1.0. If an API is not explicitly listed, it is assumed not to be supported.
companiontype integer arraynvol integer Volume normalization mode. Refer to List: Volume Normalization Modes in AdCOM 1.0.
durfloors object arrayext object Placeholder for exchange-specific extensions to OpenRTB.
@@ -1526,14 +1567,18 @@ The presence of a `Native` as a subordinate of the `Imp` object indicates that t - - + + - + @@ -1549,25 +1594,25 @@ The presence of a `Native` as a subordinate of the `Imp` object indicates that t - + - -
Attribute        Type                    AttributeType Description
request string; requiredRequest payload complying with the Native Ad Specification. The root node of the payload, "native", was dropped in the Native Ads Specification 1.1.
For Native 1.0, this is a JSON-encoded string consisting of a unnamed root object, with a single subordinate object named 'native', which is the Native Markup Request object, section 4.1 of OpenRTB Native 1.0 specification.
For Native 1.1 and higher, this is a JSON-encoded string consisting of an unnamed root object which is itself the Native Markup Request Object, section 4.1 of OpenRTB Native 1.1+ .		 + Request payload complying with the Native Ad Specification. The root node of the payload, "native", was dropped in the Native Ads Specification 1.1.
+ For Native 1.0, this is a JSON-encoded string consisting of a unnamed root object, with a single subordinate object named 'native', which is the Native Markup Request object, section 4.1 of OpenRTB Native 1.0 specification.
+ For Native 1.1 and higher, this is a JSON-encoded string consisting of an unnamed root object which is itself the Native Markup Request Object, section 4.1 of OpenRTB Native 1.1+. +
verbattr integer array Blocked creative attributes. Refer to List: Creative Attributes in AdCOM.
ext object Placeholder for exchange-specific extensions to OpenRTB.
+ ### 3.2.10 - Object: Format This object represents an allowed size (i.e., height and width combination) or Flex Ad parameters for a banner impression. These are typically used in an array where multiple sizes are permitted. It is recommended that either the `w`/`h` pair or the `wratio`/`hratio`/`wmin` set (i.e., for Flex Ads) be specified. + - - + + @@ -1589,18 +1634,16 @@ This object represents an allowed size (i.e., height and width combination) or F - + - - + + - -
Attribute        Type                    AttributeType Description
hratio integer Relative height when expressing size as a ratio.
wmin integer The minimum width in device independent pixels (DIPS) at which the ad will be displayed the size is expressed as a ratio.
ext object Placeholder for exchange-specific extensions to OpenRTB.
@@ -1610,8 +1653,8 @@ This object is the private marketplace container for direct deals between buyers - - + + @@ -1628,11 +1671,11 @@ This object is the private marketplace container for direct deals between buyers - -
Attribute        Type                    AttributeType Description
ext object Placeholder for exchange-specific extensions to OpenRTB.
+ + ### 3.2.12 - Object: Deal This object constitutes a specific deal that was struck between a buyer and a seller. Its presence with the `Pmp` collection indicates that this impression is available under the terms of that deal. Refer to Section 7.3 for more details. @@ -1640,8 +1683,8 @@ This object constitutes a specific deal that was struck between a buyer and a se - - + + @@ -1673,8 +1716,8 @@ This object constitutes a specific deal that was struck between a buyer and a se - - + + @@ -1687,7 +1730,7 @@ This object constitutes a specific deal that was struck between a buyer and a se - + @@ -1696,6 +1739,8 @@ This object constitutes a specific deal that was struck between a buyer and a se
Attribute        Type                    AttributeType Description
wadomain string array Array of advertiser domains (e.g., advertiser.com) allowed to bid on this deal. Omission implies no advertiser restrictions.
guar integer, default 0 Indicates that the deal is of type `guaranteed` and the bidder must bid on the deal, where 0 = not a guaranteed deal, 1 = guaranteed deal.
durfloors object arrayContainer for floor price by duration information, to be used if a given deal is eligible for video or audio demand. An array of DurFloors objects (see Section 3.2.35).Container for floor price by duration information, to be used if a given deal is eligible for video or audio demand. An array of DurFloors objects (see Section 3.2.35).
ext
+ + ### 3.2.13 - Object: Site This object should be included if the ad supported content is a website as opposed to a non-browser application or Digital Out of Home (DOOH) inventory. A bid request must not contain more than one of a `Site`, `App` or `DOOH` object. At a minimum, it is useful to provide a site ID or page URL, but this is not strictly required. @@ -1703,8 +1748,8 @@ This object should be included if the ad supported content is a website as oppos - - + + @@ -1725,44 +1770,44 @@ This object should be included if the ad supported content is a website as oppos - - + + - - - + + + - + - + - + - - + + - + - - + + @@ -1776,32 +1821,31 @@ This object should be included if the ad supported content is a website as oppos - + - - + + - + - + - -
Attribute        Type                    AttributeType Description
cattax integer; default 1The taxonomy in use. Refer to the AdCOM List: Category Taxonomies for values. If no cattax field is supplied IAB Cotent Category Taxonomy 1.0 is assumed.
The taxonomy in use. Refer to the AdCOM List: Category Taxonomies for values. If no cattax field is supplied IAB Content Category Taxonomy 1.0 is assumed.
cat string arrayArray of IAB Tech Lab content categories of the site. The taxonomy to be used is defined by the cattax field.
Array of IAB Tech Lab content categories of the site. The taxonomy to be used is defined by the cattax field.
sectioncat string arrayArray of IAB Tech Lab content categories that describe the current section of the site. The taxonomy to be used is defined by the cattax field.Array of IAB Tech Lab content categories that describe the current section of the site. The taxonomy to be used is defined by the cattax field.
pagecat string arrayArray of IAB Tech Lab content categories that describe the current page or view of the site. The taxonomy to be used is definied by the cattax field.Array of IAB Tech Lab content categories that describe the current page or view of the site. The taxonomy to be used is defined by the cattax field.
page string URL of the page where the impression will be shown.
ref string Referrer URL that caused navigation to the current page.
search string Search string that caused navigation to the current page.
mobile integer Indicates if the site has been programmed to optimize layout when viewed on mobile devices, where 0=no, 1=yes.
privacypolicy integer Indicates if the site has a privacy policy, where 0 = no, 1 = yes.content object Details about the Content (Section 3.2.16) within the site.
keywords string Comma separated list of keywords about the site. Only one of keywords or kwarray may be present.
kwarray string array Array of keywords about the site. Only one of keywords or kwarray may be present.
inventorypartnerdomain string A domain to be used for inventory authorization in the case of inventory sharing arrangements between a site owner and content owner. This field is typically used by authorization crawlers to establish the domain of the content owner, who has the right to monetize some portion of ad inventory within the site. The content owner's domain should be listed in the site owner's ads.txt file as an inventorypartnerdomain. Authorization for supply from the inventorypartnerdomain will be published in the ads.txt file on the root of that domain. Refer to the ads.txt 1.1 spec for more details.
ext object Placeholder for exchange-specific extensions to OpenRTB.
+ ### 3.2.14 - Object: App This object should be included if the ad supported content is a non-browser application (typically in mobile) as opposed to a website. A bid request must not contain more than one of a `Site`, `App` or `DOOH` object. At a minimum, it is useful to provide an App ID or bundle, but this is not strictly required. @@ -1809,8 +1853,8 @@ This object should be included if the ad supported content is a non-browser appl - - + + @@ -1822,7 +1866,7 @@ This object should be included if the ad supported content is a non-browser appl - + @@ -1832,7 +1876,7 @@ This object should be included if the ad supported content is a non-browser appl - + @@ -1842,38 +1886,38 @@ This object should be included if the ad supported content is a non-browser appl - + - - - + + + - + - + - + - - + + - + @@ -1882,28 +1926,26 @@ This object should be included if the ad supported content is a non-browser appl - + - - + + - + - + - -
Attribute        Type                    AttributeType Description
name string App name (may be aliased at the publisher's request).
bundle stringdomain string Domain of the app (e.g., "mygame.foo.com").
storeurl stringcattax integer; default 1 The taxonomy in use. Refer to the AdCOM List: Category Taxonomies for values.
cat string arrayArray of IAB Tech Lab content categories of the app. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied Content Category Taxonomy 1.0 is assumed.
Array of IAB Tech Lab content categories of the app. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied Content Category Taxonomy 1.0 is assumed.
sectioncat string arrayArray of IAB Tech Lab content categories that describe the current section of the app. The taxonomy to be used is defined by the cattax field.Array of IAB Tech Lab content categories that describe the current section of the app. The taxonomy to be used is defined by the cattax field.
pagecat string arrayArray of IAB Tech Lab content categories that describe the current page or view of the app. The taxonomy to be used is definied by the cattax field.Array of IAB Tech Lab content categories that describe the current page or view of the app. The taxonomy to be used is definied by the cattax field.
ver string Application version.
privacypolicy integer Indicates if the app has a privacy policy, where 0 = no, 1 = yes.
paid integer 0 = app is free, 1 = the app is a paid version.
publisher object Details about the Publisher (Section 3.2.15) of the app.content object Details about the Content (Section 3.2.16) within the app.
keywords string Comma separated list of keywords about the app. Only one of keywords or kwarray may be present.
kwarray string array Array of keywords about the app. Only one of keywords or kwarray may be present.
inventorypartnerdomain string A domain to be used for inventory authorization in the case of inventory sharing arrangements between an app owner and content owner. This field is typically used by authorization crawlers to establish the domain of the content owner, who has the right to monetize some portion of ad inventory within the app. The content owner's domain should be listed in the app owner's app-ads.txt file as an inventorypartnerdomain. Authorization for supply from the inventorypartnerdomain will be published in the ads.txt file on the root of that domain. Refer to the ads.txt 1.1 spec for more details.
ext object Placeholder for exchange-specific extensions to OpenRTB.
@@ -1914,11 +1956,10 @@ This object should be included if the ad supported content is a non-browser appl This object describes the entity who directly supplies inventory to and is paid by the exchange. This may be a publisher, intermediary exchange, ad network, etc. - - - + + @@ -1935,11 +1976,11 @@ This object describes the entity who directly supplies inventory to and is paid - + - + @@ -1950,20 +1991,20 @@ This object describes the entity who directly supplies inventory to and is paid - -
Attribute        Type                    AttributeType Description
cattax integer; default 1 The taxonomy in use. Refer to the AdCOM List: Category Taxonomies for values.
cat string arrayArray of IAB Tech Lab content categories of the publisher. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied Content Category Taxonomy 1.0 is assumed.Array of IAB Tech Lab content categories of the publisher. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied Content Category Taxonomy 1.0 is assumed.
domainext object Placeholder for exchange-specific extensions to OpenRTB.
+ ### 3.2.16 - Object: Content This object describes the content in which the impression will appear, which may be syndicated or non-syndicated content. This object may be useful when syndicated content contains impressions and does not necessarily match the publisher’s general content. The exchange might or might not have knowledge of the page where the content is running, because of the syndication method. For example, might be a video impression embedded in an iframe on an unknown web property or device. + - - + + @@ -2024,12 +2065,12 @@ This object describes the content in which the impression will appear, which may - + - + @@ -2119,6 +2160,7 @@ This object describes the content in which the impression will appear, which may
Attribute        Type                    AttributeType Description
cattax integer; default 1The taxonomy in use. Refer to list List: Category Taxonomies in AdCOM 1.0 for values.The taxonomy in use. Refer to List: Category Taxonomies in AdCOM 1.0 for values.
cat string arrayArray of IAB Tech Lab content categories that describe the content. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied Content Category Taxonomy 1.0 is assumed.Array of IAB Tech Lab content categories that describe the content. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied Content Category Taxonomy 1.0 is assumed.
prodq
+ ### 3.2.17 - Object: Producer This object defines the producer of the content in which the ad will be shown. This is particularly useful when the content is syndicated and may be distributed through different publishers and thus when the producer and publisher are not necessarily the same entity. @@ -2126,8 +2168,8 @@ This object defines the producer of the content in which the ad will be shown. T - - + + @@ -2139,41 +2181,41 @@ This object defines the producer of the content in which the ad will be shown. T - + - - + + - - - + + + - + - -
Attribute        Type                    AttributeType Description
name string Content producer or originator name (e.g., “Warner Bros”).
cattax integer; default 1The taxonomy in use. Refer to the AdCOM 1.0 list List: Category Taxonomies for values.
The taxonomy in use. Refer to the AdCOM 1.0 List: Category Taxonomies for values.
cat string arrayArray of IAB Tech Lab content categories that describe the content producer. -The taxonomy to be used is defined by the cattax field. If no cattax field is supplied Content Category Taxonomy 1.0 is assumed.
+ Array of IAB Tech Lab content categories that describe the content producer. + The taxonomy to be used is defined by the cattax field. If no cattax field is supplied Content Category Taxonomy 1.0 is assumed. +
domain string Highest level domain of the content producer (e.g., "producer.com").
ext object Placeholder for exchange-specific extensions to OpenRTB.
### 3.2.18 - Object: Device -This object provides information pertaining to the device through which the user is interacting. Device information includes its hardware, platform, location, and carrier data. The device can refer to a mobile handset, a desktop computer, set top box, or other digital device. +This object provides information pertaining to the device through which the user is interacting. Device information includes its hardware, platform, location, and carrier data. The device can refer to a mobile handset, a desktop computer, set-top box, or other digital device. - - + + @@ -2185,7 +2227,7 @@ This object provides information pertaining to the device through which the user - + @@ -2195,7 +2237,7 @@ This object provides information pertaining to the device through which the user - + @@ -2205,8 +2247,8 @@ This object provides information pertaining to the device through which the user - - + + @@ -2220,13 +2262,13 @@ This object provides information pertaining to the device through which the user - + - - + + @@ -2240,43 +2282,43 @@ This object provides information pertaining to the device through which the user - + - - + + - - + + - - + + - + - - + + - - + + - - + + @@ -2285,17 +2327,17 @@ This object provides information pertaining to the device through which the user - - + + - - + + - - + + @@ -2341,7 +2383,8 @@ This object provides information pertaining to the device through which the user -
Attribute        Type                    AttributeType Description
dnt integer; recommended Standard “Do Not Track” flag as set in the header by the browser, where 0 = tracking is unrestricted, 1 = do not track.
lmt integer; recommendedua string Browser user agent string. This field represents a raw user agent string from the browser. For backwards compatibility, exchanges are recommended to always populate ua with the User-Agent string, when available from the end user’s device, even if an alternative representation, such as the User-Agent Client-Hints, is available and is used to populate sua. No inferred or approximated user agents are expected in this field.
If a client supports User-Agent Client Hints, and sua field is present, bidders are recommended to rely on sua for detecting device type, browser type and version and other purposes that rely on the user agent information, and ignore ua field. This is because the ua may contain a frozen or reduced user agent string.
sua objectip string IPv4 address closest to device.
ipv6 string IP address closest to device as IPv6.make string Device make (e.g., “Apple”).
model string Device model (e.g., “iPhone”).
os string Device operating system (e.g., “iOS”).hwv string Hardware version of the device (e.g., “5S” for iPhone 5S).
h integer Physical height of the screen in pixels.
w integer Physical width of the screen in pixels.
ppi integer Screen size as pixels per linear inch.
pxratio float The ratio of physical pixels to device independent pixels.
js integer Support for JavaScript, where 0 = no, 1 = yes.
geofetch integer Indicates if the geolocation API will be available to JavaScript code running in the banner, where 0 = no, 1 = yes.
flashver string Version of Flash supported by the browser.
language string Browser language using ISO-639-1-alpha-2. Only one of language or langb should be present.langb string Browser language using IETF BCP 47. Only one of language or langb should be present.
carrier string Carrier or ISP (e.g., “VERIZON”) using exchange curated string names which should be published to bidders *a priori*.
mccmnc stringMobile carrier as the concatenated MCC-MNC code (e.g., “310-005” identifies Verizon Wireless CDMA in the USA). Refer to https://en.wikipedia.org/wiki/Mobile_country_code for further examples. Note that the dash between the MCC and MNC parts is required to remove parsing ambiguity. The MCC-MNC values represent the SIM installed on the device and do not change when a device is roaming. Roaming may be inferred by a combination of the MCC-MNC, geo, IP and other data signals.
Mobile carrier as the concatenated MCC-MNC code (e.g., “310-005” identifies Verizon Wireless CDMA in the USA). Refer to Mobile_country_code for further examples. Note that the dash between the MCC and MNC parts is required to remove parsing ambiguity. The MCC-MNC values represent the SIM installed on the device and do not change when a device is roaming. Roaming may be inferred by a combination of the MCC-MNC, geo, IP and other data signals.
connectiontype integerobject Placeholder for exchange-specific extensions to OpenRTB.
+ + ### 3.2.19 - Object: Geo @@ -2353,8 +2396,8 @@ The `lat`/`lon` attributes should only be passed if they conform to the accuracy - - + + @@ -2366,7 +2409,7 @@ The `lat`/`lon` attributes should only be passed if they conform to the accuracy - + @@ -2376,7 +2419,7 @@ The `lat`/`lon` attributes should only be passed if they conform to the accuracy - + @@ -2386,13 +2429,13 @@ The `lat`/`lon` attributes should only be passed if they conform to the accuracy - + - - + + @@ -2406,41 +2449,40 @@ The `lat`/`lon` attributes should only be passed if they conform to the accuracy - + - - + + - + - + - - -
Attribute        Type                    AttributeType Description
lon float Longitude from -180.0 to +180.0, where negative is west.
type integeraccuracy integer Estimated location accuracy in meters; recommended when lat/lon are specified and derived from a device’s location services (i.e., type = 1). Note that this is the accuracy as reported from the device. Consult OS specific documentation (e.g., Android, iOS) for exact interpretation.
lastfix integeripservice integer Service or provider used to determine geolocation from IP address if applicable (i.e., type = 2). Refer to List: IP Location Services in AdCOM 1.0.
country string Country code using ISO-3166-1-alpha-3.
region string Region code using ISO-3166-2; 2-letter state code if USA.metro string Google metro code; similar to but not exactly Nielsen DMAs. See Appendix A for a link to the codes.
city string City using United Nations Code for Trade & Transport Locations. See Appendix A for a link to the codes.
zip string ZIP or postal code.
utcoffset integer Local time as the number +/- of minutes from UTC.
ext object Placeholder for exchange-specific extensions to OpenRTB.
+ + + ### 3.2.20 - Object: User This object contains information known or derived about the human user of the device (i.e., the audience for advertising). The user `id` is an exchange artifact and may be subject to rotation or other privacy policies. However, when present, this user ID should be stable long enough to serve reasonably as the basis for frequency capping and retargeting. - - - + + @@ -2462,7 +2504,7 @@ This object contains information known or derived about the human user of the de - + @@ -2472,13 +2514,13 @@ This object contains information known or derived about the human user of the de - + - - + + @@ -2492,22 +2534,21 @@ This object contains information known or derived about the human user of the de - + - - + + - -
Attribute        Type                    AttributeType Description
gender string; DEPRECATED Gender, where “M” = male, “F” = female, “O” = known to be other (i.e., omitted is unknown).
keywords stringkwarray string array Array of keywords about the user. Only one of keywords or kwarray may be present.
customdata string Optional feature to pass bidder data that was set in the exchange’s cookie. The string must be in base85 cookie safe characters and be in any format. Proper JSON encoding must be used to include “escaped” quotation marks.
geo object Location of the user’s home base defined by a Geo object (Section 3.2.19). This is not necessarily their current location.consent string When GDPR regulations are in effect this attribute contains the Transparency and Consent Framework’s Consent String data structure.
eids object array Details for support of a standard protocol for multiple third party identity providers (Section 3.2.27).
ext object Placeholder for exchange-specific extensions to OpenRTB.
+ ### 3.2.21 - Object: Data The data and segment objects together allow additional data about the related object (e.g., user, content) to be specified. This data may be from multiple sources whether from the exchange itself or third parties as specified by the `id` field. A bid request can mix data objects from multiple providers. The specific data providers in use should be published by the exchange a priori to its bidders. @@ -2515,8 +2556,8 @@ The data and segment objects together allow additional data about the related ob - - + + @@ -2533,13 +2574,11 @@ The data and segment objects together allow additional data about the related ob - + - -
Attribute        Type                    AttributeType Description
segment object array Array of Segment (Section 3.2.22) objects that contain the actual data values.
ext object Placeholder for exchange-specific extensions to OpenRTB.
@@ -2551,8 +2590,8 @@ Segment objects are essentially key-value pairs that convey specific units of da - - + + @@ -2569,13 +2608,11 @@ Segment objects are essentially key-value pairs that convey specific units of da - + - -
Attribute        Type                    AttributeType Description
value string String representation of the data segment value.
ext object Placeholder for exchange-specific extensions to OpenRTB.
@@ -2587,8 +2624,8 @@ This object describes the network an ad will be displayed on. A Network is defin - - + + @@ -2605,26 +2642,24 @@ This object describes the network an ad will be displayed on. A Network is defin - + - -
Attribute        Type                    AttributeType Description
domain string The primary domain of the network (e.g. “abc.com” in the case of the network ABC). It is recommended to include the top private domain (PSL+1) for DSP targeting normalization purposes.
ext object Placeholder for exchange-specific extensions to OpenRTB.
### 3.2.24 - Object: Channel -This object describes the channel an ad will be displayed on. A Channel is defined as the entity that curates a content library, or stream within a brand name for viewers. Examples are specific view selectable ‘channels’ within linear and streaming television (MTV, HGTV, CNN, BBC One, etc) or a specific stream of audio content commonly called ‘stations.’ Name is a human-readable field while domain and id can be used for reporting and targeting purposes. See 7.6 for further examples. +This object describes the channel an ad will be displayed on. A Channel is defined as the entity that curates a content library, or stream within a brand name for viewers. Examples are specific view selectable ‘channels’ within linear and streaming television (MTV, HGTV, CNN, BBC One, etc.) or a specific stream of audio content commonly called ‘stations.’ Name is a human-readable field while domain and id can be used for reporting and targeting purposes. See 7.6 for further examples. - - + + @@ -2646,8 +2681,6 @@ This object describes the channel an ad will be displayed on. A Channel is defin - -
Attribute        Type                    AttributeType Description
ext object Placeholder for exchange-specific extensions to OpenRTB.
@@ -2659,8 +2692,8 @@ This object is composed of a set of nodes where each node represents a specific - - + + @@ -2677,17 +2710,16 @@ This object is composed of a set of nodes where each node represents a specific - + - -
Attribute        Type                    AttributeType Description
ver string; required Version of the supply chain specification in use, in the format of “major.minor”. For example, for version 1.0 of the spec, use the string “1.0”.
ext object Placeholder for exchange-specific extensions to OpenRTB.
+ ### 3.2.26 - Object: SupplyChainNode This object is associated with a `SupplyChain` object as an array of nodes. These nodes define the identity of an entity participating in the supply chain of a bid request. Detailed implementation examples can be found here: https://github.com/InteractiveAdvertisingBureau/openrtb/blob/master/supplychainobject.md. The `SupplyChainNode` object contains the following attributes: @@ -2695,8 +2727,8 @@ This object is associated with a `SupplyChain` object as an array of nodes. Thes - - + + @@ -2713,7 +2745,7 @@ This object is associated with a `SupplyChain` object as an array of nodes. Thes - + @@ -2728,13 +2760,11 @@ This object is associated with a `SupplyChain` object as an array of nodes. Thes - + - -
Attribute        Type                    AttributeType Description
rid string The OpenRTB RequestId of the request as issued by this seller.
name stringhp integer Indicates whether this node will be involved in the flow of payment for the inventory. When set to 1, the advertising system in the asi field pays the seller in the sid field, who is responsible for paying the previous node in the chain. When set to 0, this node is not involved in the flow of payment for the inventory. For version 1.0 of SupplyChain, this property should always be 1. Implementers should ensure that they propagate this field onwards when constructing SupplyChain objects in bid requests sent to a downstream advertising system.
ext object Placeholder for advertising-system specific extensions to this object.
@@ -2747,8 +2777,8 @@ Extended identifiers support in the OpenRTB specification allows buyers to use a - - + + @@ -2765,12 +2795,11 @@ Extended identifiers support in the OpenRTB specification allows buyers to use a - -
Attribute        Type                    AttributeType Description
ext object Placeholder for exchange-specific extensions to OpenRTB.
+ ### 3.2.28 - Object: UID This object contains a single user identifier provided as part of extended identifiers. The exchange should ensure that business agreements allow for the sending of this data. @@ -2778,8 +2807,8 @@ This object contains a single user identifier provided as part of extended ident - - + + @@ -2790,14 +2819,12 @@ This object contains a single user identifier provided as part of extended ident - - + + - -
Attribute        Type                    AttributeType Description
atype integerType of user agent the ID is from. It is highly recommended to set this, as many DSPs separate app-native IDs from browser-based IDs and require a type value for ID resolution. Refer to List: Agent Types in AdCOM 1.0
Type of user agent the ID is from. It is highly recommended to set this, as many DSPs separate app-native IDs from browser-based IDs and require a type value for ID resolution. Refer to List: Agent Types in AdCOM 1.0
ext object Placeholder for vendor specific extensions to this object.
@@ -2810,8 +2837,8 @@ Structured user agent information, which can be used when a client supports [Use - - + + @@ -2821,13 +2848,13 @@ Structured user agent information, which can be used when a client supports [Use - - + + - + @@ -2843,22 +2870,20 @@ Structured user agent information, which can be used when a client supports [Use - + - - + + - -
Attribute        Type                    AttributeType Description
platformBrandVersion object; recommendedA BrandVersion object (see Section 3.2.30) that identifies the user agent’s execution platform / OS. Implementers should send a brand derived from the Sec-CH-UA-Platform header, and version derived from the Sec-CH-UA-Platform-Version header *.BrandVersion object; recommendedA BrandVersion object (see Section 3.2.30) that identifies the user agent’s execution platform / OS. Implementers should send a brand derived from the Sec-CH-UA-Platform header, and version derived from the Sec-CH-UA-Platform-Version header*.
mobile integer1 if the agent prefers a “mobile” version of the content, if available, i.e. optimized for small screens or touch input. 0 if the agent prefers the “desktop” or “full” content. Implementers should derive this value from the Sec-CH-UA-Mobile header *.1 if the agent prefers a “mobile” version of the content, if available, i.e. optimized for small screens or touch input. 0 if the agent prefers the “desktop” or “full” content. Implementers should derive this value from the Sec-CH-UA-Mobile header*.
architecturemodel string Device model. Implementers should retrieve this value from the Sec-CH-UA-Model header*.
source integer; default 0The source of data used to create this object, List: User-Agent Source in AdCOM 1.0
The source of data used to create this object, List: User-Agent Source in AdCOM 1.0
ext object Placeholder for vendor specific extensions to this object.
-* or an equivalent JavaScript accessor from [NavigatorUAData interface](https://wicg.github.io/ua-client-hints/#navigatoruadata). This header or accessor are only available for browsers that support [User-Agent Client Hints](https://wicg.github.io/ua-client-hints/). +* or an equivalent JavaScript accessor from [NavigatorUAData interface](https://wicg.github.io/ua-client-hints/#navigatoruadata). This header or accessor are only available for browsers that support [User-Agent Client Hints](https://wicg.github.io/ua-client-hints/). ### 3.2.30 - Object: BrandVersion @@ -2867,8 +2892,8 @@ Further identification based on [User-Agent Client Hints](https://wicg.github.io - - + + @@ -2880,13 +2905,11 @@ Further identification based on [User-Agent Client Hints](https://wicg.github.io - + - -
Attribute        Type                    AttributeType Description
version array of string A sequence of version components, in descending hierarchical order (major, minor, micro, …)
ext object Placeholder for vendor specific extensions to this object.
@@ -2896,143 +2919,176 @@ A programmatic impression is often referred to as a ‘spot’ in digital out-of - - + + - + - + - + - - + + - - - -
Attribute        Type                    AttributeType Description
multiplier float; requiredThe quantity of billable events which will be deemed to have occurred if this item is purchased. For example, a DOOH opportunity may be considered to be 14.2 impressions. Equivalent to qtyflt in OpenRTB 3.0.The quantity of billable events which will be deemed to have occurred if this item is purchased. For example, a DOOH opportunity may be considered to be 14.2 impressions. Equivalent to qtyflt in OpenRTB 3.0.
sourcetype integer; recommendedThe source type of the quantity measurement, ie. publisher. Refer to the list https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md#list-multiplier-measurement-source-types- The source type of the quantity measurement, ie. publisher. Refer to the List: DOOH Multiplier Measurement Source Types
vendorstring; required if sourcetype is present and type = 1string; required if sourcetype is present and type = 1 The top level business domain name of the measurement vendor providing the quantity measurement.
ext object Placeholder for vendor specific extensions to this object.
### 3.2.32 - Object: DOOH -This object should be included if the ad supported content is a Digital Out-Of-Home screen. A bid request with a DOOH object must not contain a site or app object. At a minimum, it is useful to provide id and/or venuetypeid, but this is not strictly required. - -|Attribute |Type |Description | -|------------|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -|id |string; recommended|Exchange provided id for a placement or logical grouping of placements. | -|name |string |Name of the dooh placement. | -|venuetype |string, array |The type of out-of-home venue. The taxonomy to be used is defined by the venuetax field. If no venuetax field is supplied, The OpenOOH Venue Taxonomy is assumed. https://github.com/openooh/venue-taxonomy/blob/main/specification-1.0.md| -|venuetypetax|integer; default 1 |The venue taxonomy in use. Refer to list https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md#list-venue-taxonomies- | -|publisher |object |Details about the publisher of the placement. | -|domain |string |Domain of the inventory owner (e.g., “mysite.foo.com”) | -|keywords |string |Comma separated list of keywords about the DOOH placement. | -|content |object |Details about the Content within the DOOH placement. | -|ext |object |Placeholder for exchange-specific extensions to OpenRTB. | +This object should be included if the ad supported content is a Digital Out-Of-Home screen. A bid request with a DOOH object must not contain a site or app object. At a minimum, it is useful to provide id and/or venuetypeid, but this is not strictly required. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AttributeTypeDescription
idstring; recommendedExchange provided id for a placement or logical grouping of placements.
namestringName of the dooh placement.
venuetypestring, arrayThe type of out-of-home venue. The taxonomy to be used is defined by the venuetax field. If no venuetax field is supplied, The OpenOOH Venue Taxonomy is assumed. Venue Taxonomy Specifications
venuetypetaxinteger; default 1The venue taxonomy in use. Refer to list https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/main/AdCOM%20v1.0%20FINAL.md#list-dooh-venue-taxonomies-
publisherobjectDetails about the publisher of the placement.
domainstringDomain of the inventory owner (e.g., “mysite.foo.com”)
keywordsstringComma separated list of keywords about the DOOH placement.
contentobjectDetails about the Content within the DOOH placement.
extobjectPlaceholder for exchange-specific extensions to OpenRTB.
+ + + ### 3.2.33 - Object: Refresh - - + + - + - + - + - - - - -
Attribute        Type                    AttributeType Description
refsettings object array; recommended A RefSettings object (see Section 3.2.34) describing the mechanics of how an ad placement automatically refreshes.
count integer; recommended The number of times this ad slot had been refreshed since last page load.
ext object Placeholder for vendor specific extensions to this object.
+ + ### 3.2.34 - Object: RefSettings -Information on how often and what triggers an ad slot being refreshed. +Information on how often and what triggers an ad slot being refreshed. - - + + - + - - + + - - - + + + - -
Attribute        Type                    AttributeType Description
reftype integer; default 0; recommendedThe type of the declared auto refresh. Refer to List: Auto Refresh Triggers in AdCOM 1.0 -
The type of the declared auto refresh. Refer to List: Auto Refresh Triggers in AdCOM 1.0
minint integer; recommendedThe minimum refresh interval in seconds. This applies to all refresh types. This is the (uninterrupted) time the ad creative will be rendered before refreshing to the next creative. If the field is absent, the exposure time is unknown. This field does not account for viewability or external factors such as a user leaving a page. -
The minimum refresh interval in seconds. This applies to all refresh types. This is the (uninterrupted) time the ad creative will be rendered before refreshing to the next creative. If the field is absent, the exposure time is unknown. This field does not account for viewability or external factors such as a user leaving a page.
ext object Placeholder for vendor specific extensions to this object.
+ + ### 3.2.35 - Object: DurFloors This object allows sellers to specify price floors for video and audio creatives, whose price varies based on time. For example: 1-15 seconds at a floor of $5; 16-30 seconds at a floor of $10, > 31 seconds at a floor of $20. There are no explicit constraints on the defined ranges, nor guarantees that they don't overlap. In cases where multiple ranges may apply, it is up to the buyer and seller to coordinate on which floor is applicable. - - + + - + - + - + - -
Attribute        Type                    AttributeType Description
mindur integerAn integer indicating the low end of a duration range. If this value is missing, the low end is unbounded. Either mindur or maxdur is required, but not both.An integer indicating the low end of a duration range. If this value is missing, the low end is unbounded. Either mindur or maxdur is required, but not both.
maxdur integerAn integer indicating the high end of a duration range. If this value is missing, the high end is unbounded. Either mindur or maxdur is required, but not both.An integer indicating the high end of a duration range. If this value is missing, the high end is unbounded. Either mindur or maxdur is required, but not both.
bidfloor float; default 0Minimum bid for a given impression opportunity, if bidding with a creative in this duration range, expressed in CPM. For any creatives whose durations are outside of the defined min/max, the `bidfloor` at the `Imp` level will serve as the default floor.Minimum bid for a given impression opportunity, if bidding with a creative in this duration range, expressed in CPM. For any creatives whose durations are outside of the defined min/max, the bidfloor at the Imp level will serve as the default floor.
ext object Placeholder for vendor specific extensions to this object.
@@ -3042,7 +3098,7 @@ RTB responses contain bids that reference specific impressions within a bid requ ## 4.1 - Object Model -Following is the object model for the bid response. The top-level object (i.e., in JSON the unnamed outer object) is denoted as `BidResponse` in the model. A bid response may contain bids from multiple “seats” (i.e., the buying entity upstream from the actual bidder). In fact, a response may contain multiple bids from the same seat; typically but not necessarily from different campaigns. This can improve the seat’s chances of winning since most exchanges enforce various block lists on behalf of their publishers. +Following is the object model for the bid response. The top-level object (i.e., in JSON the unnamed outer object) is denoted as `BidResponse` in the model. A bid response may contain bids from multiple “seats” (i.e., the buying entity upstream from the actual bidder). In fact, a response may contain multiple bids from the same seat; typically but not necessarily from different campaigns. This can improve the seat’s chances of winning since most exchanges enforce various block lists on behalf of their publishers. ![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/864a56706b106eda94c03abefaa01dd43544864c/assets/Figure3.png) @@ -3055,11 +3111,10 @@ Not shown in the model figure is an extensions object. This is an object of unde The following table summarizes the objects in the Bid Response model and serves as an index into the detailed definitions in the subsections that follow. - - - + + @@ -3071,13 +3126,11 @@ The following table summarizes the objects in the Bid Response model and serves - + - -
Object        Section                    ObjectSection Description
SeatBid 4.2.2 Collection of bids made by the bidder on behalf of a specific seat.
Bid 4.2.3 An offer to buy a specific impression under certain business terms.
@@ -3096,11 +3149,10 @@ This object is the top-level bid response object (i.e., the unnamed outer JSON o To express a “no-bid”, the options are to return an empty response with HTTP 204. Alternately if the bidder wishes to convey to the exchange a reason for not bidding, just a `BidResponse` object is returned with a reason code in the `nbr` attribute. - - - + + @@ -3111,13 +3163,13 @@ To express a “no-bid”, the options are to return an empty response with HTTP - - + + - + @@ -3127,18 +3179,16 @@ To express a “no-bid”, the options are to return an empty response with HTTP - + - + - -
Attribute        Type                    AttributeType Description
seatbid object arrayArray of seatbid objects; 1+ required if a bid is to be made.
Array of seatbid objects; 1+ required if a bid is to be made.
bidid string Bidder generated response ID to assist with logging/tracking.
cur string; default "USD"customdata string Optional feature to allow a bidder to set data in the exchange’s cookie. The string must be in base85 cookie safe characters and be in any format. Proper JSON encoding must be used to include “escaped” quotation marks.
nbr integer Reason for not bidding. Refer to List: No-Bid Reason Codes in OpenRTB 3.0.
ext object Placeholder for bidder-specific extensions to OpenRTB.
@@ -3151,8 +3201,8 @@ A bid response can contain multiple `SeatBid` objects, each on behalf of a diffe - - + + @@ -3164,18 +3214,16 @@ A bid response can contain multiple `SeatBid` objects, each on behalf of a diffe - + - + - -
Attribute        Type                    AttributeType Description
seat string ID of the buyer seat (e.g., advertiser, agency) on whose behalf this bid is made.
group integer; default 0 0 = impressions can be won individually; 1 = impressions must be won or lost as a group.
ext object Placeholder for bidder-specific extensions to OpenRTB.
@@ -3188,8 +3236,8 @@ A `SeatBid` object contains one or more `Bid` objects, each of which relates to - - + + @@ -3201,12 +3249,12 @@ A `SeatBid` object contains one or more `Bid` objects, each of which relates to - + - + @@ -3216,12 +3264,12 @@ A `SeatBid` object contains one or more `Bid` objects, each of which relates to - + - + @@ -3231,12 +3279,12 @@ A `SeatBid` object contains one or more `Bid` objects, each of which relates to - + - + @@ -3246,17 +3294,17 @@ A `SeatBid` object contains one or more `Bid` objects, each of which relates to - + - + - + - + @@ -3266,12 +3314,12 @@ A `SeatBid` object contains one or more `Bid` objects, each of which relates to - + - - + + @@ -3280,18 +3328,18 @@ A `SeatBid` object contains one or more `Bid` objects, each of which relates to - - + + - + - + - + @@ -3300,13 +3348,13 @@ A `SeatBid` object contains one or more `Bid` objects, each of which relates to - - + + - + @@ -3316,17 +3364,17 @@ A `SeatBid` object contains one or more `Bid` objects, each of which relates to - + - + - + - + @@ -3336,33 +3384,33 @@ A `SeatBid` object contains one or more `Bid` objects, each of which relates to - + - + - + - + - -
Attribute        Type                    AttributeType Description
impid string; required ID of the Imp object in the related bid request.
price float; required Bid price expressed as CPM although the actual transaction is for a unit impression only. Note that while the type indicates float, integer math is highly recommended when handling currencies (e.g., BigDecimal in Java).
nurl stringburl string Billing notice URL called by the exchange when a winning bid becomes billable based on exchange-specific business policy (e.g., typically delivered, viewed, etc.). Substitution macros (Section 4.4) may be included.
lurl string Loss notice URL called by the exchange when a bid is known to have been lost. Substitution macros (Section 4.4) may be included. Exchange-specific policy may preclude support for loss notices or the disclosure of winning clearing prices resulting in ${AUCTION_PRICE} macros being removed (i.e., replaced with a zero-length string).
adm stringadid string ID of a preloaded ad to be served if the bid wins.
adomain string array Advertiser domain for block list checking (e.g., “ford.com”). This can be an array of for the case of rotating creatives. Exchanges can mandate that only one domain is allowed.
bundle stringiurl string URL without cache-busting to an image that is representative of the content of the campaign for ad quality/safety checking.
cidcid string Campaign ID to assist with ad quality checking; the collection of creatives for which iurl should be representative.
crid string Creative ID to assist with ad quality checking.
tactic stringcattax integer; default 1 The taxonomy in use. Refer to List: Category Taxonomies for values.
cat string arrayIAB Tech Lab content categories of the creative. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied Content Taxonomy 1.0 is assumed
IAB Tech Lab content categories of the creative. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied Content Taxonomy 1.0 is assumed
attr integer array
apis integer arrayList of supported APIs for the markup. If an API is not explicitly listed, it is assumed to be unsupported. Refer to List: API Frameworks in AdCOM 1.0.
List of supported APIs for the markup. If an API is not explicitly listed, it is assumed to be unsupported. Refer to List: API Frameworks in AdCOM 1.0.
apiapi integer; DEPRECATED NOTE: Deprecated in favor of the apisinteger array. API required by the markup if applicable. Refer to List: API Frameworks in AdCOM 1.0.
protocol integer Video response protocol of the markup if applicable. Refer to List: Creative Subtypes - Audio/Video in AdCOM 1.0.
qagmediarating integer
language stringLanguage of the creative using ISO-639-1-alpha-2. The non- standard code “xx” may also be used if the creative has no linguistic content (e.g., a banner with just a company logo). Only one of language or langb should be present.
Language of the creative using ISO-639-1-alpha-2. The non-standard code “xx” may also be used if the creative has no linguistic content (e.g., a banner with just a company logo). Only one of language or langb should be present.
langb string Language of the creative using IETF BCP 47. Only one of language or langb should be present.
dealid stringw integer Width of the creative in device independent pixels (DIPS).
hh integer Height of the creative in device independent pixels (DIPS).
wratio integer Relative width of the creative when expressing size as a ratio. Required for Flex Ads.
hratio integerexp integer Advisory as to the number of seconds the bidder is willing to wait between the auction and the actual impression.
dur integer Duration of the video or audio creative in seconds.
mtype integerType of the creative markup so that it can properly be associated with the right sub-object of the BidRequest.Imp.
-Values:
-1 = Banner
-2 = Video,
-3 = Audio
-4 = Native
 + Type of the creative markup so that it can properly be associated with the right sub-object of the BidRequest.Imp.
+ Values:
+ 1 = Banner
+ 2 = Video,
+ 3 = Audio
+ 4 = Native
+
slotinpod integer; default 0 Indicates that the bid response is only eligible for a specific position within a video or audio ad pod (e.g. first position, last position, or any). Refer to List: Slot Position in Pod in AdCOM 1.0 for guidance on the use of this field.
ext object Placeholder for bidder-specific extensions to OpenRTB.
@@ -3408,6 +3456,7 @@ Each of the ad serving methods has its own advantages that may be of varying imp - *Potential Concurrency*: The exchange can choose to return that ad markup and call the win notice concurrently, thereby improving user experience. + ## 4.4 - Substitution Macros The win notice and billing notice URLs and their format are defined by the bidder. For the exchange to convey certain information to the bidder (e.g., the clearing price), several substitution macros can be inserted into these URLs. Prior to calling a win or billing notice URL, the exchange will search the specified URL for any of the defined macros and replace them with the appropriate data.
@@ -3416,11 +3465,10 @@ Note that the substitution is simple in the sense that wherever a legal macro is These same substitution macros can also be placed in the ad markup. The exchange will perform the same data substitutions as in the aforementioned notice URLs. This occurs irrespective of whether the markup is returned on the win notice or passed in the `bid.adm` attribute of the bid response. A use case for macros in the ad markup might be when a bidder prefers to receive its win notification from the device itself. To accomplish this, the bidder would include a tracking pixel in the ad markup, the URL for which would include any of the available macros. - - - + + @@ -3429,11 +3477,11 @@ These same substitution macros can also be placed in the ad markup. The exchange - + - + @@ -3441,11 +3489,11 @@ These same substitution macros can also be placed in the ad markup. The exchange - + - + @@ -3457,24 +3505,22 @@ These same substitution macros can also be placed in the ad markup. The exchange - + - - - - - - + +
Macro        Description                    MacroDescription
${AUCTION_ID}
${AUCTION_BID_ID} ID of the bid; from BidResponse.bidid attribute.
${AUCTION_IMP_ID} ID of the impression just won; from imp.id attribute.
${AUCTION_SEAT_ID} ID of the bidder seat for whom the bid was made.
${AUCTION_AD_ID} ID of the ad markup the bidder wishes to serve; from bid.adid attribute.
${AUCTION_PRICE} Clearing price using the same currency and units as the bid.
${AUCTION_CURRENCY} The currency used in the bid (explicit or implied); for confirmation only.
${AUCTION_LOSS} Loss reason codes. Refer to List: Loss Reason Codes in OpenRTB 3.0.
${AUCTION_MIN_TO_WIN} Minimum bid to win the exchange's auction, using the same currency and units as the bid.
${AUCTION_MULTIPLIER} The total quantity of impressions won; for confirmation only. This should always be less than or equal to the multiplier value sent in the bid request. This value is a float value greater than zero and may be less than one. Should be used to confirm that the buyer expects and understands the multiplier value.
${AUCTION_IMP_TS}Timestamp when the impression was fulfilled (e.g. when the ad is displayed) in Unix format (i.e., milliseconds since the epoch). -This may be used by platforms that cannot fire a notification as soon as the impression takes place. If omitted, it is assumed the impression took place a few seconds before the notification is fired.
+ Timestamp when the impression was fulfilled (e.g. when the ad is displayed) in Unix format (i.e., milliseconds since the epoch). + This may be used by platforms that cannot fire a notification as soon as the impression takes place. If omitted, it is assumed the impression took place a few seconds before the notification is fired. +
@@ -3484,7 +3530,6 @@ Note that OpenRTB compliance exchanges must support all macros for which data is **BEST PRACTICE**: Encoding of macro data should be used sparingly due to the additional processing overhead. For communications strictly between exchange and bidder (e.g., a win notice called from the exchange), encoding is generally considered unnecessary. - Prior to substitution, macro data values can be encoded for security purposes using various obfuscation or encryption algorithms. This may be of particular interest for use cases where price information is carried beyond the exchange, through the publisher, and into the device browser via a tracking pixel in the markup. To specify that a particular macro is to be encoded, the suffix “`:X`” should be appended to the macro name, where X is a string that indicates the algorithm to be used. Algorithms choices are not defined by this specification and must be mutually agreed upon between parties. As an example, suppose that the price macro is to be encoded using Base64 and that its code is “`B64`”. The macro would then be written as follows: @@ -3496,10 +3541,10 @@ To specify that a particular macro is to be encoded, the suffix “`:X`” shoul Except where the value "AUDIT" applies, as above, the macro is replaced by: - The empty string, if the exchange chooses not to provide the value, for example because: - - The bid was not allowed into the auction, e.g., because of blocks on the seat, advertiser, etc. - - Per the loss code, price was not the deciding factor in the loss. - - As dictated by exchange privacy controls, e.g., if price data is not shared to bidders that did not meet the desired floor, or if the exchange supports a publisher or winning bidder election not to share price data with the other bidders. - + - The bid was not allowed into the auction, e.g., because of blocks on the seat, advertiser, etc. + - Per the loss code, price was not the deciding factor in the loss. + - As dictated by exchange privacy controls, e.g., if price data is not shared to bidders that did not meet the desired floor, or if the exchange supports a publisher or winning bidder election not to share price data with the other bidders. + - The minimum price required to tie with the winning bid, when your bid lost to another in the auction. - The minimum price required to tie with the next-closest bid, or the floor if there was only one bid, when your bid won the auction. @@ -3511,8 +3556,8 @@ For a first-price auction:
- - + + @@ -3524,18 +3569,16 @@ For a first-price auction:
- + - + - -
Bid Price        ${AUCTION_PRICE}                    Bid Price${AUCTION_PRICE} ${AUCTION_MIN_TO_WIN}
$0.90 Empty string $1.00
$0.80 Empty string $1.00
Invalid n/a Empty string
@@ -3544,8 +3587,8 @@ For a second-price auction (where, for the sake of the illustration, the clearin - - + + @@ -3557,18 +3600,16 @@ For a second-price auction (where, for the sake of the illustration, the clearin - + - + - -
Bid Price        ${AUCTION_PRICE}                    Bid Price${AUCTION_PRICE} ${AUCTION_MIN_TO_WIN}
$0.90 Empty string $0.91
$0.80 Empty string $0.91
Invalid n/a Empty string
@@ -3998,12 +4039,13 @@ Following is a basic example of a bid request for a banner ad with a direct deal ``` + ### 6.2.6 - Example 6 – Native Ad For details on Native Ad implementation including examples, please review the OpenRTB Native Ads API Specification: https://iabtechlab.com/standards/openrtb-native/ -## 6.3 - Bid Responses +## 6.3 - Bid Responses ### 6.3.1 - Example 1 – Ad Served on Win Notice @@ -4116,8 +4158,9 @@ Following is an example of a bid response with the ad served on win notice. The ``` + ### 6.3.4 - Example 4 – Native Markup Returned Inline - + Following is an example of a bid response that returns a native ad inline to be served. The `adm` attribute contains an encoded string of a native ad request that conforms to the Dynamic Native Ads API and specifically the same version as that used for the request string. Alternatively, the `adm` attribute could have been omitted in favor of returning the native ad markup in the response to the win notice `nurl`. ```javascript @@ -4140,9 +4183,10 @@ Following is an example of a bid response that returns a native ad inline to be ``` + ## [7. Implementation Notes](implementation.md#implementationnotes) -- [7.1 - No-Bid Signaling](implementation.md#nobidsignaling) +- [7.1 - No-Bid Signaling](implementation.md#nobidsignaling) - [7.2 - Impression Expiration](implementation.md#impressionexpiration) @@ -4164,188 +4208,187 @@ Following is an example of a bid response that returns a native ad inline to be - [7.11 - Guidance on the Use of Floors](implementation.md#floors) - + # Appendix A. Additional Information - + - Creative Commons / Attribution License - - creativecommons.org/licenses/by/3.0 - + + creativecommons.org/licenses/by/3.0 + - IAB (Interactive Advertising Bureau) - - www.iab.com - + + www.iab.com + - IAB Quality Assurance Guidelines (QAG): - - www.iab.com/guidelines/iab-quality-assurance-guidelines-qag-taxonomy/ - + + www.iab.com/guidelines/iab-quality-assurance-guidelines-qag-taxonomy/ + - JavaScript Object Notation (JSON) - - www.json.org - + + www.json.org + - MMA (Mobile Marketing Association) - - mmaglobal.com - + + mmaglobal.com + - OpenRTB Project on Github - - github.com/openrtb/OpenRTB/ - + + github.com/openrtb/OpenRTB/ + - Apache Avro - - avro.apache.org - - Protocol Buffers (Protobuf) - -code.google.com/p/protobuf - + + avro.apache.org + +- Protocol Buffers (Protobuf) + + code.google.com/p/protobuf + - Google Metro Codes - - code.google.com/apis/adwords/docs/appendix/metrocodes.html - + + code.google.com/apis/adwords/docs/appendix/metrocodes.html + - U.N. Code for Trade and Transport Locations: - - www.unece.org/cefact/locode/service/location.htm - - + + www.unece.org/cefact/locode/service/location.htm + + # Appendix B. Specification Change Log - + This appendix serves as an index of specification changes across 2.x versions. These changes pertain only to the substance of the specification and not routine document formatting, organization, or content without technical impact. **Please refer to GitHub [Releases](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/releases) page for release notes for ORTB2.6-202303 onward** - + **Version 2.6-202210 (Base 2.6 version) to 2.6-202211:** + - - + + - - + + - + - + - - - + + - - + + + - + - +
Section        Description                    SectionDescription
3.1Object Model Update to model image to show DOOH and Qty objects3.1Object Model Update to model image to show DOOH and Qty objects
3.2.33.2.3 Object: Regs Additional fields gpp and gpp_sid to support Global Privacy Protection string
3.2.13, 3.2.14Objects: Site, App Added inventorypartnerdomain (previously ext)
3.2.13, 3.2.14Objects: Site, App Added inventorypartnerdomain (previously ext)
3.2.31Object: Qty New object to describe source of multiplier value in Digital Out of Home
3.2.31Object: Qty New object to describe source of multiplier value in Digital Out of Home
3.2.32 Object: DOOH New object to support programmatic buys of Digital Out of Home inventory
7.9 Implementation Notes Addition of notes, examples and best practices for utilizing DOOH
+ **Version 2.5 to 2.6:** - - + - - + + + - - + + + - + - + - + - - - + + + - - + + - + - + - + - - - + + + - + - + - - - + + + - + - + - + - + - - - + + + - - - - + +
Section        Description                    SectionDescription
3.2.1, 3.2.16, 4.2.3, 3.2.18 Added new language field to support IETF BCP 47, IETF BCP 47 offers additional layers of granularity, for example, differentiating written language versions of the same spoken language (e.g. Traditional and Simplified Chinese), https://en.wikipedia.org/wiki/IETF_language_tag
3.2.3 Object: Regs added `gdpr` attribute (previously ext)
3.2.20
3.2.20 Object: User added `consent` attribute (previously ext)
5 Removed section (Enumerated Lists) All references now point to AdCOM 1.0 / OpenRTB 3.0 Lists
3.2.1, 3.2.13, 3.2.14, 3.2.15, 3.2.16, 3.2.17, 4.2.3 Objects: BidRequest, Site, App, Publisher, Content, Producer, Bid Use of cattax for all taxonomy references
3.2.7, 3.2.8 Objects: Video, Audio Added rqddurs
3.2.7, 3.2.8Objects: Video, Audio Added maxseq, poddur, podid, podseq, mincpmpersec, slotinpod for pod bidding support
3.2.7, 3.2.8Objects: Video, Audio Added maxseq, poddur, podid, podseq, mincpmpersec, slotinpod for pod bidding support
4.4, 4.4.1Substition Macros Added AUCTION_MIN_TO_WIN
Substitution Macros Added AUCTION_MIN_TO_WIN
4.2.3 Object, Bid Added apis
3.2.43.2.4 Object: Imp Added rwdd
3.2.1, 3.2.14, 4.2.3 Objects: App, Bid, BidRequest Clarified laguage around use of storeid vs bundle
3.2.4Object Imp Added ssai
3.2.4Object Imp Added ssai
3.2.18 Object: Device Clarified language around mccmnc and roaming
3.2.23, 3.2.243.2.23, 3.2.24 Added Objects: Network, Channel, SupplyChain, SupplyChainNode, EIDs and UIDs*
4.2.3Object: Bid Added mtype
4.2.3Object: Bid Added mtype
3.2.6, 3.2.7, 3.2.16 Removed previously deprecated attributes Object: Banner, wmax, hmax, wmin, hmin, Object: Video, protocol, Object: Content, videoquality
7.6 Pod Bidding for Video and Audio implementers guide
7.77.7 Network and Channel object examples
3.2.7, 3.2.8, 3.2.18, 3.2.20, 4.2.3 Deprecated attributes Object: Video, sequence, Object: Audio, sequence, Ojbect: Device, didsha1, didmd5, dpidsha1, dpidnd5, macsha1, macmd5, Object: User, yob, gender, Object: Bid, api
7.8 Added Counting Billable events and tracked ads
7.8 Added Counting Billable events and tracked ads
3.2.29, 3.2.30Object: UserAgent & Object Brand Version added3.2.29, 3.2.30Object: UserAgent & Object Brand Version added
- - + **Version 2.4 to 2.5:** - - + @@ -4356,20 +4399,21 @@ This appendix serves as an index of specification changes across 2.x versions. T - + - + - + - + - - + + + @@ -4378,58 +4422,53 @@ This appendix serves as an index of specification changes across 2.x versions. T - + - - - + + + - - - + + + - + - + - - - + + + - + - + - + - + - - - + + + - - - - + +
Section        Section: Data Encoding New section added.
3.13.1 Object Model: Bid Request Update to include Source and Metric objects.
3.2.13.2.1 Object: BidRequest, Attributes bseat, wlang, and source have been added.
3.2.2 Object: Source New Source object has been added including the Payment ID pchain attribute.
3.2.4Object: Imp Attribute Metric object has been added.
3.2.4Object: Imp Attribute Metric object has been added.
3.2.5
3.2.6 Object: Banner, Attribute vcm has been added.
3.2.7Object: Video, Attributes placement and playbackend have been added. Guidance added to use only the first element of attribute playbackmethod in preparation for future converson to an integer.
3.2.7Object: Video, Attributes placement and playbackend have been added. Guidance added to use only the first element of attribute playbackmethod in preparation for future conversion to an integer.
3.2.10 Object: Format Attributes wratio, hratio, and wmin have been added.
3.2.4Object Imp Added ssai
3.2.4Object Imp Added ssai
3.2.13 Object: Device Attribute mccmnc has been added. Attribute carrier has been clarified to eliminate a reference to using "WIFI" as a carrier.
4.2.34.2.3 Object: Bid Attributes burl, lurl, tactic, language, wratio, and hratio have been added.
4.4Subsititution Macros: Macros ${AUCTION_MBR} and ${AUCTION_LOSS} have been added. A best practice has been added to use “AUDIT” for unknown values when rendering for test or quality purposes.
4.4Substitution Macros: Macros ${AUCTION_MBR} and ${AUCTION_LOSS} have been added. A best practice has been added to use “AUDIT” for unknown values when rendering for test or quality purposes.
5.6 List: API Frameworks Item 6 has been added.
5.9 List: Video Placement Types New list has been added.
5.105.10 List: Playback Methods Items 5-6 have been added.
5.11 List: Playback Cessation Modes New list has been added.
5.24List: No-Bid Reason Codes Items 9-10 have been added.
5.24List: No-Bid Reason Codes Items 9-10 have been added.
5.25List: Loss Reason Codes New list has been added.5.25List: Loss Reason Codes New list has been added.
- - -