diff --git a/2.6.md b/2.6.md index 79d0841..426e1ac 100644 --- a/2.6.md +++ b/2.6.md @@ -133,9 +133,13 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [3.2.31 - Object: Qty](#objectqty) - [3.2.32 - Object: DOOH](#objectdooh) + - [3.2.33 - Object: Refresh](#objectrefresh) + - [3.2.34 - Object: RefSettings](#objectrefsettings) + - [3.2.35 - Object: DurFloors](#objectdurfloors) + ## [4. Bid Response Specification](#bidresponsespec) - [4.1 - Object Model](#4.2objectmodel) @@ -190,26 +194,29 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [6.3.4 - Example 4 – Native Markup Returned Inline](#nativemarkupreturnedinline) -## [7. Implementation Notes](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) +## [7. Implementation Notes](implementation.md#implementationnotes) + +- [7.1 - No-Bid Signaling](implementation.md#nobidsignaling) -- [7.1 - No-Bid Signaling](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#71-no-bid-signaling-) +- [7.2 - Impression Expiration](implementation.md#impressionexpiration) -- [7.2 - Impression Expiration](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#72-impression-expiration-) +- [7.3 - PMP & Direct Deals](implementation.md#pmpanddirectdeals) -- [7.3 - PMP & Direct Deals](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#73-pmp--direct-deals-) +- [7.4 - Skippability](implementation.md#skippability) -- [7.4 - Skippability](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#74-skippability-) +- [7.5 - Regs Resources](implementation.md#regsresources) -- [7.5 - Regs Resources](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#75-regs-resources-) +- [7.6 - Pod Bidding for Video and Audio](implementation.md#podbidding) -- [7.6 - Pod Bidding for Video and Audio](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#76-pod-bidding-for-video-and-audio-) +- [7.7 - Network vs Channel Example Cases](implementation.md#networkandchannel) -- [7.7 - Network vs Channel Example Cases](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#77-network-vs-channel-example-cases-) +- [7.8 - Counting Billable Events and Tracked Ads](implementation.md#counting) -- [7.8 - Counting Billable Events and Tracked Ads](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#78-counting-billable-events-and-tracked-ads-) +- [7.9 - Digital Out-Of-Home](implementation.md#dooh) -- [7.9 - Digital Out-Of-Home](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#79---digital-out-of-home-) -- [7.10 - Updated Video Signals](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#710---updated-video-signals) +- [7.10 - Updated Video Signals](implementation.md#videosignals) + +- [7.11 - Guidance on the Use of Floors](implementation.md#floors) ## [Appendix A. Additional Information](#appendixa) @@ -680,7 +687,7 @@ The following table summarizes the objects in the Bid Request model and serves a ### 3.2.1 - Object: BidRequest -The top-level bid request object contains a globally 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. +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. @@ -695,7 +702,7 @@ There are also several subordinate objects that provide detailed data to potenti id string; required - Unique ID of the bid request, provided by the exchange. + ID of the bid request, assigned by the exchange, and unique for the exchange’s subsequent tracking of the responses. The exchange may use different values for different recipients. imp @@ -772,10 +779,15 @@ There are also several subordinate objects that provide detailed data to potenti string array Allowed list of languages for creatives using IETF BCP 47I. Omission implies no specific restrictions, but buyers would be advised to consider language attribute in the Device and/or Content objects if available. Only one of wlang or wlangb should be present. + + acat + string array + 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 array - 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. + 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 @@ -972,7 +984,7 @@ The presence of `Banner` (Section 3.2.6), `Video` (Section 3.2.7), and/or `Nativ bidfloorcur string; default "USD" - Currency specified using ISO-4217 alpha codes. This may be different from bid currency returned by bidder if this is allowed by the exchange. + Currency specified using ISO-4217 alpha codes. This may be different from bid currency returned by bidder if this is allowed by the exchange. This currency sets the default for all floors specified in the `Imp` object. clickbrowser @@ -1327,12 +1339,17 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th api integer array List of supported API frameworks for this impression. Refer to List: API Frameworks in AdCOM 1.0. If an API is not explicitly listed, it is assumed not to be supported. - + companiontype integer 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). + + durfloors + object array + An array of `DurFloors` objects (Section 3.2.35) indicating the floor prices for video creatives of various durations that the buyer may bid with. + ext object @@ -1460,7 +1477,7 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th maxseq integer The maximum number of ads that can be played in an ad pod. - + feed integer @@ -1476,6 +1493,11 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th integer Volume normalization mode. Refer to List: Volume Normalization Modes in AdCOM 1.0. + + durfloors + object array + An array of `DurFloors` objects (Section 3.2.35) indicating the floor prices for audio creatives of various durations that the buyer may bid with. + ext object @@ -1629,29 +1651,42 @@ This object constitutes a specific deal that was struck between a buyer and a se bidfloorcur string; default "USD" - Currency specified using ISO-4217 alpha codes. This may be different from bid currency returned by bidder if this is allowed by the exchange. + Currency specified using ISO-4217 alpha codes. This may be different from bid currency returned by bidder if this is allowed by the exchange. This field does not inherit from `Imp.bidfloorcur`; it is either explicitly specified or defaults to USD. at integer Optional override of the overall auction type of the bid request, where 1 = First Price, 2 = Second Price Plus, 3 = the value passed in bidfloor is the agreed upon deal price. Additional auction types can be defined by the exchange. - + wseat string array Allowed list of buyer seats (e.g., advertisers, agencies) allowed to bid on this deal. IDs of seats and the buyer’s customers to which they refer must be coordinated between bidders and the exchange a priori. Omission implies no seat restrictions. - - + + 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. + + + mincpmpersec + float + Minimum CPM per second. This is a price floor for video or audio impression opportunities, relative to the duration of bids an advertiser may submit. + + durfloors + object array + 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 object Placeholder for exchange-specific extensions to OpenRTB. - - @@ -1683,7 +1718,7 @@ This object should be included if the ad supported content is a website as oppos cattax - integer + integer; default 1 The 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. @@ -2963,6 +2998,40 @@ Information on how often and what triggers an ad slot being refreshed. +### 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                    Description
mindurintegerAn 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.
maxdurintegerAn 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.
bidfloorfloat; 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.
extobjectPlaceholder for vendor specific extensions to this object.
+ # 4. Bid Response Specification @@ -4067,27 +4136,29 @@ Following is an example of a bid response that returns a native ad inline to be ``` -# [7. Implementation Notes](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) +## [7. Implementation Notes](implementation.md#implementationnotes) + +- [7.1 - No-Bid Signaling](implementation.md#nobidsignaling) -- [7.1 - No-Bid Signaling](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#71-no-bid-signaling-) +- [7.2 - Impression Expiration](implementation.md#impressionexpiration) -- [7.2 - Impression Expiration](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#72-impression-expiration-) +- [7.3 - PMP & Direct Deals](implementation.md#pmpanddirectdeals) -- [7.3 - PMP & Direct Deals](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#73-pmp--direct-deals-) +- [7.4 - Skippability](implementation.md#skippability) -- [7.4 - Skippability](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#74-skippability-) +- [7.5 - Regs Resources](implementation.md#regsresources) -- [7.5 - Regs Resources](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#75-regs-resources-) +- [7.6 - Pod Bidding for Video and Audio](implementation.md#podbidding) -- [7.6 - Pod Bidding for Video and Audio](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#76-pod-bidding-for-video-and-audio-) +- [7.7 - Network vs Channel Example Cases](implementation.md#networkandchannel) -- [7.7 - Network vs Channel Example Cases](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#77-network-vs-channel-example-cases-) +- [7.8 - Counting Billable Events and Tracked Ads](implementation.md#counting) -- [7.8 - Counting Billable Events and Tracked Ads](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#78-counting-billable-events-and-tracked-ads-) +- [7.9 - Digital Out-Of-Home](implementation.md#dooh) -- [7.9 - Best Practices for server-side billing notifications](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#best-practices-for-server-side-billing-notifications-) +- [7.10 - Updated Video Signals](implementation.md#videosignals) -- [7.10 - Digital Out-Of-Home](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/OOH-Ammends/implementation.md#79---digital-out-of-home-) +- [7.11 - Guidance on the Use of Floors](implementation.md#floors) # Appendix A. Additional Information @@ -4184,6 +4255,12 @@ This appendix serves as an index of specification changes across 2.x versions. T 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 + Object: User added `consent` attribute (previously ext) + 5 Removed section (Enumerated Lists) All references now point to AdCOM 1.0 / OpenRTB 3.0 Lists diff --git a/assets/Screenshot (101).png b/assets/dynamic_pod.png similarity index 100% rename from assets/Screenshot (101).png rename to assets/dynamic_pod.png diff --git a/assets/Screenshot (100).png b/assets/hybrid_pod.png similarity index 100% rename from assets/Screenshot (100).png rename to assets/hybrid_pod.png diff --git a/assets/interstitial.gif b/assets/interstitial.gif new file mode 100644 index 0000000..13c1a3f Binary files /dev/null and b/assets/interstitial.gif differ diff --git a/assets/Screenshot (102).png b/assets/structured_pod.png similarity index 100% rename from assets/Screenshot (102).png rename to assets/structured_pod.png diff --git a/implementation.md b/implementation.md index 32f8996..8d4c462 100644 --- a/implementation.md +++ b/implementation.md @@ -1,9 +1,9 @@ -# 7. Implementation Notes +# 7. Implementation Notes The following section will provide brief notes on how certain objects and fields are to be interpreted and implemented. -## 7.1 - No-Bid Signaling +## 7.1 - No-Bid Signaling This section covers best practices for using the optional no-bid signaling. See the [List: No-Bid Reason Codes](https://github.com/InteractiveAdvertisingBureau/openrtb/blob/master/OpenRTB%20v3.0%20FINAL.md#list--no-bid-reason-codes-) in OpenRTB 3.0 for the enumerated list of no-bid reason codes. @@ -50,7 +50,7 @@ Recapping the typical impression flow through RTB, an ad will be requested by a Winning the auction, however, does not guarantee that the ad will be successfully delivered to the client or that it will meet viewability expectations. Furthermore, policies vary among exchanges as to the criteria for billing. Most consider an ad billable upon some form of delivery or rendering vs. the auction win alone. This aligns better with the buyer’s obvious goal of ensuring that the impressions they pay for are actually displayed. -Some exchanges attempt to facilitate this alignment by placing the win notice in the winning ad markup so that it can serve as both a win notice and rendering notice. This is neither endorsed nor prohibited by OpenRTB except that it precludes the exchange from accepting markup on the win notice return as described in Section 4.3.1. Similarly, many buyers use their own tracking URL placed within their ad markup to signal rendering independent of the OpenRTB auction win notice. In video specifically, VAST supports an impression tracking URL that is often used for billing and is always distinct from the auction win notice. +Some exchanges attempt to facilitate this alignment by placing the win notice in the winning ad markup so that it can serve as both a win notice and rendering notice. This is neither endorsed nor prohibited by OpenRTB except that it precludes the exchange from accepting markup on the win notice return as described in [Section 4.2.1](2.6.md#objectbidresponse). Similarly, many buyers use their own tracking URL placed within their ad markup to signal rendering independent of the OpenRTB auction win notice. In video specifically, VAST supports an impression tracking URL that is often used for billing and is always distinct from the auction win notice. To abstract the concept, let us refer to “*billing notice*” as the firing of some notification URL at the time when the clearing price of the impression will be booked as spend. This is irrespective of whether the actual OpenRTB win notice URL is delegated to the client for firing or some other tracking URL is used. @@ -58,9 +58,9 @@ For buyers, this billing notice is used to book progress toward spend goals and Bidders are strongly advised to track the time between the auction and the win and/or billing notices to ensure reasonable delays. If unreasonable delays are encountered frequently, bidders may elect to ignore such events and bring them to the attention of the exchange for resolution. Unfortunately, the sequence from ad request through the auction and finally to rendering and billing is fundamentally not transactional. There are simply too many parties, policies, and technologies involved and thus a good support relationship between exchange and buyer is still important. -The OpenRTB protocol does provide some real-time assistance, however. The `imp.exp` attribute (Section 3.2.4) in the bid request allows an exchange to provide guidance to bidders of the number of seconds that may elapse between the auction and the billing event. As usual, omitted means unknown. Bidders can then decide if they want to bid understanding the likely delay. Bidders are advised, however, to interpret this as guidance as opposed to a contract unless the exchange expresses otherwise since exchanges are not always in a position to make hard guarantees (e.g., the SDK within the client app may not be under the exchange’s control). +The OpenRTB protocol does provide some real-time assistance, however. The `imp.exp` attribute ([Section 3.2.4](2.6.md#objectimp)) in the bid request allows an exchange to provide guidance to bidders of the number of seconds that may elapse between the auction and the billing event. As usual, omitted means unknown. Bidders can then decide if they want to bid understanding the likely delay. Bidders are advised, however, to interpret this as guidance as opposed to a contract unless the exchange expresses otherwise since exchanges are not always in a position to make hard guarantees (e.g., the SDK within the client app may not be under the exchange’s control). -Similarly, the `bid.exp` attribute (Section 4.3.3) in the bid response allows the bidder to express the maximum number of seconds they are willing to tolerate between auction and billing notice. This allow the exchange to drop bids with expiration constraints it believes are likely to be violated. Bidders should not assume that a delayed billing notice greater than their specified bid expirations will not be billable. That is a policy and contract discussion between bidder and exchange and not imposed by OpenRTB. +Similarly, the `bid.exp` attribute ([Section 4.2.3](2.6.md#objectbid)) in the bid response allows the bidder to express the maximum number of seconds they are willing to tolerate between auction and billing notice. This allow the exchange to drop bids with expiration constraints it believes are likely to be violated. Bidders should not assume that a delayed billing notice greater than their specified bid expirations will not be billable. That is a policy and contract discussion between bidder and exchange and not imposed by OpenRTB. The following expiration times are offered as examples of reasonable delays based on the nature of the impression. These are only provided as rules of thumb. A more data-driven method of determining these times in specific situations is highly recommended. @@ -76,9 +76,9 @@ The following expiration times are offered as examples of reasonable delays base
Audio or video with server-side stitchingVery Long or Unknown
-## 7.3 - PMP & Direct Deals +## 7.3 - PMP & Direct Deals -**Best Practice Bidding Logic** +**Best Practice Bidding Logic** Receive request and parse;
Create empty bid list for response;
@@ -94,40 +94,40 @@ Return response list to exchange;
- Minimum viable is “1+1” bidding. - Ideal is “M+N” bidding. -**Warning** +**Warning** Returning only one bid when both Deal ID and open auction bids are valid creates problems. The exchange side may be configured by a publisher to prioritize all Deal ID bids above open auction bids, or to force a price auction between them with different floors by class of bid. There are multiple common practices that depend on how the publisher prefers to sell inventory with Deal ID. -**Policy Recommendations** +**Policy Recommendations** - A Deal ID should be utilized for any situation where the auction may be awarded to a bid not on the basis of price alone. Any prioritization of bids other than by price should have a Deal ID. - A Deal ID is recommended for all situations where a preferential floor may be assigned to a seat entity. -**Anti-Patterns** +**Anti-Patterns** The below is a set of anti-patterns that OpenRTB supporting platforms have observed in various attempts to implement Deal ID bidding logic. -**Subjecting Deal ID Bids to an internal auction on price** +**Subjecting Deal ID Bids to an internal auction on price** The ideal bidding logic describes a process of being liberal about sending bids. Deal ID bids may not be subject to a classic price auction. There may be an expectation that the buyer and seller want prioritization to achieve a larger objective: complete delivery of the Deal represented by the Deal ID. Thus any bidding logic that sorts Deal ID bids by price (with or without open marketplace bids) and truncates the list too aggressively can endanger the fulfillment of the Deal. -**Associating Deal ID to the wrong Object** +**Associating Deal ID to the wrong Object** A Deal ID should be treated as a “targeting token” associated to orders, line-items or campaigns. If the Deal ID is associated to a Seat/Buyer it may create an undesired application of the Deal ID too many active campaigns. Alternatively if it is associated to the Advertiser it may limit that entity to only a single Deal ID. -**Improper Handling of the Private vs Open Market Flag** +**Improper Handling of the Private vs Open Market Flag** The `pmp.private_auction` flag indicates that the seller is willing or not willing to accept open market bids (i.e., “all bidders are welcome”). If this flag is not read and interpreted correctly, bid responses may be invalid. Open market bids sent to a private impression auction may be rejected and should not have been exposed to all bidders. -**Improper handling of Seat IDs** +**Improper handling of Seat IDs** If Seat IDs are treated as a filter of eligible demand partners on an open market impression, this defeats the “all bidders are welcome” intention. -**Silently Applying Margin Discounts to Deal ID Bids** +**Silently Applying Margin Discounts to Deal ID Bids** With Deal ID buyers are sellers are communicating directly. The Exchange and Bidder become third- party automation platforms. If there are any automatic or silent discounts of bid prices (based upon margins or fees) set by either the exchange or the bidder, then the Deal may fail to function correctly. -**Use cases** +**Use cases** *Case-1: Open Trading Agreement with Buyer* @@ -216,7 +216,7 @@ DSPs should confirm with publishers whether it is permissible to respond with ad Some examples of these concepts follow: -**Bid Request** +**Bid Request** *Case-1: Skippable after N Seconds for All Creatives* @@ -266,7 +266,7 @@ In this case, the publisher will not impose skippability. Ads will only be skipp In this case, the `skip` attribute is omitted which indicates that exchange does not know if skippability will be imposed by the publisher. This may be the case, for example, when the exchange is not an SSP and thus may not have control or full knowledge of the publisher’s intentions. -**Bid Response** +**Bid Response** Consider Case-3 above, where the publisher does not impose skippability. If the ad markup itself will request skippability (e.g., via VPAID or VAST 3.0), then the bid must signal this intention. This is accomplished by including creative attribute 16 (i.e., Skippable) in the bid as shown below. If the markup is not going to request skippability, then this creative attribute should not be indicated. @@ -302,23 +302,23 @@ Please see the below resources for more details and framework specifications sho Starting in version 2.6, OpenRTB now supports ‘pod bidding’ for video and audio content streams. An ad pod is the term describing an ad break of the type you’d see in a TV-like viewing experience or hear on a radio stream. An ad pod typically contains one or more in-stream creative assets that play out contiguously within a stream of video or audio content. Ad podding features in OpenRTB 2.6 build on capabilities in previous versions for including multiple ad requests within a single bid request object to indicate those ad requests are in some way related. Pod bidding signals communicate additional information about the pod & impression opportunities within the pod such as the sequence of the ad impressions, total pod length, maximum # of ads within a pod, multiple pod associations, and more. -**Terminology** +**Terminology** Ad Slot: Space for an individual ad impression within a pod. Structured Pod: The seller offers a fully defined pod structure; the number of ad slots, their slot in the ad pod, and duration is pre-defined and static. -![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/864a56706b106eda94c03abefaa01dd43544864c/assets/Screenshot%20(102).png) +![](assets/structured_pod.png) Dynamic Pod: The seller offers a pod structure where the number of ads & the duration of each ad in the break is indeterminate, but the total duration and maximum number of ads are constrained. In other words, the total duration of the pod is known, but the number and durations of the individual ads within the break may not be defined ahead of time. This allows bidders more flexibility to optimize their selection of ads across the demand on their platform. -![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/864a56706b106eda94c03abefaa01dd43544864c/assets/Screenshot%20(101).png) +![](assets/dynamic_pod.png) Hybrid Pod: The seller offers a pod structure containing BOTH structured and dynamic components. In other words, the ad pod is composed of some combination of ad slots with predetermined durations, and ad slots constrained by a total duration & maximum number of ads. -![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/864a56706b106eda94c03abefaa01dd43544864c/assets/Screenshot%20(100).png) +![](assets/hybrid_pod.png) -**Recommendations** +**Recommendations** - Sellers should only indicate a `slotinpod` of 1, 2, or -1 if they can absolutely guarantee placement of an ad within the first or last slot of an ad pod. - Buyers should only indicate a `slotinpod` in response to a dynamic pod segment, including a dynamic component of a hybrid pod, if they only want to buy the first or last ad slot specifically @@ -330,7 +330,7 @@ Hybrid Pod: The seller offers a pod structure containing BOTH structured and dyn - Sellers are encouraged to offer dynamic pods when possible to allow bidders to source the most optimal demand from their platforms - Buyers should expect that final pod construction is done by the seller. Buyers who submit N bids for a particular pod may find that the seller selects anywhere between 0 to N of those bids to construct the pod that is shown to the user. Furthermore, the seller may co-mingle bids from other buyers in that pod. -**Pod bidding example scenarios** +**Pod bidding example scenarios** *“Structured” Ad Pod Request/Response* @@ -975,9 +975,9 @@ BidResponse -## 7.7 - Network vs Channel Example Cases +## 7.7 - Network vs Channel Example Cases -Starting in version 2.6, OpenRTB now supports Network and Channel objects. See 3.2.23 and 3.2.24 for details).While these examples are straight forward for traditional linear television, the options for CTV consumption warrant a few examples. +Starting in version 2.6, OpenRTB now supports Network and Channel objects. See [3.2.23](2.6.md#objectnetwork) and [3.2.24](2.6.md#objectchannel) for details).While these examples are straight forward for traditional linear television, the options for CTV consumption warrant a few examples. *Example 1*: A user viewing content on an internet connected device, on an app with multiple channel options (e.g. Discovery+ App > HGTV Channel/show) @@ -1001,7 +1001,7 @@ Starting in version 2.6, OpenRTB now supports Network and Channel objects. See < - Pluto is the network (also identified by `bundle`) - PlutoTV Spotlight is the channel -## 7.8 - Counting Billable Events and Tracked Ads +## 7.8 - Counting Billable Events and Tracked Ads There are multiple conventions for how to count billable events or tracked ads via OpenRTB, typically an impression or other such common metric. This section outlines the common ones, addresses common mistakes, and offers a comparison of the approaches. @@ -1009,7 +1009,7 @@ This section addresses technical methods available for implementers to consume t Implementers should discuss the definition of the billable event and the technical basis for counting it with their counterparties to determine a mutually acceptable approach. -**Overview of counting methodologies** +**Overview of counting methodologies** @@ -1044,7 +1044,7 @@ Implementers should discuss the definition of the billable event and the technic
-**Pixel in markup (banner ads)** +**Pixel in markup (banner ads)** This is the original convention for counting impressions/tracked ads; in this method, the OpenRTB specification itself does not address how to receive the events. The bidder self-embeds a tracking pixel in their HTML markup (i.e. an tag which makes a request to the bidder’s servers). When the client device loads the markup, it fires the pixel. @@ -1056,13 +1056,13 @@ For banner ads on web, this is a widely adopted approach to counting billable ev **BEST PRACTICE**: When it is possible to do so, exchanges should avoid using adm-based notifications as the determinant for billing events in the mobile app context, and instead use burl or an independent measurement approach (e.g. OMID), that is predicated upon an ad actually being displayed to the user. -**VAST event (video/audio)** +**VAST event (video/audio)** The VAST specification includes a provision for objects, which demand chain participants can use to request notifications when a billable event has occurred. The IAB prescribes that for video, the VAST event is the official signal that the billable event has occurred. Demand chain participants are discouraged from using billing notice URLs (burl) for video/audio transactions. -**Billing notice (“burl”)** +**Billing notice (“burl”)** Billing notice support was introduced in OpenRTB 2.5. In this scenario, **outside** of the ad markup itself, a “billing notice URL” is included in the bid response. A billing event is when a transaction results in a monetary charge from the publisher to an exchange, and subsequently from the exchange or other intermediary to one of their demand-side partners. This event is subject to publisher and exchange-specific business policies that should be conveyed clearly to their partners. For a DSP, this event signals that they can increment spend and deduct the remaining budget against the related campaign. The exchange conveys this event by invoking the URL provided by the demand source in the bid.burl attribute. @@ -1080,17 +1080,17 @@ Billing notice support was introduced in OpenRTB 2.5. In this scenario, **outsid For VAST video/audio, if the `bid.burl` attribute is specified, it should be fired at the same time as the VAST event. However, subtle technical issues may lead to additional discrepancies and bidders are cautioned to avoid this scenario. One option is for exchanges nearest a video supply source to use the VAST event as their billing signal and then use the billing notice URL (burl) as described. -**Native eventtrackers, imptrackers, jstrackers** +**Native eventtrackers, imptrackers, jstrackers** For native ads specifically, the OpenRTB Native specification offers options for including an impression tracking URL or script to be loaded at impression time. See the [OpenRTB Native](https://iabtechlab.com/standards/openrtb-native/) spec for more information. For native video, most platforms utilize the impression events within VAST for billing and other event notifications, rather than the structured tracking options available within the native spec. -**Win notice (“nurl”) – not a billable or tracked ad event** +**Win notice (“nurl”) – not a billable or tracked ad event** At first glance, an auction “win” and the associated win notice (`nurl`) field appears suitable as a proxy for billable/tracked ad counting. However, winning an auction does not guarantee that an impression will indeed be served, and in fact in many cases only a small percentage of won auctions will become impressions. This occurs because of downstream auctions (i.e. client-side header bidding), inability to play back media (in video and audio), etc. **Win notice URLs should never be used to count impressions or tracked ads.** -### Best Practices for server-side billing notifications +### Best Practices for server-side billing notifications In some cases, publishers or their vendors may choose to fire impression notifications from a server. This is very common in long-form video, which uses server-side ad insertion to coordinate the delivery and measurement of ads to a “thin” client on the user’s device. It is also common in mobile app, where the monetization SDK uses a server-side service to fire burl notifications. @@ -1483,32 +1483,32 @@ In DOOH, there can be significant delay between winning an auction, and the crea } ``` -## 7.10 - Updated Video Signals +## 7.10 - Updated Video Signals #### 7.10.1 - Examples #### 7.10.1.1 Instream Video: Pre-roll, mid-roll, and post-roll ads that are played before, during or after the streaming video content that the consumer has requested. Instream video must be set to “sound on” by default at player start, or have explicitly clear user intent to watch the video content. While there may be other content surrounding the player, the video content must be the focus of the user’s visit. It should remain the primary content on the page and the only video player in-view capable of audio when playing. If the player converts to floating/sticky subsequent ad calls should accurately convey the updated player size. -![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/assets/Instream.gif) +![](assets/Instream.gif) #### 7.10.1.2 Accompanying Content: Pre-roll, mid-roll, and post-roll ads that are played before, during, or after streaming video content. The video player loads and plays before, between, or after paragraphs of text or graphical content, and starts playing only when it enters the viewport. Accompanying content should only start playback upon entering the viewport. It may convert to a floating/sticky player as it scrolls off the page. -![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/assets/Accompanying%20Content.gif) +![](assets/Accompanying%20Content.gif) #### 7.10.1.3 Interstitial: Video ads that are played without video content. During playback, it must be the primary focus of the page and take up the majority of the viewport and cannot be scrolled out of view. This can be in placements like in-app video or slideshows. -Example file coming soon! +![](https://github.com/hillslatt/openrtb2.x/blob/develop/assets/interstitial.gif) #### 7.10.1.4 No Content/Standalone: Video ads that are played without streaming video content. This can be in placements like slideshows, native feeds, in-content or sticky/floating. -![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/assets/No%20Content_Standalone%20-%20Slideshow.gif) +![](assets/No%20Content_Standalone%20-%20Slideshow.gif) #### 7.10.2 - Using plcmt attribute in Object: Video -The release of updated definitions in AdCOM List: Plcmt Subtypes – Video and a new attribute (plcmt in Object: Video) to give publishers a way to signal video inventory in a way that more closely aligns with the updated ad format guidelines without breaking existing workstreams. +The release of updated definitions in AdCOM List: Plcmt Subtypes – Video and a new attribute (plcmt in [Object: Video](2.6.md#objectvideo)) to give publishers a way to signal video inventory in a way that more closely aligns with the updated ad format guidelines without breaking existing workstreams. Case 1: In-stream to Instream @@ -1534,3 +1534,23 @@ Here is an example ad request: “plcmt”: “4” } +## 7.11 - Guidance on the Use of Floors + +### 7.11.1 - History of Floors Fields + +In versions of OpenRTB prior to 2.6-202307, floors were provided in the `Imp` and `Deal` objects with the fields `imp.bidfloor` and `deal.bidfloor`, respectively. The initial release of OpenRTB 2.6 (PDF version, pre-GitHub) introduced the `mincpmpersec` field in the `Audio` and `Video` objects, which was the first time that floor-related information was associated with specific formats. + +As of OpenRTB 2.6-202307, `mincpmpersec` was also added to the `Deal` object, to allow sellers of audio or video supply to indicate to buyers the relationship between the duration of ads and their floor price in the ad server (in recognition of the fact that in audio/video ad serving, longer duration ads are typically priced higher than shorter ones). Concurrently, a new object serving a similar purpose, known as Duration Floors (see [Object: DurFloors](2.6.md#objectdurfloors)), was added to the `Audio` and `Video` objects, as well as the `Deal` object. The purpose of Duration Floors is to allow sellers to express a nonlinear relationship between the duration of creatives and the associated floor price of the impression opportunity. + +### 7.11.2 - How Sellers Should Provide Floor Guidance + +Sellers may specify floors in 3 locations within a BidRequest: +- `Imp` (via `imp.bidfloor`) +- `Video` or `Audio` (via `video.mincpmpersec` or `video.durfloors`, or `audio.mincpmpersec` or `audio.durfloors`) +- `Deal` (via `deal.bidfloor` or `deal.mincpmpersec` or `deal.durfloors`) + +In the `Video` and `Audio` objects, sellers must only include one form of floor guidance. In other words, a seller should either provide `mincpmpersec` or `durfloors`. Similarly, in the `Deal` object, a seller should either provide `mincpmpersec` or `durfloors` or `bidfloor`. + +### 7.11.2 - How Buyers Should Interpret Floor Guidance + +Buyers bidding with a specific Deal ID should use the floor guidance provided in the corresponding `Deal` object. If there is no floor guidance in the `Deal` object or the buyer is bidding on an Open Market impression opportunity, the buyer should use the floor guidance provided in the corresponding `Video` or `Audio` object to inform their bids. Finally, if no floors are provided in the `Video` or `Audio` objects or the buyer is bidding on a Native or Banner impression opportunity, the buyer should use the floor guidance provided in the `Imp` object. \ No newline at end of file