标签：#vast

A trafficking template copies last quarter's instream tag, changes one field to pause inventory, and ships. The VAST response validates. The buyer's filter reads plcmt=5 and playbackmethod=1 in the same <Extension> block and treats the impression as a generic instream spot with sound on, not a pause placement with its own playback semantics. Nothing throws a player error because both values are integers inside AdCOM's allowed ranges. The failure is semantic: two signals that were supposed to describe one CTV Ad Portfolio format now describe two different ones. plcmt and playbackmethod answer different questions IAB's CTV Ad Portfolio (finalized July 2026) adds five transactable video formats beyond classic instream: Pause, Screensaver, Overlay, Squeezeback, and In-Scene. OpenRTB carries the buy on video.plcmt values 5 through 9. Downstream of the auction, DSPs echo those signals back into VAST as AdCOM extensions so SSAI paths and measurement vendors that never saw the bid request can still read what was sold. On VAST 4.x the pattern is one signal per extension: <Extensions> <Extension type= "plcmt" ext= "adcom" ><plcmt> 5 </plcmt></Extension> <Extension type= "playbackmethod" ext= "adcom" ><playbackmethod> 9 </playbackmethod></Extension> </Extensions> On VAST 2.0 the same five formats can ship inside a single back-port container ( type="ctv_ad_portfolio" ) with plcmt , playbackmethod , MediaFiles , and Duration in one block. The signaling table is the same; only the XML shape differs. plcmt names the format row: 5 is Pause, 6 is Screensaver, 7 is Overlay, 8 is Squeezeback, 9 is In-Scene. playbackmethod is older AdCOM vocabulary. For legacy instream it still means things like autoplay with sound on (1) or click-to-play (2). The portfolio guidance assigns new playbackmethod values to Pause and Screensaver because those rows needed sound-on and sound-off variants that did not exist in the pre-portfolio table: plcmt Format playbackmethod (firm mapping) 5 Pause 8 (sound

A VAST wrapper with no AdSystem, no VASTAdTagURI and no Impression validates against the VAST 4.4 draft schema. The same document has been invalid in every version from 2.0 through 4.2. It is one line of XSD, and it is almost certainly a side effect of the CTV Ad Portfolio restructure rather than a decision anyone made on purpose. I have filed it with IAB Tech Lab. This post is the working, because the reproduction is short enough that anyone can check it in about a minute. The change In vast_4.4.xsd on master, both vastInLine_type and vastWrapper_type wrap their children in a single compositor: an xs:choice with minOccurs zero and maxOccurs unbounded. That looks harmless. It is the idiom people reach for when they want to say "these children may appear in any order". What it actually says is stronger than that. In XSD, the cardinality on the compositor governs the content model, and the minOccurs on the individual child elements only describes a single selection from the choice. Set the choice itself to zero-or-more and every constraint underneath it stops binding. So the children still declare minOccurs="1". They are still, in effect, optional. The compositor in question <!-- vast_4.4.xsd, vastWrapper_type and vastInLine_type --> <xs:choice minOccurs= "0" maxOccurs= "unbounded" > <xs:element name= "AdSystem" type= "vastAdSystem_type" /> <xs:element name= "VASTAdTagURI" type= "vastURIElement_type" /> <xs:element name= "Impression" type= "vastImpression_type" /> <xs:element name= "Creatives" type= "vastCreatives_type" /> <!-- ... --> </xs:choice> Three consequences, not one The empty wrapper is the headline, but the compositor gives up three separate guarantees at once. Each is reproducible with xmllint against the published schema. What now validates in 4.4 Everything is optional. An empty <Wrapper/> validates. So does an empty <InLine/> , with no AdSystem, no AdTitle, no Impression and no Creatives. Everything repeats. maxOccurs="unbounded" on the choice means any