Repository navigation
[Comment] § 5.2, § 5.5 — Support venue-level inventory selection and hierarchical locations #81
Description
Which section?
1 — Preamble and scope
Field(s) involved
No response
Your comment
OpenProposal should explicitly support advertising inventory selection at different levels of a physical location hierarchy.
In public transport environments, buyers may want to select advertising coverage at station, railway station, transport line or network level, rather than identifying individual screens or advertising placements.
For example, an advertiser may request a campaign covering a selected group of Paris Metro stations, allowing the media owner to determine the most appropriate combination of available OOH and DOOH placements.
We recommend introducing a structured hierarchy supporting:
Transport network or operating area.
Transport line or geographical grouping.
Station or railway station.
Specific area within a station, such as platforms, corridors or concourses.
Individual advertising placements or screens.
The specification should also distinguish between buyer-selected locations and seller-allocated placements within those locations.
This would allow buying agents to express meaningful geographical and commercial requirements while preserving the media owner's flexibility to optimize inventory allocation.
Concrete scenario
No response
You are commenting as
Buyer / advertiser
Before you submit
- I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
- This comment contains no confidential or commercially sensitive information.
Activity
KonstantinMirin commentedon Oct 22, 2026
Postindustria (IAB Tech Lab member) supports station-level buying for DOOH. It fits § 5.2, inventory composition once the seller can allocate screens.
propertiesisselectablewithpricingandmax_select, so a buyer picks 30 stations fromavailable[]. Our DOOH properties change request addsvenue_typefrom the OpenOOH Venue Taxonomy 1.1, whose ids split transit by place, andscreens[], with the ids that proof-of-play logs carry. A property's screens share onevenue_type, so a seller offers a line's platforms (10502) and its trains (10501) as two properties.allocation: all | seller_allocatedandmin_screens. Withseller_allocated, the seller picks at leastmin_screensscreens,screens[]is OPTIONAL and lists the pool, the commitment is in plays or impressions, and the proof-of-play log names the screens used.Open questions:
max_selectenough?venue_type, as our DOOH properties change request proposes, so a line's platforms and trains are two properties, or should a property allow a differentvenue_typeper screen?properties, as we propose, or the selectable geo of per-market geo price deltas (draft PR #72)?seller_allocatedfrom our DOOH properties change request, is amin_screensfloor enough, or should the seller also commit to how plays spread across the pool, such as a minimum share per screen?Related: #52, transit environments, #58, typed geo codes, and #83, a duplicate.
Analyzed and generated with the help of Claude, fully reviewed by me.