[Comment] § 5.2 Static OOH: posting cycles, printed material, install lead time and proof of posting #125

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:

1. 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?
2. 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?
3. 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.