[Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label

@fgranata

What kind of change?

Change a field's type or shape

Which section?

Whole document / more than one section

Current text

§ 5.1:

| `channel` | Enum | immutable | `display` \| `video` \| `audio` \| `ctv` \| `dooh` \| `native`. The discriminator for how the rest of the line item is read |

§ 5.2:

| `environments` | Object | selectable | `available[]` from `web_desktop` \| `web_mobile` \| `app_mobile` \| `ctv` \| `dooh` \| `audio_streaming` |

Proposed text

§ 5.1, `channel` row:

| `channel` | MediaChannel | REQUIRED | immutable | Core terms in § 5.1.1. The discriminator for how the rest of the line item is read |

#### 5.1.1 channel

An impression's channel is the first row of this table that the impression
matches. Conditions are stated in AdCOM 1.0 terms: the distribution channel,
the ad's media (`Placement` subtypes) and the device type. Where an impression
accepts more than one medium, its media is that of the ad served.

| `channel` | Condition |
| :--- | :--- |
| `dooh` | Distribution channel `Dooh` |
| `audio` | Audio ad (`AudioPlacement`) |
| `ctv` | A TV device type |
| `native` | Native ad (`DisplayPlacement.nativefmt`), including native ads with video assets |
| `video` | Video ad (`VideoPlacement`) |
| `display` | Any other display ad (`DisplayPlacement`) |

**`MediaChannel`** is a `VocabularyTerm` (§ 2.2) whose core terms are the rows
of this table. An impression a row matches has that row's channel, so an
extension term covers only impressions no row matches.

Device types are values of AdCOM 1.0 List: Device Types, each written as its
name followed by its code. The *TV device types* are Connected TV (3),
Connected Device (6), and Set Top Box (7). The *mobile device types* are
Mobile/Tablet - General (1), Phone (4), and Tablet (5).

- The seller MUST serve a line item only on impressions of its `channel`.
  Placement type, such as interstitial or rewarded (OpenRTB 2.6
  `video.plcmt`, `imp.instl` and `imp.rwdd`), does not change the channel.
- Impressions in linear TV, including addressable linear, are outside this
  table: they have no core `channel` term in 3.0.

§ 5.2, `environments` row:

| `environments` | Selectable[Environment] | OPTIONAL | selectable | The distribution channels and device types the line item runs on. See 5.2.1. Absent: the seller promises no environment |

#### 5.2.1 environments

**`Environment`** is a value of this table. Each value is the set of
(distribution channel, device type) pairs formed from its row, in AdCOM 1.0
terms. An impression matches the value when both its distribution channel and
its device type are in the row. Device types are as in 5.1.1.

| `environments` | Distribution channel | Device types |
| :--- | :--- | :--- |
| `web_desktop` | `Site` | Personal Computer (2) |
| `web_mobile` | `Site` | The mobile device types |
| `app_mobile` | `App` | The mobile device types |
| `ctv` | `Site` or `App` | The TV device types |
| `dooh` | `Dooh` | Any |

Each `environments.available[]` value MUST match at least one impression to
which 5.1.1 gives the line item's `channel`.

§ 2.1, `LineItemSummary`: add `environments.available[]`.

Why

channel and environments have no definitions, and their values overlap. Two sellers can label the same impression differently, and a buyer can't check delivery against the label. In @jaanijuk's mapping run on #8, deriving environments from an ad server's environment type labeled a DOOH screen as web inventory. We define each value in the terms AdCOM uses to describe an impression: distribution channel, ad media, and device type. Delivery is then checkable wherever the impression carries them.

video or ctv? The CTV example uses channel: ctv, but nothing rules out channel: video with environments: [ctv]. The § 2.1 summary carries channel but not environments.
dooh is a distribution channel. OpenRTB 2.6 Object: DOOH replaces site or app, with any media.
native is a display format. AdCOM puts it inside DisplayPlacement, so native video fits two values.
audio_streaming names a medium, not a surface, as @fgranata notes on #8. ctv stays in both fields. As a channel, it marks line items whose frequency_cap.per and placement.ssai differ from web and app. As an environment, it is the TV surface, which an audio line item can also select.

The first-match order keeps the six labels and gives each impression one. Because channel is an open vocabulary, an extension term covers what no row matches. Print and static OOH have no ad-served impression. @matthew-iabtechlab filed the print channel change request (#102) for BCN, and @clerongi and @premesh raised OOH as a channel (#49). They need no row and no rule of their own: a field with no meaning for them stays absent, and an absent key promises nothing. Whether 3.0 adds core print or ooh terms stays with #102 and #49, linear TV with #44, and the environment list with #8.

Our channel definitions PR (#119) carries the channel and environment tables, with channel typed MediaChannel. Our shared types PR defines VocabularyTerm and states the unknown-term rule once, in § 2.2.

Details: Channel and environments: full rationale and examples.

Knock-on effects

The audio example lists web_mobile and app_mobile instead of audio_streaming.
A cross-screen video deal becomes a video and a ctv line item. requires.all_of[] from #23 binds them in one commit, as our lifecycle PR defines it. @fgranata reports that their exchange already sells television as its own lane, by the TV device types.
device narrows environments. Our buyer writes PR types device on AdCOM Device Types, as our reply on #58 proposed. A seller or buyer separates consoles and streaming devices from TVs with device, not with another environment value.

Open questions for the working group

Should 3.0 keep the six channel labels and define them with the first-match table? Or should 3.0 replace channel with separate media, distribution, and device fields, and derive the label from them?
Is the first-match order right? audio comes before ctv, so audio in a TV app is audio. native comes before video, so native video is native. Should either pair go the other way?
Answered by @fgranata on this issue. Should a cross-screen video deal split into a video and a ctv line item, tied by line-item dependencies (#23)? Or should channel say what renders and environments say where, as @fgranata suggested on open question 7 on environments (#8)? Then frequency_cap.per and placement.ssai would be set per environment. Two line items: their exchange already works that way, and they withdrew the alternative.
Answered in part in our device-type revision: the filing adds no connected_device value. app_tv in place of ctv went with the alternative that @fgranata withdrew on this issue. Our channel definitions PR (#119) drops audio_streaming. Still open: should open question 7 on environments (#8) settle the rest of the value list, including app_tablet?
Answered in our shared types PR. A consumer skips a line item whose channel it doesn't recognize. Should the text also say that it can't commit a linked_execution or requires from line-item dependencies (#23) that contains the line item? § 2.2 states that a receiver never assents to what it can't read. So it can't send a commit that needs the skipped line item.
Answered by @premesh on #125. Should proof of performance be one field across channels that also covers DOOH proof of play, as @premesh asks on #49? Or should it be part of each channel's own object, like print.proof_of_publication in #102? One type. Our DOOH PR defines ProofOfPerformance { logged_by, evidence[] }. Its evidence[] is a VocabularyTerm list whose core terms are play_log, photo, and audit_report. A channel that 3.0 adds, such as print or static OOH, can reuse the type with its own evidence terms, such as install_record or tearsheet.
A smart speaker that reports Connected Device (6) is in the ctv environment. So an audio line item sold on smart speakers selects ctv, and a buyer screening for ctv also finds that audio. Should smart speakers stay in ctv, narrowed by device as in our reply on typed targeting codes (#58)? Or should they get their own value? For any separate Connected Device (6) value, @fgranata asks that a seller may omit it and a buyer reach TV without selecting it.
What happens when an impression doesn't carry an attribute that a condition names? device.devicetype is optional in OpenRTB 2.6 Object: Device. So a TV video impression without it falls through to video, and an impression without a device type matches no environment except dooh. Should a missing attribute fail the condition? Or should the seller classify the impression from what it knows about the property? This goes with the question on sending device.devicetype in the supporting material's open questions.
Should the seller also serve a line item only on impressions that match an environment in effect: environments.selected[] or, without it, included[]? As written, 5.2.1 limits which environments a line item may offer, not where it serves. So a buyer can check delivery against channel but not against the environments it chose.

Would this break an implementation already built to this draft?

Yes — breaking

Alternatives you considered and rejected

channel for what renders, environments for where (#8): TV would share a line item with web and app. But frequency_cap.per and placement.ssai are set once per line item, and they differ on TV. @fgranata has withdrawn it.
Connected Device (6) in its own connected_device environment: a television line item couldn't serve those impressions, which @fgranata's TV lane includes. device separates them where needed.
Separate media, distribution, and device fields: cleanest. The table derives the label from them, so a later version can add them without relabeling.
channel[]: breaks one channel per line item.

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 as the text our PRs carry, with their field names and open questions 4, 6, and 9 updated. An open MediaChannel vocabulary replaces the print and static OOH paragraph and answers open question 5.

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

Implementation evidence from an in-app + CTV supply-side exchange, on the open questions.

Q3 (one line item per channel vs. channel = what renders, environments = where). We already operate the way the first-match table implies. Television is its own lane in our catalogue: separate line items, separate floors, separate frequency and serving settings, identified by device type 3/6/7 on the request, never by OS (a large share of our CTV impressions report android). A cross-screen video deal is two line items for us today, so the table matches practice; the alternative I floated on #8 would make frequency_cap.basis and serving_mode per environment, which we could not honour on one line. Withdrawn in favour of this definition.

Q4 (connected_device). We fold device type 6 into the television lane and do not yet see meaningful volume on it to treat separately. A separate environment value is fine as long as a seller may omit it; a buyer should not have to select it to reach television.

Q2. No audio inventory here yet; no position on audio before ctv.

One request: keep the device-type codes in the table, as drafted. They are what we filter on at request time, so delivery against the label becomes checkable for us without a mapping step.

@fgranata

Revision, from implementation evidence on this issue. @fgranata reports that their television lane is identified by device type 3, 6, or 7 on the request, and that device type 6 carries no volume worth separating. As drafted, ctv covers device types 3 and 7 only. That would leave their television line items unable to serve Connected Device (6) impressions, because a line item serves only impressions of its channel.

We revise both tables:

§ 5.1.1, `ctv` row: Device type Connected TV (3), Connected Device (6), or
Set Top Box (7).

§ 5.2.1: `ctv` | `Site` or `App` | Connected TV (3), Connected Device (6),
Set Top Box (7). Remove the `connected_device` row.

The device-type codes stay in the table, as @fgranata asks, because delivery is checked against them at request time. A seller or buyer that wants to separate consoles and streaming devices narrows with device targeting, which our reply on typed targeting codes (#58) defines on AdCOM Device Types. A separate environment value isn't needed for that. This also answers part of open question 4: the filing adds no connected_device value.

The same evidence answers open question 3. A cross-screen video deal is two line items, video and ctv, tied by line-item dependencies (#23), and @fgranata withdraws the alternative raised on open question 7 on environments (#8).

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

@matthew-iabtechlab

Revision, from the print channel change request (#102) that @matthew-iabtechlab filed for BCN, and from @clerongi and @premesh on Add OOH as a channel (#49). Print and static OOH both sell inventory with no ad-served impression. Our rationale says that static OOH "gets no value until AdCOM describes it". Read that way, neither channel could ever get a value. We make two changes.

In § 5.1.1, after the Linear TV rule, add:

A channel whose delivery is not an AdCOM ad-served impression, such as
`print` or `ooh`, is not in the first-match table. The rule that a line
item serves only impressions of its `channel`, and the environment rule
in 5.2.1, apply only to channels in the table. Such a channel defines
its own environment values, and its definition lists the fields that
have no meaning for it. Those fields are absent from its line items. A
proof of performance, such as proof of publication or proof of posting,
shows its delivery in place of a served-impression count. Audience and
circulation guarantees stay in `committed_metrics[]`.

In Why, drop the sentence "Static OOH (#49) gets no value until AdCOM describes it."

The per-channel list of absent fields follows #102's own recommendation. We don't add the not_applicable value of #102's design principle 5: as in our placement change request (#89), an absent key doesn't constrain the line item. The first-match table still labels every served impression. Linear TV stays with linear TV scope (#44). Whether 3.0 adds print or ooh stays with the print channel (#102) and OOH as a channel (#49).

Open question for the working group

Should proof of performance be one field across channels that also covers DOOH proof of play, as @premesh asks on #49, or part of each channel's own object, like print.proof_of_publication in #102?

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

@fgranata

Draft PR: § 2.1, § 5.1, § 5.2 — Define channel and environments in AdCOM terms. It applies this change request with the revision for Connected Device (6), from @fgranata's implementation evidence. It removes audio_streaming and leaves the rest of the environment value list, such as app_tablet, to #8. The revision for print and static OOH isn't in it yet.

Writing the change as spec text added one rule that the issue's labels ("Audio ad", "Video ad") imply but the issue didn't state:

Where an impression accepts more than one medium, its media is that of the ad served.

Without it, the first match makes every impression that accepts both video and display a video impression, so a display line item could never serve it. A buyer can check the served media against bid.mtype in OpenRTB 2.6 Object: Bid.

The PR also gives the delivery rule an actor: "The seller MUST serve a line item only on impressions of its channel." The PR description lists the other wording changes, such as putting linear TV outside the table. None of them changes what this issue asks for.

It also raised three questions:

A smart speaker that reports Connected Device (6) is now in the ctv environment, so an audio line item sold on smart speakers selects ctv, and a buyer that screens for the ctv environment also finds that audio. Should smart speakers stay in ctv, narrowed by device targeting as in our reply on typed targeting codes (#58), or get their own value that, as @fgranata asks, a seller may omit and a buyer doesn't have to select to reach TV?
What happens when an impression doesn't carry an attribute that a condition names? device.devicetype is optional in OpenRTB 2.6 Object: Device, so a TV video impression without it falls through to video, and an impression without a device type matches no environment except dooh. Should a missing attribute fail the condition, or should the seller classify the impression from what it knows about the property? This goes with the question on sending device.devicetype in the supporting material's open questions.
Should the seller also serve a line item only on impressions that match a value in its environments.included[]? As written, § 5.2.1 in the PR limits which environments a line item may offer, not where it serves, so a buyer can check delivery against channel but not against the environments it selected.

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

Navigation Menu

Repository navigation

[Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90

What kind of change?

Which section?

Current text

Proposed text

Why

Knock-on effects

Open questions for the working group

Would this break an implementation already built to this draft?

Alternatives you considered and rejected

You are commenting as

Before you submit

Open question for the working group

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90

Description

What kind of change?

Which section?

Current text

Proposed text

Why

Knock-on effects

Open questions for the working group

Would this break an implementation already built to this draft?

Alternatives you considered and rejected

You are commenting as

Before you submit

Activity

fgranata commented on Oct 23, 2026

KonstantinMirin commented on Oct 23, 2026

KonstantinMirin commented on Oct 25, 2026

Open question for the working group

KonstantinMirin commented on Oct 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions