[Change] § 5.2, § 5.9 — Audio: name the feed, and say when an ad is recorded into the content #101

What kind of change?

Add a new field

Which section?

Whole document / more than one section

Current text

§ 5.2 and § 5.9:

| `content_detail` | Object | seller-set | Shows, series, sections, network verticals |

| `serving_mode` | Enum | seller-set | `client_side` \| `ssai` \| `dai` |

Proposed text

§ 5.2, in place of the `content_detail` row:

| `episodes` | Enum | REQUIRED when `placement.feed` is Podcast (3) or Catch-up radio (4) | seller-set | `new` \| `catalog` \| `all`. `new`: released within the flight. `catalog`: released before it. `all`: either |

§ 5.2.2, a `Placement` key:

| `feed` | Integer | REQUIRED when `channel` is `audio` | A value from List: Feed Types, such as Podcast (3) | `AudioPlacement.feed`, `audio.feed` |

§ 2.1, `LineItemSummary` adds the paths `episodes` and `placement.feed`.

§ 5.9, the `serving_mode` row and a row after it:

| `serving_mode` | VocabularyTerm | OPTIONAL | seller-set | How the ad reaches the content or the player. Core terms: `dai` \| `scheduled` \| `embedded`, defined below. `placement.ssai` states server-side insertion |
| `retention` | Range[Duration] | REQUIRED when `serving_mode` is `embedded` | seller-set | From release or air. The ad stays in every copy of the content the seller distributes for at least `min` and is removed by `max`. No `max`: indefinitely. When `placement.feed` is present, only copies in that feed count toward delivery |

Later in § 5.9:

The `serving_mode` core terms mean the same on every channel:

- `dai`: an ad server picks the ad for each impression when the content or the ad
  break is requested, including ad replacement in a station's stream.
- `scheduled`: the media owner's scheduler pushes plays to the player.
- `embedded`: the ad is recorded into the content or aired in a live program, so
  everyone who receives that content receives that ad. A baked-in podcast read, a
  live read, and a broadcast spot carried in a simulcast are `embedded`.

On an `embedded` line item:

- `commitment.flight` bounds release or air dates. Delivery to that content after
  `commitment.flight.end` counts toward `commitment` until the `final_after` of the
  `controlling_measurement` option in effect elapses after that end (§ 5.7.1).
- `episodes`, when present, MUST be `new`.
- `geo`, `markets`, `device`, and `frequency_cap` MUST be absent. `daypart` bounds air
  time, not listening or viewing time, so `time_zone` MUST NOT be `viewer_local`.
- `transaction_mechanism.available[]` MUST hold only the `direct_io` option.

§ 5.7, `controlling_measurement` is REQUIRED when `serving_mode` is `embedded`.

§ 5.7.1, after the final-count sentence:

An `embedded` line item with no `final_after` also states no end to the counting in
§ 5.9, and `terms_refs[]` (§ 5.8) may state one.

Why

An audio line item can't say whether it sells a podcast, a music stream, or a station simulcast. It also can't say whether the ad is recorded into the content. Those two facts decide what the flight, the targeting, and a delivered unit mean.

Feed. § 5.2 has one audio value, audio_streaming. OpenRTB 2.6 audio.feed already sends the difference, from AdCOM 1.0 List: Feed Types. Streams count per listening session. The IAB Tech Lab Podcast Technical Measurement Guidelines v2.3 count podcasts from server logs, because most players "send no information about playback". Copied to a podcast, the § 6.4 example's completion_rate 0.92 promises something else.

Embedded. The guidelines name baked-in ads, which "are part of the content", so "everyone who downloads the episode gets the same ads". The IAB Digital Audio Buyer's Guide 2.0 says native ads "can be permanently integrated into the program or dynamically inserted". On a baked-in read, the buyer reads the flight end as the day the ad stops. The seller reads it as the last release date, while downloads keep coming. No frequency cap can apply, and no bid request exists for a deal to act on.

Retention. Baked-in ads "can't easily be removed or changed once the episode has published" (Acast), so a promo code outlives its offer. The parties agree how long the ad stays.

Our video and audio PR carries this text, and our settlement PR the final_after sentence. The rules issue lists the embedded rules we left out.

Details: Audio feed and embedded ads: full rationale and examples

Knock-on effects

• Our channel and environments change request (#90) drops audio_streaming: channel carries the medium, and feed the kind of audio.
• Our placement change request (#89) adds placement.ssai, so serving_mode drops client_side and ssai.
• Our DOOH properties change request (#96) adds the serving_mode core term scheduled.
• Content categories on inventory (#48), from @esteininger. If accepted, a seller should be able to declare categories per show or per episode for Podcast (3) and Catch-up radio (4). On catalog episodes, classification.assessed_at should postdate release, so the buyer screens the audio it buys. An embedded line item's new episodes don't exist at commit, so the buyer screens it on show-level categories, as @esteininger notes on this issue.
• Per-source counting (#38): a podcast count is a metric term that cites the podcast guidelines (our reply).
• Downstream: feed checks against imp.audio.feed. embedded lands in OpenDirect 2.1 only.

Open questions for the working group

1. Should an embedded line item be limited to direct_io with a MUST, as proposed, or with a SHOULD? Some sellers book baked-in reads as programmatic_guaranteed through an SSP for billing, though no bid request exists.
2. Should retention be REQUIRED on every embedded line item, as proposed, or only when the seller distributes a stored copy? A live read or broadcast spot that is never recorded could then omit it.
3. Answered in our video and audio PR. Should episodes stay a content_detail key? Or should it move into placement from our placement change request (#89)? Or onto a series option in programs from our programs change request (#100)? None of these: content_detail is removed, and episodes is its own seller-set field in § 5.2.
4. Answered in part in our video and audio PR: Should post-flight delivery on an embedded line item stop counting when our settlement change request (#95)'s final_after elapses? Or should embedded carry its own delivery window? final_after ends it when present, and controlling_measurement is REQUIRED under embedded. Still open: should final_after be REQUIRED on the option in effect too? The rules issue lists it.
5. Answered in our video and audio PR. Should the § 6.4 audio line item example declare Music streaming service (1), Web radio (5), or Podcast (3)? It offers the audio/host-read-30s format. The example declares Music streaming service (1), and the host read is pre-recorded. A new embedded podcast example covers the podcast.
6. Content categories on inventory (#48) puts declared[] on the line item. Where should per-show and per-episode categories sit? On a show or episode key in [Change] § 5.2, § 5.5: Structured content categories (taxonomy_ref) on inventory, and a contextual targeting bound #48's declared[] entries, or as AdCOM 1.0 Content cat and cattax in a programs option's content? There, as every content key does, they would also limit which impressions match.
7. Should an embedded line item let the buyer reject a new episode before the ad is recorded into it? If so, on what pre-release disclosure?

Would this break an implementation already built to this draft?

Yes — breaking

Alternatives you considered and rejected

• Audio values in environments: that field is buyer-selected and says where an ad renders; the feed is what the content is.
• Insertion in the format id (audio/host-read-baked-30s): it doubles every id; insertion isn't creative shape.

You are commenting as

Other — IAB Tech Lab member (Postindustria).

Before you submit

• I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
• This contains no confidential or commercially sensitive information.

Revised 2026-11-03: Rewritten against our video and audio PR: episodes is its own field, serving_mode gains scheduled, and markets is absent under embedded. Questions 3 to 5 state answers, 4 in part.

Analyzed and generated with the help of Claude, fully reviewed by me.