-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added 7.11 to Implementation.md #67
Open
katiestroudpro
wants to merge
6
commits into
InteractiveAdvertisingBureau:develop
Choose a base branch
from
katiestroudpro:main
base: develop
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
bded6db
Added 7.11 for podcast signaling
katiestroudpro 556bc13
Sync main with dev (#64)
07ce7dc
Update implementation.md
katiestroudpro 675f84a
Add 7.11 Signaling Podcast Inventory (with simple TOC)
katiestroudpro 654b55e
Merge branch 'InteractiveAdvertisingBureau:main' into main
katiestroudpro 09cb7f2
Update implementation.md removed supply chain verification section
katiestroudpro File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,6 +2,18 @@ | |
# 7. Implementation Notes <a name="7implementationnotes"></a> | ||
|
||
The following section will provide brief notes on how certain objects and fields are to be interpreted and implemented. | ||
|
||
### [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-) | ||
### [7.9 - Digital Out-Of-Home](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#79---digital-out-of-home-) | ||
### [7.10 - Updated Video Signals](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#710---updated-video-signals) | ||
### [7.11 - Signaling Podcast Inventory](signalingpodcastinventory) | ||
|
||
## 7.1 - No-Bid Signaling <a name="nobadsignaling"></a> | ||
|
||
|
@@ -43,6 +55,8 @@ Make best effort to classify and reject non-human traffic (NHT) requests for ads | |
- For exchanges, filtering the impression means that the exchange should respond to the “ad call” with either a blank HTTP 204 response or an unpaid ad (PSA) and not offered to any bidders. | ||
- For bidders, filtering the impression means that the bidder should respond with a no-bid. | ||
- For both exchanges and bidders, the impression transaction records should be clearly marked in any logging systems and be removed from contributing to any event counts associated with planning, forecasting, and reporting systems. | ||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) | ||
|
||
## 7.2 - Impression Expiration <a name="impressionexpiration"></a> | ||
|
||
|
@@ -75,7 +89,9 @@ The following expiration times are offered as examples of reasonable delays base | |
<tr> | ||
<td>Audio or video with server-side stitching</td><td>Very Long or Unknown</td></tr> | ||
</table> | ||
|
||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) | ||
|
||
## 7.3 - PMP & Direct Deals <a name="pmpdirectdeals"></a> | ||
|
||
**Best Practice Bidding Logic** <a name="bestpracticebiddinglogic"></a> | ||
|
@@ -200,7 +216,9 @@ With Deal ID buyers are sellers are communicating directly. The Exchange and Bid | |
|
||
- Same as Case-6. | ||
- Deal ID represents some combination of private first-party data from the Publisher. | ||
|
||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) | ||
|
||
## 7.4 - Skippability <a name="skippability"></a> | ||
|
||
This section clarifies the common use cases related to declaring skippability of video creatives. | ||
|
@@ -284,6 +302,8 @@ When responding to Case-3 with this skippable attribute specified in the bid, th | |
``` | ||
|
||
In Case-1 and Case-2 where the publisher may impose its own skippability, creative attribute 16 should not be specified. Furthermore, publishers are advised to filter responses containing attribute 16 since this could conflict with the skip button rendered by the publisher. When using a VAST 3.0 response, publishers may choose to implement support for VAST 3.0 `skipoffset` at their discretion and ads should be assumed to play non-skippable if the player does not support it. | ||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) | ||
|
||
## 7.5 - Regs Resources <a name="regsresources"></a> | ||
|
||
|
@@ -296,6 +316,7 @@ Please see the below resources for more details and framework specifications sho | |
|
||
**<a href="https://github.com/InteractiveAdvertisingBureau/USPrivacy">CCPA (California Consumer Privacy Act)</a>** | ||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) | ||
|
||
## 7.6 - Pod Bidding for Video and Audio <a name="podbidding"></a> | ||
|
||
|
@@ -973,7 +994,7 @@ BidResponse | |
} | ||
``` | ||
|
||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) | ||
|
||
## 7.7 - Network vs Channel Example Cases <a name="networkvschannel"></a> | ||
|
||
|
@@ -1000,7 +1021,9 @@ Starting in version 2.6, OpenRTB now supports Network and Channel objects. See < | |
- Samsung TV is the device | ||
- Pluto is the network (also identified by `bundle`) | ||
- PlutoTV Spotlight is the channel | ||
|
||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) | ||
|
||
## 7.8 - Counting Billable Events and Tracked Ads <a name="countingbillableevents"></a> | ||
|
||
There are multiple conventions for how to count billable events or tracked ads via OpenRTB, typically an impression or other such common metric. This section outlines the common ones, addresses common mistakes, and offers a comparison of the approaches. | ||
|
@@ -1107,10 +1130,13 @@ These HTTP headers allow recipients of impression notifications to run anti-IVT | |
|
||
**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. | ||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) | ||
|
||
## 7.9 - Digital Out-Of-Home <a name="dooh"></a> | ||
|
||
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. | ||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) | ||
|
||
### 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. | ||
|
@@ -1483,6 +1509,8 @@ In DOOH, there can be significant delay between winning an auction, and the crea | |
} | ||
``` | ||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) | ||
|
||
## 7.10 - Updated Video Signals | ||
#### 7.10.1 - Examples | ||
#### 7.10.1.1<strong> Instream Video:</strong> | ||
|
@@ -1534,3 +1562,66 @@ Here is an example ad request: | |
“plcmt”: “4” | ||
} | ||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) | ||
|
||
## 7.11 - Signaling Podcast Inventory <a name="signalingpodcastinventory"></a> | ||
|
||
As the Podcast Industry continues to grow and mature, it is important for the industry to adhere to advertising and content guidelines successfully established in other channels. This guide serves as a tool to consolidate and highlight a clear way to pass the most important signals available today in podcasting through programmatic channels. | ||
|
||
While IAB Tech Lab advises that all partners participating in the programmatic buying and selling of podcast inventory should pass all prescribed information below, this is first and foremost a technical guideline built to outline process and does not supersede individual business relationships established by buyers and sellers. It does, however, fully define how data should be sent. | ||
|
||
In the tables below, an added column for “Value” is used to define the expected information in the listed field for podcast inventory. This is additional information beyond the description of the field provided formally in OpenRTB and helps to reduce ambiguity about how to use the field to signal podcast inventory. | ||
|
||
### 7.11.1 Identity Signals in the Device Object | ||
|
||
Programmatic advertising is an operational tool built to simplify the process of buying and selling inventory. To accomplish that simplicity, it is important not only to provide as many data signals as possible for a medium, but also to pass them predictably in the prescribed parameters. | ||
|
||
Identity signals enable all sides of programmatic advertising to augment data, providing a unique value proposition to their clients. Some channels offer additional ID types, such as cookie IDs, device IDs, and other proprietary solutions as a match point. To supplement for these ID’s, podcast ad servers or SSPs should pass a consistent synthetic ID composed of a hashed IP address and Device User Agent to provide a probabilistic alternative for buyers looking for this type of anchor. | ||
|
||
IAB Tech Lab recommends passing the following values as identified in the OpenRTB spec: | ||
|
||
#### Object: Device | ||
|
||
|**Field** |**Value** |**Type**|**Description** | | ||
|:------|:----------|:------------|:------------------------------------------------------------------| | ||
|ua |User agent |string |A raw user agent string from the browser. See ua field under device object for more details.| | ||
|sau|User agent|object|Structured user agent as an object detailing device make, model, app, version etc.| | ||
|ip|Ip address|string|IPv4 address closest to device.| | ||
|ifa|Device ID|string|For podcast specifically, SSPs should fill in using a persistent synthetic ID.| | ||
|
||
#### Signaling ifa_type in the Device Object | ||
|
||
The identifier for advertisers (ifa) type is signaled in OpenRTB using [device.ext](https://github.com/ChrisBasis/openrtb/blob/master/extensions/community_extensions/ifa_type.md) to indicate the source of the id (i.e. device, publisher, SSP, or session-based). It does not enumerate platform specific ids such as Roku, Apple, or Android. When the ifa_type is provided by the device (device.ext.ifa_type=dpid), the platform is inferred based on other signals within OpenRTB. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should link to other IABTL documentation. It's not a standard if it's not also here. |
||
|
||
**Note:** Inventory that does not provide these values should be expected to be classified as “unverifiable” with the expectation that buyers are likely to de-prioritize. The passing of these signals from podcast channels will enable larger programmatic budgets from advertisers adhering to premium buying standards. | ||
|
||
|
||
### 7.11.2 - Content and Audio Signals | ||
|
||
Providing clear identification of content is just as important as listener identification signals. Podcasting has a wealth of knowledge contained within episode, show, and genre that will empower robust analytics and activation opportunities by programmatic partners. | ||
|
||
#### Object: Content | ||
|
||
|Field|Value|Type|Description| | ||
|:----|:----------|:----------|:----------------------------------------------------------------| | ||
|series|show name|string|Content title. Specifically for podcast inventory, use the show name.| | ||
|title|episode title|string|Content series. Specifically for podcast inventory, use the episode title.| | ||
|genre|category|array of string|Genre that best describes the content (e.g., true crime, comedy, etc.). IAB podcasts genre taxonomy preferred. | | ||
|len|duration|integer|length of content in seconds| | ||
|id|GUID|string|Unique ID identifying episode. For podcast inventory, use the GUID.| | ||
|url|RSS URL|string|Unique URL identifying show. For podcast inventory, use the RSS URL.| | ||
|
||
**Note:** for the above id and url fields, providing GUID and RSS URL are unique to podcast inventory to support signaling podcast inventory specifically. | ||
|
||
#### Object: Audio | ||
|
||
|**Field**|**Value**|**Type**|**Description**| | ||
|:----|:----------|:----------|:------------------------------------------------------------------| | ||
|startdelay|ad position|integer|Indicates the start delay in seconds for pre-roll, mid-roll, or post-roll ad placements. Refer to List: [Start Delay Modes](https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/master/AdCOM%20v1.0%20FINAL.md#list--start-delay-modes-) in AdCOM 1.0. | | ||
|podid| |string|Unique identifier indicating that an impression opportunity belongs to an audioad pod. If multiple impression opportunities within a bid request share the same podid, this indicates that those impression opportunities belong to the same audio ad pod.| | ||
|
||
|
||
### 7.11.3 - Updates and Feedback for Signaling Podcast Inventory | ||
Thank you for your attention to these important implementation guidelines for signaling podcast inventory. We are open to your feedback and suggestions that will help us achieve our above stated goals. For questions or comments on these implementation guidelines, please post an issue or email [email protected]. | ||
|
||
[Top](https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md#7-implementation-notes-) |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see a difference in the usage of
ua
,sua
for podcasts -- why is this needed? :)