A Pause Ad Used to Be a JPEG. VAST 4.4 Changes That.

Two documents, one process

On 17 July a file called vast_4.4.xsd landed in the IAB Tech Lab VAST repository, from a branch called 4.4Development, in a pull request titled "CTV Ad Portfolio Updates." Five days later, on 22 July, the CTV Ad Portfolio signaling guidance was finalised, after a comment period that closed 5 June.

Both matter, and they sit at different points in the same process. The signaling guidance is a finished standard you can build against today. The schema is explicitly labelled a working draft, in its own annotation: "IAB VAST (Video Ad Serving Template), Version 4.4 - DRAFT for working group discussion."

That is a normal and healthy state for a spec still being worked through, and it is the right label. It also means tooling should treat the two sources differently, which is the decision this post is about.

Why a pause ad schema is worth two days of anyone's time

US CTV ad spend is heading for roughly $38 billion in 2026, up from about $33 billion last year. This is also the year the CTV upfront, at $17.73 billion, passes primetime linear TV upfront at $16.98 billion for the first time. The pivot everyone forecast is arriving on schedule.

Almost all of that spend is pre-roll and mid-roll. Interruptive inventory. And ad load is the one lever streamers cannot keep pulling, because subscribers notice and subscribers leave.

The six formats in the CTV Ad Portfolio are the alternative. Pause, Screensaver, Overlay, Squeezeback, In-Scene and Menu monetise moments that were previously worth nothing: the viewer hitting pause, the idle home screen, the lower third during play. New inventory that adds no interruption at all.

The pricing backs that up. Hulu pause ads reportedly clear in the $25 to $40 CPM range, which puts them alongside standard programmatic premium AVOD at $25 to $45. A pause ad clears at roughly what a mid-roll clears at, on inventory that costs the publisher nothing in viewer tolerance.

Until now, every one of these formats ran on a bespoke integration. Publisher by publisher, custom fields, custom creative specs, no programmatic scale. That is the problem the Ad Format Hero initiative set out to fix, and it is a genuinely good piece of standards work: hundreds of format submissions from dozens of companies, sorted down to six that cover most of the market. The stated design goal tells you a lot about the care that went in: "no one should be able to accidentally purchase a pause ad." Buyers opt in deliberately.

The XML change that makes it possible

Going through the diff, the thing that stands out is how long NonLinearAds sat untouched. Seventeen years, essentially unchanged since VAST 2.0.

Before this, a pause ad was a JPEG. That was the whole vocabulary: one StaticResource, an iframe, or an HTML blob. No video, no duration, and therefore no quartile tracking.

The 4.4 draft gives NonLinear the same MediaFiles container Linear has always had, holding MediaFile, Mezzanine, InteractiveCreativeFile and ClosedCaptionFiles. Video and cinemagraph assets in a pause slot. Duration, so quartiles actually fire. Icons under NonLinearAds for an AdChoices disclosure. And NonLinearCustomClick, missing from every published XSD since 3.0.

The Duration change matters more than it looks. Without it there is no quartile tracking and no overlayViewDuration, which means a buyer cannot verify how long the ad was on screen. Selling a $35 CPM against a format with no duration measurement is a hard conversation.

Ship a fallback or lose the impression

The split between MediaFile and InteractiveCreativeFile is the part worth flagging to anyone building creative for these slots. MediaFile is a renderable asset. InteractiveCreativeFile is a separate interactive layer that needs the player to execute SIMID. If the player cannot run SIMID it renders the MediaFile instead. If there is no MediaFile, it fires the error URI and the impression is gone.

SIMID support across CTV devices is nowhere near universal, and there is no credible public number for how far it reaches. You do not need one to do the arithmetic. At a $30 pause CPM, every percentage point of your device base that cannot execute SIMID and has no fallback to render is 30 cents per thousand impressions you never see, with nothing in your logs to explain it. On a hundred million monthly pause impressions, one percent is $30,000 a month. Five percent is $150,000.

The guidance spells the fallback rule out explicitly, which reads like the working group anticipating exactly this failure and heading it off.

Three integers that change what publishers can sell

Most of this release is plumbing. One part is not, and it is three new AdCOM Creative Attributes describing motion: 21 Static Visual, 22 Limited Motion (Cinemagraph), 23 Full-Motion Video.

Consider what a publisher could express before. MIME types and protocols describe what a placement can decode. Nothing described what experience it expects. A streamer whose pause slot renders an MP4's first frame as a still image, or one designed for subtle cinemagraph motion rather than full video, had two options: block MP4 entirely and lose every buyer who would have complied, or accept motion creative and hope.

Now the publisher sets battr: [22, 23] to block motion while still accepting MP4 delivery, and the DSP declares what it actually sent with attr. Both sides can check. That opens up demand that was previously unbuyable on those placements, and if you are on the sell side it is the piece worth implementing first.

Why a VAST element now carries bid-request values

VAST elements do not normally carry OpenRTB enumerations. In 4.4 they do, and the reason becomes obvious once you follow where the tag ends up.

The VAST response outlives the bid object. An SSAI stitcher or a measurement vendor sitting downstream of the auction never sees the bid, only a creative. Without the format context it has no way to know whether it is about to render a fullscreen pause ad or a lower-third overlay, and no way to verify the creative matches what was bought. So the DSP echoes the context back into the creative, one signal per Extension, marked ext="adcom".

Given how much CTV inventory now moves through server-side stitching, that is the pragmatic call.

The values, since the guidance spreads them across four tables

• plcmt gains 5 Pause, 6 Screensaver, 7 Overlay, 8 Squeezeback, 9 In-Scene. Values 1 to 4 predate the portfolio.
• playbackmethod gains 8 and 9 for Pause with sound on and off, 10 and 11 for Screensaver. Overlay, Squeezeback and In-Scene reuse the existing 1 and 2.
• pos extends past the old 0 to 7 ceiling: 7 and 8 for fullscreen and partial Pause and Screensaver, 5/9/10/14/15 for Overlay geometry, 11/12/13/16/17 for Squeezeback layouts. Highest value in the document is 17.
• attr gains the three motion attributes above, 21 through 23.

QR codes get a standard, and the timing is interesting

Pause and screensaver slots are the obvious home for a QR code. The viewer is not mid-content, the remote is in hand, and there is no rush. The draft adds four typed elements for scan URL, image URL, position and size.

What makes the timing interesting is that eMarketer's Industry KPIs reported CTV QR scan rates falling sharply through Q4 2025, while survey work still puts roughly three quarters of viewers willing to scan a relevant TV QR code. If people are willing but scan rates are dropping, execution is the problem: codes too small, badly placed, on screen too briefly, in slots where nobody is holding a phone.

Standardising position and size in the creative payload is a sensible response, and it is the kind of thing that only gets fixed once it is machine-readable. There is a subtlety worth knowing about: Icon types its xPosition and yPosition as vastIntegerOrPercent_type, so xPosition="120" is valid there and has been for years. QrCodePosition types the same-named attributes as vastPercent_type. CTV screens vary too much in resolution for pixels to mean anything, so percentages are clearly the right choice, but anyone generating QR blocks by copying existing icon code will produce something that looks fine and is not.

How we decided to treat the draft

Because the schema is still in discussion, there are two places where vastlint waits rather than enforces. Neither is a problem with the draft; both are the kind of detail that gets settled during working-group discussion.

The draft is scoped to the CTV work. Some 4.2 elements are not carried over: AltText, BlockedAdCategories, Expires, IconClickFallbackImage and IconClickFallbackImages. Nothing in the CTV Ad Portfolio guidance touches any of them, so we read their absence as scope rather than deprecation. vastlint models 4.4 as 4.3's content model plus the additions, and does not derive removals from a document still in progress.

The draft is also stricter on Extension than 4.2, making @type required and restricting custom children to the ##other namespace. In 4.2, type is optional and custom children use processContents="skip". Enforcing the stricter form today would flag a lot of deployed vendor extensions, so we are holding off until the schema settles.

Three example typos, contributed back

Working through the guidance turned up three small things in its example XML: a Screensaver sample with an unbalanced closing tag, an Overlay sample carrying attr 20 where the document defines 21 through 23, and a template still reading version="INSERT VAST VERSION".

Typos in sample markup, nothing structural, and a decent argument for why validators exist. We sent them upstream so they get cleaned up. Worth knowing if you are copying markup out of that document, which most implementers will be.

Keep 4.2 or 4.3 in your version attribute for now

This is the practical takeaway, and it is the opposite of what you would expect from a new version number.

Every VAST example in the final guidance declares version="4.2". Not one declares 4.4. They use the new NonLinear content model while sitting on a version string the ecosystem has supported since 2019, which matches the deployed base. A player that version-gates strictly will reject a 4.4 tag outright, so you would gain nothing by moving early.

Build the new content model. Keep the old version string.

What we shipped

vastlint now recognises version="4.4" and validates the CTV Ad Portfolio content model, with 17 new rules in a dedicated category. The catalog is 212 rules.

The severity design follows the lifecycle split at the top of this post. Rules from the finalised guidance carry normal weight. Rules from the draft schema alone stay at warning or info, so the tooling stays useful without getting ahead of the working group. The only errors are constructs malformed under any reading of any version: a non-integer AdCOM payload, a QR position in pixels.

The new NonLinear content model is accepted on any VAST 4.x document rather than only on 4.4, because the guidance's own examples ship it on 4.2 tags. VAST 3.0 and below are unchanged, with a regression fixture guarding it. When 4.4 finalises we re-examine a handful of severities and the tooling catches up in an afternoon.