Repository navigation
[Change] § 5.5 — Type the device and daypart envelopes: AdCOM device types, and dayparts with a time-zone basis #111
Description
What kind of change?
Change a field's type or shape
Which section?
5.5 — Targeting envelope
Current text
| `device` | Object | settable | `allowed[]` of device categories |
| `daypart` | Object | settable | `allowed[]` of time windows |Proposed text
§ 5.5, replace the two rows:
| `device` | Object | settable | `allowed[]` of AdCOM 1.0 device type values (List: Device Types). See 5.5.2 |
| `daypart` | Object | settable | `allowed[]` of daypart windows. See 5.5.3 |
New § 5.5.2 device:
Each entry in `allowed[]` is an AdCOM 1.0 device type integer (e.g. 1 Mobile/Tablet,
2 Personal Computer, 3 Connected TV, 4 Phone, 5 Tablet, 6 Connected Device, 7 Set Top Box).
A consumer MUST NOT infer a device type that is not listed.
New § 5.5.3 daypart:
Each entry in `allowed[]` is `{ days, start, end, tz_basis, tz }`:
| Key | Required | Meaning |
| :--- | :--- | :--- |
| `days` | REQUIRED | ISO 8601 weekday numbers, 1 (Monday) to 7 (Sunday) |
| `start`, `end` | REQUIRED | `HH:MM`, 24-hour. `end` is exclusive. `end` earlier than `start` means the window crosses midnight into the next day |
| `tz_basis` | REQUIRED | `viewer` (the user's local time) or `fixed` (one named zone) |
| `tz` | REQUIRED when `tz_basis` is `fixed` | IANA time-zone name, e.g. `America/New_York` |Why
Both envelopes are settable, so a buyer's agent has to pick values inside them and then pass those values to an ad server or DSP. As written:
- Device: "device categories" has no vocabulary, so the same CTV inventory can be offered as
ctv,CTV,connected_tvor3. - Daypart: "time windows" says nothing about the time zone. "Prime time 20:00–23:00" means different hours depending on whether it is the viewer's local time or the seller's zone, and DSPs differ in which one they apply. That moves delivery by hours on any national buy.
AdCOM device types are already the vocabulary #90 uses to define channel (Connected TV 3, Set Top Box 7), so reusing them keeps one source of truth.
Knock-on effects
- The examples in § 6 that use
deviceordaypartneed typed values. - It pairs with [Change] § 5.5 — Typed geo codes aligned with the OpenRTB 2.6 Geo object #58 (typed geo), so all four settable envelopes become typed.
Would this break an implementation already built to this draft?
Yes — breaking, for anything that used free-text values. The draft is unratified and has no schema yet, so now is the cheapest time to type them.
Alternatives considered
- Keep free text and add a
vocabularykey per envelope. This is more flexible, but every buyer agent then has to map N vocabularies.
Filed after the 2026-10-22 close of the comment period, so we understand this is post-comment and for the next draft. Submitted by Hypermindz (buy-side agentic media planning platform).
Activity
KonstantinMirin commentedon Oct 25, 2026
Thank you, @dineshbhat. Our reply on typed targeting values (#58) covers the same two envelopes, and we agree on most of it: AdCOM 1.0 List: Device Types, civil-time windows, and an exclusive
end. The main difference is how a daypart crosses midnight.Midnight. Our proposed text makes
endlater thanstartand lets it be24:00. A Monday window from 22:00 to 02:00 is then two windows: Monday 22:00–24:00 and Tuesday 00:00–02:00. Three Google platforms already work this way:DayPartmakesendTimeexclusive, takes hours 0 to 24, and rejects an end before the start withEND_TIME_NOT_AFTER_START_TIME.AdScheduleInfo: "24 signifies end of the day". It rejects a window that crosses midnight withAD_SCHEDULE_INTERVAL_CANNOT_SPAN_MULTIPLE_DAYS.No IAB Tech Lab standard defines a start-and-end daypart window or a rule for crossing midnight. OpenDirect 2.1 OOH targeting lists the hours of the flight by index instead. With
endearlier thanstart, a validator can't catch swapped times, and anendequal tostartreads as either an empty day or a full one.Two smaller differences. We set the clock once per line item, not per window, because
frequency_cap.periodneeds the same clock as the daypart. And you propose that "a consumer MUST NOT infer a device type that is not listed", while open question 3 of our reply on #58 asks whether Mobile/Tablet - General (1) covers Phone (4) and Tablet (5). Either works, but the text has to pick one.Would two windows work for your planning use?
Open question:
channelin 3.0, and @bhillman-TelevisaUnivision's linear TV scope question (#44) is still open. If linear comes into scope, which rule should § 5.5 Targeting envelope use: a broadcast-day option, the midnight rule in this change request (#111) withdaysnaming the day the window starts, or two civil-time windows?Analyzed and generated with the help of Claude, fully reviewed by me.
KonstantinMirin commentedon Oct 26, 2026
Draft PR #123: § 5.5 — Daypart clock: a line-item time zone and the window shape. It covers the clock and window parts of @dineshbhat's change request, with the § 5.5 text from our reply on typed geo codes (#58). A line-item
time_zone, an IANA name orviewer_local, is the clock fordaypartandfrequency_cap.period. A window is{ days[], start, end }, with an exclusiveendlater thanstart, up to24:00. It differs from #111 in two ways, which our earlier reply explains: one clock per line item, and a window that crosses midnight is two windows. The device half, AdCOM device types, stays with this issue.Analyzed and generated with the help of Claude, fully reviewed by me.