DEV Community

Aleksander Sekowski
Aleksander Sekowski

Posted on

VAST Extension type="pos" With a plcmt Child Still Validates. Stitchers Read type.

A pause campaign ships. OpenRTB carried video.plcmt=5. The VAST InLine looks fine in a schema validator. Format reporting still shows squeezeback geometry, or nothing at all, because one extension copied the wrong attribute onto the wrapper.

<Extension type="pos" ext="adcom">
  <plcmt>5</plcmt>
</Extension>
Enter fullscreen mode Exit fullscreen mode

The integer 5 is correct for Pause. The child tag name is correct for a placement subtype. The type attribute says this block is a pos signal. Anything that trusts type before it reads children will treat the payload as screen position, not as plcmt, or it will drop the block when the inner tag does not match the declared signal.

IAB Tech Lab finalized CTV Ad Portfolio signaling in July 2026. The VAST side round-trips four AdCOM enumerations inside <Extension ext="adcom">: plcmt, pos, playbackmethod, and attr. Each signal gets its own extension node. The type attribute names which signal the extension carries. The child element repeats that name and holds the integer value.

The canonical shape looks like this:

<Extension type="plcmt" ext="adcom"><plcmt>5</plcmt></Extension>
<Extension type="pos" ext="adcom"><pos>7</pos></Extension>
<Extension type="playbackmethod" ext="adcom"><playbackmethod>9</playbackmethod></Extension>
Enter fullscreen mode Exit fullscreen mode

That pattern exists because the VAST response outlives the bid request. SSAI stitchers and measurement vendors downstream of the auction often never see OpenRTB. They learn what was sold from the creative envelope. Copy-paste from an older template, a merge conflict in a trafficking UI, or a single swapped attribute on export is enough to produce a tag where every integer is in range and the labels disagree.

Why type and tag name are not redundant

Schema validation cares about nesting and text content. It does not require type="plcmt" when the only child is <plcmt>. Many pipelines therefore green-light the mistake.

Production consumers are not symmetric. Portfolio guidance treats type as the selector. Rule VAST-4.4-adcom-extension-type-mismatch flags exactly this case: the declared AdCOM signal in type does not match the payload element name. The rule text notes that downstream stitchers key off type to decide what to read.

That is a different failure mode from inconsistent values across signals. You can ship plcmt=5 with playbackmethod=1 and every extension wrapper can be structurally perfect while the integers still describe incompatible formats. Value-level mismatch is its own QA problem. The bug here is mislabeling at the wrapper: the pause integer rode inside a node advertised as geometry.

A related defect is type="loudness" or any string outside the four signal names, which triggers VAST-4.4-adcom-extension-unknown-signal. The type-or-child swap is quieter because both strings are real AdCOM field names.

How I catch it before traffic

I start with the VAST tag tester. Paste the live ad tag URL or the resolved InLine XML. It fetches wrappers when needed, previews the NonLinear or video asset, and runs the portfolio rule pack alongside generic VAST checks. For a pause or overlay buy I confirm both render path and the AdCOM extensions in the same pass, not just that an MP4 bit rate exists.

Portfolio tags often chain. When the defect might live in a wrapper hop, I run the same URL through the VAST inspector. It walks each redirect, validates every hop, and shows where the InLine with extensions actually lands.

For NonLinear SIMID and IAB sample layouts, I also open the IAB-style VAST tester (SIMID studio and sample creatives). That workbench is an independent fork, not an IAB Tech Lab product. Live URL QA still belongs on vastlint.org/tester/; wrapper debugging stays on the inspector.

After browser QA I keep vastlint check on fixtures in CI. The type mismatch warning survives automation better than eyeballing four nearly identical extension blocks.

Where to read the contract

The type mismatch rule reference shows the wrong and right markup side by side. Pair it with unknown signal when type is not one of the four AdCOM names at all.

The CTV Ad Portfolio guide maps Pause, Screensaver, Overlay, Squeezeback, and In-Scene to the signal combinations each format allows. Use it when you need to verify that the integers inside correctly labeled extensions still belong to the same row in the table.

Legacy players that never implemented VAST 4.x NonLinear still expect portfolio creative inside <Extension type="ctv_ad_portfolio">. That path binds by creative id and carries its own required MediaFiles rules. The VAST 2.0 portfolio extensions write-up is the reference when your QA stack only understands 2.0-shaped XML. For how finalized signaling relates to the VAST 4.4 draft schema, see signaling versus schema validation.

Do not treat a converting draft-schema blog post as the only checklist. The failure mode in this article is visible on 4.2 tags today, which is where IAB's own portfolio examples still declare version.

Closing the loop with trafficking

When format mix dashboards disagree with the deal line, grep the resolved InLine for <Extension blocks before you reopen the player integration. One swapped type attribute is enough for pause spend to inherit overlay position reporting, with no player error to paste into a ticket.

Fix the wrapper, redeploy, and re-run the same URL in the tester so the extensions you see match the plcmt value the buyer actually purchased.

Top comments (0)