[Change] § 5.5 — Typed geo codes aligned with the OpenRTB 2.6 Geo object #58

Activity

1. dtbarne

   added

   change-requestProposes specific normative wordingProposes specific normative wording

   normativeChanges what the spec requiresChanges what the spec requires

   on Oct 22, 2026
2. KonstantinMirin commented on Oct 22, 2026

   

   KonstantinMirin

   on Oct 22, 2026

   Last edited by KonstantinMirin

   More actions

   Postindustria (IAB Tech Lab member) supports this. The other § 5.5 targeting values need the same treatment: a buyer and seller can agree one line item and read it differently.

   • Daypart: define a window as { days[], start, end } in civil time, with end exclusive. Add time_zone, the clock for windows and cap periods: an IANA time zone name or viewer_local, REQUIRED with daypart or period. The UTC rule that #37 proposes suits instants, not civil-time windows: 06:00 in New York is 10:00 UTC in summer, 11:00 in winter. At a daylight-saving change, a skipped hour matches no instant and a repeated hour matches both.
   • Device: values from AdCOM 1.0 List: Device Types, the list OpenRTB 2.6 Device.devicetype sends. AdCOM lists the values flat; we propose that Mobile/Tablet - General (1) covers Phone (4) and Tablet (5).
   • Frequency: period takes hour, day, week, month, or flight, the OpenDirect 2.1 frequencyinterval values (flight for LineDuration), as calendar periods in time_zone, with weeks starting on Monday. basis gains person, as in #38 and #39. The buyer sets the cap count; period and basis stay with the seller.
   • Narrowing: for geo, device, and daypart, the buyer's value (the value key from #22) is { include[], exclude[] } and only narrows allowed[]. Exclusion wins. A country covers the regions and cities whose codes name it, and the postal codes that carry it as country. A metro code names no country, so only the same metro covers it. Nothing else is assumed.
   • Default: § 3 requires an explicit default but names no key. We propose default, beside value, in the same shape.

   geo:
     allowed: [{ type: country, code: USA }]
     default: { include: [{ type: country, code: USA }] }
     value:   { include: [{ type: country, code: USA }], exclude: [{ type: region, code: US-TX }] }
   daypart:
     allowed: [{ days: [monday, tuesday, wednesday, thursday, friday], start: "06:00", end: "10:00" }]
     default: { include: [{ days: [monday, tuesday, wednesday, thursday, friday], start: "06:00", end: "10:00" }] }
   time_zone: America/New_York
   frequency_cap: { max: { min: 1, max: 4 }, default: 3, period: day, basis: person }

   This is a breaking change. device and daypart values change shape, buyer values become { include[], exclude[] }, and time_zone is a new field, REQUIRED with daypart or period. We think now is the right time: a break costs least before 3.0 is final, and today the draft gives these values no shape that two implementations could already share.

   Open questions:

   1. Should time_zone take only an IANA name or viewer_local, or also an inventory_local token for sellers whose units span zones, or be settable so the buyer picks the clock?
   2. Should period count calendar periods, as OpenDirect 2.1 Line.frequencyinterval does, or rolling windows written as ISO 8601 durations (P1D, P7D), the duration style that the issue on example timestamp formats (#37) proposes?
   3. Should Mobile/Tablet - General (1) cover Phone (4) and Tablet (5), or should AdCOM 1.0 List: Device Types stay flat, so a buyer lists every value it accepts?
   4. Should a metro be covered only by the same metro code, as proposed, so that a seller lists the metros it sells, or should the spec name a metro-to-country table so that USA covers every US metro?
   5. Should the declared default that § 3 Field mutability requires live in a default key beside value, as proposed, or should the change request on the buyer's selection keys (#22) name that key when it defines value?

   Our channel definitions filing gives each environments value its device types, so device narrows environments. Proposed text: Targeting values: proposed text and rationale.

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

   added

   section:5.5-targeting

   on Oct 23, 2026
4. nitinms2 commented on Nov 9, 2026

   

   nitinms2

   on Nov 9, 2026

   More actions

   Commenting as: seller. Intersection, out-of-home media owner offering digital, place-based, traditional and large-format OOH across street furniture, place-based venues and moving media.

   Typed codes help, but out-of-home buys are often a radius around a point of interest ("within 800 m of a stadium") rather than a region. Could allowed[] admit { type: radius, lat, lon, meters } alongside the code types? OpenRTB 2.6 has no radius type, so this one wouldn't pass straight through to a bid request. That's acceptable for direct and guaranteed OOH, where the seller resolves the radius to the units inside it.
5. KonstantinMirin commented on Nov 10, 2026

   

   KonstantinMirin

   on Nov 10, 2026

   More actions

   Thanks, @nitinms2. #141 carries #58. There, a GeoCode is an ISO 3166 code or an extension term for any other area (§ 5.5). A seller can list a radius it sells, such as example.com:stadium-800m, in allowed[], and resolve it to the units inside.

   An extension term covers only itself, so it can't carry a point and radius that the buyer picks. That needs a structured type, which #141 doesn't add, so we'd leave it to the working group.

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