[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:

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

§ 5.9:

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

Proposed text

§ 5.2, in the placement subsection (proposed in our placement filing),
add a key:

| `feed` | REQUIRED when `channel` is `audio` | A value from AdCOM 1.0 List: Feed Types: Music streaming service (1), FM/AM broadcast (2), Podcast (3), Catch-up radio (4), Web radio (5), Video game (6), Text to speech (7) | `AudioPlacement.feed`, `audio.feed` |

§ 5.2, replace the content_detail row:

| `content_detail` | Object | seller-set | Shows, series, sections, network verticals. When `placement.feed` is Podcast (3) or Catch-up radio (4), REQUIRED `episodes`: `new` (released within the flight) \| `catalog` (released before it) \| `all` |

§ 2.1, add to the per-line-item summary: `placement.feed`.

§ 5.9, replace the serving_mode row and add a row after it:

| `serving_mode` | Enum | seller-set | `client_side` \| `ssai` \| `dai` \| `embedded` |
| `retention` | Object | seller-set | REQUIRED when `serving_mode` is `embedded`. `{ min, max }`, ISO 8601 durations 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. Only copies in this line item's `placement.feed` count toward delivery |

After the table:

On an audio line item, `dai`: an ad server picks the ad for each listener
when the content or the ad break is requested, including ad replacement in
a station's stream. `embedded`: the ad is recorded into
the content or aired in a live program, so everyone who hears that content
hears 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_start` and `flight_end` bound release or air dates.
  Delivery to that content after `flight_end` counts toward `commitment`
  until the agreed `controlling_measurement` option's `final_after`
  (proposed in our settlement filing) elapses after `flight_end`. An
  `embedded` line item MUST therefore offer `controlling_measurement`.
- `episodes`, when present, MUST be `new`.
- `geo`, `device`, and `frequency_cap` MUST be absent. `daypart` bounds
  air time, not listening time, so `time_zone` (proposed in our
  targeting-values reply on #58) MUST NOT be `viewer_local`.
- `transaction_mechanism.available[]` MUST be `DIRECT_IO` only.

Why

An audio line item can't say whether it sells a podcast, a music stream, or a station simulcast, or whether the ad is recorded into the episode. 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 are counted per listening session. The IAB Tech Lab Podcast Technical Measurement Guidelines v2.3 count podcasts from server logs, because most players that download a podcast "send no information about playback". Copied to a podcast network, the § 6.4 example's completion_rate 0.92 promises something else. AdCOM 1.0 AudioPlacement carries feed, so it joins our placement filing's object.

Embedded. The guidelines name baked-in ads, which "are part of the content", so "everyone who downloads the episode gets the same ads", and ads inserted "at the time of episode request". The IAB Digital Audio Buyer's Guide 2.0 says native ads, "often host read", "can be permanently integrated into the program or dynamically inserted". § 5.9 has no value for the first. On a baked-in read, the buyer reads flight_end as the day the ad stops. The seller reads it as the last release date, while downloads keep coming. Copied to a baked-in read, the example's 1–6 per listener cap is unenforceable, and PREFERRED_DEAL has no bid request.

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 in every copy; only copies in the line item's feed count.

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

Knock-on effects

• § 6.4 gains placement.feed Music streaming service (1). Appendix A gains a retention row; Appendix B counts one more seller-set field.
• Our channel and environments filing drops audio_streaming: channel carries the medium, feed the kind of audio.
• Our programs and live events filing keeps episodes in content_detail.
• 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). For catalog episodes (episodes: catalog or all), classification.assessed_at SHOULD postdate the episode's release, so the buyer screens the audio it buys. An embedded line item sells only new episodes, which don't exist when the buyer commits, so the buyer screens it on show-level categories, assessed from earlier episodes.
• Our draft PR for #89 leaves feed out of its placement subsection for this filing to add. The PR's rule that a key matches when its value is equal applies to feed.
• Per-source counting (#38): podcast ad deliveries count with tracking: server (our reply). Our settlement filing's final_after bounds when post-flight deliveries stop counting.
• 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, since some sellers book baked-in reads as PROGRAMMATIC_GUARANTEED through an SSP for billing even though no bid request exists?
2. Should retention be REQUIRED on every embedded line item, or only when the seller distributes a stored copy, so that a live read or broadcast spot that is never recorded can omit it?
3. Should episodes stay a content_detail key, as proposed, move into placement from our placement filing, or move onto a series option in programs from our programs and live events filing? It binds delivery, and separating brand safety disclosure from content_detail (#46) would let a seller leave content_detail empty.
4. Should delivery after flight_end on an embedded line item stop counting when our settlement filing's final_after elapses, as proposed, or should embedded carry its own delivery window beside retention so it doesn't depend on that filing?
5. Should the § 6.4 audio line item example declare Music streaming service (1), as proposed, or Web radio (5) or Podcast (3), given that it offers the audio/host-read-30s format?
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 on a series option in programs from our programs and live events filing? This ties to question 3, on where episodes sits.
7. Should an embedded line item let the buyer reject a new episode before the ad is recorded into it, and 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-10-25: Knock-on effects and open questions 6 and 7 add per-show and per-episode content categories and how an embedded line item is screened, from @esteininger's comment and our reply. Knock-on effects also note that our draft PR for #89 leaves feed for this filing to add.

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