Repository navigation
[Comment] § 5.2 Static OOH: posting cycles, printed material, install lead time and proof of posting #125
Description
Which section?
5.2 — Inventory composition
Field(s) involved
delivery_type, commitment, flight dates, creative, proof_of_play
Your comment
Following Matthew's suggestion, splitting static OOH out of the DOOH and share-of-voice threads (#79, #92, #93, #96). Static roadside, transit and wallscape units don't fit the play-based model, and the gaps get lost in those threads. Earlier context in #5, #49 and #102. #78 already covers printing, installation and removal; this issue is about the unit, the schedule and how delivery is proved.
How static is sold, from the seller side:
- The unit is sold by the posting cycle, usually 4 weeks, not by impressions or plays. Flight dates and posting dates aren't the same thing. A unit can post a few days off the contracted start, and contracts allow for that.
- Creative is printed material (vinyl, paper), not a file. The buyer or their printer ships it to the seller's production or install team, so material deadlines and install lead times drive the schedule (see [Comment] § 5.4 — Support printing, installation and removal requirements for physical OOH #78).
- Delivery is proved with proof of posting (photos, install records), not a play log. There is no loop, no slot and no share of voice.
- Audience is estimated per unit per period from the measurement provider. It is a planning number, not something the seller delivers against.
What the draft has no place for today:
- A unit period (posting cycle) as the thing bought and billed
- Posting schedule vs flight dates, with an allowed variance
- Material specs, a material due date and install lead time
- Proof of performance as photos and install records rather than plays
- A commitment type that is "unit for the period" rather than impressions
Proposed: an ooh extension object on the product or line, roughly as sketched in #102: unit, unit_periods, posting_schedule, material, install_lead_time, proof_of_performance.
Open questions:
- Should this be an extension object or a delivery_type alongside the ones in [Change] § 5.9, § 5.6, § 2.1 — Add delivery_type: guaranteed, share_of_voice, non_guaranteed #93?
- Where should proof of posting live: in [Change] § 5.6, § 5.7 — DOOH: define a play, and whose multiplier turns plays into impressions #92's proof_of_play evidence types, or as its own object?
- How do mixed buys (static and digital units in one domination or package) reference each other? See [Change] § 5.9, § 5.6, § 2.1 — Add delivery_type: guaranteed, share_of_voice, non_guaranteed #93 OQ7 and [Change] § 5.6 — Give cancellation_policy and exclusivity options a typed shape #98.
Concrete scenario
A buyer books a 4-week static posting on a roadside unit. The draft can express flight dates and an impression goal, but not that the buy is one unit for one posting cycle, that posting may land a few days off the flight start, that printed material is due before install, or that delivery is confirmed by proof of posting photos rather than plays. A buying agent reading the proposal has no way to check feasibility or reconcile delivery.
You are commenting as
Publisher / seller
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 27, 2026
Thanks, @premesh, for giving static OOH its own thread.
Your open question 2 is also open on our side. Open question 6 on #90 asks whether proof of performance is one field across channels or part of each channel's own object. It includes DOOH proof of play, comes from your comment on #49, and question 15 in PR #119 carries it.
Analyzed and generated with the help of Claude, fully reviewed by me.
premesh commentedon Oct 28, 2026
Thanks @KonstantinMirin. On #90 OQ6, I'd make it one
proof_of_performanceobject across channels, with a typed evidence list, and let each channel say which evidence types apply:play_logfor DOOH,posting_photoandinstall_recordfor static OOH,tearsheetfor print. Buyers and verification vendors then read one shape, and the channel-specific part is just which evidence types count.nitinms2 commentedon Nov 9, 2026
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.
+1 to @premesh's list from our traditional and large-format inventory. One gap to add, and one refinement:
Seller-assigned units. Buyers buy "40 2-sheets across downtown rail stations" or "5 buses from one garage," and we assign the specific faces or vehicles at posting. #96's allocation: seller_allocated covers this for DOOH screens. Could the same rule cover static packages and vehicle garages, with the assigned units reported after posting?
Materials due relative to the flight. A bus wrap needs about 30 days of production, a 2-sheet about 14. Stating the deadline as an offset from the flight start (e.g. -P30D) keeps it right when the flight moves.
premesh commentedon Nov 10, 2026
Thanks @nitinms2, agree on both. Seller-assigned units are the norm for static packages and transit too, so #96's
seller_allocatedshould apply to the ooh channel, with the assigned units reported as part of proof of posting. And a material deadline as an offset from flight start (or from the posting date) is better than a fixed date, since flights move.