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

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: replace the enum with "One value from Channel values".

#### 5.1.1 Channel values

An impression's channel is the first row it matches, in AdCOM 1.0 terms.
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 |
| `ctv` | Device type Connected TV (3), Connected Device (6), or Set Top Box (7) |
| `native` | Native ad (`nativefmt`), video assets included |
| `video` | Video ad |
| `display` | Any other display ad |

The seller MUST serve a line item only on impressions of its `channel`.
Placement type does not change it. A consumer MUST skip a line item whose
`channel` it does not recognize, and MUST NOT reject the proposal because
of it. Impressions in linear TV, including addressable linear, are outside
this table: they have no `channel` value in 3.0.

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` (#92), with the evidence terms its definition lists,
shows its delivery in place of a served-impression count. Audience and
circulation guarantees stay in `committed_metrics[]`.

§ 5.2, `environments` row: `available[]` of values from Environment values.

#### 5.2.1 Environment values

Each value is the set of (distribution channel, device type) pairs formed
from its row. An impression matches the value when both its distribution
channel and its device type are in the row.

| Value | Distribution channel | Device types |
| :--- | :--- | :--- |
| `web_desktop` | `Site` | Personal Computer (2) |
| `web_mobile` | `Site` | Mobile/Tablet - General (1), Phone (4), Tablet (5) |
| `app_mobile` | `App` | Mobile/Tablet - General (1), Phone (4), Tablet (5) |
| `ctv` | `Site` or `App` | Connected TV (3), Connected Device (6), Set Top Box (7) |
| `dooh` | `Dooh` | any |

Device types are AdCOM 1.0 List: Device Types, named with their codes.

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

§ 2.1, Summary Representation: 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. We ask to 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? Nothing says whether CTV video is channel: ctv, as in the CTV example, or channel: video, environments: [ctv]. The § 2.1 summary carries channel but not environments. Display & Video 360 sells Connected TV as its own line item type, with position, video, and device targeting preselected.
• dooh is a distribution channel. OpenRTB 2.6 Object: DOOH is sent instead of site or app, with any media.
• native is a display format. AdCOM puts it inside DisplayPlacement; its video asset reuses VideoPlacement. Native video fits two values.
• audio_streaming names a medium, not a surface. @fgranata (#8) notes that ctv and audio_streaming both repeat the channel. We keep ctv in both fields. As a channel, it marks lines whose household caps and SSAI serving 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 makes each impression's label unique. It proposes a definition rule for environments (#8) and leaves the value list open to the inventory evidence there. Linear TV gets no value, and its scope is left to #44. Print, in the print channel change request (#102) that @matthew-iabtechlab filed for BCN, and static OOH, in OOH as a channel (#49) from @clerongi and @premesh, sell inventory with no ad-served impression. Such a channel sits outside the table and shows delivery by proof of performance. 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. Whether 3.0 adds print or ooh stays with #102 and #49.

Definitions: AdCOM 1.0 objects Site, App, Dooh, and AudioPlacement.

Details: Channel and environments: full rationale and examples.

Knock-on effects

• The § 6.4 audio example lists surfaces instead of audio_streaming.
• Under this definition, a cross-screen video deal becomes a video and a ctv line item, tied by #23 and our commitment-set reply on #23. This fits #20 item 6: packages are linked line items. @fgranata reports that their exchange already sells television as its own lane, identified by Connected TV (3), Connected Device (6), or Set Top Box (7).
• Our targeting-values reply on #58: device narrows environments, now checkable locally. A seller or buyer that wants to separate consoles and streaming devices from TVs narrows ctv with device targeting, not a separate environment value.

Open questions for the working group

1. Should 3.0 keep the six channel labels and define them with the first-match table, or replace channel now with separate media, distribution, and device fields and derive the label from them?
2. Is the first-match order right, in particular audio before ctv (audio in a TV app is audio) and native before video (native video is native), or should either pair go the other way?
3. 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 suggests on open question 7 on environments (#8), with frequency_cap.basis and serving_mode set per environment?
4. Answered in part in our device-type revision: the filing adds no connected_device value, and app_tv in place of ctv went with the alternative that @fgranata withdrew on this issue. Still open: should this filing drop audio_streaming, or should open question 7 on environments (#8) settle the value list, including app_tablet, while this filing sets only the rule?
5. When 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), or a commitment set from our commitment-set reply, that contains the line item?
6. 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 part of each channel's own object, like print.proof_of_publication in #102? One proof_of_performance object, { logged_by, evidence[] } as [Change] § 5.6, § 5.7 — DOOH: define a play, and whose multiplier turns plays into impressions #92 drafts it, serves every channel. Each channel's definition lists its evidence terms: play_log for DOOH, posting_photo and install_record for static OOH, and [Change] § 1.1, § 5.1, § 5.9, new § 5.11 — Add a print channel: enum, print extension object, downstream row #102's proof-of-publication types for print.
7. 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 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?
8. 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.
9. Should the seller also serve a line item only on impressions that match a value in its environments.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 selected.

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 then share a line item with web and app, but frequency_cap.basis and serving_mode are set once per line item and differ on TV. @fgranata has since withdrawn it.
• Connected Device (6) outside ctv, in its own connected_device environment: a television line item could then not serve Connected Device (6) impressions, which @fgranata's TV lane includes, and a buyer would have to select a second value to reach television. Device targeting 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-10-28: Proof of performance is one object across channels, as @premesh proposes on #125. From @fgranata's implementation evidence, ctv covers Connected Device (6), the connected_device environment is gone, and cross-screen deals are settled as two line items (our device-type revision). Channels without an ad-served impression, such as print or ooh, sit outside the table, the fields with no meaning for such a channel are absent, and open question 6 asks about proof of performance (our print and OOH revision). The draft PR adds the served-ad media rule, states the delivery, skip, linear TV, and consistency rules more precisely, defines environments as (distribution channel, device type) pairs, and raises open questions 7 to 9.

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