Repository navigation
[Change] § 5.6, § 5.7 — DOOH: define a play, and whose multiplier turns plays into impressions #92
Description
What kind of change?
Add a new field
Which section?
Whole document / more than one section
Current text
§ 5.6: | `pricing[].cost_method` | Enum | seller-set | CPM, CPC, flat, etc. |
§ 5.6: | `availability` | Object | derived | `{ unit, basis, as_of, granularity, type: forecast \| reservable, quantity }`. Recomputed against the buyer's selection |
§ 5.7: | `committed_metrics[]` | Array[Object] | requestable | `{ metric, value, basis }` tuples — `viewable_rate` for display, `completion_rate` for video/audio/CTV, an audience-modelled metric for DOOH. Seller declares a ceiling; a buyer MAY request above it |Proposed text
Our DOOH PR carries this text and closes this issue and #96. Our settlement PR adds the § 5.7.1 impressions metric and the rate-or-count rule.
§ 5.6, after the `availability` row:
| `delivery_counting` | DeliveryCounting | REQUIRED when `channel` is `dooh` | seller-set | How the line item counts plays and, when it counts impressions, turns them into impressions. See § 5.6.4 |
#### 5.6.4 Plays and impressions
On a `dooh` line item, a **play** is one display of an ad on one screen, inside
the screen's operating hours, that ends no more than `play_tolerance_ms` short of
the ad's full duration and that the proof-of-play log records. On a sync group
(§ 5.2.8), a display that meets those conditions on at least
`min_screens_per_play` of its screens is one play, not one per screen. An
**impression** is a play times the multiplier for that screen or sync group at
that time. Every impression count on the line item (`pricing[]`, `commitment`,
`availability`, `committed_metrics[]`) counts these. A line item counts
impressions when any of those counts is in impressions.
**`DeliveryCounting`** keys:
| Key | Type | Required | Meaning |
| :--- | :--- | :--- | :--- |
| `play_tolerance_ms` | Integer | REQUIRED | How far short of its full duration a play may end and still count |
| `proof_of_performance` | ProofOfPerformance | REQUIRED | Who logs the plays and what the buyer receives |
| `partial_play_credit` | VocabularyTerm | REQUIRED when a property has `sync_groups[]` | What a display on fewer than `min_screens_per_play` screens counts. Core terms: `none` (no play) \| `pro_rata` (screens played ÷ `min_screens_per_play`) |
| `impression_multiplier` | ImpressionMultiplier | REQUIRED when the line item counts impressions | What turns a play into impressions |
**`ProofOfPerformance`** keys:
| Key | Type | Required | Meaning |
| :--- | :--- | :--- | :--- |
| `logged_by` | Measurer | REQUIRED | Who keeps the proof-of-play log |
| `evidence[]` | Array[VocabularyTerm] | REQUIRED | What the buyer receives. Core terms: `play_log` \| `photo` \| `audit_report` |
**`ImpressionMultiplier`** keys:
| Key | Type | Required | Meaning |
| :--- | :--- | :--- | :--- |
| `impression_type` | Enum | REQUIRED | `gross` \| `viewable` \| `lts` \| `audience`: Gross, Viewable (OTS), Likelihood-to-See, or Audience impressions, as the MRC Out-of-Home Measurement Standards (Phase 1 & 2 Combined, December 2025) define them |
| `source_type` | Integer | REQUIRED | Who supplies the multiplier. A value from AdCOM 1.0 List: DOOH Multiplier Measurement Source Types other than Unknown (`0`). The value OpenRTB 2.6 `imp.qty.sourcetype` carries |
| `vendor` | RegistrableDomain | REQUIRED when `source_type` is not Publisher Provided (`2`) | The domain of the vendor or exchange that supplies the multipliers, as OpenRTB 2.6 `imp.qty.vendor` names a vendor |
| `dataset` | String | REQUIRED | The source's named data release. A new release is a new `dataset` |
| `settles_on` | Enum | REQUIRED | `declared` \| `restated`. `declared`: the value `dataset` gives that screen, or sync group, and hour when the play runs. `restated`: that value after any reissue of `dataset` by its source before the count is final (§ 5.7.1) |
The multiplier's source controls the count of impressions: `seller` when
`source_type` is Publisher Provided (`2`) or `vendor` is the proposal's
`seller.domain`, and `vendor` otherwise. Every impression count that settles or
invoices the line item MUST use its multipliers, and a committed `impressions`
level (§ 5.7.1) settles on that source's count.
Impressions MUST be summed unrounded over each invoice period and rounded once.Why
A DOOH CPM doesn't say what it counts. Sellers multiply plays by an audience figure the line item doesn't name. #82, CPM based on opportunities to see, asks for this denominator.
Loop and operating hours set each screen's plays (#79, #96). Take 200 screens, one 10-second slot in a 60-second loop, 18 hours a day for 14 days: 3,024,000 plays. At CPM 8.00:
| Read as | Units | Invoice (USD) |
|---|---|---|
| Per 1,000 plays | 3,024,000 | 24,192.00 |
| Impressions, publisher multiplier 4.2 | 12,700,800 | 101,606.40 |
| Impressions, vendor multiplier 2.9 | 8,769,600 | 70,156.80 |
One record supports all three. It must name the multiplier's source, and that source counts what's invoiced.
OpenRTB 2.6 imp.qty carries a multiplier per bid request. The MRC Out-of-Home Measurement Standards define four impression levels and expect reissues.
A CPM's unit is a commercial term, so the proposed 4.0 deferral of measurement (#20) doesn't remove it from 3.0.
@premesh proposes sync groups, partial_play_credit, and one proof_of_performance object. The rate-or-count rule comes from @jaanijuk on #4.
Details and examples: Plays and impressions in DOOH: full rationale and examples
Knock-on effects
- Our DOOH properties filing (#96) adds
sync_groups[]andslots_per_loop. - Our cost-method filing (#94) adds
PLAY, per 1,000 plays. - Our settlement filing (#95): on a
doohline item that counts impressions,controlling_measurementcounted_byMUST be the multiplier's source. - #38, #51, and #54 ask what audience figures count, and none defines a DOOH impression.
- Our channel definitions filing (#90) maps
doohto AdCOM 1.0Dooh. - § 6 gains a DOOH example. The field is inside
record_digest(#63), and restated values arrive afteragreedunder a fixed rule (#68). - Two rules stay out of the text, in our rules issue: which way the one rounding goes, and what a
FLATday counts ondooh.
Open questions for the working group
- Should
delivery_counting.impression_multiplierstay seller-set in 3.0, or become selectable under § 3.1 Selectable structure? A buyer could then pick the publisher's or a vendor's multiplier, with a price andpricing[].unit_boundsper option. - Answered in our DOOH PR. Should
settles_on: restatedcarry its own deadline for reissues, or is thefinal_afterdeadline in our settlement filing enough? A reissue counts only before the count is final, sofinal_after, when set, is the deadline. - On a line item that counts only plays, should
proof_of_performance.logged_bybe the controlling counter of plays? Or may the buyer name a differentcounted_byin thecontrolling_measurementof our settlement filing? - How should a buy at the Opportunity to See level of the MRC Out-of-Home Measurement Standards be priced? As
CPMwithimpression_type: viewable, or asCPMVfrom our cost-method filing? And shouldviewableget a name that doesn't suggest digital viewability? - Should
proof_of_performance.evidence[]stay in 3.0 as a commercial term, or move to 4.0 with measurement if the proposed 4.0 deferral of measurement (#20) is accepted? - Answered by @premesh. Under
partial_play_credit: pro_rata, what share of a play does a sync group display on too few screens earn:screens_played÷min_screens_per_play, or ÷ the group's screens? @premesh's suggestion left it open. It's ÷min_screens_per_play.
Would this break an implementation already built to this draft?
Yes — breaking
Alternatives you considered and rejected
- Leave it to the bid stream.
imp.qtynames each request's source, not the agreed one, and a direct IO has none. selectable, so a buyer picks its measurement provider.pricing[].unit_boundssits on the pricing entry, so a provider option can't carry its own.- Inside
measurement_source. Nothing tiespricing[],commitment, oravailabilityto it, and it can't hold the play definition.
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 to match our DOOH PR, which nests impression_multiplier under delivery_counting and renames sourcetype to source_type. Answers open question 2 and moves two rules to the rules issue.
Analyzed and generated with the help of Claude, fully reviewed by me.
Activity
premesh commentedon Oct 26, 2026
Commenting as: seller. OUTFRONT Media, US out-of-home media owner (roadside static and digital, transit).
A gap in the play definition: synchronized screens. We sell venues where several screens show the same ad at the same moment, and the buyer buys the venue, programmatic and direct. One play is one play against the venue, delivered on at least a contracted number of its screens. Under "one display of an ad on one screen", a ten-screen venue play counts as ten plays, and per-screen multipliers summed across those screens count the same audience ten times.
This isn't specific to us. Synchronized screens sold as one play are common across out-of-home. Airports are the clearest case, where every screen in a baggage claim or gate area runs the same creative at the same moment, and the same goes for transit stations and platforms, malls and stadiums. So this belongs in the core DOOH property model, not in a seller-specific extension.
Proposal:
doohproperty ([Change] § 5.2, § 5.5 — DOOH properties: venue type, screens, operating hours, and loop #96), addsync_group: a set of screens that play together, withmin_screens_per_play, the fewest screens that must show a play for it to count. (Distinct from [Change] § 5.2, § 5.5 — DOOH properties: venue type, screens, operating hours, and loop #96's line-itemmin_screens.)frequency_capwithbasis: screen([Change] § 5.2, § 5.5 — DOOH properties: venue type, screens, operating hours, and loop #96) counts a sync group as one screen.Open question: should a sync group play that confirms on fewer than
min_screens_per_playcount as no play, or as a partial play?premesh commentedon Oct 27, 2026
Answering my own open question above. A play that reaches fewer screens than min_screens_per_play shouldn't silently count as a full play, and it shouldn't disappear either.
Suggest:
screens_playedalongsidemin_screens_per_play, so a shortfall is visible.partial_play_credit: none | pro_rata. Synced takeovers are usually sold as all-or-nothing. Some sellers will want pro-rata.@KonstantinMirin would it make sense to fold sync_group into #92's play definition and #96's screens model, rather than keep it as a separate object?
KonstantinMirin commentedon Oct 27, 2026
Yes, thank you, @premesh. We fold
sync_groupinto this filing's play definition and #96's screens model, credited to you. We revise both in place, and thePLAYrow of #94 to match.In our DOOH properties filing (#96), a property gains
sync_groups, each with its screens and amin_screens_per_play. In this filing's play definition, a display on at least that many screens is one play, with one multiplier for the venue.frequency_capwithbasis: screencounts the group as one screen.partial_play_creditis a seller-set term, withnoneandpro_rataas core terms of an open vocabulary.Our supporting material logs one record per play with
screens_played, from your second comment, and keepsmin_screens_per_playon the sync group. One point stays open, as open question 6. Underpro_rata, is a display on too few screens worthscreens_played÷min_screens_per_play, or ÷ the group's screens?Analyzed and generated with the help of Claude, fully reviewed by me.
premesh commentedon Oct 28, 2026
@KonstantinMirin thanks for folding it in. On OQ6: divide by
min_screens_per_play. Any play at or above the minimum is a full play, sopro_rataonly applies below it. Dividing by the group's screens would make credit jump at the threshold: a play one screen short of the minimum would be worth well under the full play it nearly was.screens_played÷min_screens_per_playrises to 1 at the minimum, and the buyer is paying for the minimum, not the whole group.