From 934c24fd8297956ca3a48a22b56f095f6e19d2ac Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 13:23:36 +0100 Subject: [PATCH 01/64] Update 2.6.md First test update, Key OOH contributors --- 2.6.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index 0fe147e..f79c0f1 100644 --- a/2.6.md +++ b/2.6.md @@ -6,7 +6,7 @@ The IAB Technology Laboratory is a nonprofit research and development consortium ### 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, Café Media; Aron Schatz, Director Product Management, Double Verify; Jake Jolly, Product Manager, Google; Amit Shetty, VP Product, Pixalate +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, Café Media; 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; Liam Whiteside, Head Of Ad Technology, Global; Chris Coupland, Platform Operations Manager, Centro; ### IAB Tech Lab Lead: From 3d1c5fa518b41f40bc8696871fe0d3f83a165d1a Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 14:11:51 +0100 Subject: [PATCH 02/64] imp.qty qty added to the imp object --- 2.6.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/2.6.md b/2.6.md index f79c0f1..bf2c9b4 100644 --- a/2.6.md +++ b/2.6.md @@ -972,6 +972,11 @@ Recommended for video and/or apps. integer Advisory as to the number of seconds that may elapse between the auction and the actual impression. + + qty + object + A means of passing a multiplier in the bid request, representing the total quantity of impressions + ext object @@ -979,6 +984,7 @@ Recommended for video and/or apps. + From 101c3c897d81754241124531396cd0e9db869b1e Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 14:14:47 +0100 Subject: [PATCH 03/64] imp.qty text update --- 2.6.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index bf2c9b4..746b990 100644 --- a/2.6.md +++ b/2.6.md @@ -975,7 +975,7 @@ Recommended for video and/or apps. qty object - A means of passing a multiplier in the bid request, representing the total quantity of impressions + 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 ext From d5a6affa0360366e8102fa1877fdee29391d72d4 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 14:29:28 +0100 Subject: [PATCH 04/64] Object Qty V1 --- 2.6.md | 31 ++++++++++++++++++++++++++++++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index 746b990..31ef062 100644 --- a/2.6.md +++ b/2.6.md @@ -975,7 +975,7 @@ Recommended for video and/or apps. qty object - 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 + 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. ext @@ -2801,6 +2801,35 @@ Further identification based on [User-Agent Client Hints](https://wicg.github.io +### 3.2.30 - Object: Qty + +A programmatic impression is often referred to as a ‘spot’ in digital out-of-home and CTV, with an impression being a unique member of the audience viewing it. Therefore, a standard means of passing a multiplier in the bid request, representing the total quantity of impressions, is required. This object includes the impression multiplier, and describes the source of the multiplier value. + + + + + + + + + + + + + + + + + + + + + + + + +
Attribute        Type                    Description
multiplierfloat; 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.
sourcetypeinteger; recommendedThe source type of the quantity measurement, ie. publisher. Refer to list .........
vendorstring; required if sourcetype is present and type = 1The top level business domain name of the measurement vendor providing the quantity measurement.
+ # 4. Bid Response Specification From 7b18e5cd235e56b604897f4eb9b7aae06382b03e Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 14:47:47 +0100 Subject: [PATCH 05/64] obj qty link --- 2.6.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/2.6.md b/2.6.md index 31ef062..42a06e8 100644 --- a/2.6.md +++ b/2.6.md @@ -2801,7 +2801,7 @@ Further identification based on [User-Agent Client Hints](https://wicg.github.io -### 3.2.30 - Object: Qty +### 3.2.31 - Object: Qty A programmatic impression is often referred to as a ‘spot’ in digital out-of-home and CTV, with an impression being a unique member of the audience viewing it. Therefore, a standard means of passing a multiplier in the bid request, representing the total quantity of impressions, is required. This object includes the impression multiplier, and describes the source of the multiplier value. @@ -2819,7 +2819,7 @@ A programmatic impression is often referred to as a ‘spot’ in digital out-of sourcetype integer; recommended - The source type of the quantity measurement, ie. publisher. Refer to list ......... + The source type of the quantity measurement, ie. publisher. Refer to the list [Multiplier Measurement Source Types](https://github.com/knittingmedia/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md#list-multiplier-measurement-source-types-) vendor From 231b3577898816cf6bc5275363ff06f2085fc3bd Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 14:51:18 +0100 Subject: [PATCH 06/64] index update --- 2.6.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index 42a06e8..5a6c79b 100644 --- a/2.6.md +++ b/2.6.md @@ -132,6 +132,8 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [3.2.30 - Object: BrandVersion](#objectbrandversion) + - [3.2.31 - Object: Qty](#objectqty) + ## [4. Bid Response Specification](#bidresponsespec) - [4.1 - Object Model](#4.2objectmodel) @@ -2819,7 +2821,7 @@ A programmatic impression is often referred to as a ‘spot’ in digital out-of sourcetype integer; recommended - The source type of the quantity measurement, ie. publisher. Refer to the list [Multiplier Measurement Source Types](https://github.com/knittingmedia/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 listt (https://github.com/knittingmedia/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md#list-multiplier-measurement-source-types-) vendor From 69d313007321e5096857bd108d0c2152b6144569 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 14:52:04 +0100 Subject: [PATCH 07/64] link tidy --- 2.6.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index 5a6c79b..ea84697 100644 --- a/2.6.md +++ b/2.6.md @@ -2821,7 +2821,7 @@ A programmatic impression is often referred to as a ‘spot’ in digital out-of sourcetype integer; recommended - The source type of the quantity measurement, ie. publisher. Refer to the listt (https://github.com/knittingmedia/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 https://github.com/knittingmedia/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md#list-multiplier-measurement-source-types- vendor From f2b65766604f1a433b85ab9a7e5ee46ecc160d30 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 15:00:15 +0100 Subject: [PATCH 08/64] imp:etime --- 2.6.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/2.6.md b/2.6.md index ea84697..565a9e3 100644 --- a/2.6.md +++ b/2.6.md @@ -974,6 +974,11 @@ Recommended for video and/or apps. integer Advisory as to the number of seconds that may elapse between the auction and the actual impression. + + etime + integer + The exposure time in seconds per view that the creative will be displayed before refreshing to the next creative. + qty object From a69d0d19a052bcaea14cfcbe63497373321e2434 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 15:16:43 +0100 Subject: [PATCH 09/64] DOOH object --- 2.6.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/2.6.md b/2.6.md index 565a9e3..58233e7 100644 --- a/2.6.md +++ b/2.6.md @@ -134,6 +134,8 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [3.2.31 - Object: Qty](#objectqty) + - [3.2.31 - Object: DOOH](#objectdooh) + ## [4. Bid Response Specification](#bidresponsespec) - [4.1 - Object Model](#4.2objectmodel) @@ -2838,6 +2840,22 @@ A programmatic impression is often referred to as a ‘spot’ in digital out-of +### 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. + +| 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, 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 8.3.1 | +| publisher | object | Details about the publisher of the placement. | +| domain | string | Domain of the inventory (ads.txt) owner (e.g., “mysite.foo.com”) | +| keywords | string | Comma separated list of keywords about the DOOH placement. | +| content | object | Details about the Content (Section x.x.x) within the DOOH placement. | +| ext | object | Placeholder for exchange-specific extensions to OpenRTB. | + + # 4. Bid Response Specification RTB responses contain bids that reference specific impressions within a bid request. Bids are in essence an offer to buy. The bid response consists of the top-level bid response object and optional objects that depict the specific bids. An empty HTTP response constitutes a no-bid and is in fact the most bandwidth friendly form of this signal although returning a response with a “no-bid reason” is encouraged. A malformed response or a response that contains no actual bids will also be interpreted as no-bid. From 4d882f45c7004aa8124604117107d0d870d9d207 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 15:17:12 +0100 Subject: [PATCH 10/64] 3.2.32 - Object: DOOH --- 2.6.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index 58233e7..e89713b 100644 --- a/2.6.md +++ b/2.6.md @@ -134,7 +134,7 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [3.2.31 - Object: Qty](#objectqty) - - [3.2.31 - Object: DOOH](#objectdooh) + - [3.2.32 - Object: DOOH](#objectdooh) ## [4. Bid Response Specification](#bidresponsespec) From 3438a018a152e9bda83428f1d1fb1a5f011a69e8 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 15:19:29 +0100 Subject: [PATCH 11/64] dooh table fix --- 2.6.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/2.6.md b/2.6.md index e89713b..c89ef38 100644 --- a/2.6.md +++ b/2.6.md @@ -2844,16 +2844,17 @@ A programmatic impression is often referred to as a ‘spot’ in digital out-of 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. -| 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, 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 8.3.1 | -| publisher | object | Details about the publisher of the placement. | -| domain | string | Domain of the inventory (ads.txt) owner (e.g., “mysite.foo.com”) | -| keywords | string | Comma separated list of keywords about the DOOH placement. | -| content | object | Details about the Content (Section x.x.x) within the DOOH placement. | -| ext | object | Placeholder for exchange-specific extensions to OpenRTB. | +|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, 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 8.3.1 | +|publisher |object |Details about the publisher of the placement. | +|domain |string |Domain of the inventory (ads.txt) owner (e.g., “mysite.foo.com”) | +|keywords |string |Comma separated list of keywords about the DOOH placement. | +|content |object |Details about the Content (Section x.x.x) within the DOOH placement. | +|ext |object |Placeholder for exchange-specific extensions to OpenRTB. | # 4. Bid Response Specification From bd839f3f0184994be6c785bd414ee46950cf64aa Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 15:33:40 +0100 Subject: [PATCH 12/64] dooh object link tidy --- 2.6.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/2.6.md b/2.6.md index c89ef38..a202e5e 100644 --- a/2.6.md +++ b/2.6.md @@ -2848,8 +2848,8 @@ This object should be included if the ad supported content is a Digital Out-Of-H |------------|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |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, 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 8.3.1 | +|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/knittingmedia/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 (ads.txt) owner (e.g., “mysite.foo.com”) | |keywords |string |Comma separated list of keywords about the DOOH placement. | From d907b7ae01adda2f6dd343d8ea327bf84c0c9210 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 15:36:16 +0100 Subject: [PATCH 13/64] Content tidy --- 2.6.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index a202e5e..e44f8fa 100644 --- a/2.6.md +++ b/2.6.md @@ -2853,7 +2853,7 @@ This object should be included if the ad supported content is a Digital Out-Of-H |publisher |object |Details about the publisher of the placement. | |domain |string |Domain of the inventory (ads.txt) owner (e.g., “mysite.foo.com”) | |keywords |string |Comma separated list of keywords about the DOOH placement. | -|content |object |Details about the Content (Section x.x.x) within the DOOH placement. | +|content |object |Details about the Content within the DOOH placement. | |ext |object |Placeholder for exchange-specific extensions to OpenRTB. | From 20a9581b2d17be4953c14a152152c294d7d70e82 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 15:41:59 +0100 Subject: [PATCH 14/64] AUCTION_MULTIPLIER macro --- 2.6.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/2.6.md b/2.6.md index e44f8fa..8dd7eff 100644 --- a/2.6.md +++ b/2.6.md @@ -3292,6 +3292,12 @@ These same substitution macros can also be placed in the ad markup. The exchange + + ${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. + + + From 70834590069acc324aca68caf73181180ec07863 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 16:00:24 +0100 Subject: [PATCH 15/64] 7.9 --- implementation.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/implementation.md b/implementation.md index 93c0eb4..7aaa9c6 100644 --- a/implementation.md +++ b/implementation.md @@ -1106,3 +1106,8 @@ The following best practice is derived from the [VAST 4.2 spec](https://iabtechl These HTTP headers allow recipients of impression notifications to run anti-IVT checks using metadata about the end user device, rather than the server itself. **BEST PRACTICE**: When firing impression notifications via HTTP request from the server-side, the notifier should establish an [ads.cert Call Sign](https://iabtechlab.com/wp-content/uploads/2021/09/2-ads-cert-call-signs-pc.pdf) and make use of the [ads.cert Authenticated Connections protocol](https://iabtechlab.com/wp-content/uploads/2021/09/3-ads-cert-authenticated-connections-pc.pdf) to cryptographically sign notifications. This allows recipients of impression notifications, who’ve established ads.cert Call Signs of their own, to authenticate the sender for anti-fraud purposes. + + +## 7.9 - Digital Out-Of-Home + +DOOH Implementation Notes From 3befc0dd7b1e27fb531fb9a12e7df06e23a951c8 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 16:08:13 +0100 Subject: [PATCH 16/64] WIP 7.9 --- implementation.md | 49 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 48 insertions(+), 1 deletion(-) diff --git a/implementation.md b/implementation.md index 7aaa9c6..9c2e956 100644 --- a/implementation.md +++ b/implementation.md @@ -1110,4 +1110,51 @@ These HTTP headers allow recipients of impression notifications to run anti-IVT ## 7.9 - Digital Out-Of-Home -DOOH Implementation Notes +This section details the unique differences between trading the online world of digital display and real-world aspects of Outdoor display and links to the key objects that enable this media to be traded in OpenRTB. + +### 7.9.1 - Multiple/Variable Impressions +The OpenRTB trading method was built around the assumption that a targeted user holds one device and is served an ad as they visit a webpage e.g. One impression = One user. +OOH Media is a medium where one advert play (a spot) is viewable by everyone who is in the vicinity of the advert being displayed e.g. One ad display = multiple viewers/users (this number can be both greater than *or* less than 1 - due to numbers being based on statistical modeling, fractional values (e.g. .32 impressions per ad display) are common. These rates are also variable as they may be based on hourly-adjusted projections, or real-time sensor data. + +Multiplying by decimal values (especially with a CPM) can lead to discrepancies when the ‘buy side’ and ‘sell side’ truncate decimal places. Measures need to be taken to avoid this at an account level. + +### 7.9.2 Highly Variable Physical Size +The majority of devices that are served ads via OpenRTB are of a size that one person can hold or lean into. In OOH media the advert can be traded and served on anything from the size of a shelf edge label to the size of multiple football pitches. This far exceeds the size range of anything that can be held in the viewer's hand or hung on their living room wall. + +The size and direction of an OOH display not only affects the size of the audience that could see it, but also changes the chances of the audience that will see the advertisement being served. + +A common trait with both OOH and digital display ads is that there are a wide variety of sizes, resolutions and aspect ratios to be accommodated as the physical displays ‘build into’ physical spaces vary, and may contain additional content (e.g. tickers, application, labels) that cause ad slot sizes to vary. + +### 7.9.3 Private Networks / Geo-Location Information +The majority of commercial DOOH digital displays sit on ‘walled garden’ private ip networks. This protects the displays from a wide spectrum of internet security issues, vulnerabilities and attacks. + +This can lead to 3rd party ad serving, cookies and http event logging service being constricted by the ‘safe-lists’ of urls allowed through the ‘walled garden’ security. + +Many Media Owners / Publishers therefore publish proprietary ‘1st Party’ playout reports and confirmations and use ‘1st Party’ ad servers and/or CMS systems. + +The use of private ip networks also means that DSPs are not able to use their normal IP address geolocation techniques to get information about where ads are delivered - though publisher-reported locations (e.g. lat/lon, geo information like address, zip, region) are almost always available. In the case of moving media (e.g. taxi-top displays, bus panels, etc.) near-real time GPS-derived information is common. + +### 7.9.4 Non-Persistent Connections / Longer-Than-Realtime Delays +Most DOOH display panels in urban and remote connections rely on cellular networks for their network connectivity. Whilst a Media Owner may have their own private network with a telecoms provider, the network is still at the mercy of congestion on the local cell tower. Over subscription to cell towers at peak times and locations leads to the DOOH display panels having non-persistent internet connection. + +To mitigate this, some DOOH Media Owners and/or publishers employ ‘forward and store’ technology and give a lead time tolerance from bid request to display. Bids may be requested in advance (to allow pre-buffering or populate “playlists'' on devices, and the confirmation of playback may be delayed due to log collection or processing within publisher systems + +The current industry accepted lead time from ‘bid confirmation’ to ‘display’ can be up to 1 to 2 hours. + +### 7.9.5 Proprietary Device Attributes +Unlike the TV, Tablet and Mobile phone market, there are no dominant global brands supplying digital OOH screen technology to the market. Media Owners and/or Publishers source their own screen technology from a wide variety of manufacturers, technologies and installation partners resulting in each network having its own proprietary device types,identifiers, and other attributes such as user agent strings. + +Some countries have attempted to create standards for describing the shape, size and format of the digital units, but to date there is no recognised global standard for identifying a digital out of home device or the users who it may reach. + +In the case of user agents, oftentimes non-standard strings are used by Media Owners, which has been known to plague device detection and traffic protection systems. It is advised that Media Owners comply with the HTTP user agent standards set forth by the IETF and submit their user agents to the IAB Spiders and Bots List using the "Submit here" button on this page. + +### 7.9.6 Commercially Critical Brand Safety +One bad advert being served at one time to one person is survivable. +One bad advert served at one time to 1000’s of people in a public place will lead to a Media Owner and/or Publisher risking their contract/permission to serve ads to networks of screens. + +All ads being served on large commercial networks need to be manually pre-approved (typically involving human, visual review) by the publisher (and in some cases other 3rd parties e.g. venue landlords) before any bids can be accepted for display. + +This means typical lead times for creative approval are on the order of “working days” - though they may be expedited through operational processes. It also means many publishers and networks will prohibit creative rotation, dynamic content, or changes post-approval - pending further review. 3rd-Party AdServing (3PAS) support (and support for HTML) is possible, but not guaranteed - including limitations of variations of typical banner ads like dynamic content, animation, or DCO. + +For the above reasons, use of IAB Ad Management API (https://github.com/InteractiveAdvertisingBureau/AdManagementAPI/blob/master/Ad%20Management%20API%201.0%20FINAL.md) for creative submission to DOOH exchanges is strongly recommended, though many SSPs may have proprietary extensions to allow submitting ads to specific individual publishers. + From 0ab9a0c8e785ed6641aab5c4b6569bf23d62348b Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 16:10:52 +0100 Subject: [PATCH 17/64] words --- implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/implementation.md b/implementation.md index 9c2e956..8d75d83 100644 --- a/implementation.md +++ b/implementation.md @@ -1110,7 +1110,7 @@ These HTTP headers allow recipients of impression notifications to run anti-IVT ## 7.9 - Digital Out-Of-Home -This section details the unique differences between trading the online world of digital display and real-world aspects of Outdoor display and links to the key objects that enable this media to be traded in OpenRTB. +This section details the unique differences between trading the online world of digital display and real-world aspects of Digital Out-Of-Home (DOOH) media. Each sub section links to the key objects that enable DOOH to be traded using the OpenRTB standard. ### 7.9.1 - Multiple/Variable Impressions The OpenRTB trading method was built around the assumption that a targeted user holds one device and is served an ad as they visit a webpage e.g. One impression = One user. From 2ff91c8028ec9420359d165a1beef3ec794bd973 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 16:41:09 +0100 Subject: [PATCH 18/64] Sample Implementation Text --- implementation.md | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/implementation.md b/implementation.md index 8d75d83..5142974 100644 --- a/implementation.md +++ b/implementation.md @@ -1117,15 +1117,20 @@ The OpenRTB trading method was built around the assumption that a targeted user OOH Media is a medium where one advert play (a spot) is viewable by everyone who is in the vicinity of the advert being displayed e.g. One ad display = multiple viewers/users (this number can be both greater than *or* less than 1 - due to numbers being based on statistical modeling, fractional values (e.g. .32 impressions per ad display) are common. These rates are also variable as they may be based on hourly-adjusted projections, or real-time sensor data. Multiplying by decimal values (especially with a CPM) can lead to discrepancies when the ‘buy side’ and ‘sell side’ truncate decimal places. Measures need to be taken to avoid this at an account level. + +The OpenRTB imp object now includes a qty object that enables the multiplier dimension -### 7.9.2 Highly Variable Physical Size +### 7.9.2 Unique Device Characterisitcs + +#### 7.9.2.1 Highly Variable Physical Size The majority of devices that are served ads via OpenRTB are of a size that one person can hold or lean into. In OOH media the advert can be traded and served on anything from the size of a shelf edge label to the size of multiple football pitches. This far exceeds the size range of anything that can be held in the viewer's hand or hung on their living room wall. The size and direction of an OOH display not only affects the size of the audience that could see it, but also changes the chances of the audience that will see the advertisement being served. A common trait with both OOH and digital display ads is that there are a wide variety of sizes, resolutions and aspect ratios to be accommodated as the physical displays ‘build into’ physical spaces vary, and may contain additional content (e.g. tickers, application, labels) that cause ad slot sizes to vary. + -### 7.9.3 Private Networks / Geo-Location Information +#### 7.9.2.2 Private Networks / Geo-Location Information The majority of commercial DOOH digital displays sit on ‘walled garden’ private ip networks. This protects the displays from a wide spectrum of internet security issues, vulnerabilities and attacks. This can lead to 3rd party ad serving, cookies and http event logging service being constricted by the ‘safe-lists’ of urls allowed through the ‘walled garden’ security. @@ -1134,21 +1139,36 @@ Many Media Owners / Publishers therefore publish proprietary ‘1st Party’ pla The use of private ip networks also means that DSPs are not able to use their normal IP address geolocation techniques to get information about where ads are delivered - though publisher-reported locations (e.g. lat/lon, geo information like address, zip, region) are almost always available. In the case of moving media (e.g. taxi-top displays, bus panels, etc.) near-real time GPS-derived information is common. -### 7.9.4 Non-Persistent Connections / Longer-Than-Realtime Delays +#### 7.9.2.3 Non-Persistent Connections / Longer-Than-Realtime Delays Most DOOH display panels in urban and remote connections rely on cellular networks for their network connectivity. Whilst a Media Owner may have their own private network with a telecoms provider, the network is still at the mercy of congestion on the local cell tower. Over subscription to cell towers at peak times and locations leads to the DOOH display panels having non-persistent internet connection. To mitigate this, some DOOH Media Owners and/or publishers employ ‘forward and store’ technology and give a lead time tolerance from bid request to display. Bids may be requested in advance (to allow pre-buffering or populate “playlists'' on devices, and the confirmation of playback may be delayed due to log collection or processing within publisher systems The current industry accepted lead time from ‘bid confirmation’ to ‘display’ can be up to 1 to 2 hours. -### 7.9.5 Proprietary Device Attributes +#### 7.9.2.4 Proprietary Device Attributes Unlike the TV, Tablet and Mobile phone market, there are no dominant global brands supplying digital OOH screen technology to the market. Media Owners and/or Publishers source their own screen technology from a wide variety of manufacturers, technologies and installation partners resulting in each network having its own proprietary device types,identifiers, and other attributes such as user agent strings. Some countries have attempted to create standards for describing the shape, size and format of the digital units, but to date there is no recognised global standard for identifying a digital out of home device or the users who it may reach. In the case of user agents, oftentimes non-standard strings are used by Media Owners, which has been known to plague device detection and traffic protection systems. It is advised that Media Owners comply with the HTTP user agent standards set forth by the IETF and submit their user agents to the IAB Spiders and Bots List using the "Submit here" button on this page. -### 7.9.6 Commercially Critical Brand Safety +#### 7.9.2.5 Key Object Attributes To Use For DOOH Device Reference in OpenRTB + +| Object Reference | Type | Implementation Guidance | +| ----------------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | +| device.geo | object | Since ip may not be available, geo location  lat / lon field is required for DOOH transactions. geo.type is recommended. | +| device.devicetype | string array | Digital out of home devices shall be identified as type 8. | +| device.ppi | integer | Screen dimensions in inches can be calculated using ppi, w and h. | +| device.ifa | string | A device ID used to identify an individual out of home device. | +| device.ifa\_type | string | For DOOH this is usually given as "ppid" to show this is a publisher-provided device id or "sspid" to show this is an exchange-provided device id | +| device.eids | object | Used to send additional identifiers. e.g. geopath.org or oohspace.co.uk or to signal the ifa provider. See AdCom eids | +| imp.video.boxingallowed | integer | For DOOH, when boxingallowed = 0, the video aspect ratio should strictly match that of the placement, as determined by the video w and h fields. | +| imp.dt | float | Timestamp when the item is estimated to be fulfilled (e.g. when a DOOH impression will be displayed) in Unix format (i.e., milliseconds since the epoch). | +| imp.etime | integer | The exposure time in seconds per view that the creative will be displayed before refreshing to the next creative. | + + +### 7.9.3 Commercially Critical Brand Safety One bad advert being served at one time to one person is survivable. One bad advert served at one time to 1000’s of people in a public place will lead to a Media Owner and/or Publisher risking their contract/permission to serve ads to networks of screens. From 96aa28b49bb5a6633689df709256924a22d937bf Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 16:50:32 +0100 Subject: [PATCH 19/64] Example space --- implementation.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/implementation.md b/implementation.md index 5142974..a36c105 100644 --- a/implementation.md +++ b/implementation.md @@ -1178,3 +1178,6 @@ This means typical lead times for creative approval are on the order of “worki For the above reasons, use of IAB Ad Management API (https://github.com/InteractiveAdvertisingBureau/AdManagementAPI/blob/master/Ad%20Management%20API%201.0%20FINAL.md) for creative submission to DOOH exchanges is strongly recommended, though many SSPs may have proprietary extensions to allow submitting ads to specific individual publishers. + +### 7.9.4 - DOOH Example Scenarios + From 0efdf8a59194525bf5e947fe35c8ed054305c085 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 17:00:47 +0100 Subject: [PATCH 20/64] references --- implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/implementation.md b/implementation.md index a36c105..f5de01a 100644 --- a/implementation.md +++ b/implementation.md @@ -1110,7 +1110,7 @@ These HTTP headers allow recipients of impression notifications to run anti-IVT ## 7.9 - Digital Out-Of-Home -This section details the unique differences between trading the online world of digital display and real-world aspects of Digital Out-Of-Home (DOOH) media. Each sub section links to the key objects that enable DOOH to be traded using the OpenRTB standard. +This section details the unique differences between trading the online world of digital display and real-world aspects of Digital Out-Of-Home (DOOH) media. Each sub section references the key objects that enable DOOH to be traded using the OpenRTB standard. ### 7.9.1 - Multiple/Variable Impressions The OpenRTB trading method was built around the assumption that a targeted user holds one device and is served an ad as they visit a webpage e.g. One impression = One user. From 2943fc913846092f3a6a89956e289327823e7a26 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 17:05:44 +0100 Subject: [PATCH 21/64] updated table --- implementation.md | 31 ++++++++++++++++++++----------- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/implementation.md b/implementation.md index f5de01a..67fd29b 100644 --- a/implementation.md +++ b/implementation.md @@ -1155,17 +1155,26 @@ In the case of user agents, oftentimes non-standard strings are used by Media Ow #### 7.9.2.5 Key Object Attributes To Use For DOOH Device Reference in OpenRTB -| Object Reference | Type | Implementation Guidance | -| ----------------------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | -| device.geo | object | Since ip may not be available, geo location  lat / lon field is required for DOOH transactions. geo.type is recommended. | -| device.devicetype | string array | Digital out of home devices shall be identified as type 8. | -| device.ppi | integer | Screen dimensions in inches can be calculated using ppi, w and h. | -| device.ifa | string | A device ID used to identify an individual out of home device. | -| device.ifa\_type | string | For DOOH this is usually given as "ppid" to show this is a publisher-provided device id or "sspid" to show this is an exchange-provided device id | -| device.eids | object | Used to send additional identifiers. e.g. geopath.org or oohspace.co.uk or to signal the ifa provider. See AdCom eids | -| imp.video.boxingallowed | integer | For DOOH, when boxingallowed = 0, the video aspect ratio should strictly match that of the placement, as determined by the video w and h fields. | -| imp.dt | float | Timestamp when the item is estimated to be fulfilled (e.g. when a DOOH impression will be displayed) in Unix format (i.e., milliseconds since the epoch). | -| imp.etime | integer | The exposure time in seconds per view that the creative will be displayed before refreshing to the next creative. | +| Object Reference | Type | Implementation Guidance | +| ----------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| device.geo | object | Since ip may not be available, geo location  lat / lon field is required for DOOH transactions. geo.type is recommended. | +| device.devicetype | string array | Digital out of home devices shall be identified as type 8. | +| device.ppi | integer | Screen dimensions in inches can be calculated using ppi, w and h. | +| device.ifa | string | A device ID used to identify an individual out of home device. | +| device.ifa\_type | string | For DOOH this is usually given as "ppid" to show this is a publisher-provided device id or "sspid" to show this is an exchange-provided device id | +| device.eids | object | Used to send additional identifiers. e.g. geopath.org or oohspace.co.uk or to signal the ifa provider. See AdCom eids | +| imp.video.boxingallowed | integer | For DOOH, when boxingallowed = 0, the video aspect ratio should strictly match that of the placement, as determined by the video w and h fields. | +| imp.dt | float | Timestamp when the item is estimated to be fulfilled (e.g. when a DOOH impression will be displayed) in Unix format (i.e., milliseconds since the epoch). | +| imp.etime | integer | The exposure time in seconds per view that the creative will be displayed before refreshing to the next creative. | +| dooh.id | string; recommended | Exchange provided id for a placement or logical grouping of placements. | +| dooh.name | string | Name of the dooh placement. | +| dooh.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, OpenOOH Venue Taxonomy is assumed.](https://github.com/openooh/venue-taxonomy/blob/main/specification-1.0.md) | +| dooh.venuetypetax | integer; default 1 | The venue taxonomy in use. Refer to list 8.3.1 | +| dooh.publisher | object | Details about the publisher of the placement. | +| dooh.domain | string | Domain of the inventory (ads.txt) owner (e.g., “mysite.foo.com”) | +| dooh.keywords | string | Comma separated list of keywords about the DOOH placement. | +| dooh.content | object | Details about the Content within the DOOH placement. | +| dooh.ext | object | Placeholder for exchange-specific extensions to OpenRTB. | ### 7.9.3 Commercially Critical Brand Safety From f22c88bef92a3db0280f657faa6a637cb3fb8c33 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Thu, 27 Oct 2022 17:07:41 +0100 Subject: [PATCH 22/64] add table link --- implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/implementation.md b/implementation.md index 67fd29b..c691efc 100644 --- a/implementation.md +++ b/implementation.md @@ -1169,7 +1169,7 @@ In the case of user agents, oftentimes non-standard strings are used by Media Ow | dooh.id | string; recommended | Exchange provided id for a placement or logical grouping of placements. | | dooh.name | string | Name of the dooh placement. | | dooh.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, OpenOOH Venue Taxonomy is assumed.](https://github.com/openooh/venue-taxonomy/blob/main/specification-1.0.md) | -| dooh.venuetypetax | integer; default 1 | The venue taxonomy in use. Refer to list 8.3.1 | +| dooh.venuetypetax | integer; default 1 | The venue taxonomy in use. Refer to list https://github.com/knittingmedia/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md#list-venue-taxonomies- | | dooh.publisher | object | Details about the publisher of the placement. | | dooh.domain | string | Domain of the inventory (ads.txt) owner (e.g., “mysite.foo.com”) | | dooh.keywords | string | Comma separated list of keywords about the DOOH placement. | From 62b7b440ff1e8fc39b60f96e91f5ff6ba5482e64 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Fri, 28 Oct 2022 11:37:34 +0100 Subject: [PATCH 23/64] Code Examples V1 --- implementation.md | 286 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 285 insertions(+), 1 deletion(-) diff --git a/implementation.md b/implementation.md index c691efc..db5f130 100644 --- a/implementation.md +++ b/implementation.md @@ -1189,4 +1189,288 @@ For the above reasons, use of IAB Ad Management API (https://github.com/Interact ### 7.9.4 - DOOH Example Scenarios - + +## 7.9.4.1 - Banner Bid Request + +```javascript +{ + "$schema": "https://raw.githubusercontent.com/knittingmedia/OpenRTB/main/Schema/OpenRTB_OOH_V1.json", + "id": "162059897743978051070", + "at": 1, + "imp": [ + { + "id": "007", + "secure": 1, + "exp": 360, + "bidfloor": 5.0, + "bidfloorcur": "GBP", + "banner": { + "w": 1080, + "h": 1920, + "format": [ + { + "w": 1080, + "h": 1920 + }, + { + "w": 720, + "h": 1366 + } + ], + "mimes": [ + "image/jpg", + "image/png", + "text/html" + ] + }, + "pmp": { + "private_auction": 0, + "deals": [ + { + "id": "123", + "at": 1, + "bidfloor": 4.50 + }, + { + "id": "333", + "at": 1, + "bidfloor": 3.00 + }, + { + "id": "444", + "at": 1, + "bidfloor": 2.00 + } + ] + }, + "dt": 12345670, + "etime": 10, + "qty": { + "multiplier": 14.2, + "sourcetype": 1, + "vendor": "route.org.uk" + } + } + ], + "device": { + "geo": { + "lat": 0.0001, + "long": -0.1235, + "lastfix": 0 + }, + "devicetype": 8, + "w": 1080, + "h": 1920, + "ppi": 72, + "ifa": "1235461904", + "ifa_type": "ppid", + "eids": [ + { + "source": "oohspace.co.uk", + "uids": [ + { + "atype": 501, + "id": "1235461904" + } + ] + } + ] + }, + "dooh": { + "content": {}, + "id": "15790", + "keywords": "Roadside, Billboard, D96", + "name": "This", + "publisher": { + "id": "G1", + "name": "Global" + }, + "domain": "global.com", + "venuetax": 1, + "venuetypeid": 30101 + }, + "cur": [ + "GBP" + ] +} +``` + +## 7.9.4.1 - Banner Bid Response + +```javascript +{ + "$schema": "https://raw.githubusercontent.com/knittingmedia/OpenRTB/main/Schema/OpenRTB_OOH_V1_response.json", + "id": "1234567890", + "bidid": "162059897743978051070", + "cur": "GBP", + "seatbid": [ + { + "seat": "512", + "bid": [ + { + "id": "1", + "impid": "102", + "price": 9.43, + "banner": { + "img": "http://adserver.com/creative112.jpg" + }, + "burl": "http://adserver.com/billingnotice?impid=102& bidid=abc1123&price=${AUCTION_PRICE}&multiplier=${AUCTION_MULTIPLIER}", + "adomain": [ + "advertiserdomain.com" + ], + "cid": "campaign111", + "crid": "creative112", + "attr": [ + 1, + 2, + 3, + 4, + 5, + 6, + 7, + 12 + ], + "w": 1080, + "h": 1920, + "cat": [ + "IAB1" + ] + } + ] + } + ] +} +``` + +## 7.9.4.1 - Video Bid Request + +```javascript +{ + "$schema": "https://raw.githubusercontent.com/knittingmedia/OpenRTB/main/Schema/OpenRTB_OOH_V1.json", + "id": "873465983764395", + "at": 1, + "imp": [ + { + "id": "123456", + "secure": 1, + "exp": 720, + "bidfloor": 4.8, + "bidfloorcur": "GBP", + "video": { + "boxingallowed": 1, + "w": 960, + "h": 480, + "maxduration": 20, + "minduration": 20, + "mimes": [ + "video/jpeg", + "video/mp4", + "video/mov" + ] + }, + "pmp": { + "private_auction": 1, + "deals": [ + { + "id": "V123", + "at": 1, + "bidfloor": 4.50 + } + ] + }, + "dt": 1647010095, + "qty": { + "multiplier": 14.2, + "sourcetype": 0, + "vendor": "route.org.uk" + } + } + ], + "device": { + "geo": { + "lat": 51.51112, + "long": -0.09043, + "lastfix": 0 + }, + "devicetype": 8, + "w": 960, + "h": 480, + "ppi": 3, + "ifa": "1234928801", + "ifa_type": "ppid", + "eids": [ + { + "source": "oohspace.co.uk", + "uids": [ + { + "atype": 501, + "id": "1234928801" + } + ] + } + ] + }, + "dooh": { + "content": {}, + "id": "1Frame", + "keywords": "LargeFormat,CANNON STREET STN,CANNON STREET,MAIN CONCOURSE", + "name": "Transvision", + "publisher": { + "id": "VJCDUK", + "name": "viooh" + }, + "domain": "viooh.com", + "venuetax": 1, + "venuetypeid": 10602 + }, + "cur": [ + "GBP" + ] +} +``` + +## 7.9.4.1 - Video Bid Response + +```javascript +{ + "$schema": "https://raw.githubusercontent.com/knittingmedia/OpenRTB/main/Schema/OpenRTB_OOH_V1_response.json", + "id": "1234567890", + "bidid": "162059897743978051070", + "cur": "GBP", + "seatbid": [ + { + "seat": "512", + "bid": [ + { + "id": "1", + "impid": "102", + "price": 9.43, + "nurl": "http://adserver.com/winnotice?impid=102&bidid=abc1123", + "burl": "http://adserver.com/billingnotice?impid=102&bidid=abc1123&price=${AUCTION_PRICE}&multiplier=${AUCTION_MULTIPLIER}", + "adm": " AdServer 00:00:10 ", + "adomain": [ + "advertiserdomain.com" + ], + "cid": "campaign111", + "crid": "creative112", + "attr": [ + 1, + 2, + 3, + 4, + 5, + 6, + 7, + 12 + ], + "w": 1920, + "h": 1080, + "cat": [ + "IAB1" + ] + } + ] + } + ] +} +``` From 1602c03a2b5bcd4ddfe9fd7378bddb2a73564fb4 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Fri, 28 Oct 2022 11:39:52 +0100 Subject: [PATCH 24/64] Example Titles --- implementation.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/implementation.md b/implementation.md index db5f130..6218467 100644 --- a/implementation.md +++ b/implementation.md @@ -1190,7 +1190,7 @@ For the above reasons, use of IAB Ad Management API (https://github.com/Interact ### 7.9.4 - DOOH Example Scenarios -## 7.9.4.1 - Banner Bid Request +#### 7.9.4.1 - DOOH Banner Bid Request ```javascript { @@ -1295,7 +1295,7 @@ For the above reasons, use of IAB Ad Management API (https://github.com/Interact } ``` -## 7.9.4.1 - Banner Bid Response +#### 7.9.4.2 - Banner Bid Response ```javascript { @@ -1342,7 +1342,7 @@ For the above reasons, use of IAB Ad Management API (https://github.com/Interact } ``` -## 7.9.4.1 - Video Bid Request +#### 7.9.4.3 - DOOH Video Bid Request ```javascript { @@ -1429,7 +1429,7 @@ For the above reasons, use of IAB Ad Management API (https://github.com/Interact } ``` -## 7.9.4.1 - Video Bid Response +#### 7.9.4.4 - DOOH Video Bid Response ```javascript { From 4b0aa353505c76d11790b790080cbdf0d933d1d8 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Fri, 28 Oct 2022 11:42:38 +0100 Subject: [PATCH 25/64] 7.9 title --- 2.6.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/2.6.md b/2.6.md index 8dd7eff..ec3a6e9 100644 --- a/2.6.md +++ b/2.6.md @@ -213,6 +213,9 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [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-) - [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.9 - Digital Out-Of-Home](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/OOH-Ammends/implementation.md#79---digital-out-of-home-) + ## [Appendix A. Additional Information](#appendixa) From ecf94127f87f87e00beb8e263884b08659db5322 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Fri, 28 Oct 2022 17:10:03 +0100 Subject: [PATCH 26/64] Simon etime def --- 2.6.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index ec3a6e9..59bcc3d 100644 --- a/2.6.md +++ b/2.6.md @@ -982,7 +982,7 @@ Recommended for video and/or apps. etime integer - The exposure time in seconds per view that the creative will be displayed before refreshing to the next creative. + The minimum exposure time in seconds per view that the creative will be displayed before refreshing to the next creative. If the field is absent, the exposure time is unknown. If 0, the exposure time is indefinite. qty From 191171d8ebd93e4be0959433af1b49c45ed13c06 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Fri, 28 Oct 2022 17:20:10 +0100 Subject: [PATCH 27/64] etime is gone --- 2.6.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/2.6.md b/2.6.md index 59bcc3d..85880b5 100644 --- a/2.6.md +++ b/2.6.md @@ -979,11 +979,6 @@ Recommended for video and/or apps. integer Advisory as to the number of seconds that may elapse between the auction and the actual impression. - - etime - integer - The minimum exposure time in seconds per view that the creative will be displayed before refreshing to the next creative. If the field is absent, the exposure time is unknown. If 0, the exposure time is indefinite. - qty object From 4553f47d3a757870ce2ce541286264078624c5d0 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Fri, 28 Oct 2022 17:36:53 +0100 Subject: [PATCH 28/64] Added dooh object to 3.2.1 --- 2.6.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/2.6.md b/2.6.md index 85880b5..809c02d 100644 --- a/2.6.md +++ b/2.6.md @@ -699,6 +699,11 @@ There are also several subordinate objects that provide detailed data to potenti object; recommended Details via an App object (Section 3.2.14) about the publisher’s app (i.e., non-browser applications). Only applicable and recommended for apps. + + dooh + 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 object; recommended From a094aa76c3173314e6ee00c827099bcf60a0c871 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Fri, 28 Oct 2022 17:38:47 +0100 Subject: [PATCH 29/64] remove dooh.x from 7.9.2.5 --- implementation.md | 9 --------- 1 file changed, 9 deletions(-) diff --git a/implementation.md b/implementation.md index 6218467..68cd990 100644 --- a/implementation.md +++ b/implementation.md @@ -1166,15 +1166,6 @@ In the case of user agents, oftentimes non-standard strings are used by Media Ow | imp.video.boxingallowed | integer | For DOOH, when boxingallowed = 0, the video aspect ratio should strictly match that of the placement, as determined by the video w and h fields. | | imp.dt | float | Timestamp when the item is estimated to be fulfilled (e.g. when a DOOH impression will be displayed) in Unix format (i.e., milliseconds since the epoch). | | imp.etime | integer | The exposure time in seconds per view that the creative will be displayed before refreshing to the next creative. | -| dooh.id | string; recommended | Exchange provided id for a placement or logical grouping of placements. | -| dooh.name | string | Name of the dooh placement. | -| dooh.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, OpenOOH Venue Taxonomy is assumed.](https://github.com/openooh/venue-taxonomy/blob/main/specification-1.0.md) | -| dooh.venuetypetax | integer; default 1 | The venue taxonomy in use. Refer to list https://github.com/knittingmedia/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md#list-venue-taxonomies- | -| dooh.publisher | object | Details about the publisher of the placement. | -| dooh.domain | string | Domain of the inventory (ads.txt) owner (e.g., “mysite.foo.com”) | -| dooh.keywords | string | Comma separated list of keywords about the DOOH placement. | -| dooh.content | object | Details about the Content within the DOOH placement. | -| dooh.ext | object | Placeholder for exchange-specific extensions to OpenRTB. | ### 7.9.3 Commercially Critical Brand Safety From 0aee86b26ecad0ba3085235ca55bee711b36eaa8 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Fri, 28 Oct 2022 17:47:39 +0100 Subject: [PATCH 30/64] 7.9.2.5 explanations --- implementation.md | 1 + 1 file changed, 1 insertion(+) diff --git a/implementation.md b/implementation.md index 68cd990..f9ad0ea 100644 --- a/implementation.md +++ b/implementation.md @@ -1154,6 +1154,7 @@ Some countries have attempted to create standards for describing the shape, size In the case of user agents, oftentimes non-standard strings are used by Media Owners, which has been known to plague device detection and traffic protection systems. It is advised that Media Owners comply with the HTTP user agent standards set forth by the IETF and submit their user agents to the IAB Spiders and Bots List using the "Submit here" button on this page. #### 7.9.2.5 Key Object Attributes To Use For DOOH Device Reference in OpenRTB +Key objects such as imp.qty and dooh have been added to the OpenRTB specification to enable the programmatic trading of the medium. The following table gives guidance to the use of more common OpenRTB object references when transacting DOOH bids. | Object Reference | Type | Implementation Guidance | | ----------------------- | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | From 804362539f93286ecf95a694861f1c9ac1ad6a43 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Fri, 28 Oct 2022 17:50:34 +0100 Subject: [PATCH 31/64] Added DOOH Pricing Example --- implementation.md | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/implementation.md b/implementation.md index f9ad0ea..846c404 100644 --- a/implementation.md +++ b/implementation.md @@ -1179,10 +1179,27 @@ This means typical lead times for creative approval are on the order of “worki For the above reasons, use of IAB Ad Management API (https://github.com/InteractiveAdvertisingBureau/AdManagementAPI/blob/master/Ad%20Management%20API%201.0%20FINAL.md) for creative submission to DOOH exchanges is strongly recommended, though many SSPs may have proprietary extensions to allow submitting ads to specific individual publishers. + +### 7.9.4 DOOH Pricing +Bid price and clearing price should be expressed as a CPM rate per impression. +For example, if an advertiser is bidding $2.50 CPM on a 1st price auction, and the auction is for 30.3 impressions: +multiplier = 30.3 (Impression multiplier from bid request) +bid.price = 2.50 (Bid price in CPM from bid response) + +If the advertiser wins, tracking URL (e.g. burl) macros will contain the following values: +${AUCTION_PRICE} = 2.50 (The clearing price of the auction) +${AUCTION_MULTIPLIER} = 30.3 (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.) + +To calculate the total cost of the transaction: +(AUCTION_PRICE / 1000) * AUCTION_MULTIPLIER = COST +(2.50 / 1000) * 30.3 = $0.07575 + +The above auction would translate to an invoice of $0.07575. + -### 7.9.4 - DOOH Example Scenarios +### 7.9.5 - DOOH Example Scenarios -#### 7.9.4.1 - DOOH Banner Bid Request +#### 7.9.5.1 - DOOH Banner Bid Request ```javascript { @@ -1287,7 +1304,7 @@ For the above reasons, use of IAB Ad Management API (https://github.com/Interact } ``` -#### 7.9.4.2 - Banner Bid Response +#### 7.9.5.2 - Banner Bid Response ```javascript { @@ -1334,7 +1351,7 @@ For the above reasons, use of IAB Ad Management API (https://github.com/Interact } ``` -#### 7.9.4.3 - DOOH Video Bid Request +#### 7.9.5.3 - DOOH Video Bid Request ```javascript { @@ -1421,7 +1438,7 @@ For the above reasons, use of IAB Ad Management API (https://github.com/Interact } ``` -#### 7.9.4.4 - DOOH Video Bid Response +#### 7.9.5.4 - DOOH Video Bid Response ```javascript { From 6106817287b6e1995ed4da00196496c6c5556d3b Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Fri, 28 Oct 2022 17:56:39 +0100 Subject: [PATCH 32/64] Added imp.dt --- 2.6.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/2.6.md b/2.6.md index 809c02d..e9e392d 100644 --- a/2.6.md +++ b/2.6.md @@ -989,6 +989,11 @@ Recommended for video and/or apps. object 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. + + dt + float + Timestamp when the item is estimated to be fulfilled (e.g. when a DOOH impression will be displayed) in Unix format (i.e., milliseconds since the epoch). + ext object From f345892305c651819ed3e9b04874b7fb18e58063 Mon Sep 17 00:00:00 2001 From: wittjill <57421053+wittjill@users.noreply.github.com> Date: Fri, 28 Oct 2022 16:01:32 -0400 Subject: [PATCH 33/64] GPP string and applicable section notification https://docs.google.com/document/d/1CCnCGRnlLt3VPmQcbd_dTucTLO84KqQIfX1Sw9ON5So/edit --- 2.6.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index d9905ee..dbff745 100644 --- a/2.6.md +++ b/2.6.md @@ -827,7 +827,7 @@ This object describes the nature and behavior of the entity that is the source o ### 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 CCPA. +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. @@ -850,6 +850,16 @@ This object contains any legal, governmental, or industry regulations that the s + + + + + + + + + + From 51c2d4f41a14a470b387d60958ec040156e42844 Mon Sep 17 00:00:00 2001 From: strasler Date: Fri, 28 Oct 2022 16:53:10 -0700 Subject: [PATCH 34/64] Add 'etime' to the 'imp' object --- 2.6.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/2.6.md b/2.6.md index d9905ee..72a75ac 100644 --- a/2.6.md +++ b/2.6.md @@ -966,6 +966,11 @@ The presence of `Banner` (Section 3.2.6), `Video` (Section 3.2.7), and/or `Nativ + + + + + From 385fd87031f9dacff2bcc6319c9ef4cfa403e0ab Mon Sep 17 00:00:00 2001 From: wittjill <57421053+wittjill@users.noreply.github.com> Date: Mon, 31 Oct 2022 12:43:03 -0400 Subject: [PATCH 35/64] Update 2.6.md feedback from Scott --- 2.6.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/2.6.md b/2.6.md index dbff745..6d5c432 100644 --- a/2.6.md +++ b/2.6.md @@ -853,12 +853,12 @@ This object contains any legal, governmental, or industry regulations that the s - + - + From 6a84eaa5f46e92e4bd4fc6c40004afeecf26d06f Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Tue, 1 Nov 2022 11:50:23 -0400 Subject: [PATCH 36/64] Text Edit HS Small text edits to include DOOH where site and app are mentioned as mutually exclusive and ensure reference consistency --- 2.6.md | 32 +++++++++++++++++++++++--------- 1 file changed, 23 insertions(+), 9 deletions(-) diff --git a/2.6.md b/2.6.md index e9e392d..b0283ad 100644 --- a/2.6.md +++ b/2.6.md @@ -6,7 +6,7 @@ The IAB Technology Laboratory is a nonprofit research and development consortium ### 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, Café Media; 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; Liam Whiteside, Head Of Ad Technology, Global; Chris Coupland, Platform Operations Manager, Centro; +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, Café Media; 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, Centro; ### IAB Tech Lab Lead: @@ -659,6 +659,20 @@ The following table summarizes the objects in the Bid Request model and serves a + + + + + + + + + + + + + +
string Communicates signals regarding consumer privacy under US privacy regulation. See US Privacy String specifications. Refer to Section 7.5 for more information.
gppstringContains the Global Privacy Platform’s consent string. See the for more details.
gpp_sidinteger arrayArray of the section(s) of the string which should be applied for this transaction. Generally will contain one and only one value, but there are edge cases where more than one may apply. Sections 3 & 4 need not be signaled for this purpose. See the GPP Section Information for more details.
ext objectinteger Advisory as to the number of seconds that may elapse between the auction and the actual impression.
etimeintegerThe minimum exposure time, in seconds per view, that the (uninterrupted) player will display the creative before refreshing to the next creative. If the field is absent, the exposure time is unknown. If 0, the exposure time is indefinite.
ext object
gpp stringContains the Global Privacy Platform’s consent string. See the for more details.Contains the Global Privacy Platform’s consent string. See the Global Privacy Platform specification for more details.
gpp_sid integer arrayArray of the section(s) of the string which should be applied for this transaction. Generally will contain one and only one value, but there are edge cases where more than one may apply. Sections 3 & 4 need not be signaled for this purpose. See the GPP Section Information for more details.Array of the section(s) of the string which should be applied for this transaction. Generally will contain one and only one value, but there are edge cases where more than one may apply. GPP Section 3 (Header) and 4 (Signal Integrity) do not need to be included. See the GPP Section Information for more details.
ext
Qty3.2.31A means of passing a multiplier in the bid request, representing the total quantity of impressions for adverts that display to more than one person.
DOOH3.2.32Details of the Digital Out of Home inventory calling for the impression.
@@ -669,7 +683,7 @@ The following table summarizes the objects in the Bid Request model and serves a 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. -There are also several subordinate objects that provide detailed data to potential buyers. Among these are the `Site` and `App` 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 or a non-browser application, 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. @@ -1631,7 +1645,7 @@ between a buyer and a seller. Its presence with the `Pmp` collection indicates t ### 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. A bid request must not contain both a `Site` and an `App` object. At a minimum, it is useful to provide a site ID or page URL, but this is not strictly required. +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. @@ -1663,17 +1677,17 @@ This object should be included if the ad supported content is a website as oppos - + - + - + @@ -1732,7 +1746,7 @@ This object should be included if the ad supported content is a website as oppos ### 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 both an `App` and a `Site` object. At a minimum, it is useful to provide an App ID or bundle, but this is not strictly required. +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.
cat string arrayArray of IABTL content categories of the site. The taxonomy to be used is defined by the cattax field.Array of IAB TechLab content categories of the site. The taxonomy to be used is defined by the cattax field.
sectioncat string arrayArray of IABTL content categories that describe the current section of the site. The taxonomy to be used is defined by the cattax field.Array of IAB TechLab 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 IABTL 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 TechLab content categories that describe the current page or view of the site. The taxonomy to be used is definied by the cattax field.
page
@@ -1779,12 +1793,12 @@ This object should be included if the ad supported content is a non-browser appl - + - + From 68ec2216554368f78e9a7f66e5019ef3bf909ba1 Mon Sep 17 00:00:00 2001 From: Rob Hazan Date: Tue, 1 Nov 2022 12:35:41 -0400 Subject: [PATCH 37/64] Add inventorypartnerdomain to app/site Added the inventorypartnerdomain field in the App and Site objects. Propose adding these directly to the mainline, as opposed to an extension, because this is a core usecase. Better to mainline early than wait, because migration will be harder once there's more industry adoption. Also did some minor repair/reformat of the tags in the table for the App fields. --- 2.6.md | 76 ++++++++++++++++++++++++++++++++-------------------------- 1 file changed, 42 insertions(+), 34 deletions(-) diff --git a/2.6.md b/2.6.md index d9905ee..b7ba188 100644 --- a/2.6.md +++ b/2.6.md @@ -1819,22 +1819,27 @@ This object describes the entity who directly supplies inventory to and is paid - + - + - - + + - + + + + + + @@ -1864,7 +1869,7 @@ This object describes the content in which the impression will appear, which may - + @@ -1874,7 +1879,7 @@ This object describes the content in which the impression will appear, which may - + @@ -1884,13 +1889,13 @@ This object describes the content in which the impression will appear, which may - + - - + + @@ -1904,18 +1909,18 @@ This object describes the content in which the impression will appear, which may - + - - + + - + @@ -1924,28 +1929,28 @@ This object describes the content in which the impression will appear, which may - + - - + + - + - - + + - + @@ -1954,23 +1959,23 @@ This object describes the content in which the impression will appear, which may - + - - + + - + - + @@ -1979,33 +1984,36 @@ This object describes the content in which the impression will appear, which may - + - - + + - + - + - + + + + + + - -
sectioncat string arrayArray of IABTL content categories that describe the current section of the app. The taxonomy to be used is defined by the cattax field.Array of IAB TechLab 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 IABTL 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 TechLab content categories that describe the current page or view of the app. The taxonomy to be used is definied by the cattax field.
ver
name string Seller name (may be aliased at the seller's request).
cattax integer; default 1 The taxonomy in use. Refer to the AdCOM List: Category Taxonomies for values.
cat string array 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.
domain string Highest level domain of the seller (e.g., "seller.com").
inventorypartnerdomainstringA 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 objectepisode integer Episode number.
title stringseries string Content series.
*Video Examples:* “The Office” (television), “Star Wars” (movie), or “Arby ‘N’ The Chief” (made for web).
*Non-Video Example:* “Ecocentric” (Time Magazine blog).
season stringartist string Artist credited with the content.
genre string Genre that best describes the content (e.g., rock, pop, etc).
album string Album to which the content belongs; typically for audio.producer object Details about the content Producer (Section 3.2.17).
url string URL of the content, for buy-side contextualization or review.
cattax integer; default 1 The taxonomy in use. Refer to list List: Category Taxonomies in AdCOM 1.0 for values.
cat string array 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 integer Production quality. Refer to List: Production Qualities in AdCOM 1.0.
context integer Type of content (game, video, text, etc.). Refer to List: Content Contexts in AdCOM 1.0.
contentrating string Content rating (e.g., MPAA).
userrating string User rating of the content (e.g., number of stars, likes, etc.).
qagmediarating integer Media rating per IQG guidelines. Refer to List: Media Ratings in AdCOM 1.0.
keywords string Comma separated list of keywords describing the content. Only one of keywords or kwarray may be present.kwarry string array Array of keywords about the site. Only one of keywords or kwarray may be present.
livestream integer 0 = not live, 1 = content is live (e.g., stream, live blog).
sourcerelationship integer 0 = indirect, 1 = direct.
len integer Length of content in seconds; appropriate for video or audio.
language string Content language using ISO-639-1-alpha-2. Only one of language or langb should be present.langb string Content language using IETF BCP 47. Only one of language or langb should be present.
embeddable integer Indicator of whether the content is embeddable (e.g., an embeddable video player), where 0 = no, 1 = yes.
data object array Additional content data. Each Data object (Section 3.2.21) represents a different data source.
network object Details about the network (Section 3.2.23) the content is on.
channel object Details about the channel (Section 3.2.24) the content is on.
inventorypartnerdomainstringA 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.
From f969b2155c7e7dd6f2d3ca9da44e60688d6b37cc Mon Sep 17 00:00:00 2001 From: Rob Hazan Date: Wed, 2 Nov 2022 10:56:19 -0400 Subject: [PATCH 38/64] Updates to Versioning, Contributing, and Releasing Added some detail around the date codes to be used in versioning. Created a new section detailing the process for contributing changes, and one detailing the monthly release process. --- README.md | 44 ++++++++++++++++++++++++++++++-------------- 1 file changed, 30 insertions(+), 14 deletions(-) diff --git a/README.md b/README.md index f287d37..94b2af0 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,7 @@ -# openrtb2.x -OpenRTB 2.x specification, from 2.6 onward - ![IAB Tech Lab](https://drive.google.com/uc?id=10yoBoG5uRETSXRrnJPUDuONujvADrSG1) # **OpenRTB 2.x** +OpenRTB 2.x specification, from 2.6 onward #### About OpenRTB https://iabtechlab.com/openrtb @@ -12,29 +10,47 @@ https://iabtechlab.com/openrtb #### AdCOM: Advertising Common Object Model https://github.com/InteractiveAdvertisingBureau/AdCOM -#### VERSIONING POLICY -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. +#### Versioning Policy +As of OpenRTB 2.6-202210, 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. The current version of the OpenRTB specification is updated approximately once a month if there are non-breaking improvements to be released such as new fields, objects, or values in enumerated lists. Errata, such as clarifications or corrections to descriptions not materially impacting the specification itself, are also addressed during monthly updates. See Errata. -Release branches are created for each monthly release and the history of these can be reviewed on GitHub. The master branch for the repository will always reflect the most recent release, whereas ongoing development work occurs in the 'develop' branch. +The format for version numbering includes major and minor version and a date code. For example, 2.6-202210 represents the release for October 2022. The following releases may be 2.6-202211 (November), 2.6-202212 (December), 2.6-202301 (January), etc. This versioning policy is a break from historical practice for OpenRTB 2.x. In versions of OpenRTB prior to 2.6, major version numbers represent breaking changes and minor version numbers represent non-breaking changes. +#### How To Contribute + +1. Clone this GitHub repo into your own GitHub account +1. Create a new branch based on `develop`, giving your new branch a short but descriptive name (e.g. if you're adding support for a new flux capacitor object, you could call the branch "add-flux-capacitor") +1. Make the desired changes in your branch, with one commit per logical change (e.g. if you're adding 2 distinct features in your branch, create 2 distinct commits). Give each of your commits a short but descriptive "Summary" name, and then provide a longer "Description" to fully explain your proposed changes. +1. (Optional) Consider doing a round of internal reviews/feedback within your own organization, and make any additional updates in your own branch. +1. Once you're happy with your branch, create a new Pull Request (PR) to propose merging your changes into the `develop` branch. +1. The OpenRTB Commit Group will review your change, leave comments, and may propose changes. You may need to make additional commits to receive approval for your PR. +1. Once your PR is approved, it will be merged into the `main` branch at the time of the next monthly release. Details below on how the Release Process works. +1. (Sometimes) It's possible, especially if your PR is open for a long time, that it cannot be automatically merged into the `develop` branch. In this case, there will be a message in the PR asking you to resolve conflicts before the PR can be merged. + +#### Monthly Release-Cutting Process (for repo admins) + +Over the course of each month, the OpenRTB Commit Group may review any submitted PRs and take the following possible actions for each: +- approve it for inclusion in the next release +- ask the author(s) for additional changes +- reject it (with a rationale) + +On the last Friday of the month, if there are any approved PRs in the `develop` branch, the following steps are executed: + +1. A PR is created to merge the `develop` branch into the `main` branch. +1. A new Release and Tag are create concurrently. The naming convention for the release is "OpenRTB v2.6-YYYYYY", and the tag is "2.6-YYYYYY" where YYYYYY is the date code (e.g. 202301 for January 2023). + +The result of this process is that tagged releases are created for each release of OpenRTB, and the history of these is easily reviewed. The `main` branch for the repository will always reflect the most recent release, and ongoing development work will always occur in the `develop` branch. + #### Contact For more information, or to get involved, please email support@iabtechlab.com. #### About IAB Tech Lab - 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. +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. Learn more about IAB Tech Lab here: [https://www.iabtechlab.com/](https://www.iabtechlab.com/) From 27f9c2419858d5626d345c1e3f84160865ccaf8b Mon Sep 17 00:00:00 2001 From: Rob Hazan Date: Wed, 2 Nov 2022 10:59:39 -0400 Subject: [PATCH 39/64] Add missing "publish" step --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 94b2af0..d3ac30d 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ This versioning policy is a break from historical practice for OpenRTB 2.x. In v 1. Create a new branch based on `develop`, giving your new branch a short but descriptive name (e.g. if you're adding support for a new flux capacitor object, you could call the branch "add-flux-capacitor") 1. Make the desired changes in your branch, with one commit per logical change (e.g. if you're adding 2 distinct features in your branch, create 2 distinct commits). Give each of your commits a short but descriptive "Summary" name, and then provide a longer "Description" to fully explain your proposed changes. 1. (Optional) Consider doing a round of internal reviews/feedback within your own organization, and make any additional updates in your own branch. -1. Once you're happy with your branch, create a new Pull Request (PR) to propose merging your changes into the `develop` branch. +1. Once you're happy with your branch, publish it to GitHub. Then create a new Pull Request (PR) to propose merging your changes into the `develop` branch. 1. The OpenRTB Commit Group will review your change, leave comments, and may propose changes. You may need to make additional commits to receive approval for your PR. 1. Once your PR is approved, it will be merged into the `main` branch at the time of the next monthly release. Details below on how the Release Process works. 1. (Sometimes) It's possible, especially if your PR is open for a long time, that it cannot be automatically merged into the `develop` branch. In this case, there will be a message in the PR asking you to resolve conflicts before the PR can be merged. From 99322d5c5e0bb8b677c009a5e01d9bb86df48398 Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Wed, 2 Nov 2022 11:37:17 -0400 Subject: [PATCH 40/64] Update README.md --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index d3ac30d..50cabab 100644 --- a/README.md +++ b/README.md @@ -11,11 +11,11 @@ https://iabtechlab.com/openrtb https://github.com/InteractiveAdvertisingBureau/AdCOM #### Versioning Policy -As of OpenRTB 2.6-202210, 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. +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. The current version of the OpenRTB specification is updated approximately once a month if there are non-breaking improvements to be released such as new fields, objects, or values in enumerated lists. Errata, such as clarifications or corrections to descriptions not materially impacting the specification itself, are also addressed during monthly updates. See Errata. -The format for version numbering includes major and minor version and a date code. For example, 2.6-202210 represents the release for October 2022. The following releases may be 2.6-202211 (November), 2.6-202212 (December), 2.6-202301 (January), etc. +The format for version numbering includes major and minor version and a date code. For example, 2.6-202211 represents the release for November 2022. The following releases may be 2.6-202212 (December), 2.6-202301 (January), etc. This versioning policy is a break from historical practice for OpenRTB 2.x. In versions of OpenRTB prior to 2.6, major version numbers represent breaking changes and minor version numbers represent non-breaking changes. @@ -26,13 +26,13 @@ This versioning policy is a break from historical practice for OpenRTB 2.x. In v 1. Make the desired changes in your branch, with one commit per logical change (e.g. if you're adding 2 distinct features in your branch, create 2 distinct commits). Give each of your commits a short but descriptive "Summary" name, and then provide a longer "Description" to fully explain your proposed changes. 1. (Optional) Consider doing a round of internal reviews/feedback within your own organization, and make any additional updates in your own branch. 1. Once you're happy with your branch, publish it to GitHub. Then create a new Pull Request (PR) to propose merging your changes into the `develop` branch. -1. The OpenRTB Commit Group will review your change, leave comments, and may propose changes. You may need to make additional commits to receive approval for your PR. +1. The Programmatic Supply Chain Working Group and Commit Group will review your update(s), leave comments, and may propose changes. You may need to make additional commits to receive approval for your PR. 1. Once your PR is approved, it will be merged into the `main` branch at the time of the next monthly release. Details below on how the Release Process works. 1. (Sometimes) It's possible, especially if your PR is open for a long time, that it cannot be automatically merged into the `develop` branch. In this case, there will be a message in the PR asking you to resolve conflicts before the PR can be merged. #### Monthly Release-Cutting Process (for repo admins) -Over the course of each month, the OpenRTB Commit Group may review any submitted PRs and take the following possible actions for each: +Over the course of each month, the Programmatic Supply Chain Working Group and Commit Group may review any submitted PRs and take the following possible actions for each: - approve it for inclusion in the next release - ask the author(s) for additional changes - reject it (with a rationale) @@ -40,7 +40,7 @@ Over the course of each month, the OpenRTB Commit Group may review any submitted On the last Friday of the month, if there are any approved PRs in the `develop` branch, the following steps are executed: 1. A PR is created to merge the `develop` branch into the `main` branch. -1. A new Release and Tag are create concurrently. The naming convention for the release is "OpenRTB v2.6-YYYYYY", and the tag is "2.6-YYYYYY" where YYYYYY is the date code (e.g. 202301 for January 2023). +1. A new Release and Tag are created concurrently. The naming convention for the release is "OpenRTB v2.6-YYYYMM", and the tag is "2.6-YYYYMM" where YYYYMM is the date code (e.g. 202301 for January 2023). The result of this process is that tagged releases are created for each release of OpenRTB, and the history of these is easily reviewed. The `main` branch for the repository will always reflect the most recent release, and ongoing development work will always occur in the `develop` branch. From 23d9ff5b18cb1b0eed292c0fded16e698c01843d Mon Sep 17 00:00:00 2001 From: Rob Hazan Date: Wed, 2 Nov 2022 11:45:19 -0400 Subject: [PATCH 41/64] Review to occur during last week Rather than constraining ourselves to "last Friday". --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 50cabab..1ea0682 100644 --- a/README.md +++ b/README.md @@ -37,7 +37,7 @@ Over the course of each month, the Programmatic Supply Chain Working Group and C - ask the author(s) for additional changes - reject it (with a rationale) -On the last Friday of the month, if there are any approved PRs in the `develop` branch, the following steps are executed: +During the last week of the month, if there are any approved PRs in the `develop` branch, the following steps are executed: 1. A PR is created to merge the `develop` branch into the `main` branch. 1. A new Release and Tag are created concurrently. The naming convention for the release is "OpenRTB v2.6-YYYYMM", and the tag is "2.6-YYYYMM" where YYYYMM is the date code (e.g. 202301 for January 2023). From 32fad77aa1aee12f3ae6c2e7e0ff432ed0375cd1 Mon Sep 17 00:00:00 2001 From: Jason Shao Date: Fri, 4 Nov 2022 11:39:51 -0400 Subject: [PATCH 42/64] Update Brand Safety to Ad Quality as Brand Safety tends to refer to Brand's perception of quality more than the publishers --- implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/implementation.md b/implementation.md index 846c404..ac300ea 100644 --- a/implementation.md +++ b/implementation.md @@ -1169,7 +1169,7 @@ Key objects such as imp.qty and dooh have been added to the OpenRTB specificatio | imp.etime | integer | The exposure time in seconds per view that the creative will be displayed before refreshing to the next creative. | -### 7.9.3 Commercially Critical Brand Safety +### 7.9.3 Commercially Critical Ad Quality One bad advert being served at one time to one person is survivable. One bad advert served at one time to 1000’s of people in a public place will lead to a Media Owner and/or Publisher risking their contract/permission to serve ads to networks of screens. From 6684d770b1180f527714a0832d050fb9ea9861f9 Mon Sep 17 00:00:00 2001 From: Jason Shao Date: Fri, 4 Nov 2022 11:58:53 -0400 Subject: [PATCH 43/64] Removing schema references (since it's not a complete 2.6 schema) @knittingmedia purging this since I don't think we can have a partial schema and I don't think this schema is "official" and complete --- implementation.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/implementation.md b/implementation.md index ac300ea..9dda944 100644 --- a/implementation.md +++ b/implementation.md @@ -1203,7 +1203,6 @@ The above auction would translate to an invoice of $0.07575. ```javascript { - "$schema": "https://raw.githubusercontent.com/knittingmedia/OpenRTB/main/Schema/OpenRTB_OOH_V1.json", "id": "162059897743978051070", "at": 1, "imp": [ @@ -1308,7 +1307,6 @@ The above auction would translate to an invoice of $0.07575. ```javascript { - "$schema": "https://raw.githubusercontent.com/knittingmedia/OpenRTB/main/Schema/OpenRTB_OOH_V1_response.json", "id": "1234567890", "bidid": "162059897743978051070", "cur": "GBP", @@ -1355,7 +1353,6 @@ The above auction would translate to an invoice of $0.07575. ```javascript { - "$schema": "https://raw.githubusercontent.com/knittingmedia/OpenRTB/main/Schema/OpenRTB_OOH_V1.json", "id": "873465983764395", "at": 1, "imp": [ @@ -1442,7 +1439,6 @@ The above auction would translate to an invoice of $0.07575. ```javascript { - "$schema": "https://raw.githubusercontent.com/knittingmedia/OpenRTB/main/Schema/OpenRTB_OOH_V1_response.json", "id": "1234567890", "bidid": "162059897743978051070", "cur": "GBP", From bf091ce58308760bb24e37a538976179f34f52d2 Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Fri, 4 Nov 2022 12:35:55 -0400 Subject: [PATCH 44/64] Updated Object Model Image (#26) updated ERD, minor text edits Co-authored-by: wittjill <57421053+wittjill@users.noreply.github.com> Co-authored-by: Jason Shao --- 2.6.md | 454 ++++++++++++++++++++++---------------------- README.md | 9 +- assets/ORTB ERD.png | Bin 0 -> 48214 bytes 3 files changed, 235 insertions(+), 228 deletions(-) create mode 100644 assets/ORTB ERD.png diff --git a/2.6.md b/2.6.md index b0283ad..882941b 100644 --- a/2.6.md +++ b/2.6.md @@ -1,5 +1,3 @@ -2.6 final draft - # About the IAB Tech Lab 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 @@ -10,7 +8,7 @@ Stanislav Belov, Software Engineer, Google; Allen Dove, CTO, Magnite; Steven Kat ### IAB Tech Lab Lead: -Jill Wittkopp, VP of Product, IAB Tech Lab +Hillary Slattery, Director of Product, IAB Tech Lab ### License @@ -156,10 +154,6 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [4.3.3 - Comparison of Ad Serving Approaches](#comparisonofapproaches) - - [4.3.4 - Ad Served on the Win Notice](#adservedonwin) - - - [4.3.5 - Ad Served in the Bid](#adservedinbid) - - [4.4 - Substitution Macros](#substitutionmacros) - [4.4.1 - Notes on the macro ${AUCTION_MIN_TO_WIN}](#notesonmacro) @@ -212,10 +206,9 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [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-) - - [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.8 - 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.9 - Digital Out-Of-Home](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/OOH-Ammends/implementation.md#79---digital-out-of-home-) - ## [Appendix A. Additional Information](#appendixa) @@ -238,47 +231,50 @@ Some optional attributes are denoted "recommended." As that term is used herein Examples of required attributes.
Grouped at the tops of tables for convenience id - string, required + string;
required ... imp - object array; required;
default “adcom” + object array;
required ... Examples of recommended attributes.
Grouped after required attributes. site - object; recommended  + object;
recommended ... app - object; recommended * - .... + object;
recommended + ... Examples of optional attributes with and without defaults.
Attributes are assumed optional unless explicitly qualified as required or recommended. test - integer; default 0 * - .... + integer;
default 0 + ... at - integer; recommended + integer;
default 2 ... tmax - object; * - .... + integer; + ... wseat - string array * - .... + string array + ... +*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. # 1. Introduction @@ -288,18 +284,17 @@ The mission of OpenRTB is to spur growth in Real-Time Bidding (RTB) marketplaces This document specifies a standard for the Real-Time Bidding Interface that grew out of previous OpenRTB collaboration on the “block list project” and the “OpenRTB Mobile” project. These protocol standards aim to simplify the connection between suppliers of publisher inventory (i.e., exchanges, networks working with publishers, and sell-side platforms) and competitive buyers of that inventory (i.e., bidders, demand side platforms, or networks working with advertisers). -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. +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. +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. 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. Governance over the technical content of the specification remains with the OpenRTB community and its governance rules. +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 @@ -330,8 +325,6 @@ 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 -OpenRTB GitHub Repository https://github.com/InteractiveAdvertisingBureau/openrtb - 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 @@ -346,7 +339,7 @@ The following terms are used throughout this document specifically in the contex RTB - Bidding for individual impressions in real-time (i.e., while a consumer is waiting) + Bidding for individual impressions in real-time (i.e., while a consumer is waiting). Exchange @@ -354,7 +347,7 @@ The following terms are used throughout this document specifically in the contex Bidder - an entity that competes in real-time auctions to acquire impressions + An entity that competes in real-time auctions to acquire impressions. Seat @@ -383,11 +376,11 @@ The URLs for win, billing, and loss notices and the ad markup itself can contain ![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/864a56706b106eda94c03abefaa01dd43544864c/assets/Figure1%20OpenRTB.png) -Figure 2: Reference Model - Request Sequence. +*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: -- [AdCOM](https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md): The Advertising Common Object Model, a companion specification that defines common objects and values expected to be used across many IAB Tech Lab spec. As of OpenRTB 2.6, all enumerated lists used by OpenRTB 2.6 are kept in AdCOM to enable more rapid iteration. +- [AdCOM](https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md): The Advertising Common Object Model, a companion specification that defines common objects and values expected to be used across many IAB Tech Lab specifications. As of OpenRTB 2.6, all enumerated lists used by OpenRTB 2.6 are kept in AdCOM to enable more rapid iteration. - [OpenRTB Ad Management API](https://github.com/InteractiveAdvertisingBureau/AdManagementAPI/blob/master/Ad%20Management%20API%201.0%20FINAL.md): A companion specification for facilitating creative review between bidders and exchanges. Other interactions (e.g., block list synchronization, traffic control, etc.) are candidates for future OpenRTB initiatives or alternate projects. @@ -403,13 +396,13 @@ Invalid calls (e.g., a bid request containing a malformed or corrupt payload) sh ## 2.2 - Security -HTTPS (i.e., secure HTTP) is not required for OpenRTB compliance. However, there is a growing trend in the industry to use HTTPS for added security of exchange/bidder communications. It is recommended, therefore, that exchanges and bidders consider supporting both HTTP and HTTPS. +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 IAB reference implementations is highly recommended to reduce exchange-specific variations. +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. @@ -423,17 +416,15 @@ As a convention, the absence of an attribute has a formal meaning. In most cases 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``` @@ -451,14 +442,21 @@ This version should be specified as `.` (e.g., 2.6). ## 2.6 - Versioning Behavior -Breaking changes are not permitted without a major version increment. The minor version number increments are reserved for non-breaking changes. This means that implementers need not specifically treat the minor version of OpenRTB 2.x as significant, in most circumstances. For example: +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. + +The current version of the OpenRTB specification is updated approximately once a month if there are non-breaking improvements to be released such as new fields, objects, or values in enumerated lists. Errata, such as clarifications or corrections to descriptions not materially impacting the specification itself, are also addressed during monthly updates. See Errata. + +Release branches are created for each monthly release and the history of these can be reviewed on GitHub. The master branch for the repository will always reflect the most recent release, whereas ongoing development work occurs in the 'develop' branch. + +This versioning policy is a break from historical practice for OpenRTB 2.x. In versions of OpenRTB prior to 2.6, major version numbers represent breaking changes and minor version numbers represent non-breaking changes. +This means: - Bidders and exchanges must tolerate receiving new or unexpected fields and enumerated list values gracefully, treating them as unknown or ignoring them - Bidders and exchanges should freely transmit new fields or enumerated list values -For example, if a new field or object is introduced in a future version of OpenRTB 2.x, 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 minor version number, but rather should discuss specific fields of interest as they become available. +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.x 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. +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 @@ -467,7 +465,7 @@ Without limiting the scope of the Disclaimer, the OpenRTB specification does inc - The status of do not track headers (Section 3.2.18) - Presence of site/app privacy policies (Section 3.2.13 and Section 3.2.14) - Regulations or laws that the transmitter of a bid request believes are applicable (Section 3.2.3) -- Consent and opt-out information strings for the user (US Privacy String and Transparency and Consent Framework consent strings) (Section 3.2.3 and Section 3.2.20) +- Consent and opt-out information strings for the user (Global Privacy Platform, US Privacy String and Transparency and Consent Framework consent strings) (Section 3.2.3 and Section 3.2.20) As noted in the Disclaimer, each implementer is responsible to ensure that their implementation complies with any applicable laws, regulations, or self-regulatory frameworks. @@ -489,9 +487,9 @@ RTB transactions are initiated when an exchange or other supply source sends a b 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. -![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/864a56706b106eda94c03abefaa01dd43544864c/assets/Figure2%20Bid%20Request%20object%20model.png) +![](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/a29f4b1060c04813270dbf13607bba0403409068/assets/ORTB%20ERD.png) -Figure 3: Bid Request object model. +*Figure 3: Bid Request object model.* Other subordinates to the `BidRequest` provide various forms of information to assist bidders in making targeting and pricing decisions. @@ -515,12 +513,12 @@ The following table summarizes the objects in the Bid Request model and serves a Source 3.2.2 - Request source details on post-auction decisioning (e.g., header bidding). + Request source details on post-auction decisioning (e.g., header bidding). Regs 3.2.3 - Regulatory conditions in effect for all impressions in this bid request. + Regulatory conditions in effect for all impressions in this bid request. Imp @@ -560,7 +558,7 @@ The following table summarizes the objects in the Bid Request model and serves a Pmp 3.2.11 - Collection of private marketplace (PMP) deals applicable to this impression.. + Collection of private marketplace (PMP) deals applicable to this impression. Deal @@ -580,7 +578,7 @@ The following table summarizes the objects in the Bid Request model and serves a Pubisher 3.2.15 - Entity that controls the content of and distributes the site or app.. + Entity that controls the content of and distributes the site or app. Content @@ -701,12 +699,12 @@ There are also several subordinate objects that provide detailed data to potenti imp object array; required - Array of Imp objects (Section 3.2.4) representing the impressions offered. At least 1 Imp object is required. + Array of Imp objects (Section 3.2.4) representing the impressions offered. At least 1 Imp object is required. site object; recommended - Details via a Site object (Section 3.2.13) about the publisher’s website. Only applicable and recommended for websites. + Details via a Site object (Section 3.2.13) about the publisher’s website. Only applicable and recommended for websites. app @@ -741,17 +739,17 @@ There are also several subordinate objects that provide detailed data to potenti tmax integer - Maximum time in milliseconds the exchange allows for bids to be received including Internet latency to avoid timeout. This value supersedes any a priori guidance from the exchange. + Maximum time in milliseconds the exchange allows for bids to be received including Internet latency to avoid timeout. This value supersedes any *a priori* guidance from the exchange. wseat string array - Allowed list of buyer seats (e.g., advertisers, agencies) allowed to bid on this impression. IDs of seats and knowledge of the buyer’s customers to which they refer must be coordinated between bidders and the exchange a priori. At most, only one of wseat and bseat should be used in the same request. Omission of both implies no seat restrictions. + Allowed list of buyer seats (e.g., advertisers, agencies) allowed to bid on this impression. IDs of seats and knowledge of the buyer’s customers to which they refer must be coordinated between bidders and the exchange *a priori*. At most, only one of wseat and bseat should be used in the same request. Omission of both implies no seat restrictions. bseat string array - Block list of buyer seats (e.g., advertisers, agencies) restricted from bidding on this impression. IDs of seats and knowledge of the buyer’s customers to which they refer must be coordinated between bidders and the exchange a priori. At most, only one of wseat and bseat should be used in the same request. Omission of both implies no seat restrictions. . + Block list of buyer seats (e.g., advertisers, agencies) restricted from bidding on this impression. IDs of seats and knowledge of the buyer’s customers to which they refer must be coordinated between bidders and the exchange *a priori*. At most, only one of wseat and bseat should be used in the same request. Omission of both implies no seat restrictions. allimps @@ -766,23 +764,22 @@ There are also several subordinate objects that provide detailed data to potenti wlang string array - Allowed list of languages for creatives using ISO-639-1-alpha-2. 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. + Allowed list of languages for creatives using ISO-639-1-alpha-2. 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. wlangb 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.. - + 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. + 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 Category 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. cattax integer; default 1 - The taxonomy in use for bcat. Refer to the AdCOM 1.0 list List: Category Taxonomies + The taxonomy in use for bcat. Refer to the AdCOM 1.0 list List: Category Taxonomies for values. badv @@ -843,7 +840,7 @@ This object describes the nature and behavior of the entity that is the source o schain object; recommended - This object represents both the links in the supply chain as well as an indicator whether or not the supply chain is complete. Details via the SupplyChain object (section 3.2.25) + This object represents both the links in the supply chain as well as an indicator whether or not the supply chain is complete. Details via the SupplyChain object (section 3.2.25). ext @@ -868,12 +865,12 @@ This object contains any legal, governmental, or industry regulations that the s coppa integer - Flag indicating if this request is subject to the COPPA regulations established by the USA FTC, where 0 = no, 1 = yes. Refer to Section 7.5 for more information. + Flag indicating if this request is subject to the COPPA regulations established by the USA FTC, where 0 = no, 1 = yes. Refer to Section 7.5 for more information. gdpr integer - Flag that indicates whether or not the request is subject to GDPR regulations 0 = No, 1 = Yes, omission indicates Unknown. Refer to Section 7.5 for more information. + Flag that indicates whether or not the request is subject to GDPR regulations 0 = No, 1 = Yes, omission indicates unknown. Refer to Section 7.5 for more information. us_privacy @@ -914,7 +911,7 @@ The presence of `Banner` (Section 3.2.6), `Video` (Section 3.2.7), and/or `Nativ banner object - A Banner object (section 3.2.6); required if this impression is offered as a banner ad opportunity. + A Banner object (section 3.2.6); required if this impression is offered as a banner ad opportunity. video @@ -939,14 +936,12 @@ The presence of `Banner` (Section 3.2.6), `Video` (Section 3.2.7), and/or `Nativ displaymanager string - 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. + 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 string - 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. + 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. instl @@ -956,7 +951,7 @@ Recommended for video and/or apps. tagid string - Identifier for specific ad placement or ad tag that was used to initiate the auction. This can be useful for debugging of any issues, or for optimization by the buyer . + Identifier for specific ad placement or ad tag that was used to initiate the auction. This can be useful for debugging of any issues, or for optimization by the buyer. bidfloor @@ -966,7 +961,7 @@ Recommended for video and/or apps. 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. clickbrowser @@ -977,11 +972,11 @@ Recommended for video and/or apps. secure integer Flag to indicate if the impression requires secure HTTPS URL creative assets and markup, where 0 = non-secure, 1 = secure. If omitted, the secure state is unknown, but non-secure HTTP support can be assumed. - + iframebuster string array - Array of exchange-specific names of supported iframe busters. + Array of exchange-specific names of supported iframe busters. rwdd @@ -1033,7 +1028,7 @@ This object is associated with an impression as an array of metrics. These metri type string; required - Type of metric being presented using exchange curated string names which should be published to bidders a priori. + Type of metric being presented using exchange curated string names which should be published to bidders a priori. value @@ -1070,8 +1065,8 @@ The presence of a `Banner` as a subordinate of the `Imp` object indicates that t format - 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. + 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. w @@ -1086,13 +1081,12 @@ The presence of a `Banner` as a subordinate of the `Imp` object indicates that t btype integer array - Blocked 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.
battr @@ -1117,7 +1111,7 @@ Values: expdir integer array - Directions in which the banner may expand. Refer to List: Expandable Directions in AdCOM 1.0. + Directions in which the banner may expand. Refer to List: Expandable Directions in AdCOM 1.0. api @@ -1127,12 +1121,12 @@ Values: id string - Unique identifier for this banner object. Recommended when Banner objects are used with a Video object (Section 3.2.7) to represent an array of companion ads. Values usually start at 1 and increase with each object; should be unique within an impression. + Unique identifier for this banner object. Recommended when Banner objects are used with a Video object (Section 3.2.7) to represent an array of companion ads. Values usually start at 1 and increase with each object; should be unique within an impression. vcm integer - Relevant only for Banner objects used with a Video object (Section 3.2.7) in an array of companion ads. Indicates the companion banner rendering mode relative to the associated video, where 0 = concurrent, 1 = end-card. + Relevant only for Banner objects used with a Video object (Section 3.2.7) in an array of companion ads. Indicates the companion banner rendering mode relative to the associated video, where 0 = concurrent, 1 = end-card. ext @@ -1146,9 +1140,9 @@ Values: ### 3.2.7 - Object: Video -This object represents an in-stream 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. +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. -The presence of a `Video` as a subordinate of the `Imp` object indicates that this impression is offered as a video type impression. At the publisher’s discretion, that same impression may also be offered as banner, audio, and/or native by also including as `Imp` subordinates objects of those types. However, any given bid for the impression must conform to one of the offered types. +The presence of a `Video` as a subordinate of the `Imp` object indicates that this impression is offered as a video type impression. At the publisher’s discretion, that same impression may also be offered as `Banner`, `Audio`, and/or `Native` by also including as `Imp` subordinates objects of those types. However, any given bid for the impression must conform to one of the offered types. @@ -1160,17 +1154,17 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + - + - + @@ -1185,12 +1179,12 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + - + @@ -1200,7 +1194,7 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + @@ -1210,12 +1204,12 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + - + @@ -1230,8 +1224,7 @@ The presence of a `Video` as a subordinate of the `Imp` object indicates that th - + @@ -1245,8 +1238,8 @@ If a bidder sends markup/creative that is itself skippable, the Bid object shoul - - + + @@ -1257,11 +1250,11 @@ If a bidder sends markup/creative that is itself skippable, the Bid object shoul - + - + @@ -1271,17 +1264,17 @@ If a bidder sends markup/creative that is itself skippable, the Bid object shoul - + - + - + @@ -1291,7 +1284,7 @@ If a bidder sends markup/creative that is itself skippable, the Bid object shoul - + @@ -1332,7 +1325,7 @@ If a bidder sends markup/creative that is itself skippable, the Bid object shoul 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. -The presence of a `Audio` as a subordinate of the `Imp` object indicates that this impression is offered as an audio type impression. At the publisher’s discretion, that same impression may also be offered as banner, video, and/or native by also including as `Imp` subordinates objects of those types. However, any given bid for the impression must conform to one of the offered types. +The presence of a `Audio` as a subordinate of the `Imp` object indicates that this impression is offered as an audio type impression. At the publisher’s discretion, that same impression may also be offered as `Banner`, `Video`, and/or `Native` by also including as `Imp` subordinates objects of those types. However, any given bid for the impression must conform to one of the offered types.
mimes string array; requiredContent MIME types supported (e.g., “video/mp4”).Content MIME types supported (e.g., “video/mp4”).
minduration integer; default 0 recommendedMinimum video ad duration in seconds. This field is mutually exclusive with rqddurs; only one of minduration and rqddurs may be in a bid request.Minimum video ad duration in seconds. This field is mutually exclusive with rqddurs; only one of minduration and rqddurs may be in a bid request.
maxduration integer; recommendedMaximum video ad duration in seconds. This field is mutually exclusive with rqddurs; only one of maxduration and rqddurs may be in a bid request. Maximum video ad duration in seconds. This field is mutually exclusive with rqddurs; only one of maxduration and rqddurs may be in a bid request.
startdelay
poddur integer; recommendedIndicates the total amount of time in seconds that advertisers may fill for a “dynamic” video ad pod (See Section 7.6 for more details), or the dynamic portion of a “hybrid” ad pod. This field is required only for the dynamic portion(s) of video ad pods. This field refers to the length of the entire ad break, whereas minduration/maxduration/rqddurs are constraints relating to the slots that make up the pod Indicates the total amount of time in seconds that advertisers may fill for a “dynamic” video ad pod (See Section 7.6 for more details), or the dynamic portion of a “hybrid” ad pod. This field is required only for the dynamic portion(s) of video ad pods. This field refers to the length of the entire ad break, whereas minduration/maxduration/rqddurs are constraints relating to the slots that make up the pod.
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 Substypes - Audio/Video in AdCOM 1.0.
w
h integer; recommendedHeight of the video player in device independent pixels (DIPS). Height of the video player in device independent pixels (DIPS).
podid
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 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.
placement
skip integerIndicates 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.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
sequenceinteger; default 0 DEPRECATEDIf multiple ad impressions are offered in the same bid request, the sequence number will allow for the coordinated delivery of multiple creatives. integer; default 0
DEPRECATED		If multiple ad impressions are offered in the same bid request, the sequence number will allow for the coordinated delivery of multiple creatives.
slotinpodmincpmpersec float Minimum CPM per second. This is a price floor for the "dynamic" portion of a video ad pod, relative to the duration of bids an advertiser may submit.
battr integer arrayBlocked creative attributes. Refer to List: Creative Attributes in AdCOM 1.0Blocked creative attributes. Refer to List: Creative Attributes in AdCOM 1.0.
maxextended
minbitrate inptegerMinumim bit rate in Kbps.Minumim bit rate in Kbps (kilobits per second).
maxbitrate integerMaximum bit rate in Kbps.Maximum bit rate in Kbps (kilobits per second).
boxingallowed integer; default 1Indicates if letter-boxing of 4:3 content into a 16:9 window is allowed, where 0=no, 1=yes Indicates if letter-boxing of 4:3 content into a 16:9 window is allowed, where 0=no, 1=yes.
playbackmethod
playbackend integerTHe event that causes playback to end. Refer to List: Playback Cessation Modes in AdCOM 1.0.The event that causes playback to end. Refer to List: Playback Cessation Modes in AdCOM 1.0.
delivery
@@ -1344,22 +1337,22 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th - + - + - + - + @@ -1369,12 +1362,12 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th - + - + @@ -1384,12 +1377,12 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th - + - - + + @@ -1413,23 +1406,23 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th - - + + - + - + - + @@ -1449,12 +1442,12 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th - + - + @@ -1476,9 +1469,9 @@ The presence of a `Audio` as a subordinate of the `Imp` object indicates that th This object represents a native type impression. Native ad units are intended to blend seamlessly into the surrounding content (e.g., a sponsored Twitter or Facebook post). As such, the response must be well-structured to afford the publisher fine-grained control over rendering. -The Native Subcommittee has developed a companion specification to OpenRTB called the Dynamic Native Ads API. It defines the request parameters and response markup structure of native ad units. This object provides the means of transporting request parameters as an opaque string so that the specific parameters can evolve separately under the auspices of the Dynamic Native Ads API. Similarly, the ad markup served will be structured according to that specification. +The Native Subcommittee has developed a companion specification to OpenRTB called the Dynamic Native Ads API. It defines the request parameters and response markup structure of native ad units. This object provides the means of transporting request parameters as an opaque string so that the specific parameters can evolve separately under the auspices of the Dynamic Native Ads API. Similarly, the ad markup served will be structured according to that specification. -The presence of a `Native` as a subordinate of the `Imp` object indicates that this impression is offered as a native type impression. At the publisher’s discretion, that same impression may also be offered as banner, video, and/or audio by also including as `Imp` subordinates objects of those types. However, any given bid for the impression must conform to one of the offered types. +The presence of a `Native` as a subordinate of the `Imp` object indicates that this impression is offered as a native type impression. At the publisher’s discretion, that same impression may also be offered as `Banner`, `Video`, and/or `Audio` by also including as `Imp` subordinates objects of those types. However, any given bid for the impression must conform to one of the offered types.
mimes string array; requiredContent MIME types supported (e.g., “audio/mp4”).Content MIME types supported (e.g., “audio/mp4”).
minduration integer; default 0 recommendedMinimum audio ad duration in seconds. This field is mutually exclusive with rqddurs; only one of minduration and rqddurs may be in a bid request.Minimum audio ad duration in seconds. This field is mutually exclusive with rqddurs; only one of minduration and rqddurs may be in a bid request.
maxduration integer; recommendedMaximum audio ad duration in seconds. This field is mutually exclusive with rqddurs; only one of maxduration and rqddurs may be in a bid request. Maximum audio ad duration in seconds. This field is mutually exclusive with rqddurs; only one of maxduration and rqddurs may be in a bid request.
poddur integer; recommendedIndicates the total amount of time that advertisers may fill for a "dynamic" audio ad pod, or the dynamic portion of a "hybrid" ad pod. This field is required only for the dynamic portion(s) of audio ad pods. This field refers to the length of the entire ad break, wheras minduration/maxduration/rqddurs are constraints relating to the slots that make up the pod.Indicates the total amount of time that advertisers may fill for a "dynamic" audio ad pod, or the dynamic portion of a "hybrid" ad pod. This field is required only for the dynamic portion(s) of audio ad pods. This field refers to the length of the entire ad break, wheras minduration/maxduration/rqddurs are constraints relating to the slots that make up the pod.
protocols
startdelay integer; recommendedIndicates the start delay in seconds for pre-roll, mid-roll, or post-roll ad placements. Refer to List: Start Delay Modes in AdCOM 1.0. Indicates the start delay in seconds for pre-roll, mid-roll, or post-roll ad placements. Refer to List: Start Delay Modes in AdCOM 1.0.
rqddurs integer arrayPrecise acceptable durations for audio creatives in seconds. This field specifically targets the live audio/radio use case where non-exact ad durations would result in undesirable 'dead air'. This field is mutually exclusive with minduraiton and maxduration; if rqddurs is specified, minduraiton and maxduration must not be specified and vice versa. Precise acceptable durations for audio creatives in seconds. This field specifically targets the live audio/radio use case where non-exact ad durations would result in undesirable 'dead air'. This field is mutually exclusive with minduraiton and maxduration; if rqddurs is specified, minduraiton and maxduration must not be specified and vice versa.
podid
podseq integer; default 0The sequence (position) of the audio ad pod within a content stream. Refer to List: Pod Sequence in AdCOM 1.0 for guidance on the use of this field. The sequence (position) of the audio ad pod within a content stream. Refer to List: Pod Sequence in AdCOM 1.0 for guidance on the use of this field.
sequenceinteger; default 0 DEPRECATEDIf multiple ad impressions are offered in the same bid request, the sequence number will allow for the coordinated delivery of multiple creatives. integer; default 0
DEPRECATED		If multiple ad impressions are offered in the same bid request, the sequence number will allow for the coordinated delivery of multiple creatives.
slotinpod
minbitrateinptegerMinumim bit rate in Kbps.integerMinumim bit rate in Kbps (kilobits per second).
maxbitrate integerMaximum bit rate in Kbps.Maximum bit rate in Kbps (kilobits per second).
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.
companionad object arrayArray of Banner objects (Section 3.2.6) if companion ads are available.Array of Banner objects (Section 3.2.6) if companion ads are available.
api
feed integerType of audio feed. Refer to List: Feed Types in AdCOM 1.0 Type of audio feed. Refer to List: Feed Types in AdCOM 1.0.
stitched integerIndicates if the ad is stitched with audio content or delivered independently, where 0=no, 1=yes. Indicates if the ad is stitched with audio content or delivered independently, where 0=no, 1=yes.
nvol
@@ -1490,14 +1483,12 @@ The presence of a `Native` as a subordinate of the `Imp` object indicates that t - + - + @@ -1507,7 +1498,7 @@ The presence of a `Native` as a subordinate of the `Imp` object indicates that t - + @@ -1537,7 +1528,7 @@ This object represents an allowed size (i.e., height and width combination) or F - + @@ -1581,7 +1572,7 @@ This object is the private marketplace container for direct deals between buyers - + @@ -1594,8 +1585,7 @@ This object is the private marketplace container for direct deals between buyers ### 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. +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.
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+ .
ver string; recommendedVersion of the Dynamic Native Ads API to which request complies; highly recommended for efficient parsing. Version of the Dynamic Native Ads API to which request complies; highly recommended for efficient parsing.
api
battr integer arrayBlocked creative attributes/ Refer to List: Creative Attributes in AdCOM.Blocked creative attributes. Refer to List: Creative Attributes in AdCOM.
ext
h integerHeight in device independent pixels (DIPS). Height in device independent pixels (DIPS).
wratio
deals object arrayArray of Deal (Section 3.2.12) objects that convey the specific deals applicable to this impression. Array of Deal (Section 3.2.12) objects that convey the specific deals applicable to this impression.
ext
@@ -1612,7 +1602,7 @@ between a buyer and a seller. Its presence with the `Pmp` collection indicates t - + @@ -1662,7 +1652,7 @@ This object should be included if the ad supported content is a website as oppos - + @@ -1677,17 +1667,17 @@ This object should be included if the ad supported content is a website as oppos - + - + - + @@ -1727,12 +1717,12 @@ This object should be included if the ad supported content is a website as oppos - + - + @@ -1763,12 +1753,12 @@ This object should be included if the ad supported content is a non-browser appl - + - + @@ -1788,21 +1778,21 @@ This object should be included if the ad supported content is a non-browser appl - + - + - + - + @@ -1828,12 +1818,12 @@ This object should be included if the ad supported content is a non-browser appl - + - + @@ -1861,12 +1851,12 @@ This object describes the entity who directly supplies inventory to and is paid - + - + @@ -1876,7 +1866,7 @@ This object describes the entity who directly supplies inventory to and is paid - + @@ -1895,7 +1885,7 @@ This object describes the entity who directly supplies inventory to and is paid ### 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. +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.
bidfloor float; default 0Minimum bid for this impression expressed in CPM. Minimum bid for this impression expressed in CPM.
bidfloorcur
name stringSite name (may be aliased at the publisher's request). Site name (may be aliased at the publisher's request).
domain
cat string arrayArray of IAB TechLab 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 TechLab 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 TechLab 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 definied by the cattax field.
page
keywords stringComma separated list of keywords about the site. Only one of ‘keywords’ or ‘kwarray’ may be present.Comma separated list of keywords about the site. Only one of keywords or kwarray may be present.
kwarray string arrayArray of keywords about the site. Only one of ‘keywords’ or ‘kwarray’ may be present.Array of keywords about the site. Only one of keywords or kwarray may be present.
ext
name stringApp name (may be aliased at the publisher's request). App name (may be aliased at the publisher's request).
bundle stringThe store ID of the app in an app store. See OTT/CTV Store Assigned App Identification Guidelines for more details about expected strings for CTV app stores. For mobile apps in Google Play Store, these should be bundle or package names (e.g. com.foo.mygame). For apps in Apple App Store, these should be a numeric ID. The store ID of the app in an app store. See OTT/CTV Store Assigned App Identification Guidelines for more details about expected strings for CTV app stores. For mobile apps in Google Play Store, these should be bundle or package names (e.g. com.foo.mygame). For apps in Apple App Store, these should be a numeric ID.
domain
cat string arrayArray of IAB content categories of the app. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied IAB 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 TechLab 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 TechLab 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.
versrtingstring Application version.
keywords stringComma separated list of keywords about the app. Only one of ‘keywords’ or ‘kwarray’ may be present.Comma separated list of keywords about the app. Only one of keywords or kwarray may be present.
kwarray string arrayArray of keywords about the app. Only one of ‘keywords’ or ‘kwarray’ may be present.Array of keywords about the app. Only one of keywords or kwarray may be present.
ext
id stringExchange-specific seller ID. Every ID must map to only a single entity that is paid for inventory transacted via that ID. Corresponds to a seller_id of a seller in the exchange’s sellers.json file.Exchange-specific seller ID. Every ID must map to only a single entity that is paid for inventory transacted via that ID. Corresponds to a seller_id of a seller in the exchange’s sellers.json file.
name stringSeller name (may be aliased at the seller's request). Seller name (may be aliased at the seller's request).
cattax
cat string arrayArray of IABTL content categories of the publisher. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied IAB 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.
domain
@@ -1911,17 +1901,17 @@ This object describes the content in which the impression will appear, which may - + - + - + @@ -1966,7 +1956,7 @@ This object describes the content in which the impression will appear, which may - + @@ -1996,12 +1986,12 @@ This object describes the content in which the impression will appear, which may - + - + @@ -2021,12 +2011,12 @@ This object describes the content in which the impression will appear, which may - + - + @@ -2087,8 +2077,8 @@ This object defines the producer of the content in which the ad will be shown. T - + @@ -2118,7 +2108,7 @@ This object provides information pertaining to the device through which the user - + @@ -2133,13 +2123,12 @@ This object provides information pertaining to the device through which the user - + - - + + @@ -2219,17 +2208,17 @@ If a client supports User-Agent Client Hints, and ‘sua’ field is present, bi - + - + - + @@ -2312,12 +2301,12 @@ The `lat`/`lon` attributes should only be passed if they conform to the accuracy - + - + @@ -2393,7 +2382,7 @@ This object contains information known or derived about the human user of the de - + @@ -2408,12 +2397,12 @@ This object contains information known or derived about the human user of the de - + - + - + @@ -2427,18 +2416,18 @@ This object contains information known or derived about the human user of the de - + - + - + @@ -2488,7 +2477,7 @@ The data and segment objects together allow additional data about the related ob ### 3.2.22 - Object: Segment -Segment objects are essentially key-value pairs that convey specific units of data. The parent `Data` object is a collection of such values from a given data provider. The specific segment names and value options must be published by the exchange a priori to its bidders. +Segment objects are essentially key-value pairs that convey specific units of data. The parent `Data` object is a collection of such values from a given data provider. The specific segment names and value options must be published by the exchange *a priori* to its bidders.
episode integerEpisode number. Episode number.
title stringContent title. Video Examples: “Search Committee” (television), “A New Hope” (movie), or “Endgame” (made for web). Non-Video Example: “Why an Antarctic Glacier Is Melting So Quickly” (Time magazine article).Content title.
*Video Examples:* “Search Committee” (television), “A New Hope” (movie), or “Endgame” (made for web).
*Non-Video Example:* “Why an Antarctic Glacier Is Melting So Quickly” (Time magazine article).
series stringContent series. Video Examples: “The Office” (television), “Star Wars” (movie), or “Arby ‘N’ The Chief” (made for web). Non-Video Example: “Ecocentric” (Time Magazine blog).Content series.
*Video Examples:* “The Office” (television), “Star Wars” (movie), or “Arby ‘N’ The Chief” (made for web).
*Non-Video Example:* “Ecocentric” (Time Magazine blog).
season
cat string arrayArray of IAB content categories that describe the content. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied IAB 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
keywords stringComma separated list of keywords describing the content. Only one of ‘keywords’ or ‘kwarray’ may be present.Comma separated list of keywords describing the content. Only one of keywords or kwarray may be present.
kwarry string arrayArray of keywords about the site. Only one of ‘keywords’ or ‘kwarray’ may be present.Array of keywords about the site. Only one of keywords or kwarray may be present.
livestream
language stringContent language using ISO-639-1-alpha-2. Only one of language or langb should be present.Content language using ISO-639-1-alpha-2. Only one of language or langb should be present.
langb stringContent language using IETF BCP 47. Only one of language or langb should be present.Content language using IETF BCP 47. Only one of language or langb should be present.
embeddable
cat string arrayArray of IAB content categories that describe the content producer. -The taxonomy to be used is defined by the cattax field. If no cattax field is supplied IAB 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
geo object; recommendedLocation of the device assumed to be the user’s current location defined by a Geo object (Section 3.2.19).Location of the device assumed to be the user’s current location defined by a Geo object (Section 3.2.19).
dnt
ua stringBrowser 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.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.
suaUserAgent objectStructured user agent information defined by a UserAgent object (see Section 3.2.29). If both ‘ua’ and ‘sua’ are present in the bid request, ‘sua’ should be considered the more accurate representation of the device attributes. This is because the ‘ua’ may contain a frozen or reduced user agent string.objectStructured user agent information defined by a UserAgent object (see Section 3.2.29). If both ua and sua are present in the bid request, sua should be considered the more accurate representation of the device attributes. This is because the ua may contain a frozen or reduced user agent string.
ip
language stringBrowser language using ISO-639-1-alpha-2. Only one of language or langb should be present.Browser language using ISO-639-1-alpha-2. Only one of language or langb should be present.
langb stringBrowser language using IETF BCP 47. Only one of language or langb should be present.Browser language using IETF BCP 47. Only one of language or langb should be present.
carrier stringCarrier or ISP (e.g., “VERIZON”) using exchange curated string names which should be published to bidders a priori.Carrier or ISP (e.g., “VERIZON”) using exchange curated string names which should be published to bidders *a priori*.
mccmnc
type integerSource of location data; recommended when passing lat/lon. Refer to List: Location Types in AdCOM 1.0.Source of location data; recommended when passing lat/lon. Refer to List: Location Types in AdCOM 1.0.
accuracy integerEstimated 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.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
buyeruid stringBuyer-specific ID for the user as mapped by the exchange for the buyer. Buyer-specific ID for the user as mapped by the exchange for the buyer.
yob
keywords stringComma separated list of keywords, interests, or intent. Only one of ‘keywords’ or ‘kwarray’ may be present.Comma separated list of keywords, interests, or intent. Only one of keywords or kwarray may be present.
kwarrykwarray string arrayArray of keywords about the user. Only one of ‘keywords’ or ‘kwarray’ may be present.Array of keywords about the user. Only one of keywords or kwarray may be present.
customdata
dataoject arrayobject array Additional user data. Each Data object (Section 3.2.21) represents a different data source.
consent stringWhen GDPR regulations are in effect this attribute contains the Transparency and Consent Framework’s Consent String data structure. When GDPR regulations are in effect this attribute contains the Transparency and Consent Framework’s Consent String data structure.
eids object arrayDetails for support of a standard protocol for multiple third party identity providers (Section 3.2.27)Details for support of a standard protocol for multiple third party identity providers (Section 3.2.27).
ext
@@ -2524,7 +2513,7 @@ Segment objects are essentially key-value pairs that convey specific units of da ### 3.2.23 - Object: Network -This object describes the network an ad will be displayed on. A Network is defined as the parent entity of the Channel object’s entity for the purposes of organizing Channels. Examples are companies that own and/or license a collection of content channels (Viacom, Discovery, CBS, WarnerMedia, Turner and others), or studio that creates such content and self-distributes content. 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 network an ad will be displayed on. A Network is defined as the parent entity of the `Channel` object’s entity for the purposes of organizing Channels. Examples are companies that own and/or license a collection of content channels (Viacom, Discovery, CBS, WarnerMedia, Turner and others), or studio that creates such content and self-distributes content. Name is a human-readable field while domain and id can be used for reporting and targeting purposes. See 7.6 for further examples.
@@ -2613,7 +2602,7 @@ This object is composed of a set of nodes where each node represents a specific - + @@ -2632,7 +2621,7 @@ This object is composed of a set of nodes where each node represents a specific ### 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: +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:
nodes object array; requiredArray of SupplyChainNode objects in the order of the chain. In a complete supply chain, the first node represents the initial advertising system and seller ID involved in the transaction, i.e. the owner of the site, app, or other medium. In an incomplete supply chain, it represents the first known node. The last node represents the entity sending this bid request.Array of SupplyChainNode objects in the order of the chain. In a complete supply chain, the first node represents the initial advertising system and seller ID involved in the transaction, i.e. the owner of the site, app, or other medium. In an incomplete supply chain, it represents the first known node. The last node represents the entity sending this bid request.
ver
@@ -2649,7 +2638,7 @@ This object is associated with a SupplyChain object as an array of nodes. These - + @@ -2659,7 +2648,7 @@ This object is associated with a SupplyChain object as an array of nodes. These - + @@ -2669,7 +2658,7 @@ This object is associated with a SupplyChain object as an array of nodes. These - + @@ -2701,7 +2690,7 @@ Extended identifiers support in the OpenRTB specification allows buyers to use a - + @@ -2747,7 +2736,7 @@ This object contains a single user identifier provided as part of extended ident ### 3.2.29 - Object: UserAgent -Structured user agent information, which can be used when a client supports [User-Agent Client Hints](https://wicg.github.io/ua-client-hints/). If both `device.ua` and `device.sua` are present in the bid request, `device.sua` should be considered the more accurate representation of the device attributes. This is because the device.ua may contain a frozen or reduced user agent string due to deprecation of user agent strings by browsers. +Structured user agent information, which can be used when a client supports [User-Agent Client Hints](https://wicg.github.io/ua-client-hints/). If both `device.ua` and `device.sua` are present in the bid request, `device.sua` should be considered the more accurate representation of the device attributes. This is because the `device.ua` may contain a frozen or reduced user agent string due to deprecation of user agent strings by browsers.
sid string; requiredThe identifier associated with the seller or reseller account within the advertising system. This must contain the same value used in transactions (i.e. OpenRTB bid requests) in the field specified by the SSP/exchange. Typically, in OpenRTB, this is publisher.id. For OpenDirect it is typically the publisher’s organization ID.Should be limited to 64 characters in length.The identifier associated with the seller or reseller account within the advertising system. This must contain the same value used in transactions (i.e. OpenRTB bid requests) in the field specified by the SSP/exchange. Typically, in OpenRTB, this is publisher.id. For OpenDirect it is typically the publisher’s organization ID. Should be limited to 64 characters in length.
rid
name stringThe name of the company (the legal entity) that is paid for inventory transacted under the given seller_ID. This value is optional and should NOT be included if it exists in the advertising system’s sellers.json file.The name of the company (the legal entity) that is paid for inventory transacted under the given seller_ID. This value is optional and should NOT be included if it exists in the advertising system’s sellers.json file.
domain
hp integerIndicates 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.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
uids object arrayArray of extended ID UID objects from the given source. Refer to 3.2.28 Extended Identifier UIDsArray of extended ID UID objects from the given source. Refer to 3.2.28 Extended Identifier UIDs
ext
@@ -2758,13 +2747,13 @@ Structured user agent information, which can be used when a client supports [Use - - + + - + @@ -2800,7 +2789,7 @@ Structured user agent information, which can be used when a client supports [Use
browsersarray of BrandVersion objects; recommendedEach BrandVersion object (see Section 3.2.30) identifies a browser or similar software component. Implementers should send brands and versions derived from the Sec-CH-UA-Full-Version-List header*.array of BrandVersion objects; recommendedEach BrandVersion object (see Section 3.2.30) identifies a browser or similar software component. Implementers should send brands and versions derived from the Sec-CH-UA-Full-Version-List header*.
platform 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 *.A 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
-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 @@ -2885,12 +2874,11 @@ 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) -Figure 4: Bid Response object model. +*Figure 4: Bid Response object model.* Referring to the figure, the actual response objects are shown on the left, specifically the `BidResponse` top level object the seat specific `SeatBid` collections of `Bid` objects. The other objects shown are those objects from the bid request to which response objects related. Specifically, `BidResponse` includes the `BidRequest` ID for positive tracking purposes, and since a request can include multiple impressions `Bid` includes the ID of the `Imp` for which the bid is an offer to purchase. If a bid is made under the terms of a private marketplace deal, the `Bid` also includes the ID of the specific `Deal` object. @@ -2970,8 +2958,7 @@ To express a “no-bid”, the options are to return an empty response with HTTP 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. + 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 @@ -3008,7 +2995,7 @@ A bid response can contain multiple `SeatBid` objects, each on behalf of a diffe seat string - ID of the buyer seat (e.g., advertiser, agency) on whose behalf this bid is made + ID of the buyer seat (e.g., advertiser, agency) on whose behalf this bid is made. group @@ -3028,7 +3015,7 @@ A bid response can contain multiple `SeatBid` objects, each on behalf of a diffe ### 4.2.3 - Object: Bid -A `SeatBid` object contains one or more Bid objects, each of which relates to a specific impression in the bid request via the `impid` attribute and constitutes an offer to buy that impression for a given `price`. +A `SeatBid` object contains one or more `Bid` objects, each of which relates to a specific impression in the bid request via the `impid` attribute and constitutes an offer to buy that impression for a given `price`. @@ -3070,8 +3057,7 @@ A `SeatBid` object contains one or more Bid objects, each of which relates to a - + @@ -3081,8 +3067,7 @@ Substitution macros (Section 4.4) may be included. - + @@ -3117,7 +3102,7 @@ Exchanges can mandate that only one domain is allowed. - + @@ -3147,12 +3132,12 @@ Exchanges can mandate that only one domain is allowed. - + - + @@ -3192,21 +3177,17 @@ Exchanges can mandate that only one domain is allowed. - + - - + + @@ -3224,7 +3205,7 @@ For each bid, the `nurl` attribute can contain the win notice URL. If the bidder **BEST PRACTICE**: Firing of the billing notice should be server-side and as “close” as possible to where the exchange books revenue in order to minimize discrepancies between exchange and bidder. -**BEST PRACTICE**: For VAST Video, the IAB prescribes that the VAST impression event is the official signal that the impression is billable. If the `burl` attribute is specified, it too should be fired at the same time if the exchange is adhering to this policy. However, subtle technical issues may lead to additional discrepancies and bidders are cautioned to avoid this scenario. +**BEST PRACTICE**: For VAST Video, the IAB Tech Lab prescribes that the VAST impression event is the official signal that the impression is billable. If the `burl` attribute is specified, it too should be fired at the same time if the exchange is adhering to this policy. However, subtle technical issues may lead to additional discrepancies and bidders are cautioned to avoid this scenario. Several other attributes are used for ad quality checks or enforcing publisher restrictions. These include the advertiser domain via `adomain`, a non-cache-busted URL to an image representative of the content of the campaign via `iurl`, an ID of the campaign and of the creative within the campaign via `cid` and `crid` respectively, an array of creative attribute via `attr`, and the dimensions via `h` and `w`. If the bid pertains to a private marketplace deal, the `dealid` attribute is used to reference that agreement from the bid request. @@ -3243,16 +3224,16 @@ In this method, ad markup is returned to the exchange is via the win notice. In In this method, ad markup is returned directly in the bid itself. This is accomplished via the `bid.adm` attribute. If both the `adm` attribute and win notice return data, the `adm` contents will take precedence. -### 4.3.3 - Comparison of Ad Serving Approaches +### 4.3.3 - Comparison of Ad Serving Approaches Each of the ad serving methods has its own advantages that may be of varying importance to either the exchange or the bidder. -### 4.3.4 - Ad Served on the Win Notice +**Ad Served on the Win Notice** - *Reduced Bandwidth Costs*: Serving ad markup only upon winning can save large amounts of bandwidth usage, the costs for which can be large at high volumes or when sending multiple bids per bid response. - *Additional Bidder Flexibility*: Bidders may typically know the ad they will serve at the time of bid, but this provides an additional optional decision point after the clearing price has been established. -### 4.3.5 - Ad Served in the Bid +**Ad Served in the Bid** - *Reduced Risk of Forfeiture*: A forfeit is the scenario in which a bidder wins, but forfeits due to failure to serve the ad markup. The risk of an additional HTTP failure (e.g., calling the win notice) is mitigated by this method. - *Potential Concurrency*: The exchange can choose to return that ad markup and call the win notice concurrently, thereby improving user experience. @@ -3260,7 +3241,7 @@ Each of the ad serving methods has its own advantages that may be of varying imp ## 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. +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.
Note that the substitution is simple in the sense that wherever a legal macro is found, it will be replaced without regard for syntax correctness. Furthermore, if the source value is an optional parameter that was not specified, the macro will simply be removed (i.e., replaced with a zero-length string). 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. @@ -3332,9 +3313,9 @@ Note that OpenRTB compliance exchanges must support all macros for which data is 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: +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: -${AUCTION PRICE:B64} +`${AUCTION PRICE:B64}` ### 4.4.1 - Notes on the macro ${AUCTION_MIN_TO_WIN} @@ -3346,12 +3327,13 @@ Except where the value "AUDIT" applies, as above, the macro is replaced by: - 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 +- 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. Note, the exchange in question may not be the final decision-maker. It may propagate two or more bids into a second auction. In that case, still only one auction bid is the "winner" and the macro is replaced for all bids as above. In the following examples, assume an auction with a floor price of $0.85, and that each row is a competing bid. Note the exchange may also choose to replace the macros with the empty string for the reasons above. +For a first-price auction:
adm stringOptional means of conveying ad markup in case the bid wins; supersedes the win notice if markup is included in both. -Substitution macros (Section 4.4) may be included.Optional means of conveying ad markup in case the bid wins; supersedes the win notice if markup is included in both. Substitution macros (Section 4.4) may be included.
adid
adomain string arrayAdvertiser 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.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
cat string arrayIAB content categories of the creative. The taxonomy to be used is defined by the cattax field. If no cattax field is supplied IAB Content Category 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
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 stringLanguage of the creative using IETF BCP 47. Only one of language or langb should be present.Language of the creative using IETF BCP 47. Only one of language or langb should be present.
dealid
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 = NativeType 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
slotinpodinteger; deafault 0Indicates 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.integer; default 0Indicates 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
@@ -3384,7 +3366,7 @@ In the following examples, assume an auction with a floor price of $0.85, and th
-For a second-price auction (where, for the sake of the illustration, the clearing price is the second-best price plus $0.01): +For a second-price auction (where, for the sake of the illustration, the clearing price is the second-best price plus $0.01):
@@ -3651,7 +3633,7 @@ This example builds the first and adds parameters to describe support for an exp ### 6.2.3 - Example 3 – Mobile -This example uses a device object to reflect a mobile device, and an app object to reflect a request from a mobile application . +This example uses a device object to reflect a mobile device, and an app object to reflect a request from a mobile application. ```javascript { @@ -4426,6 +4408,24 @@ 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.1 - No-Bid Signaling](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#71-no-bid-signaling-) + +- [7.2 - Impression Expiration](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#72-impression-expiration-) + +- [7.3 - PMP & Direct Deals](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#73-pmp--direct-deals-) + +- [7.4 - Skippability](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#74-skippability-) + +- [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](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#76-pod-bidding-for-video-and-audio-) + +- [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](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#78-counting-billable-events-and-tracked-ads-) + # Appendix A. Additional Information diff --git a/README.md b/README.md index 07de5a4..f287d37 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,14 @@ https://iabtechlab.com/openrtb #### AdCOM: Advertising Common Object Model https://github.com/InteractiveAdvertisingBureau/AdCOM -#### VERSIONING POLICY TBD +#### VERSIONING POLICY +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. + +The current version of the OpenRTB specification is updated approximately once a month if there are non-breaking improvements to be released such as new fields, objects, or values in enumerated lists. Errata, such as clarifications or corrections to descriptions not materially impacting the specification itself, are also addressed during monthly updates. See Errata. + +Release branches are created for each monthly release and the history of these can be reviewed on GitHub. The master branch for the repository will always reflect the most recent release, whereas ongoing development work occurs in the 'develop' branch. + +This versioning policy is a break from historical practice for OpenRTB 2.x. In versions of OpenRTB prior to 2.6, major version numbers represent breaking changes and minor version numbers represent non-breaking changes. #### Contact For more information, or to get involved, please email support@iabtechlab.com. diff --git a/assets/ORTB ERD.png b/assets/ORTB ERD.png new file mode 100644 index 0000000000000000000000000000000000000000..c597e9dabe56124e9bee25d5a27f469352197b41 GIT binary patch literal 48214 zcmc%xWmJ_>*98nyA}!sW0@9rl(kb0t(g+AhOG$TwfOMC1N~d%qA>G{|??!#@=N{j9 zzQ6Cw7-w)e=gPhJwbop7&PA}IyaX}=J^};;1hSOm8zl$`s0i?4go6T~wAvGEf?tr1 zN)jRvWj_daz#rD88d7F*au9UjJsboKBtFEmr%k|15R%|O@5LcsLO}od92_U;9R$q3 zZREl4ryoi1dfMmjZ>UVD|Jed6A`|*Q?-`#qeTeBa1i#?zB{dx(AP_O0UXTzeX}I7r z5#Fh2IBCeq@*3OOFdCZJ8JRM=+Sots1;Ovi3*Oq8IvJ9>+F08<^12F;|Ji~Uynp(b ziJbJ$CQeoYc+`{^vMvOdXBizq5CGXJ``OyP3Ma`~S1s(>H&2 z`*UA^PsjgsFkU57M>}ihr>j!6edi>|%Kzsa|Gyvq??v)I9gA1-ovW#}#+!FGrnZh? zS3yn=c7CS+^PB&3PtE_`lY@i%zxVvFZ~pDc&-64}|22Alr{>S6U~U8v_?iAQ&w>c< zuT(xkKnOudy%AP%h1^ev_fQd=z7)Qsf+r;ntSIOtmw^zb+Q&0pCYn=yBZNxG^3v~i zIH~=vmGv{aj!=}C3e-#9Pp=Rd4Pz_lU^=J~4AoK5KOuhVygI^6m{~}d&%avmyv0dr zbXG{`y->OE+*O$>rSrJhof0`kgMon*7D7dZf$=pETWK`lkljcB&qt61P-4$u|9yQd zymG!Xv8t?LELE&hXw>{oO`~95>w;<;0qTShljQvO*I#60tadDI6SBg1At@{P+}24d?-y#O}my0Z0ny*E=N7#1c~(O@`=o}v^&FG%O#rCW=$Us zoN~bF$|*?oYG%l=0>G(ImEiUl8>-)Ci(>}cb@WtyA62YB{)UDDe+LD5Qsn7dw2cXd zt3pUflJ`{+4;%umo-?Y-r=+JV6b^$}TL|+tUWulVz=e2WB-8yZN=&GL*Q8htff{_T zCk##3 zN@NPfFk158tV5A1=IeNT|ANp&Iq$9UeF*y4I~8f_(Ik-}Tv)6g^Nd~A6s&i$w49vx;;t?kd?ji=@42$R5|J>BYgHxN&M$4}#J zT5%Z4u5W_1TuHEx_*}G|qF2x{yok&0rB3~5$71D4U%`837bjWgbUvw+?waYug$d3G znR~88W&v+rJt$IA6^7wIPYGl%oKD00jh3q=tNCy5wtl1&$!IWN_7JGwbnJfad)d=Y zW-Q(o?xAxx9VnMtM=sHtT|C9@_G%)25l^Of;e!~ftcgh(uPmKb2rXC+&%_NLZZE)5 zv@1KBjT+iRIw&BGSArG7*m=90ce{yan+V3c-OUnsX%=c@W%V-597>gDW;1`Jw|Fr! zRUU`ol=JfM=}I$zL)}oc(@(zseZ5v|v+&_yKDQQfN_*IRAypM zFHR)SQ&+Q&3dk;@ReMgWUUG5@O*J#86xCB@(_Fl%MP5k8Jjfz@y`Qk@RD2NLhu)Yg+ zZ7pJ<*wl`DGv&+K5-*f?6eR~qM;o2@sO3^D9QP&**}&*{(t_wV0tcshhiBg}4_1ANZ~I#0YrR}) zEK{puwNevAOe+=b&swxi@c|ay(v?rakPQZ`Bn$!q_uKQG6b`EhT$T)b{b6b$?H21<5Qj^&QDZl1 zET{CEtPOWqO=VBAJZ}=UZEKw%1Bw`QJt3I|O;4I$rwLg7e7J#vm^;$cyFcmueua#b zyN2n_lsxkIXnk;7s$CmLul{3;=Yhv>FwvVqt=U!OW=}tr<8H*|-XVa3`}(&q7M;qm ztr-Jwn%_u0n%i6u(yNwP zUy#EL{0@nyn`&-Qt4WzA?tJy~BNn}sAMHysGI}QZcF|hPT!TMR6AmiN*GJLWVlq2U zDjDH$Hh_GxiqTgOO(<1C7i($W^{Hhs7(46cie!v)s>0hwj_4%YY0Q_#$h zAW_9$#8npH&EqvBry$S1o=70-lZ-4=^BeSYciHQ!LW_3Z?cJ5phk4IvLNI*%5&QMS z`NVvU)nEd{U_Yv!IwJz2KZLXAsYYJ8wu-N86;7+`iIJtH<<02^&(7fQvMzsSkRXXV z;;nqYde)nKw^GhnNT~gN7Mb{BZ-K}80wHYaORaBE-q#OW~Y>`sogbdt*;_bY}uEp88w__k*Q>5t2awAGH?qS<6Uge ztKClZh8h%`^h7u49101kolf%?U8u5K+~SE+QaSC!t_Oz+;4qHMj6FAplCkL3hQO0{ zb@4$eN5H;c)x{r1RzeJ zJBfb9Lyh=M*UKGMnR_#@BEPEB>T#3C<2XJsF(nlNfHjzlg(_1-bEk0w+!$KbqPX&5 z)Cb=u98hsBa~L2`^19LZOx#D~L=WMc9E3UnexPR1)!z8|4>g)dbK=ER+epkp1EXIj z9jmV6r<4Jk&yk73xzZXxQnA$U!wtE)V4+|v`$x~UxqhmdZlZf zZ?nCm;Y-!V&`Wc>PqHyt3RUsE97tptr&m|Bz4u7G^Q{1|XgY|*D`{@A zukZEkOK~ZZfVRiq?&4~mIg2^9((!c6sL^zpOmarItXmz=h%TLdHtPgzD8hpR(eP9c zdy1wU8E3I`X+|_<>A!M}OR5ZxwTP1>pFi{~Gc_N7vSd~-*W=iL^6?IS1Dz9V=#Qmoo1Dl-nY)_(v1+yh?a0!lb>yapNTtfpNez1H)NKYx z^WXUnI4f*d-evU$4t$ir=@;hyF7EyRQQ)`ABZem|>%>MrVa4Of)LS4Dz)(`ty z45_1~PwTGpsV%`sm!GLUrj)7q{Q+DvR z*}KcX=)tdgJ%$E~|9X-lvX|sdlh=p?RmdGWnzM~*^5$UPur~eH^;{)IIlYb~vRvo# z$ArocEgI*?`L>02cg-gujArJ@dkbPee~lrDMoPMF&e4doHqT{`c)D&~7V?MfjAy&d zTpkEsuRxpOUG2}UDK6O5{hV%cv7@fAYuLaJf?CD95jmCl{i@#96)k#0_NFLLvWbqs zwAD1`{JzSn-2J2TyO9*wgqZInC|KhLhb>on34DuA6LKieD62BzWHSznvFM)FbiHI! zv3Vof;VS`=peoMHfSgryT!_&tn;@6Qi=m$CYwKZgt?fQ_J;5(dK~9dPZDm7gjuNx= zYT2L6jG72*55tc@PLI-KYfX+)*zwB!dCL3q0V?D8FzYqwmYdB~kS>ib-xk)$g>u^P z+OG%^H%%3(o=NL{?ZSa8!0zVK70}=2+OZzZgrryipwe{X=k8RovtPqu;~sdpd(f-h z4;yHxsUdn@Q}^R!^eI3Pw(=MA7KCHoKx!kNwbEW0POANosi_Z((H7P8@@jpI;!>-J zN}ia{1A_QCGbzVn=giiHgcq5lk|1!?N@(whiYPU ztvf{$3w*K<9MTp;!4nvYPvdonn@dJBwy`4fyf>8Zxy%Z>x<4D4ki>qa;S)Pt)QLtR zK59TW2)~Vx$$ZUd-KIr`B+Ve^MB>{<6V~K?e*KF|y0N??3O!P-EwQ_Uv3ugpJpWqX zOAj0l8(D-4y_%h2^;CL7Rr#9%e|QV64JDq@AyxXL$r#I=rAyh#dH>FMbX}a}WMyO1wA-$G=F>{AJ8EeL(d>D52~yBE zEXu%V5Rk-fA=Ke+d$`x=%k!=>Y?UFCiI*SiyGax@(shcJ*kzkz#-J|eZj5@g%=4jG z7j2*@6%!|0E#-SQ^NpCL>R`H@xJmP-3k(+!B?VUleXM=aZ8?bbHo9rd=CoYnHKq61 zU@T-ToqElAJ{t+QvpiLYxH!Sc$S}uIpt{Va^UJ~2-Vvf93$=Xfsetuvumc2`mlWhvYKa!q> zhY}4!s(p?4erG(F{;_&{_4~uY9zB!l2>%&U&h_iZv)69$Nx!@wF4R-5mLGp#sg)Ae zEkQp=NqbzC{V^A-Qbt?an)6Wo*0en0Y7bX=MgQ>@=i`#+m98>BuUu0|3d}mI2bdw0 zjK)iODISP{g3nunFJ9jt&zWaXQBvZrIVWMz{z&8TYfoY^cFGBbWCtb70{}H`_op%- z#p}wNGW95Xt@VThjsb^BFDx>$4u>>w_!!h4n(yy_-yJQ~+E~T-<|t$cwtP6yB3{hX zCS(c^0F;AKsG^|}2KQ29iE43z6xIcY?P7g~*KNO{XR`kk)$^2eezzFWA?}2QZlW(U zC7Om2vO8_~NA~!ZBW+2|t-j=!_EQ$pZ@B3)q zWWK}t&a4e|TDaLSih$)=6ouHd`Z@ohjIH;0HD;dv`_8BWk$Vb z?*6-ry)B*bo1dU)%AjBwohVi>Z>G#z-QKn^d5Jb6mpvPdL8J0KS3aGW&*hMPiQHq^ z^C~)ohC{(-f}!D@2x>Bs_w!I|>*>JxPJTvS-u3-i#^aDo5AF+>5BsxdZa+|#Yi&|b z5)h7-TC^jp!tgl;^n8-q9uDj*R$i63EV=b&wOf_9m{k`lW<4kI7|rr|bBpJzuJ0M& znwY^h%*B_r>p_O@%a3Lt$wN2r0Sb$RSnBdUn2I$_QmWB>1rm2i8kYJFkk-}T*){Iu zfm)Iq?Zf*$P)Tie>F4GH98y1n62Nn%-mmx-)USOnjrlEqk4cblEOqQW4(k8@iv9~d zozLZmt9nPPXuFgr&(Qg3mS|<=3<{eKD6k?*L|Kg2!O^_d!nukDh1t5R{Zb$`rRQ|;ZU;Y_|MY(9RlPqdaeoeJul*8DN*by^O{71 zP{avrTW`$rh~+voY~vbM0|^8l&XuXyyno*t1#TREW)Um0&CSoBDb=1yih_5hekMDx zF}?>bm?_AONZ{ind-PCP&&gUZ5kj$~xIV5QiyC9-VAyHNGqxovBu5f{SH(eG37t4f zU2Wcat#)qP92mmJO)b6uE!@3CG6BrWlfY8`$p1y<^6}xw8!T08bb}Jt-Uy|KmsN*$+OsI$Vi|+r9DztF}qF zk$2$6#W&C|d7C2n-JWj-vsovk54l->~DR?~oevp&GRh(;bDVOfJZupYR8S;Hu zi{|JVt{qw)qU3XR#H60^xQZ65vJI*g5|~f1ML*r9rY3){vm&7xpt>%%dggudJ{#sL zEG(ppapS{YOo2&aGU14#9ber55WTOtdh*s-mU&( zCRLyD6CH7oWha~vzw|JfPjM~hX)E$2q>^upH~kq~yb}+X+1=4K#V?W{p`1x=hk#71cw$Eqh}Qx$R#Bm9Jrr& zi}+n<-&1;t!7S%3PCS-I9*IV4b_6d2;k!p(w`M^MZ60-j|B{Bv14k;_D@IjV= zPX-sU$6fAK4~t;%7xzP+Y@ajc&dHu{qx?*AJPN;#4=Ez=-i^a>V7ki1z4p3yr7~{23@@ENpZ|u(W`;XK%=bao zT^?om6&HfcZ0MiW)v*23wZJr}oO>bPXoC3i@@;9yYK-`$UD!FSn*FY%rt*wK|;ILZghFDL9gPMA&2rIqI&AC@1fu=vt>7R!ezUnMSy z_}nT@&|hA}t7FsB(o)GJn5;2>=p2^m!CY=}ccGi<5B;>O`t0(BLDzc%OCCAcDGgQ9XV^P9qW3)ND1B00fYacQ~X7vqexj)^PEIU}T0|hJlF9W|Bi~C*i zPgQE#a*df|s%G0H!y&X|e!k z)R0SG4ISw{D4ab$?=Y5IM;BR673H}$oYO*0;!Lep0Q6AzCKz3oxHI$#-mQ+wBr;Z- z48b>5+nxXxwi{Pj%QJX+u}qh*Wl^|y4?=sqNYFnbS_lG7k={B@#X`s$qnwwtLMHDY z=>FtW{It?S;`;s(fN)R%t{41&wh5-Qs^a<+@B0j9x=fqvD!lG%r}b79$&W8?*5?$r zn6xdKLdaLL~D}x(9!)Xj$j~-gl9qyLIznCiFFqh$}BwYi>x_q0_#2%p^0oK1i zCnw*hu`E3r3bZ08CcQ7$tfoe?4T+QCLLKeI`VMg#B%=frHv$=9ikwn(yRe)c0MEmX z&}${Y&=6w;qrrTF^NsCg&8G}k&}|W!>)N;+jwrkZtd4Btpb!>xnu0okUQ~=57V;xYL4R&lFm zw65ze5?z%0d4t`-?nWcIpiY$!uBViHcKkfP7iDcGwxGDm6df9((?R zcz-;15b&>n81}w7HN6<7VpYzQeGAEOB)-zL7)b!{$K21g?6C$*dg$x1yAEGYA*5}I zKa-Mx4OBgbgZ8DLFx!ITaPH@LZ#vibc=LLOa31YeD#q5!j4WD41XR=CYOg3R^LeeZ!D zX9-E{LF)*|3A%wFIRJ-I zr{30cfj6-2!#+y-L`*7&T`4}Ltilj?mSwnstx&=3h-+UwDQXGaiU-osf*T-B2ZV?} zD^rJYy|3=KCr){F@O^=rn0)K*x-xrVd>W%bw>&F^h05WMm6fh&L6>2p+42gaM5FQ- zMI`?(JuNP!gV#>8;VL)OSuJCvWLi@klc!yy!77R86b+OfWPCClVjbM0&oA>N-slpn zWtoah@ixF<0v?5dLHJ2*;~&H2_b}{mHDzS;Mlw=J<5hmWCfmJI`8l7}ao2Gm%kVln zh;)g^TatC%A|_ErxLp*+K6Lfn=eb$5oS$F#zZ9~Q^v%i%A>S9|72Kw{t^(^9Y!SR z!(wmb8uqIM>1Za`Qr3CVs(V>W2?V4qIA++THsi%usSyHI;UT}kh~4q8f@e&xFqu>e zc-Q5uCz}!G68)_ z0j~J+Po4>|lLjJ)%T`l~8uWi7HR=Ztxr21$Wqkhy>XLvbDQ;J$1Pf?dAil%# zfhgTsHjvx?FQHD02-ONzs(A+2e2-`^Z`1p2y>aTdqwV)ov3$Oc%b2Uz*;O_717<=<^nZVtQlxR_Eu)6e*QJR0=zeA_VWO1oa8(#UIYa1Re& z)tyM`E$%d2+$&8bN%|6Pp-~(`#REscsG0vr)2uM~o+<1%0Mn8G;x@&>EOSVePgLUY zUn+BrXiwDlN=`@!`~tLMkbm6Dm>1c>fM|!yxcwQBV=ky_^ASO(ZPW%cbMq$y&FRMA z@7nfXH}I<3%~0JQe^THl0$&05%M$%Iy@i(%HGv%$U<~&(f^+`Ok}p~km)+7*i@P(c zSxLTJY915S3Idp@vP??Wf1`RxYJa@)9mq2&O18_bKex?O4+nAuz&4jjl41WcrVHvz z)gsJtu_UMXmv6rUl`2oN!RZq?6^8wK!oO`K;8Xx{4wx!xtWvES%juG2S|!GGz*HW< z5H?W#o%0o1C}>!u&*9-yT3`d7kLMOZw^j!W<-;?o=zoqNdko)HyVeF!O!J;RsRv)h z5dV*jNPGeR2Zk3mCo&?!YrnF0Q6004HlV1pW;1v3FAhNT1seI1^NjBLbivzfPMi5_ z`i0Sci2`1yT_tJqrwbAqC1-ZpR@B+`_xA@1+w;4c{@>Z;C4PG|mDQiMAwuknP9+WSTdq-eNCM+dgX7k0mphp31jYd8aGd}4tYj8U zT$O3DYVl^#H;RT) z?(|Pe{^G)fs?pDWnUu{##ZyuP(po4J71av?^E9R$4fvMAEr5ODNv9TW_l7IcZBla% zw45wh?SJL>_zFc){+H@=IM@C^QN#CG+yH2w0C%^f+`-#Xo-(z#{`Ww(3O#Aq0A93? z5*qOWa8@Fc%l&7NHJ~9S8>M2YEf-T~+KB;1vzjG>qYo&8_HA5$^1FNznx%l?sNtWD;$4Sw{)C@fZ@IAQW;rUYXA(T-kTpvP@7`CvUddBBw$b- zPzl(~!r15jcm6I~Q z4@p^4tr$}p6^DQ#w!%r%lOzqU@84GsR7U5kZ{K|DpsU11&>3&%(u(4dSX*-li+Y7Osr{^68JiO zY+{qmyAi_scXOpfV)X$Mtzc^ZGP$YZ( zwuVy(JkWY@$DrJyYDQTZfj?~ygFki6+9fR~Wl=!24{IM<-%8=EbKoQiY;s7!QUxYL z;^oTJ5H7F$GR-me#I^9~B?SGxA4_0~CbOA0=Z;EzJYG%VwArQD_*$C@$6VjxK2^fL z&H>pmq=BO%dfkVp8l<2rBP9yyyZX?m7&d=_&$?JDQ9U(!)xRe3!X$_5F1=0lT@C-? zMOR_9$Mf$auOIJ$|LRu0O`RQ(&Rl|mOY}u=g16v=#_d{fsM#o-vS#(-@b*B}@v)4P zk^^LZlN#wP5o}26{3(d~LjPCf#z^-;3AH4iBqEpxpchJaNEO$6|9)x6%n79v-kp zI4hM--aT9`+ZD2Ej%f6>YhDwfX+}IV6)&pQlj{0a0gR&4R&8WE_O9h42aOl>suRAq zK%r1-`e0KxjO^C(j>ERn_~iw?t~i91KQN<4s@D8{b5{di!jdyth0PQwv;nq_7>Eo*&m3tO9soFv_)V zroq|w=4;{$_xn@y zq}Cq_=`(Lh(Svf5i#NMaTJfM?kPm(u!PEpLtTQ<_fWH7bwO7*XuI)0Une#=az1sm) z!c5_eV!CCDf>aAjhvK+&^YthCb z-^}NcmSJ(yi+r}1@MA9ljF7XWSe7vi?xqnIy#Mfi+|D;XuY!mPV6UCgXDatNN-yX1 z+*DX_WYk;y##m!K<0Gf-<#MZ1*Q9k@-ItY)V_h04r%V-43QswrS;Ck+Bre`Cj~yT) zfWS<=obnuMXjoetn<12B2)pPKx-TXG8IluiJ(Y|0z&onQn+Tuz;&3YV_3Ok9P^W9% ze2>x7<*T*zJbqiPin)a-O!kN8gB`NLRE6t5~-#UaA}r zk~Hjbz?|3D#j@2mCupu<-egpAZ@Vlty8(Z1DvzVt-Q@wax>Nt00vvPla7G5}nI`9M z#V$UFWyQiv3Y-4^e!)RHOw2(Y=a-XTsRkfa+19&pT}QqMz!$f8-_-h_e79Z)(&C4s zrSJfKuNzY>EiL9$x>|TBd`Q?99)2A26yu`RcbaN>(GIx4C{FeYea91KoBJ$_ei(uq zX*h@^|CX9xd3$NI2 z3xuF7RgV=O_o&Zmg@;qs_bc>y1kubETomsZ@K@K`EiaX5vJp}IsS_b#Od$AS=-!5) z<~@0&O@Vl`HIgy2@fx^vfz|#z_X&HFvZJDw^Rn-YJntPQ05ZDLFqM0KJr78%p32CuaYC?K3m=0>$s)-@a$$03j0?|4a_*##9ir z8>+f3=PcTQby&Ea7-U*^SrN88qi$*Ely3E6H%AL>rbs1EmwQQK7ZI{X!_L5=6A*1j zHIhK7BfQ#!3x9|2yI)d54!pEyKWX*N*Oec(ytq3m><$`Wo&uO%%ztpgQn z@X#8tVP5$|EDkMbrWEmfDF7iJyXrN&?7?WOfOpngY+5mUa#H$sziPcMx+gp(9*&>8 z_0;w56n|oKKvAoT`kl zD8BFZ_I4Cw2BthJoYfOi(0H4BOco45lO&hK>^s4?FGG_LwP5_~0#^vuJ17+zomO?l zxxG_3OVOEovMP=x4Alo|C78vyXO={}%Yn8_blngpXgL(28CXTlf3`=FiOMEBhSu$T ziYnqsNjN*aPD0v@+00Rxt8Ckg$2D-6Ep@`(i6<;AcvCPRQiH9-30$nX`uW%%XES+T zQ*jLweuJ&d)q&6Tv&F-?d&9zq;0RhN%$RQVtomD(Cxk9P7^WQ5PvmN#+faBVWl91mZX-t6<UI!)sxRaXr$g2iTLz-%`Kmr)In3$I29^264hYa2vo2u^=bPc)=Yj$>_z~vAVO<@| z4Rfms`HkCA`^(!fj0$estKR}U82LXYq0s+0#mOM3_6`Gfr)Xo;V6VSr`pJ)_q zSByfrL-t)6kpw*xZ4o6VhNo%W)iE^Rhlf+@)Yg{#gRTySxCGDR;MZKNm##bf^WVQ` zR4k&EdTd7vT3NMDE~r)F2rd2ObA{UOtF}1AMUrJ1G#a9QfQlXb3IeMB$Jmr*0gUU2 zvN@B{c`A!dLIB(AbVo9)j!?GXtry8Q@Ai@_)tH=sdlS*ukh9j7<9&(Etd8JQS@{i) z-C~r~!UoZ;6PV^&Lp=3_I0j0qeREVbkc0PJVS51ZDc~@*EW=lL^6oN_{>cbhFuUts zpQf9mxMTszTFkA1&_}P`+}iz_i^)pPgM~dmx9#`s9?#jPI(y0SDZwph(ES&=?8+u7~FQhiC2U>MV%*eAm%jlE zGV-qd2pkFTI!?rspGT!TsnO-zskiA&%NpaOdC~j(U)8E0fuFrQOl_TYb^IIL0Uo5EHIcQMJ#T+Siw@}Szd6ecL-T;qzds}=lmn9%0WoG)!mVux7OQkTKQJ$ls-^tzDfs|w4wL>RX13H17{5V#Gmv|2@;VMnMGT=y<`GSbvk z7?{M>xM;*+tzg@F7&ZPQ6S)DIM}$)I%Jg4TR|PZRxvK7+c~-Ar>1h<@9n8pZS!g99G(%x{3U#{mS$ zL7iHY?^7b`H+T1I8vv9$d`b?TcgtyfiDzp>T5bR1{6*qyTB*ltIAuhhIn6SPjBwn?xirD0rKR$DH2=&vZkqcU8*bQ!YR7^^EzQe8gT-g%f3? zDOLM85pP%_>{+aHT-%bGj#Cq?ejvsy77w5-%;cB}UF3_zZ(fGKl&hCDyQxsF<~it7 zmgW%bw0{Q30Ft5Kv}R{161bxlUx7Vc#czG_mcY2^XtsG3bR9UqCs!aIQ86eAQB=)*Mu?9} z9Stn1N@GexilROeCP1R3RRt*#Y4v?S*9(aVybTyOVz(2bCMNeQoBN}v*HqmHMFH?2 zVGLK6(mI+8H7Y{ou(G+0r@7b=k?I_n4QoTcYm;XHx$N1G=WHL)%1yrzS#`F_KLo;n zD)_)z93XYK>(wB<(hXePAX5|Klov;`b=Gq+Gv6jtwZ!`|Xyj){lrml)4Ogq894_eA z+Z(b5SUeYG5Am_|61ZKII9tf59GoVl;TPlY9nUZO;zh<6TFYBvXUr@dQ(3ee(MxJZsSYT>gjBMT0uZQ$d<5){Vp#E44y>9oXRsnFGx5;9J>EuMPaS_c^QThq$J9-sa7OTL72 zg@hD`i^nFk*r>7BZ1SSmpcTC9k|fR~L_Q2i6H$NmfU71pEdAx2F9t;tEsetKb)1yL zILE4S@~sj}?2JQ^P6O**gbk>}K!05nqkJuGXi^d`{|*ovfEZElg?@ImRaQe7%X!7v zOC_(SO9)F4c(qprS~6hi_ER%rd;=SbS(W%pJA6ELH8v|+btg^JKh`$D@(S&a(=V$U z7qRso@k;CUPlkd5zXdL@0R1VB=owtO+YlQb!d%vjsrR%yDB|L71@~u1v1ohPKF*mG zrr96)SWJys-S?7yD2w$ZS<0g8z5EuAqv&NCa;{$=2*Jl03St7RVuj$AeKgw|&K_oeG`F-X7 zZsM=#%sdr13)+jtR#x;<*FM4NNzTCqKDU7mL}I9-+bt(*VvFjtCSj@BZfZtoEz7I#MFJE_A4mJdkja>+RftYiUp+%YgKgp$*Sz#gFmoo1B@@PYy>t*tt>4pGjPFebN!{1n>*g3$YFJ1?J-Ol3Pp z(#~BrQ=CweaD%UE_@$LS{(tooU@IYoeqd+UgtxKURIB@zgK+$rohn)eIXY0JciZQI z0W14t5|UwOPw4oVoyu9m!&sDqQbQNp!)DX zT?(`S4H#;jC|UmzpI{)1pSl#{Q_%VT2oI<*9hji9V=i^2t^KDMs-i|QD3&NG8|8DL z&NhD-evu!c*{Q~)ncV8=o|<>joHJCJQf>Z&Q2#_PV2_@+mFR1wM60vMWo}TnfcN3z z?hEV$T7uOqVy+lFnT6T)OTJKShD~v;7qRx&c|rJ4sXBk#-pB$Vn%Es9L?p5L13J!k zmY!N_orOm|qq9U|^&8%IKb%j?!dDQ^tU51{c&;0k?>ULBf<7vJPeYrLG9qr>1uQqF zK_@%ApT;#lA_en<2f~v9JW#FFrN{ntYNcAMn)do}yoz#8Jz;o2_H{dIxe7$WLswbI zzJ)R=--~OoEElCi_%jB_aK6CgEf4BbyU1_2=s>@Davh)r{FB8%iy(vV3&HDldMZS2)sc+XuPG?}s?r2KZ#NS4FQv0O zq=S)sf>fPl48i$GXVHA}!2v_#!wI;0ur_1k;^NZNe^#3-7}bXw55#;1l`aN+qGO!1 zO58!0MfXV#mDf-b3uPD6$k31q{1g?dBYx2~Ly`x?cVcse8>3FV8B9lHR?dnvMzW2ivX!HiWM$reTh{Zqu z#iD%~u6@G8J^}*+Lv@LnzH=r-A8(O5rpcq2$LtpXu1Lt8-;pdFWx6Rc1*J8pKnF+A zUAWz2s=v3wdd;KTSQ$W6z=FhL*$nzBOv~osBwG#fAVzS=(VogUVQ~1DW~vRmSAHiA zS$YByHnJ9W>_*~WYH^Omkg%tVuX?>cs1~Uhiu}aE3#gFKda7e-Q@~^AF9?Nd7=?rW zr6+YpoYP`7Q!bVBRtc)?Nv21TCa3r(hYCV<1|k>hHgWFE(Om@7e0iy*vZ;p%o2Tgf z{TTh--{;%+6M4ITLNlz5i^mehvz+u0)wtAbWvVNE8n>J%uA%0h^)ob z;X?YJ5Z;|aiRe8fjlOhmmk~CP?k;;}zHy~6YZ3X?(m0Hy!wIFpVfUvX)4i8oTV-S- zt}tl{YW+d&0yzamXHnl0UCEtFxM+XlBj~V4W!CJ34$aS}WmRE<^v$$NvFUlp>CV?anW6hz5R5guWDXyFJ3nkIxMy0LLNDj_2+8<#JiH5AfASiT z1^V34|35^XWmJ`4wDsvwKtj4hx+SDbkQPblZlt>#Y3T;(ZjkOyk?!v9j(79FcieZ3 z^YH-VF!tHcT64|$TicjYl_{F-8PSmC=qO-LP?sO-@Y486G!FPOviHN$%R7 zugXD4%_iLd97_;_3bn%}UK$x5e!QIcTHZAJ1nXgmFO~;p8%E$Aybo;)|M>`EWf9)c96TiMOHI^8w*6rgGv^GF2mvD zcSW9FbAz3^g9(fZz0M0wYx`Fx{zNw!{nuq`*?*pJ_dxL74k*!KQP*oK#>0&*n)$$H zF~4%|Ae~b7B-s9<__Pp5XRgwcz@(%NVwZ6()H`mkA;}9y8iY_!sC7k(U8)E+awDfeaq^?V{B}AdwxpH>l*aT~4o^HM*i(=;yHzV2g@Vilv+i|&COWs#IM2@Y{?b&HQ|M5Os zW5tcHA5rj-luqH5;QiS3{Qf(S*RKYtDn$_FBqKYt3b2+wTmK+jZ!cd1MT+W;I{`IE z1xybAz0+4P5u{}aw~+-ynEvM~0tQe7C3rXFV2}TOi*5vH(-S!%Xj(~7abRW#e}GB5 z#i?-yUrND2TEO86xN=YfU+Ws(T&XBn9|&>?T)SjvAhB8eU=2_QUJ0}!jt;T}@M}sS z-d(_v^kBn4c|(k{eOZcOS*f2Ph&Ezd59eIo1@1{;+SL+T?GDD!`iFrcNeh&oR}TP9 z;r~}C0(^Ci3x1UZGJ!)m_u^6}bohf*mHPyX_TrS&!_}c_Cw&6{e(xWxX)aztbg~RCFT3mV#f&BeCsXE)Qk<$Y+d40umpc(ROx1=g}Gi^oGPv7?$ z#v+a~i!8o6+}y6|;X|rJs|Lg!wsCg+iy(pqY|n8nCfLOJ!A+x32;;tEcDyM$BKkruR(5GQpGFZp} z?|j8@EN8s?Z~N$hS3#LyD0!j3{rI|2a2u@7o6v_s%=|!zFV!(&xBMhttLA|hIGlRFSf4ZSrT{ptUCzw{KCKjC zWb3kfy4pT=s;U9l?;MafoAF>ZB> z!+_|VNc@(!#Y`cvDhG@Y9K!qXttfuP&^{7KA z&wj=`Cnx1cQU2sMZrTEbeG}z^UtT8800RUHjlyr)y&ygNctJpiYDsp;1Jf)xCAMMG zEyuLN`x8(gax*G`b(Jy@US>ZT^Ng@@&uGLhU-e=dSTx9WCO0IUL8cR^m~sLSz-u`1 zo0Jp*F-?v=5`r@w%5oM14Oiks-J$M^T*PI{d4ZSCCT`bc!jA?Yt*0Ft;kM&%V2;w+ zUK0eGqRhWo6=X?Xs72~Rd(9tjHpto?AJm2+b>Cx=@%Ra>kJ``G>YhN(SO5} zyC^^CT}JgTfm0V&agTnSzGY#v^>#fJq&+b$pRX6J*v}t#Z!MOaleEbQw}3wbi(!AO zFJka50d*8!R?7F%-XJL~)bb@&zF1M|G*@Ihuav1cb!nupIfN;kVk%8o+3)c@%ztvV z>fZ#|<&{e>6z>Owol3`22pIb#zI%Mi{8F06>&Qk%8$ut;>s0yc1h{;542(gVU+JbX z7M*H^K)gRPR+~{^9N><~2lm{-xRZd(b`uyMjwv!1-{8VDKc-}!v6RDc^CGYj(^WVd zjQuukeIyDywUKBJ(H&cG9%?x~UTOk%?t<~E*4SQ|?=2X@x4XH<~JBYo$o87%N~~8Y>7d6T7NJwF>@WWzRJk- z3{XA-f|zwxe3$=n`0&v{_%_;fnZ6TIY|*M*=r(?RDuM2M%!yplr{fzG`=@`~fwihT z)r;b}(K>e^yC@G}M2znUxhKIK&a#-55+-AFE_AnQOqK*rZoT2}M*7Ca`yUwZ0wxQM zwGe#KrR7;Q)hAW5l^dWn@x@W1?V}ZA^nZWH2xd9(4Q%7HKV5TL-b5mk<+4x2@?EP2 zy%F%n^!4=AS{|)_iUDMo@Lts{f4}hZNF$@^4hM((OnQ6C=~7jpY(2EFePTMiZPjkM zcr#P?>_8M`$So{7+|>^{mpyg4KLp?PV|bD1JAF3b5f0UvXNr>D&F6 zo%v(Ob+c>=?UYq%!Xfc7Wy517a7J?PBnTvj2hxLLiGol}oF2J-A){08`TMsALW;V51FH9aC*VMf3 z*yDcNQ*r)XJmZsoM}XTtQsHh|fl-%8hI03skG=1U_lE=|0{L3Fm<>3keAOO7Op?g2 z5|nIQc=;;H8vn9-KFM^E4&g~EAV7A1!d}eW1ijJjZY-nbeB$Q-uiLc}j~tpnC@5?Z z`=MnId@m<3_EBnL4Yoo2s$lj!&-U}1A2*<)K}%ActP}`QAjQiQhT)Sm4gI06BtU3NtOIA7Wn^l&L;Vs8o3jyj>4(80a{bRA? z=J-wb7dUYqo@TM3&i4UtjJ4Ss_SvoQ*f04})Y90^rvs7kuTNI2sy4S%ta@MEF8_U5 zx_FUIeO}HPdzKGZnJAk~ge*zIRx%F~x_MEw>J9vH{QI}OtZn0${;@}sUw?w8+-3p~ zVj-R^wkZ(~mZRmxzr?r*=3U#1&8r1=D}86^nL0y(&XtN|)X3}vj=A$Jv$&8^nOw=Z ztn6%ZB&tXc;HkK5RwY}NtNyHp0?8zIRk)F4mL6zyzt&_`ornGYwpLJ9;%nI9@(w={ z3w=>Cvjf)I82U(ZN5*1?0v7Za0Il0LUKL#>!M|Tc{YU}BlC4_a<{ff->r-?WJZ|`{ zr`vlmxXhd}o0bMcpZC2p7IS{THx4R;o0Cs^m?A6xePDEWGCN)vA5;P{TzjV3G|R3f zfhXJu1hsXQm6fi#OLq(k6a1JWQcTICsY~`*CZW-C&dMUzuyof%#d&AL$M1;}UJ+M@ zZ>aSwn3O-q@ziq?e!)#5Oi4n1nix0i9gc(h9yEvbYevShBX!SpBw6KGcd;Az)DsgE zU`+P_*bRmTvsm3M>!n6YnP%mi(FxH{xJ@P>dB4ZDpLDrJh44?+HRcv15bGSdA}fXA zjjgB97-W0y#-mvXl1F1X12KNO*cAfdulw1H_at?BC+|Dl#cfjWCcX2bqky#T$6UuH zuV->yU=x-uXLbVpjc$xJczU}mA`^16aZEoVZ0!suHb`hOmWG0oXT&etEkj7qxPFZa}cH_|ooIN1P04U1;&5}g(>&gyAy9|ez$KLSC1Eka8bLAVz6 z=6!pX-h1yg=!i-pNS|eVa-}?CG?M~$h0~h-ZPwYha`wK61(mpbl~O$Z?PI_3Gs{y5 zYC7^VKTS8wv=6Bb=j^vuRoZL4`>5Q9fE>XDYcO~RgxUe$V_7g-!5$4Q^*CTxrbHK< zE?Yy39hHYLggZFbTb7zj{v*^^;4I$gwG+Q#tAy62xoDVb8rO5k>sei6z-s7#G8sXY zt=Mp-nW$K5E1>?zLRXVde`y#E6|rBl(H<9g8J8Lzmd5FW=>xs{6bThHBaKo*WX+X_ z4MKLJscO%3OJSs4r4z0teFb`3Z@I;8o(P4}9z`#@g%w7|gP@VQ8N-mxzQ=lk20DGy zyr<^zr*xv+8`O^-dMhFJe{o!5;9NsIak9LHfts-Sb$G9Kthz(R2sVk4q@OKx==X~; zjK2-NH#^F9rE3&cfwuZgs1Z(O``>9(iOx^{coZ{Hy^V5+dqhbFll$U7Fe?ghX3lii zlm3EwB_POSLWUEW;L~Zmx}^I_TZNxPp`5%en3Glst4t7zRC_u;#Zs;CZch}|>g?T=CdXrPNURy&!(p0|M+=Ge|&U`lT z1*gVX+&f89>zn@eC@IOE7^~}=wPm_9B}$^N?wbty#FB6H2XeEqLqGdoYOaM>J}|Vr z=@nK)O4!Ug;YO+_+hEpZ{_M&PL4;(8iVq|*AUdEyVtkDmP5uy(Ye%;SRbtli>lDGq&zv5e2dLEOwhI*{gd+nps#j8e66mpcDgw9R6`o_%C_@5+?2Hb_7&K0>qxTq*N4K z^hD)5%#(kixV5nQ2S(*4~ijq!JVtHx*2fPelxLN9?s2k?)Wt zx_ss6hexJaT*76Gb0J)n-dJ&-lF^Yb4Ek{3{hr=DPZo*L{UW-&pQHY}n$jCbmcy%L zx$fK5HuCK72crU~xnLTNdQ>Lv^SE$#)L4dwyzsV&Rz;(s#l($<2xO-n8j4I zQfLQu#6=nOT_+fHXiBf6Pa8XtD6u)dAxp=Jje+&DfX^`=sqI`v0_?(9ug8DUvQ=6r z0_%3MufQK*z$w6dza9Z$b7VDjO_syeRz6M+^Izqg0~>vgmQr-zsuWwJ zA+dExb{h}M=u+GeLa2HxJYEJc`ZWJpKi+=J3)P5X8#FLZYkEA`3W>8~7E}B1*p+nB z`trekLjPozx|ejsU7-kzE8MQ%%7U* zGhX>SLpXuGhe6p%>q;Ld#3WkyHAFiLd;Kd`>sOWxP4JD?^0(q?80sczZJ-vn{^Dd~ z6t(DuMbo||^rN6C9jV|{cOb73hO#GDRO!OO-CPqWXms0&Xd0gg)xJ^qrGB{BY;6!WT)p+6Z=zE)<7!diL%*HEm>DTBgxSvL$5V52UcDTQo9c5mUSqI39W1R? zce^Iz;&~24Fk6u=NtDRj5xUHUGf*4iefsSs6mv3LxsjjY$?bCfS>u8SOxxAQHW>%2 zOJ51O+KrcWH2>8zN1-yjT|;7WDM zroYq=#xBcFf_qQO4p=TfBF&fzW5nC}V4i=Q-Hc1o?jTg`+n%lW0J@2PQ3|KkvBvE4 zF`)Bt5e02*0br2Qi(G9Ba#^=^dNjA_s=&)#hpC{ekI;$XIB#jCF z21c#SZ>Yp^Ss*fjh=>SSPv(;aXsQLc<`d1ekyTi=&qD1FWx-yDea`!ASnA&7KMhrttENNfhp4BcZlLK}tNIlpIedFsvKSfK=n3lC%}oP1w_4tL5@8O~ah48Lo#)$$ zuL4u?6{D&0*T+lh47UHyh~RMI+fBzL>kXQH^xYl8U^-!ZKx!{QLPDm8{#%wmjTmFs z8(?lGR_3(V(I`CSh)wf#&lU*RSc`=`2dy2 z{iTh3qwlgSn4(JSqYopzYF`mN$J7P1QFUxkFApc!vKic(CC)Zd30Z=@)yp4>G&VP1 z(&T?jQVqjFfeMc6Ri@bdk2OzT3Om2uuHTht}@+|FHA7Nxb7 zMj_spNxOA1RB;3eDtjeQBe604qj3blmdF2UGl1;#(|^`Zs+wMY&J>)o-#XuNnV`g? z4n_zf0(0)xqKVkp_q*LWPXI^#D#8P%sj@=z(-xq10d88Cukl9d!*LUnvol^785tQh z%E6Lzn)Jee{~U?tS$vIyW3{s(zRg-Ip1K3fmC5V$p%%D-@D za7qXlr;De?R5W@EJ{tEi;G`-QD;KIH+7kh;yi-7a)K2c(ZM|^C5&El@=WEVVT5+f} zZikTYaP|mdwjc9sjEtjA+m+$aI{Q85)Kn9%aU)Lbf0PLR98mcm+wKni>O`8tv}g#) zT^NX6$LNZhbAg{(T|D`U&3yV0^v!JY4j`HHrp9gz;EPmYo`L6#dg^A;?yIzP7*~p* zcC{!pG{i7LHIKj_olK_X;xg?v{)pPV{epr5Fk5l0g4g)18}kSY=|wK6?KN5g)yBGS zMfahN7Ys{Bp>eD}0~Td+p@v5ZvH|o~ecAV@mMpW>en_qPyKx6-jo8C~+3*KTlMw8F zko>lezzQ@ff8huJPA{&0l2JMQCm-E_ipe+Jl6%GT1v0;)2F!0RG1W^LObFdSNdH9mPcLA6Q!c)VWw@Kr3H5h?-w_nX@YiA2>q*$J<(a;P1wClYN7c#-59I!NOEyWh|)7=Ho znuZqYWKu(v_5y|c2rJ|(X&zXEHO}&|iQ-e~nCi*qXD^7fx- zZ$C{sCSI#?~`d_0>G&E zo!ny4+`n~)23+WjPw{tP#^L@U4dFM1L-^N-bi3%n#W(*K4gmxLOvvTqjhMK&9*En~ z#dkx@ciKO&HhZNo%AhN)m%}Ef=!$w3y~u2AKO4NaZ?!%SJ4)dMSmOe~03L&;%i#9B zoID%O!8T6k^?V;2R_WsWG%~TaFfg7?>%ETxMi2C4i?vZ60`>$q=kv-}EK#sR&O!+gz{2PVx4OMBNU@$(O#7A)o@DtQC2G0OJc$F0s<&B0Ysi%wV&#N zpIqo~MOCseQPSyfM@y5H)j!v{CK}pkoH#U;oBqnbzj7>}W`R2o*ruMX2cV9#;3e2; zWu^bN-mLwk8?s502>q*>?@8|^$4=yEU#n3RQRy-C1=X4mJZEMq(ItdPoYDIG`#-r} zQZusmMc!L3bFOZ^?8Yc^S}>0)6>r}5-PZr2)3P;CY@o_`a+>Qe0CR$=rP~P2@CLy~ z3+un1*}Z@j&HqoP8Nji8zyhI2fa7`laFeqUg^>rZW0%IcFgx!=98sn0L9${Pm0;A1 zxEov0#M!HuKNOviLw9B(LQlo>c8sm4dyLa;zB!H#FIHM;OLK<6S|W4bTSe#@u7csm zv#?KmyZ9(NN)6^(iolo5la;m%!W2+sER}1wox*mOZJsh-^f}ip`q;lSI`qxQO)z@K zsl&;rm+`}CUJjj8MY6#V4D>P2#!KA>*-+9#GJp=EplsE5qAdE>Q-6b!@;EWFZjs|F z>k5Yyj8D^7FhZxBhZxVOIcQ@C(38~aFz4vmDwB<6{#qy`%yeJTf3dA^G@>&Eb6}1R zj4Chv)~NmR!tU5zB!jC)ztRpc?I{<>MeaQ%)L=4uSlg?Eryg@|d(BX{h(7#BZ}}Ch zx2eaBk6ZMolKq}4!(Di9m$~J9knRwN$t~xgF;MR-5zl;%E6if>0j~o%Z9}^0yc?oxd)D(8Z!ZHp~xwjT*fhu9{AuxX!gM_(FCetOM#ndTIqH zK+5i#18DwdQv}X(e_iyy6WSQww5;zeV;*2#s!@j#`c=Nz)ql2qO5f;pzV#DGwc>S{ zq|FjW!i~?z{SfY6QWG@<(jH>CGhGB#3DMD=t>cBG>3mWSp!$aH+{VEljWj;7 z^q3KV{9T~=x7X{}!TARo&fdxP0m^9hi!ioT_eiN!B;~GqMb2VD+YPsp2~@k6eK?#f3bGyJcWdKb{`kmMMh0zT`T|ly9w-C2+{U!J$U#_P>(M&(K|^@_JW^V|j-~Ujb9lzfu`e!EP4#m#gC? z{80`yhzqon(iZZtt#dhm45Hj3P`9lmAyn2nR*m~e zQ-#=4-z!h*b9SamIAVdq!#b{XvkSOdakhDw@0E7Oy+r&mqMtj^U7ZQjd!2%cqPkzi zNQ-ZZm9y0$yjJ>n>&DwT4^EYKysfd-qaP5c8T(qMT})kG_mD7rlksAW*0um^34V62 zZL|EKFj`dJMSXry@b%WxA)VI4fs7<(XZjtwF@#WW;@|_qVj{6n9k0C)o)jg^BLQpsqtZRt*^3=0A&{!(h=nN63QjZM^e#UX(`g*=r$#mD>q(M|b z@Ebk!_NTFcXe!dclTijJGbCsqXxygP3|g61%*?dIbic?EN6Q}q^8y>IxP*TYA9UiZ zGR=VNRLT+0bRieU6RnE)MtP3)cw{zBTN+_b8rbuV@KiGkfOk?iE=jJI*lbB4@)-cR zh7&LD0laTS8lIfG7t&fuES{1XVw9$mUSZXmMBx2mB5d~nt*dAjZ8{N>$b`LNJ?vi9 z@i29H7m{2tbMXL~rvSB&k2!%kfem{~J1-k#z{eqIObKl%2hx-%$K!S13q}q1z74gH zEQ674i7`K-A;c}k-%oaZ!MwM_e>V9{Ag}rK|eG&UuSi)qwjO-~>qik3!AdIP#y@YV5m09t;NwEoZ*A^VM5* zeNM>j{HZ!xF}b_x;Y!_w*XdwlVnJz-?bg?wE$d?6{yI8@ii-iTie`j27t6@VKl{~W zDU1l|xdevJJ35OmE6XnJ65lqhGMaOiU}54)#AQQZAR!?!QDJ%%1O<;je?pa}@Nqk# zaDMZX-swhw3zgaLO#w9*wWL_Izo_8n1YljGa%rm$_`&m$XPA+%8YBJr(72$i>|SZA zF39CxMM?7t#A~ba764;rXh_Z86}}VHw-^zT zcF*#s3{Ot%-%KxBz0)y`pjIxK1udJN1p8A4XoNa*#j8mT5s0CH9c?Y#%(WTUdGwbW zc}9BL%Qa4?5k<;A?ow?yu{L3n7=P0HZB;M2+=kDNQVk5|+vqe$!KD=~_VV*|Mx2IW z{yoO=6$QDpG*D!#eh?n3m%hm`VXA|<*B!LcjCbV|yaaBe2W-^xp^+4FkY;bKdRe_< zzJ7g(=UjK8@nFHd_#EHbC?-+%(RlQ5v0-9)7I@vNdqsbitM=jrfmJeVxms=`6Ys_J z$78jE8K8g|qsNbi(WVOHw-yLe2nW$nWbG=x`JCK!2=!O`nbgg{LBh8CC>dr|0-F*7 zH>xIbi)A8)RG=z_Wzc;7jLIixo>)>y=3>rx0-HhGL#l9Gxsc_~QmxizVV=Qj%<91G zCrqM>e9?H?#EwTy>wSr4t^2M3+^Mq3eN~WbS$1EeX^E|7uPq4IZ+$r5frjCfWvfp3YU?T)I)~bcF3Ymmp{Ua5h_J$)7uLd zOh?ntNv`{FRD`tux&(&DSX`daRy&G-g~b7nz1TCMya!&mYxb7L$`o%;<_Y|T!@!a;Io0?+6 z@Rd{EeP5~nFg;cn)b3Viz$w!#(vox8S$|)V^)MudyKAg?wSv4|d90+xVmZ;^3cBtd17xy@Zn5JR2a)>} z0%cVTQj;(Cu4QSFR7<+{Rgn6oMa9zQuzr%W&Z9$?j&)|CSz}E3lc4Fm?F78if1Ku8 z;}r?}4H&skMV-$W6>hW7JMxlfKP{l5_xoGh%+g|DPK#87`in)mZB=Xf4?c*xqU)eU zs18RnD$AIkZ)W45S(B3#Izpo_=UX7Fmwqm}Gyhf>Jts3=EkU7wq2lJAz%dfM7AbY@ zjKQJ8w~@_3$==~e(BI0}G35&j=01vllJkB3L?{@gQVB21vAH91A^MfIZqlw+k$5ft^Y zKTY-BgY)tE6djhj6U?adLSfvv)hU8henbAJIc3S?gr~_6CyG-b8@@u~kLGIuFKZYS z5n%UR4}=$BT@ZU*{_6?F=8^Xg`ziPy{g>jGc^QFI^#mH*CO#YJwi##r$0SF!PWSb0 z8_%bp2)xi~HH6zMst;`&q1z*ZIF!;!BJCO@82AFNonJiQ!xPzTkXZcg?X6ZC;Q#v| ze;85*6-%m|FNlcH=>4MJ*Sp`H1GL&;0#hW))^O5HqxG6O5@OQ-{E};`m6Cw5qQV_M*#NGg_VAJ*F+N_O2Um;0L?po{E)uX zblPH~v|L}WO7|y+GWBsc29A_Ty|O4JQq*8g@55bi`M0LlJt-=~?7Vl$U&*J$`BlPI zj0e1m`?#Yi}d<|7$*&NM@?0xU9D0YR#${E-HVf#=aWGEH*jqO;H>ev zu)2)g%izjgE-xV>majZ6xY9@Oudev&B=n!u+jvp6ZS6O4^o5zmm`&O|)$fFdJH>pD z_0~Fz+-9^=YTn$8Jw9GxeR^hU#p6io6jPz~!q}gDc}f`>0XHP^{PN?A-9lX<0N-^NpIsk zJpGiErT62Eui~S;VnDGfj4yJA!29hzw5)+o>wSW|Tg}Q*i^WMv*`k%Tyyv zf+${#aDwr+g}2ZRhLjd<3N*nyj;0ra8t(jgB+RlxPMmuK;;!7o53Ove3p*A8Alvf{ z%uQfliOqUMD z(PZJW+X@a3Uxjn!U{E>MxE`gFsHMtcj;M6ci*j${`- zoWmA1tt2ahlTv1Rt+m~FFp<7}^F5#}5@Kl{r#^b`O{6k)aRX2Hs{Dq?M;agT&-3p) z2`h6FQikf`@`sTPq>~>EQ}<#EeLvPwT2>f0w{p7pnTd|oggMEB-(#3ZSW^scXyNj`*CjsgHND34qSm!`kx;cgmFh38&dnf zHwaRo=?M8g(WF2oi`5#yLhWEd>DdUvm(Ep66&~Icm0iYu&1I;ca-`0&W`{u;$c+CU?bh{~-jZ*C`rjs5`v)Y(WC6REbc$9?pYMj^ z@@Zh3PFS~6vEnup&WFM<2vifW9t=E0p>;mx$SBjEiGw|u!i^!aiV+znWj|7?<5E@E z;tW@lXG$l}|6OlSTBPYQJWKi*mA`jcmaT9a@4Y_Z{72*4(_Cq@$TTBcm92fmX##^k zQK^7-lW=uC7Z1z(kE(SAs(W21MrE0sERG@*EzX=1C&{ znC&rdLtw5aair~zy>C^jr76Wml3xa!I%TdxpC(~ek5@1)YtK?V)_AeeMc;PN)BY!& zQ_RxJKhx@;O#Cc_RHs7G<=lNLWr?{iR5B%!NCV$Huo;Z;DU>HUQ8=qwtenvQ8XRWp zzqo$tSCu~^kxoK~M6*s51nQTz%T^q(%lWPT4cKjCIa$;qKr@jLh&)(Atmio~a!4`3 zWJYrd3WquShztwQ`VkJUf=?_K=JBni0U4shIC7oUrjr6 z*2+~994R*Fd_Eo}_0Hi))K>Ev%78C|1eC?^y|xDMtbV?gf}nC)6|T%EQ6hHa%}$B^ zx{jNZW0fjJBXD`8xAB!Z%Tyknx$Rk53|2S{f{k@LwjEgshl@NQqD|0 z`@W`Ia~TuBB$gX=-XjS?J;AjFdNo^aMNiSi+gBe^95fY4GZ>U`+vN>g&;Zo1gh6`i z*-Q^N}Y%bsHH!z(n7lOJfL`%il&7SHuC!2TYg=c4b{?9+)Bq`A+R4x@|aS&rryx~cd3!-P>~e=nLr4(jz~7RZY~-Ra!zhu= z$v&X@uB5>AdiVY6fMHWk>);gZ`QN+J+X@Q&N8Rm}{<|mzVOSHrbGZGiyhE@d(JByL zwH&ZevQzu{JOQX8>QR*Kk_L6luEpv(vZ5rC2;xQAn_|UDWTUD&Ytb{Dh`s&gyPbhetm3t==#RA0|zV0dfQ)a$dbW zFjR0C{ngp9t1Qd@mfL4*h5pm|Q0s5(lqlF^+51A%r6OfyiYcr&ua`OjE2)9fzgQiET z*qnJU<+X%p*xj~tftYZQ*}(FxY{Ew?h^Fq_HcE+P^at%AW*L{`#RjlAE68-KJbxa9 zDoGwd@!oc~jsM;Wr2X8k4@r$C@?_#@m0X|ic1{2eY3-zuu7CI$cgS^SZBro(@|l+1>7in_)R5*U5%Y{p3f zr5`quVd?h@68niIRP#9X!% zq@=o_!U{qmtP0_Gzhz!;0h|G_=^IG+7=1T^_?8uAwBV$zz5~x(f!I#gk>C7Fpv5r% z9Q!xH)oCTZK5FUSx^@nMP@qXS2HqxZh7| zZVZ;(DjNqsaXPo|MqW(xCB^B=+jmmQo+{j5A`aOP*dzWJCxCT!j{B2)s~vt+o(nm1 z$g{7|gOcw)Iteria3hxgI}0ul3cL}+R|DnIa+(WUtdW%9iAAe11oRTE*2JgrFDSTzblkjCej4hWRuqA;5yR`5 zm!M12u=^dwKV`d>HKcoWVIEUCP-Qscx|8N~{vp3<;fu`ot{h+x0zCBa<`nTz014mA zK5C?Znh_C{_u#vH92~mU0Ouuv;iC8gHx#V7D|L91Z{aBv2U)HIW5pysr-mA<8^-QL z!EDNR$%!`EK{je-dP=+&8fFA%LG$*X`R@*=atS+!mFye8DJ1alJ6Xi9bTp#4LE;bvEOhU-3(YiD4^dP2Ivi=rIya)H_L7(3SUh# z6gZi=F(KQ)ZSd4-&le1Kn=H3^dA%@5r(H`_y%Z`)NJO%s)I5R0`re~QAaw6| zym$wIvgzCov>u%`SwM2OcbeeS0tlA?TZVc|ct8ci6}|aUK*-$rJV@ zGSPNfZ^Q-O6#lbrj12elfq&Uw09Mu+Pz2{NsOh0lUzzf^bt_Ctjnaz$ZuxB{UJh0` z37KXjilDFf)=K4;7dg#8)yL_!Q0-%#9MU{ZY0mR9>(6hVV-~x!TN$kgkz3b>zGsry zEZj8U-R=~XBI!z(4u63m_dd7PPiF1>@>PiMF>Uf|@ z*hEvE=BLtpZScnUy$_ja2=BvTHLgEhU)+gt75^M= zkHxa6P$v;I94xz4SOrclq0ZO!Y+j&woMEt&=$wS}>hATJ*+;~QTt{V{@5M^!;aYS=@5r#ze9E|knW_6h~y z-TggbDUUo0cFp#6R2fKul7JiW_rzl#oBT*)1xU(ZBl4Vs_{zsO(9vc)R@{0PM6`FC z!Q+fm?&e&FEBZU3k?%wMA_zYcqQflCckBPcX=M3lN`i2j{Aq&MZflefVT08C;xOrB zDbN7|@jbP@=QE1P#wj+wM5=Hd?%ioyq&FNzy~&RQkId5UvNR%=?Y(GwlQ7Nv@-zh+ z3z(XXOk}ZJSTB%=0;?^5T@5t?0Ay#@+KhKB-bL9<65R2N z7ZG;sTKc09x7O~y(N=CPoX(fP9?{#7rMGOqsdknZ!zznG-ET6Y5olT zh|-TNCR$Qvbsk9W9lRVHdkR1MICxBbe`2i&(h3loIiGQ?ggeoSo z8if}FqN&Do^sxhXf|6mmxv%-H&R@@`wd$SGO0_w#Lf)pZMQtJ7w!-QQ=ug0A1jm=B ze^a@KaT1%Ntij!EAus9MUIlky&GB$;qCmps~p%RIARw8!7N@~1`Uf@5zq zJtC|*vd(czUTc_~DftJ#Dnw9^-bnOGv&|QS21%tr%2eqf53ed_*^cu=d(T_h;W2j0 zSEr&o)!RiSv25r0kC7ghx&1G8&{-3|$VduN3Kud54JaVvy$Sgjuc~gZ2`@2*_W z^ZA%$?UrY6u^i~8N)%o?Vl@Za(mC~CmNjq3a2DEjiWtxD-R6Hhq>vj+BX#kKUxDuv z@id0v5N=&6n3Q4+d4pAcDa(}c-A+w-sS4aiNe~@xTf_1j3)$m#1pECIFyhFdOh1qm z%F?mqMjAlvsi)7#QtVPS02l`VQolF0BdzVI)$;+Da9&A>k z%eU@jq89R4Ei80(JgUKp7KS6qaeMj%zyt|ymX{{5?D4)!LcQcW%Qo&m_QB%Q!~H19 zWA85;Yzg$L=(XEVblXwiHx%9v(>O7#vLoz3&34(Zbq3JG4z9wA;AF167jvhSwqe*c zK(QNq!M>)`!~McP;zzG?XVrN>2&qP}UUyD-t0I2{@!42L%(NML>K z$+X9iBO$5Q08%+oC$H%`j;G=G>$qIqnX>OdNHzb-651o1$QqP^Uu{94xsn}tX&lUb zZK6x)Ji$p+GdLr~)e5c`;8v)Bd)*I-&t`&JGp;~~P{@&9v$IR1xlYhr9;LQy5@9^7 z2bR<>O7;e#9)kJuRG~u9o{!TK=6Ln`OrG>og=H$&mQDOq$j{9e*{k`h;S!V!?-b^> zY*ZC-_6w78EkoU-IydCsFdLrivSX340gnX7_phR6AMlQ%k@RFpN;Oh~Vpa6;LTk zE@hG0gsAO->WU%O8T_SrB&0$JdZ2ZZK#1-*8Fo!<;zS12?<_%X?Z)Ds=Ao<(#+?d~IOM%0M{Tv`~Vnj?g^Wl(OJOT~6SOOH+tKd4$9mimi25 zyB?hQMZY|PeZsdlf^g_$25iP%6>%^cO$`p1t2TBznrCOn6&q#gj8*~(@;zV?hpSr* zUY`s14i^F2tSXjr<}DOg8^mKUdIBrMK|B|*j~MMMtW*A9duRDoWf!%3KopSfk`M$0 zq`Oh+6p$_n>Fy3ey1PN?knWaFiA{IIrbD{U;(4BTj5Egha{hqVkL+=8@4fDOtu@!Y ze%G9zOse{*PG!97ui1lKX}J4J2ph_&?~{K*<8x!3fXSJ(Z(kJ|pI)y~{+m+gkb33l zqUY`e?Q%EEb|%d&y28STBkXmU_n>-O`ovRI!ZwnGbv_gG7cJhIPXG$veHhfK!GKnCj*GpkoXO0-5Zi zK{pdU?csJGj?^KS@e9|L-$%HQ`nw22*7|e4&;64>$#@d+xe>tLD)*=mb6L)EeP!aK zw_Sm|K3!(^xI&zQ$-fQfLEyJ>Px#I!yG$(Jc>5-4`Lfg3oFCOCVb2={U0`ZxU}lD! zjL?;iRsO@!ZWemlm^s@uWm2TLV39GSWKmi0+YeZyM}ZQlJz3dclsV0P)ra})w}zft zRGvtNp@YZ7z}II3wtK*YTM)9qK425^Y{#iO6Ho%gHc&IAoUg_!W+xf3X#n9@hlf2- zFJ#@U)Ut48{^Yexo$TJ`Y^gLsqVV57 zNbdff)JTiKb`3QJHakMkHv}UI48*aYGhEh!K?$HYahYvEz+!P-OR{Qtp}1XvRK_Xe zs?dRr_GP+M>*glvVgJ#byb2LEO8rw%D=Ns*vUI~Iv~Lb3&MqcH>+=Z2fL;G)r z6)F!Yo%vtC_FZD>eaJSmjd4z&Dn+dF__fDk{xQ;N3 z_2V(F(9Xbw6_53Zv!yXdjaDP4yhz*8+^%Nqj81|xGtlhm$A|Bw$t(ugD6#~-cEYH1 zxSQSGL^aS+Cto{(<yD$JE)KGQ?W*H5f9s=N6I!&brX3TBGn+Ro))oP5aZ^I zpV%!p<$=0-M3FsUE#=^-cR8VGtGYO#20t=2Ep}QdU~waj{SG~!iG6`9p|@Df;FCF9 z$Px9VRt>MJpM%oJ!X$7MynMwPwS+?!ua5?gK+5TvuUyQ#kI7n0OHCc{;}aRKL@$-m zdwhn28(Z{I-!CQV6%z#Fq8<`VYb;LP%vu6zZ9p7+H(m@sK$4~5n)0;+Hhpzr*~S%? zL|HD`^EwbIX~(uLt`srD{p!rZ$m}G8){l&`5KZt5<*h9ccJ6j&ki~*sS3{;5WZq~* zT+Co&JP+v0TZbXwdhtO41;)124vN21ZV4DwCW=^^!< zTI~|U_;01^-{J`MEm@YDHrdkToQA(EB0@)|3xaQ}z1?qw{X6d;t;v(%hx0m@_p>H7 zpI^)Sm?jL-p2^5>XW#~-P!>!TB8^(gHRDRoxV3--Kw_%x(44(`Ub)exBKaxeXv47I zAUNi$Ga7()%okS2py1DnWNN8(9)h^eyx-_g(KDmh~j-T*^u#*(iv2F!#vW zWks*R$@Ks|_gJno(g1X8hQbJWT$N8^sUTR)*Zy*pnr6%{|7)$u0>4vP%Tx`V)p9yb z6fve7Dy&8qr!Qk2rF;n6N-mnsCh6P_K|F(u^Y%-m0yhN`vuBuJ|Kkw-28n0Jfg06% zvT=r9h@wdCB`ee(H-?XcHMO@Ysgrc6hRal)*m_{LqRDPz!<)20% zGFY*Ej#V(CnyY6kT^{u!=&q_1Qhpp z`$~4}rB`I>T&%KA@;uIL#FF_O<`Y-0)5d|`ORxU9x0m<>&Yh@S^;GN7Q3kPmC%B!` z?LFaA^#NL?%w`=bz7sDr>-j-N?uDmY@n$jDTH{ECYrND&TzcRb#H(1%+CJp6a207| zH-}Z+&XY}bDAKJ)m~tzqdlb}6l* z&$Q-Cm6}q6#A1=^??w-bctivGBT#Om>=jvk1Z>wtww~ovZ|j89vo6A`y@<)B+rf|i zoS*uGHAJ`%%jSxsE6OsT?gcDwk8NJ^R;NpqD!EvID-@Uq880SY(@3^RC&*%Q1gKX zYvjgV8rWO7qx$KRwsei&;LI2CGVpM+KF^goOH=GzB5zr%eHpn74vyxV>Lgosp#^?9 zydqVOMrV5Aqy6$vz7rtnfxQ&+lj?hSnZgsY5;c}%|I2D^-2)=sG#CuUN@D`nlB zLc#*ikN-WL%R0leqCCj7kca|KK^mmYYU*@QBY}c-+-kin=x(6qckhQTSl$cLAru%> z@Ds44Q+4w3_`bjm*ZO6Q_=l~(@LG=}&)J4;*XMeI+19TR+4IAfiF0C-0#uUb$V|s6x1dzZFFe-3Hti;-sX{m?bvq-ayyKl`_pQS`QdyYuf{GgUhmQvdl0`}_ zl>6HDyE*2Be}GnGs*RWFcu_oEnpkA2jRCujcw9UXW8+k4^gI>tev=JYKj#$Ltv`}Z zatU@3F%`<42ZX(1^*JyHdTq2mNIOj}el<@0tn_#SM?6rvjO&QL?roS=wSxJj82926 zi)Kuf$3C_^zh3I(9XQK+LiPT*7qtna(&-Q<-^J z$5zm>gE~yE%A4pmVO-LR#_uyaA*+A!g~Ssw^Z|e;W^Goo(Q8!lc_l@VTv>b870aq; z+S9eeP-5|4=2NDl&Z9PP;25k^Z*me#+oT$8VG+`pYH3pxAJjb}mZQ51NpG>0knsS( zL(KO}eFjRyYoP7vAFuH7PeRHDXcZ=~pJHWDRY6@j4poxR`OxCzi)q}5;O!7^4cxRA z-;`A0ldSp{s1Ub}$ZYwt`V+}G78vutE|+D-4_jVL6)1U+cX7?^w=Az4$q@bTYnq%DLk_K(AIQfX(qalWf;YW7F(IgZ-BO@X4_H#khbl1DM zRrea!vIZQ&8~B-+v=dXeHXeR+^P_uCRbW;+NS0v%d88kbU@zHgjVn~^-v420c_3%z zkTPN!oLcf@kH~TNN7H<*MThhjmYh96J(}mb-8pBI^Lxk!TAVhqn(eWUmSg=f;ndDj zrbqhtT@5n5A6!RdnSbrOd{I&J4SF3#ugci?dscmLi9(+sRxF>ew6>T2>Fw5e(uWW6 zc`f56*%YGJO64rDy-&N4Hpa^09*DZslpX`!~!`DhDiB>jqWwxiV}!uFz!@ zIk1R{@gpA>FLPImRo`ue?^fa#M~%Iq4iL8RXbyf&#o|0wYF!#L?J^F(!&9a(KiPCR z;Vb@KZvAsbY{mS{8?1+oSb40Y&+3&1h#s8xXHYg{T&8H)G7hqtHfv~64RWhG>79GU z!7W1>%5@+IvcMJYr(g<T4A;WN>8BiPU<%K+t1zESGYCr9%gSw{1Dch1^H~fn=+j^dTmY1PmPf5DEXfkHh zp|$zwa9&~kU^Sd-@K7e~3-{Vx_j5%SX4Gc{RL2)M{;INtE|WUFMQm9g=oI0{MYF#A z_^@flPUj_E=&*@4Ez{o{8DKuCY@LrJQIt+iBy|BghlotqL17*lH-)RN6N7*M_$)gq z`hQalt6t$JPxRo}%QLjdlV1$znj|Z$Uf#;yfK2>H>p3R26yfb4CM?-Hu`v+CUTCCB zYU)*cMndrO;PIDF&MFeu-bwU+mpte_qO^9|M~C8&re|#oj+orVn9WRj&_whweSC5>be~}!hx(vX)m|>&e3cGn{d(%L zR#9+OZJ`WrgUPh)lv$r(pEuZw$MX4hmv24!sNyZJ64pSWz3PSLqo5lok;VXe{UJ*A~lKA-*VG!{E? z@XJ%eL{x{1em7}b;YxN7$^3xVLWk!BKWd7mWQkoa=LbmuY@wQ7M!d;vAS%lfZc*jX zYz*BmY4ntyh@UsOapXAxuD4t}TjQd;Zp84utCYuA?DqjoYYnn+ zR%q;fA2rYf_it0p_D0u1=Q@yf%1i0ke(v>cdnmce6hciu3BKmxZ@y4>z6H6FC@5@b zb-K|%Wy%iUs@>9PMJ^Ev)9f)%UHO}CCcM?<$UOg!32`AnjPM!X3chBxf$1|HFl5=?=M=@kS^duo= za%19?2^mhPF@G@qw47h2)zCqDwr>zR5bQReTjUO!(c&KY+?;~4=u@daZgqoYRbzMxe;1F>v`xZWlC*8t?rZP{aAp*S^gKy-L)`-x) zAg-Lz#)9Ppk#X8a_~7PCS07N7?KEojmD#dM>j>~?3AnJK1|S$rN}7p#O^Vg&aVj$X z24=xZPEWIT`~b0*URF!cCw2b@2UZ->z{q_h9}so<8}-CG=rh$J^dfDU!4YhizQ7Oq)!IID`NGIB?#R^_m+S z8f=U)mm@j+uJmFi&enXR&3U@l6@_9YAxXh<3xRy~A`qsI9Z1GPNG45aLhrwevpNY1 zKOg%*IddVE4Y`2$1dN#${jP$8b$>5|^i&f;AoKOUDGr)59Pp)k0vj7BKMVnl;Xp$- zV=(n)5J!a51GaaN$d$K}t1~Nq+~SS_oVQ?$dnU^HasN~W zWwWvr&+I@2_RdtEY?>jQGJl8VfjzI_h2ro{bb|Vtp9*U6r{}ExFdwHufA7Aip909D z;@X}lEe|%|CF+(C?+n-1XpFJjwKa?*MaJ#LFIQXmEc4a- zx7wmX!Z(OHoVetkQ*qMpuij);m?7vHHPZ$Z%s%?4rl~6sR)|m!=NBfoF!5$Nk^mWm zW7XDI9KINB;!WQqq6zU=t*6N3o0zbU(OP&Ke3jG&R|G8@6n1Lo^T{`I81e%MQ4RBpdZ%i@r&Q$yToiSas z{lOH5Mz6Ak3(3LbrmUBS ze|x{|uHf+U`Cxf1BT#t=0^|KMVUTL^?9#zSV2z^Kh}#Y%{Rg;m%YvWDt}y%Wpku&_gYc82o7UjpXF{>U4%i)t z$XEIQps-g!B6PyZ4-5X6ul0d|ms1WqUf^GN7SkrqCudF}jrD)`Ax>nn-;zOE7ZRzi_va!c#-HA;hzL&+yiz;jqXL8^xvRMN4gy>-=6 zL*8VM=1wI6O@S%c>-=Sx`7Kny9kLpQ%f>NrGA_}*je7<*H0aWvwTdMWu-Iw@98dji zOD>NjZ%hvDutqOhnqu3#b5F=dwxGtRng&6yJ;5%hZ<81-DQF8Ph)btT!f*CYU>AgO zTr2@W-93Rmpi;6X z7Un|o&$DfPdbZ8ZL9*vfyXuQ8w@x$%%T>to(G<~3;LxA!rp-X2+`}g_IH+7QK;vz~ z*~)?THiJDFqudU+_=|7(qO7;)ap*zQ-|C6OqK46je47d^9phL`Ya+!QmtYWOhv4je zYPFmE?b&#=SY__M_5zYe(Jhq%Q(B8OQE=eqvATj~2Mjmwv}|}ugI0g^Vn{cXqW`nx zr~+$K`%=SU%VWS}V8}#)Qe+IcbF)|a)dQsz5;y|_rX9oud~~Aiht4T<88UL5u(!F9 zTfcV3w_xk6F4{SvjlU>M%~cp#1mFqQ6^xb-wfPg(SS_TONnU&u58oW?>J4LaV=5tf zAOFK27z0+u0wv;_Bu--DzEXYqham5W_Q{KXeo^}4chK-0P7O0_*kzdi=uwMFt9ceL zC+FebbronGKd0YQEt&J)SrSrUDotTq*n4kIAkd=qp@YG-iZ0y3Ak)f;p8D@IlE%M= zIGK_wSFP2^l44o{#ly$;V{24n8dqvMHO8!U1U>n$U+CGLOF`Rhq_dR%838^xbW3+a1OaGcgTc<>X&L^MrHjzdj!8|a#OyL+R7RKe zVIF;b8wBJf7wnUqu;BjSkHIq|w`8}2`0~%a3G*P8#&n&a*sH;#r_f(e5EevbhizPhelK5`!SMFd+m&&qWS4xfB-{T*C zh&*a2^cqq+^x?>IU?K$7Rbsmi0!Cddzk50GzUj+re3@95nj0-PQseuTQj+tdQupCF zsekqmU-GEymyl4$8AJ=rN2@V0ku$`xk(y9z2uft@LrOJ^AG-<=5`yhSz* zN=5nqdJN*8mRe}IYSj~p{Lj@nyjq8GyTHu)KP#Pr+xn!%KWn6~4S+Dw68Uo7LjGAo zMQA~!AGhSfq501WORj}zf@;I$Z00;JPdxqW!tS+Qwi7t});h3w&pCg2%rNn@ze;=- z=ylyq#w|tp^gsBLXH5<)6jnNI)slG)MN78PNatbC8`_eM|rE zrxY0EU?^aG8eT-DZg9SFaYk zufqx2ZLb8Nl&S%`jdy!x#hmxek2aN>vI}!-P8>G*n%=zS2A8kPF0j29MwH7EacJSj zK9aMwag0GUYS>>P$y_znmyg>wvI!a9(*=eOgP}SGT5D*$GB4#~sQ{Omc2hyI!1V>)syzTKP&^(B61n z&-2kkcf{#3DJgf)+rznsu4A^+s8AzMB0r(#Y-3>6bh$7o^OA%iiAjEGfkhA{gWK^U zqF2XrHMnP_&f1WQn9s34sBVkN47SPNc7tJtVE?D@*#WRxu?$q({ zF1N8R@y2NQ!iq`$!tAV{ci_x@LWP;0J?qzs<(5eC2Wy zetmXvv|xBYwOAIGdAnS>zr)FT*w7M~WH~Ug`{s!_MKItm+g5>uW z#F8kD*WPQVezq9fd9q}qo08^hWG(7ITz$nj<>NxRB~$+2D0FZ0hnrvSQh1D`kNvmw zagEpcE#d)T>FL#vI|i4kx4ZL}W&HDYn>{%^gIGdDW63J~*WbhJ*s+9DYMt z{9cv(6-*kB`@_1c`Sq>dG*e(?rcTq>=?ZX-oCDOMEFxURT8;u%dvvdLIlUf|n?;TK zXL$_UxSrQ(V2$o;h}DCh?ol+vOqp@ETJF2I_wi(yHK)34+ua_nf7MwQ`Y6;_JH==? zX0xlm>d3QVx7fN)(^O^!!qn#ObQRY{a+~2*BFG|n8&NWMh20@&G_Y29HvL+mpiC3b zzVS=9N@HT7@jah3HpF;>hMsfZqx55EOWUg>{vA(;;>*3v6$n?UasmPxQIf~a-Jg~~ zX1O(Fd?rZ9B0@wuzh~*aPhBwdL9Im|uY~Mmsu`Eq>!)J@-v>F?H<`s;_+e#9SmZ-2 z4^^AlOWJBxijt(1JDa4L6x&@&zI+3?^WIlokjFa=m0L8bCW(wD=98+;N3QF=Kfm@? z^n~~<21=jx_Q+~V^?+emP-$MtBfD^8_#PN0k6)@=y%pH;e7!*PGEt~RrF6zw(>c<` zUGQrQv)x>v{ZzH7B7^net7i`!>Cva%=FVXr#_xaJxw_i%y4_V5|6D3ha`6lijsqu3 z@oRi?ixeS;g;x((!F6U~ja}QpzYXZ4m_|r8LzknNA|3k~qDGI#xE`i1nhqE-0qZQi z^)4A{C0(1FfuX!Nv0LhWckb&g zI6s~-M%t4rwomv=$YtZruLq|y#sw`b(Ayv{DaoRyD9+>b$6Oj`iF)23rL!jCHiK-A zm0u$l+1&bjI|l8xPOY20?DL@g#SqwFW;#*`Av=8AKQ(nXlXY<^R2OC5pB$= zQ4V47Ix^H;HYjugfr!ib8pC&#Mi{|mE#I5#{LXHY6Z@_DRe)qwYs*pD<7!}rqz?7z zI8|bV(apM{By}ieAk10tUVrzYCDDSXIIZeH9Ho3|(j%IMbooeuye(>?^^D}B<+Y|3 zY0>=H4_8^y7jidU6PT2aJsl`( zqmXm>GhL_=B515{x9y&8?y2vpb_S_Pin%o&|6CouO?yQJeuXzz@8@mBJPD zI<+_NEi+qVB?`ihkr*C(nTUNY z-qdkkzJz-IQUuJW6Yk-ow5SL;CA23N*Q%7MeGAqWwF--rPWBnj;z(~q@s7B5sW7G= zSYAsBR>}FY&{8w_Sbb>|{ozC<#amvdOV|z+)ovWsHhtMm`Puv7wh5i9k%VSkO3a7x z@;QBLX2Z;+tIppZkH4Q&i#M%XOt-jFcSwy}>jYW^7Oq!$B{dYi+9faN;fhFt;&4c0|;gehfVgpV#i3f0e7WWwhOw5nr)n;1I1_ z-?ec53WWjPV!FE5+xd{kLTrK1Uq@qAJTEv|YjObpc7O25h+#I2cRciAML=2R?v_n; zQKe)Bfla##g5=S5w#%pB;1HW3PDoVm+S^Kuyzxt`vD}md&u)9*cRQ#0f)op9i`V$- zd-sajaxp?)1_^udS$%i(bn@dK@#T%s!4`vQroa9W&6R-e2LhJ0gXa$ZF6mTlXk)!!a_R9VVJ&nBCYJ39BwC8N74%qZc5_}bvQX43;j;k{w}+ZSV@X;6v(7ZuhBD(MkAfzARMr$bmhjj^_S!sF=*&?MQpG zDLh-;`t#nZkVuRuLl$MP`c5E#Ev;GV?~%@PE5?q+*rzRX)}tV3S?eLs?4DGhzV4b)~O=dMP7vz3F1z*NBx9 z3N>ZI$ecGrtg44KPj;m5j_5EeyI+d-QTIBjXxQIi=}5E5z^pgxYtr+Dso9K4ruZ@< z-He7Ag!Lq0Z-@ojvMIE@qs^$Ee8FD-rM3BTvhaAyc<`DsBQbT%6plwpOaNFcYY`Cb z$)yvtk_pa&Yfp?LPf~_5e3)4i4(b{evL%W@?m4AJsRWn z#r0~Yy^bW>W1|+~^bESL*0-?w_ti>hXyl8m@*L>kqQ%Jt1zSO33wfdY>gL_PrUr!x ziafkbe*51LQ8aV-9#bQKf^=k!kBnN)hP=d|2C{IAzJWA_2R1k8R}ZW&fM=nF7X44X z17=@TV$QzeKP&E8YyajmMA{Kx@w|Xqw~{UW-?2aH1ini zg|z>^$R7pdHTo7_DvSJ=Ic^5i+CBRx_kWoJL{zxu57&>doHG>Dr3%ZcFyNo0sGLaY IhcDm$4}^p_-v9sr literal 0 HcmV?d00001 From d76604ef4daf659cdf673702ad1b6003b101107e Mon Sep 17 00:00:00 2001 From: Rob Hazan Date: Fri, 4 Nov 2022 13:19:48 -0400 Subject: [PATCH 45/64] Minor rewording around conflict resolution --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 1ea0682..d078456 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ This versioning policy is a break from historical practice for OpenRTB 2.x. In v 1. Once you're happy with your branch, publish it to GitHub. Then create a new Pull Request (PR) to propose merging your changes into the `develop` branch. 1. The Programmatic Supply Chain Working Group and Commit Group will review your update(s), leave comments, and may propose changes. You may need to make additional commits to receive approval for your PR. 1. Once your PR is approved, it will be merged into the `main` branch at the time of the next monthly release. Details below on how the Release Process works. -1. (Sometimes) It's possible, especially if your PR is open for a long time, that it cannot be automatically merged into the `develop` branch. In this case, there will be a message in the PR asking you to resolve conflicts before the PR can be merged. +1. (Optional) If your PR has been open for a long time, it's possible that it cannot be automatically merged into the `develop` branch. In this case, there will be a message in the PR asking you to resolve conflicts before it can be merged. #### Monthly Release-Cutting Process (for repo admins) From bdbfe712e3560b71ed4ce87bedda78f186c134af Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Mon, 7 Nov 2022 15:02:07 +0000 Subject: [PATCH 46/64] Chris Coupland's additions from 4th Dec Meeting --- implementation.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/implementation.md b/implementation.md index 9dda944..87b3678 100644 --- a/implementation.md +++ b/implementation.md @@ -1161,7 +1161,8 @@ Key objects such as imp.qty and dooh have been added to the OpenRTB specificatio | device.geo | object | Since ip may not be available, geo location  lat / lon field is required for DOOH transactions. geo.type is recommended. | | device.devicetype | string array | Digital out of home devices shall be identified as type 8. | | device.ppi | integer | Screen dimensions in inches can be calculated using ppi, w and h. | -| device.ifa | string | A device ID used to identify an individual out of home device. | +| device.ifa | string | A device ID used to identify an individual out of home device. The device.ifa should not be used as a user identifier, but may be used for purposes like frequency capping. + | | device.ifa\_type | string | For DOOH this is usually given as "ppid" to show this is a publisher-provided device id or "sspid" to show this is an exchange-provided device id | | device.eids | object | Used to send additional identifiers. e.g. geopath.org or oohspace.co.uk or to signal the ifa provider. See AdCom eids | | imp.video.boxingallowed | integer | For DOOH, when boxingallowed = 0, the video aspect ratio should strictly match that of the placement, as determined by the video w and h fields. | @@ -1197,9 +1198,15 @@ To calculate the total cost of the transaction: The above auction would translate to an invoice of $0.07575. -### 7.9.5 - DOOH Example Scenarios +### 7.9.5 Auction Notifications +In DOOH, there can be significant delay between winning an auction, and the creative actually being rendered. For this reason, it is strongly recommended to separate the win and billing events, following OpenRTB best practises: +nurl - Auction event notification URL fired when a bid has won the auction. Not a guarantee that impressions will occur. +burl - Auction event billing URL fired when the creative has rendered on screen and impression[s] are billable. -#### 7.9.5.1 - DOOH Banner Bid Request + +### 7.9.6 - DOOH Example Scenarios + +#### 7.9.6.1 - DOOH Banner Bid Request ```javascript { @@ -1303,7 +1310,7 @@ The above auction would translate to an invoice of $0.07575. } ``` -#### 7.9.5.2 - Banner Bid Response +#### 7.9.6.2 - Banner Bid Response ```javascript { @@ -1349,7 +1356,7 @@ The above auction would translate to an invoice of $0.07575. } ``` -#### 7.9.5.3 - DOOH Video Bid Request +#### 7.9.6.3 - DOOH Video Bid Request ```javascript { @@ -1435,7 +1442,7 @@ The above auction would translate to an invoice of $0.07575. } ``` -#### 7.9.5.4 - DOOH Video Bid Response +#### 7.9.6.4 - DOOH Video Bid Response ```javascript { From e7e95625b3a5c581b54dcc2de4cc808849caa62e Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Mon, 7 Nov 2022 15:04:00 +0000 Subject: [PATCH 47/64] Table fix --- implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/implementation.md b/implementation.md index 87b3678..6cdf8c9 100644 --- a/implementation.md +++ b/implementation.md @@ -1162,7 +1162,7 @@ Key objects such as imp.qty and dooh have been added to the OpenRTB specificatio | device.devicetype | string array | Digital out of home devices shall be identified as type 8. | | device.ppi | integer | Screen dimensions in inches can be calculated using ppi, w and h. | | device.ifa | string | A device ID used to identify an individual out of home device. The device.ifa should not be used as a user identifier, but may be used for purposes like frequency capping. - | + | | device.ifa\_type | string | For DOOH this is usually given as "ppid" to show this is a publisher-provided device id or "sspid" to show this is an exchange-provided device id | | device.eids | object | Used to send additional identifiers. e.g. geopath.org or oohspace.co.uk or to signal the ifa provider. See AdCom eids | | imp.video.boxingallowed | integer | For DOOH, when boxingallowed = 0, the video aspect ratio should strictly match that of the placement, as determined by the video w and h fields. | From b6f2ec44d3d997b6c58893e16e2cfc1c5c205e64 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Mon, 7 Nov 2022 15:05:52 +0000 Subject: [PATCH 48/64] Table fix --- implementation.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/implementation.md b/implementation.md index 6cdf8c9..35765c5 100644 --- a/implementation.md +++ b/implementation.md @@ -1161,8 +1161,7 @@ Key objects such as imp.qty and dooh have been added to the OpenRTB specificatio | device.geo | object | Since ip may not be available, geo location  lat / lon field is required for DOOH transactions. geo.type is recommended. | | device.devicetype | string array | Digital out of home devices shall be identified as type 8. | | device.ppi | integer | Screen dimensions in inches can be calculated using ppi, w and h. | -| device.ifa | string | A device ID used to identify an individual out of home device. The device.ifa should not be used as a user identifier, but may be used for purposes like frequency capping. - | +| device.ifa | string | A device ID used to identify an individual out of home device. The device.ifa should not be used as a user identifier, but may be used for purposes like frequency capping.| | device.ifa\_type | string | For DOOH this is usually given as "ppid" to show this is a publisher-provided device id or "sspid" to show this is an exchange-provided device id | | device.eids | object | Used to send additional identifiers. e.g. geopath.org or oohspace.co.uk or to signal the ifa provider. See AdCom eids | | imp.video.boxingallowed | integer | For DOOH, when boxingallowed = 0, the video aspect ratio should strictly match that of the placement, as determined by the video w and h fields. | From 5fab32f1a1fefb4b336ec4045bfccd0da09d78b2 Mon Sep 17 00:00:00 2001 From: "Knitting.Media" <60264355+knittingmedia@users.noreply.github.com> Date: Mon, 7 Nov 2022 15:09:07 +0000 Subject: [PATCH 49/64] nurl and burl lines --- implementation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/implementation.md b/implementation.md index 35765c5..0efd04a 100644 --- a/implementation.md +++ b/implementation.md @@ -1199,8 +1199,8 @@ The above auction would translate to an invoice of $0.07575. ### 7.9.5 Auction Notifications In DOOH, there can be significant delay between winning an auction, and the creative actually being rendered. For this reason, it is strongly recommended to separate the win and billing events, following OpenRTB best practises: -nurl - Auction event notification URL fired when a bid has won the auction. Not a guarantee that impressions will occur. -burl - Auction event billing URL fired when the creative has rendered on screen and impression[s] are billable. +- nurl - Auction event notification URL fired when a bid has won the auction. Not a guarantee that impressions will occur. +- burl - Auction event billing URL fired when the creative has rendered on screen and impression[s] are billable. ### 7.9.6 - DOOH Example Scenarios From 039627c198bc342cfcf1b719391e93d1a2fff182 Mon Sep 17 00:00:00 2001 From: Jason Shao Date: Mon, 7 Nov 2022 11:47:21 -0500 Subject: [PATCH 50/64] Update 2.6.md replace KnittingMedia org references with (future) IAB org references for AdCom changes --- 2.6.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/2.6.md b/2.6.md index 882941b..a01704f 100644 --- a/2.6.md +++ b/2.6.md @@ -2839,7 +2839,7 @@ A programmatic impression is often referred to as a ‘spot’ in digital out-of - + @@ -2860,7 +2860,7 @@ This object should be included if the ad supported content is a Digital Out-Of-H |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/knittingmedia/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md#list-venue-taxonomies- | +|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 (ads.txt) owner (e.g., “mysite.foo.com”) | |keywords |string |Comma separated list of keywords about the DOOH placement. | From 45019aa5f29fa2af2f64a3ee0557b9a04b0a9cba Mon Sep 17 00:00:00 2001 From: Rob Hazan Date: Tue, 8 Nov 2022 11:47:54 -0500 Subject: [PATCH 51/64] Updated directions to fork the repo rather than clone from origin --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index d078456..be224d9 100644 --- a/README.md +++ b/README.md @@ -21,11 +21,11 @@ This versioning policy is a break from historical practice for OpenRTB 2.x. In v #### How To Contribute -1. Clone this GitHub repo into your own GitHub account -1. Create a new branch based on `develop`, giving your new branch a short but descriptive name (e.g. if you're adding support for a new flux capacitor object, you could call the branch "add-flux-capacitor") +1. Create a fork of this GitHub repo in your own GitHub account +1. Create a new branch in your fork, based on `develop`, giving your new branch a short but descriptive name (e.g. if you're adding support for a new flux capacitor object, you could call the branch "add-flux-capacitor") 1. Make the desired changes in your branch, with one commit per logical change (e.g. if you're adding 2 distinct features in your branch, create 2 distinct commits). Give each of your commits a short but descriptive "Summary" name, and then provide a longer "Description" to fully explain your proposed changes. 1. (Optional) Consider doing a round of internal reviews/feedback within your own organization, and make any additional updates in your own branch. -1. Once you're happy with your branch, publish it to GitHub. Then create a new Pull Request (PR) to propose merging your changes into the `develop` branch. +1. Once you're happy with your branch, publish it to GitHub. Then create a new Pull Request (PR) to propose merging the changes from your fork into the `develop` branch of the origin repo. 1. The Programmatic Supply Chain Working Group and Commit Group will review your update(s), leave comments, and may propose changes. You may need to make additional commits to receive approval for your PR. 1. Once your PR is approved, it will be merged into the `main` branch at the time of the next monthly release. Details below on how the Release Process works. 1. (Optional) If your PR has been open for a long time, it's possible that it cannot be automatically merged into the `develop` branch. In this case, there will be a message in the PR asking you to resolve conflicts before it can be merged. From c5a09df4672bf881a81fe431f35b1ecfaa7d47bc Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Mon, 14 Nov 2022 10:34:17 -0500 Subject: [PATCH 52/64] dooh.domain text update Removed reference to ads.txt in dooh.domain --- 2.6.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index a01704f..6178c15 100644 --- a/2.6.md +++ b/2.6.md @@ -2862,7 +2862,7 @@ This object should be included if the ad supported content is a Digital Out-Of-H |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 (ads.txt) owner (e.g., “mysite.foo.com”) | +|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. | From 5ea70fc3677b70188f463f4dc8786012d8d29511 Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Mon, 14 Nov 2022 16:53:46 -0500 Subject: [PATCH 53/64] Update implementation.md --- implementation.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/implementation.md b/implementation.md index 0efd04a..1c97ebb 100644 --- a/implementation.md +++ b/implementation.md @@ -1161,8 +1161,8 @@ Key objects such as imp.qty and dooh have been added to the OpenRTB specificatio | device.geo | object | Since ip may not be available, geo location  lat / lon field is required for DOOH transactions. geo.type is recommended. | | device.devicetype | string array | Digital out of home devices shall be identified as type 8. | | device.ppi | integer | Screen dimensions in inches can be calculated using ppi, w and h. | -| device.ifa | string | A device ID used to identify an individual out of home device. The device.ifa should not be used as a user identifier, but may be used for purposes like frequency capping.| -| device.ifa\_type | string | For DOOH this is usually given as "ppid" to show this is a publisher-provided device id or "sspid" to show this is an exchange-provided device id | +| device.ifa | string | A device ID used to identify an individual out of home device. The device.ifa should not be used as a user identifier or for audience targeting purposes, but may be used for purposes like frequency capping.| +| device.ifa_type | string | For DOOH this is usually given as "ppid" to show this is a publisher-provided device id or "sspid" to show this is an exchange-provided device id | | device.eids | object | Used to send additional identifiers. e.g. geopath.org or oohspace.co.uk or to signal the ifa provider. See AdCom eids | | imp.video.boxingallowed | integer | For DOOH, when boxingallowed = 0, the video aspect ratio should strictly match that of the placement, as determined by the video w and h fields. | | imp.dt | float | Timestamp when the item is estimated to be fulfilled (e.g. when a DOOH impression will be displayed) in Unix format (i.e., milliseconds since the epoch). | From 9da40a79aa08042386e777202a360b39ba052cf2 Mon Sep 17 00:00:00 2001 From: Rob Hazan Date: Tue, 15 Nov 2022 12:42:40 -0500 Subject: [PATCH 54/64] Moved inventorypartnerdomain to the intended location --- 2.6.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/2.6.md b/2.6.md index a464955..fbb67a4 100644 --- a/2.6.md +++ b/2.6.md @@ -1700,7 +1700,12 @@ This object should be included if the ad supported content is a website as oppos - + + + + + + @@ -1801,7 +1806,12 @@ This object should be included if the ad supported content is a non-browser appl - + + + + + + @@ -1850,11 +1860,6 @@ This object describes the entity who directly supplies inventory to and is paid - - - - - @@ -2020,11 +2025,6 @@ This object describes the content in which the impression will appear, which may - - - - - From 69be7a23aae1a49c5ffb6fa5d8fcf743895f3489 Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Tue, 15 Nov 2022 14:08:03 -0500 Subject: [PATCH 55/64] 2.6-202211 Release Notes Update to Appendix B with release notes for 2.6-202211 version --- 2.6.md | 65 +++++++++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 53 insertions(+), 12 deletions(-) diff --git a/2.6.md b/2.6.md index fbb67a4..dd52294 100644 --- a/2.6.md +++ b/2.6.md @@ -1700,12 +1700,7 @@ This object should be included if the ad supported content is a website as oppos - - - - - - + @@ -1806,12 +1801,7 @@ This object should be included if the ad supported content is a non-browser appl - - - - - - + @@ -1860,6 +1850,11 @@ This object describes the entity who directly supplies inventory to and is paid + + + + + @@ -2025,6 +2020,11 @@ This object describes the content in which the impression will appear, which may + + + + + @@ -4407,6 +4407,47 @@ code.google.com/p/protobuf 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. +**Version 2.6 to 2.6-202211:** +
sourcetype integer; recommendedThe source type of the quantity measurement, ie. publisher. Refer to the list https://github.com/knittingmedia/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 https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md#list-multiplier-measurement-source-types-
vendorkwarray string array Array of keywords about the site. Only one of keywords or kwarray may be present.
inventorypartnerdomainstringA 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 objectkwarray string array Array of keywords about the app. Only one of keywords or kwarray may be present.
inventorypartnerdomainstringA 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 objectstring Highest level domain of the seller (e.g., "seller.com").
inventorypartnerdomainstringA 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 objectobject Details about the channel (Section 3.2.24) the content is on.
inventorypartnerdomainstringA 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 objectkwarray string array Array of keywords about the site. Only one of keywords or kwarray may be present.
inventorypartnerdomainstringA 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 objectkwarray string array Array of keywords about the app. Only one of keywords or kwarray may be present.
inventorypartnerdomainstringA 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 objectstring Highest level domain of the seller (e.g., "seller.com").
inventorypartnerdomainstringA 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 objectobject Details about the channel (Section 3.2.24) the content is on.
inventorypartnerdomainstringA 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
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Section        Description                    
**3.1***Object Model* Update to model image to show DOOH and Qty objects
**3.2.3***Object: Regs* Additional fields gpp and gpp_sid to support Global Privacy Protection string
**3.2.4***Object: Imp* new field for etime to denote how long an ad will be rendered on page (see implementation notes for differences between web/app and Digital Out of Home)
**3.2.13, 3.2.14***Objects: Site, App* Added inventorypartnerdomain (previously ext)
**3.2.31***Object: Qty* New object to decribe 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
AdCOM**Lists*: Added lists for DOOH Measurement Source Types, DOOH Venue Taxonomies and depricated DOOH Venue Types
+ **Version 2.5 to 2.6:** From 98c6935bd362088366cc5cfcc9753f12963a46a2 Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Tue, 15 Nov 2022 14:39:27 -0500 Subject: [PATCH 56/64] Update Appendix B change log Change log ORTB Spec version update (2.6 to 2.6-202210) --- 2.6.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index dd52294..d0260d1 100644 --- a/2.6.md +++ b/2.6.md @@ -4407,7 +4407,7 @@ code.google.com/p/protobuf 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. -**Version 2.6 to 2.6-202211:** +**Version 2.6-202210 (Base 2.6 version) to 2.6-202211:** From 506eaac7126710215e8184223b3935e202d26886 Mon Sep 17 00:00:00 2001 From: Rob Hazan Date: Tue, 15 Nov 2022 14:45:35 -0500 Subject: [PATCH 57/64] Making inventorypartnerdomain correction again Previous correction got clobbered by another commit. --- 2.6.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/2.6.md b/2.6.md index dd52294..9cec606 100644 --- a/2.6.md +++ b/2.6.md @@ -1700,7 +1700,12 @@ This object should be included if the ad supported content is a website as oppos - + + + + + + @@ -1801,7 +1806,12 @@ This object should be included if the ad supported content is a non-browser appl - + + + + + + @@ -1850,11 +1860,6 @@ This object describes the entity who directly supplies inventory to and is paid - - - - - @@ -2020,11 +2025,6 @@ This object describes the content in which the impression will appear, which may - - - - - From 194d219185c74fd22e6230c57c2f2a9976cf16e9 Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Thu, 17 Nov 2022 14:26:05 -0500 Subject: [PATCH 58/64] Update 2.6.md main to remove etime mentions removed etime from Object: Imp and Release notes --- 2.6.md | 9 --------- 1 file changed, 9 deletions(-) diff --git a/2.6.md b/2.6.md index a074522..4870370 100644 --- a/2.6.md +++ b/2.6.md @@ -976,11 +976,6 @@ The presence of `Banner` (Section 3.2.6), `Video` (Section 3.2.7), and/or `Nativ - - - - - @@ -4421,10 +4416,6 @@ This appendix serves as an index of specification changes across 2.x versions. T - - - - From a3cabe6683e99b49e95d72fbc4c5678d3d3e72c5 Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Thu, 17 Nov 2022 16:03:14 -0500 Subject: [PATCH 59/64] Update 2.6.md --- 2.6.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/2.6.md b/2.6.md index 4870370..de01e64 100644 --- a/2.6.md +++ b/2.6.md @@ -4422,7 +4422,7 @@ This appendix serves as an index of specification changes across 2.x versions. T - + From f8ad9619105ab1897d1a0c05c58ff4f1e0ec360f Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Thu, 17 Nov 2022 16:40:35 -0500 Subject: [PATCH 60/64] Update implementation.md --- implementation.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/implementation.md b/implementation.md index 1c97ebb..a672be7 100644 --- a/implementation.md +++ b/implementation.md @@ -1166,9 +1166,7 @@ Key objects such as imp.qty and dooh have been added to the OpenRTB specificatio | device.eids | object | Used to send additional identifiers. e.g. geopath.org or oohspace.co.uk or to signal the ifa provider. See AdCom eids | | imp.video.boxingallowed | integer | For DOOH, when boxingallowed = 0, the video aspect ratio should strictly match that of the placement, as determined by the video w and h fields. | | imp.dt | float | Timestamp when the item is estimated to be fulfilled (e.g. when a DOOH impression will be displayed) in Unix format (i.e., milliseconds since the epoch). | -| imp.etime | integer | The exposure time in seconds per view that the creative will be displayed before refreshing to the next creative. | - - + ### 7.9.3 Commercially Critical Ad Quality One bad advert being served at one time to one person is survivable. One bad advert served at one time to 1000’s of people in a public place will lead to a Media Owner and/or Publisher risking their contract/permission to serve ads to networks of screens. @@ -1258,7 +1256,6 @@ In DOOH, there can be significant delay between winning an auction, and the crea ] }, "dt": 12345670, - "etime": 10, "qty": { "multiplier": 14.2, "sourcetype": 1, From 41de32785e3ba107c517b57bb79c66a707b48712 Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Thu, 17 Nov 2022 16:54:32 -0500 Subject: [PATCH 61/64] Update 2.6.md --- 2.6.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/2.6.md b/2.6.md index f45925b..9b91bd1 100644 --- a/2.6.md +++ b/2.6.md @@ -4523,11 +4523,6 @@ This appendix serves as an index of specification changes across 2.x versions. T - - - - -
Section        kwarray string array Array of keywords about the site. Only one of keywords or kwarray may be present.
inventorypartnerdomainstringA 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 objectkwarray string array Array of keywords about the app. Only one of keywords or kwarray may be present.
inventorypartnerdomainstringA 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 objectstring Highest level domain of the seller (e.g., "seller.com").
inventorypartnerdomainstringA 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 objectobject Details about the channel (Section 3.2.24) the content is on.
inventorypartnerdomainstringA 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 objectinteger Advisory as to the number of seconds that may elapse between the auction and the actual impression.
etimeintegerThe minimum exposure time, in seconds per view, that the (uninterrupted) player will display the creative before refreshing to the next creative. If the field is absent, the exposure time is unknown. If 0, the exposure time is indefinite.
ext object**3.2.3** *Object: Regs* Additional fields gpp and gpp_sid to support Global Privacy Protection string
**3.2.4***Object: Imp* new field for etime to denote how long an ad will be rendered on page (see implementation notes for differences between web/app and Digital Out of Home)
**3.2.13, 3.2.14** *Objects: Site, App* Added inventorypartnerdomain (previously ext)
**3.2.31***Object: Qty* New object to decribe source of multiplier value in Digital Out of Home *Object: Qty* New object to describe source of multiplier value in Digital Out of Home
**3.2.32****7.9** *Implementation Notes* Addition of notes, examples and best practices for utilizing DOOH
AdCOM**Lists*: Added lists for DOOH Measurement Source Types, DOOH Venue Taxonomies and depricated DOOH Venue Types
**Version 2.5 to 2.6:** From f210fc110abbb003b1d25d957aae6bf2e356d22c Mon Sep 17 00:00:00 2001 From: hillslatt <114763292+hillslatt@users.noreply.github.com> Date: Thu, 17 Nov 2022 16:57:12 -0500 Subject: [PATCH 62/64] Update 2.6.md --- 2.6.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/2.6.md b/2.6.md index 9b91bd1..bd244fc 100644 --- a/2.6.md +++ b/2.6.md @@ -4445,6 +4445,10 @@ Following is an example of a bid response that returns a native ad inline to be - [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 - 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 - Digital Out-Of-Home](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/OOH-Ammends/implementation.md#79---digital-out-of-home-) + # Appendix A. Additional Information From 475f7981058ecc20c875185321f7038c6add0a20 Mon Sep 17 00:00:00 2001 From: Rob Hazan Date: Thu, 17 Nov 2022 17:06:06 -0500 Subject: [PATCH 63/64] Fixing table of contents for Implementation Notes --- 2.6.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/2.6.md b/2.6.md index bd244fc..f13ab7a 100644 --- a/2.6.md +++ b/2.6.md @@ -206,9 +206,7 @@ THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MAT - [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 - 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 - Digital Out-Of-Home](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/OOH-Ammends/implementation.md#79---digital-out-of-home-) +- [7.9 - Digital Out-Of-Home](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#79---digital-out-of-home-) ## [Appendix A. Additional Information](#appendixa) From 44c12404aa44f46ed92c3ca51ef42ad5de181567 Mon Sep 17 00:00:00 2001 From: Rob Hazan Date: Thu, 17 Nov 2022 17:10:57 -0500 Subject: [PATCH 64/64] Fixing broken tags --- 2.6.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/2.6.md b/2.6.md index f13ab7a..3e1839c 100644 --- a/2.6.md +++ b/2.6.md @@ -4545,7 +4545,7 @@ This appendix serves as an index of specification changes across 2.x versions. T *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**/code> + **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 @@ -4561,11 +4561,11 @@ This appendix serves as an index of specification changes across 2.x versions. T *Substition Macros*, Added AUCTION_MIN_TO_WIN - **4.2.3**/code> + **4.2.3** *Object, Bid*, Added apis - **3.2.4**/code> + **3.2.4** *Object: Imp*, Added rwdd @@ -4593,11 +4593,11 @@ This appendix serves as an index of specification changes across 2.x versions. T *Removed previously deprecated attributes*, Object: Banner, wmax, hmax, wmin, hmin, Object: Video, protocol, Object: Content, videoquality - **7.6**/code> + **7.6** *Pod Bidding for Video and Audio implementers guide* - **7.7**/code> + **7.7** *Network and Channel object examples* @@ -4635,7 +4635,7 @@ This appendix serves as an index of specification changes across 2.x versions. T *Object Model: Bid Request*, Update to include Source and Metric objects. - **3.2.1**/code> + **3.2.1** *Object: BidRequest*, Attributes bseat, wlang, and source have been added. @@ -4651,11 +4651,11 @@ This appendix serves as an index of specification changes across 2.x versions. T *Object: Metric*, New Metric object has been added. - **3.2.6**/code> + **3.2.6** *Object: Banner*, Attribute vcm has been added. - **3.2.7**/code> + **3.2.7** *Object: 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. @@ -4683,11 +4683,11 @@ This appendix serves as an index of specification changes across 2.x versions. T *List: API Frameworks*, Item 6 has been added. - **5.9**/code> + **5.9** *List: Video Placement Types*, New list has been added. - **5.10**/code> + **5.10** *List: Playback Methods*, Items 5-6 have been added.