VAST 4.3: What's New in the Latest IAB Video Ad Standard

TL;DR: VAST 4.3 doesn’t overhaul the XML, but it does add a subtle-yet-important signal: a new value for the [PLAYBACKMETHODS] macro - 7 for continuous play (a.k.a. back‑to‑back episodes or “binge” playback without fresh user interaction). If you run CTV/OTT or long‑form, this flag helps ad servers choose more suitable ad experiences, pacing, and measurement rules for auto‑advancing content.

---

Why this matters (the problem VAST 4.3 is solving)

Before 4.3, players told ad servers how the content started (e.g., click‑to‑play vs. autoplay, muted vs. sound‑on) through the [PLAYBACKMETHODS] macro. But there was no standard way to say: “This next episode started because the stream continued automatically - not because the viewer re‑engaged.”

That missing signal leads to real problems:

• Pacing & Frequency: Ad servers may assume a new, fresh session and over‑deliver early‑pod ads.
• Creative Choice: Some buyers want different creative in “binge” contexts (e.g., lighter repetition caps or different sequencing).
• Measurement Nuance: Viewability, engagement, and completion expectations often shift between a click‑to‑start vs. an auto‑advance.

VAST 4.3 adds 7 = continuous play to [PLAYBACKMETHODS], letting your ad stack distinguish a new user‑initiated playback from an auto‑advanced one.

---

Quick refresher: What changed in VAST 4.3 (high‑impact items)

• Macros now managed on GitHub: The canonical macro list lives outside the PDF spec so new macros/values (like continuous play) can ship faster.
• New playback method value: [PLAYBACKMETHODS]=7 means continuous play (episodes back‑to‑back without user interaction).
• Everything else is mostly steady‑state: VAST 4.x continues the transition away from VPAID → OMID (verification) + SIMID (interactivity). If you’re on CTV/long‑form, ensure your implementation already covers AdVerifications/OMID and SIMID where relevant.

The rest of this article is hands‑on: we’ll show exactly how to implement the new signal in VAST ad requests, Wrappers, and tracking URLs - with before/after code.

---

Developer’s mental model: Where does [PLAYBACKMETHODS] go?

There are three common places you’ll see or pass macros:

1. Ad Request URLs (player → ad server)
2. <VASTAdTagURI> in Wrappers (ad server → next hop)
3. Tracking URLs (<Impression>, <Tracking>, etc.)

The party making the HTTP request is responsible for filling the macro. In pure client‑side rendering, that’s the player. In SSAI, the stitcher usually fills macros on behalf of the player.

---

Code-level comparison: Old approach vs. VAST 4.3 continuous play

1) Player → Ad server (ad request URL)

Before (no explicit continuous play):

Copy
https://ads.example.com/vast?pod=pre&playback=[PLAYBACKMETHODS]&ts=[TIMESTAMP]

Typical values your player might have passed:

• 1 = click to play
• 2 = autoplay with sound on
• 3 = autoplay muted (…values vary by environment; you likely mapped these already.)

Now (VAST 4.3, continuous play):

Copy
https://ads.example.com/vast?pod=pre&playback=7&ts=[TIMESTAMP]

When the next episode auto‑advances without fresh user interaction, set playback=7.

When to set it:

• CTV app with autoplay “Next Episode”
• FAST channels flowing programmatically into the next show block
• Long‑form mobile/desktop players with auto‑advance enabled

2) Wrapper → Downstream ad server (<VASTAdTagURI>)

If you operate a network or mediation layer, you’ll often forward macros unfilled so the next requester can populate them.

Before (forwarding only):

Copy
<VASTAdTagURI>
  <![CDATA[
    https://partner.example.net/tag?playback=[PLAYBACKMETHODS]&ua=[DEVICEUA]
  ]]>
</VASTAdTagURI>

Now (explicitly setting continuous play when you know it):

Copy
<VASTAdTagURI>
  <![CDATA[
    https://partner.example.net/tag?playback=7&ua=[DEVICEUA]
  ]]>
</VASTAdTagURI>

If your wrapper is the HTTP caller (e.g., SSAI waterfall), you should resolve 7 before making the request. If you’re just handing the URL to a client to fetch, you can leave [PLAYBACKMETHODS] in place so the client fills it.

3) Tracking URLs (Impression & Events)

You can pass the same context into tracking for analytics consistency.

Before:

Copy
<Impression><![CDATA[
  https://tracker.example.com/i?evt=imp&play=[PLAYBACKMETHODS]&ts=[TIMESTAMP]
]]></Impression>

Now (continuous play):

Copy
<Impression><![CDATA[
  https://tracker.example.com/i?evt=imp&play=7&ts=[TIMESTAMP]
]]></Impression>

Tip: Standardize ts with [TIMESTAMP] (UTC ISO-like format) so downstream systems can reliably parse and dedupe.

---

Full VAST XML examples

Example A - Client‑side InLine with tracking that includes playback context

Copy
<VAST version="4.3">
  <Ad id="demo-001">
    <InLine>
      <AdSystem version="1.0">AdServerX</AdSystem>
      <AdTitle>Pre-roll 15s</AdTitle>
      <AdServingId>0f6f2a9c-6b4a-4e0c-a513-2c5d2a1b3e22</AdServingId>

      <!-- Impression + tracking carry playback context (7 = continuous play) -->
      <Impression><![CDATA[
        https://trk.example.com/i?evt=imp&play=7&ts=[TIMESTAMP]
      ]]></Impression>

      <Creatives>
        <Creative>
          <Linear>
            <Duration>00:00:15</Duration>
            <MediaFiles>
              <MediaFile delivery="progressive" type="video/mp4" width="1920" height="1080">
                <![CDATA[https://cdn.example.com/creatives/spot-15s-1080p.mp4]]>
              </MediaFile>
            </MediaFiles>

            <TrackingEvents>
              <Tracking event="start"><![CDATA[
                https://trk.example.com/e?evt=start&play=7&ts=[TIMESTAMP]
              ]]></Tracking>
              <Tracking event="firstQuartile"><![CDATA[
                https://trk.example.com/e?evt=q1&play=7&ts=[TIMESTAMP]
              ]]></Tracking>
              <Tracking event="midpoint"><![CDATA[
                https://trk.example.com/e?evt=mid&play=7&ts=[TIMESTAMP]
              ]]></Tracking>
              <Tracking event="thirdQuartile"><![CDATA[
                https://trk.example.com/e?evt=q3&play=7&ts=[TIMESTAMP]
              ]]></Tracking>
              <Tracking event="complete"><![CDATA[
                https://trk.example.com/e?evt=comp&play=7&ts=[TIMESTAMP]
              ]]></Tracking>
            </TrackingEvents>

            <VideoClicks>
              <ClickThrough><![CDATA[https://brand.example.com/landing?src=preroll]]></ClickThrough>
            </VideoClicks>
          </Linear>
        </Creative>
      </Creatives>

      <!-- OMID verification (recommended for non-VPAID workflows) -->
      <AdVerifications>
        <Verification vendor="omid.example">
          <JavaScriptResource apiFramework="omid" browserOptional="true"><![CDATA[
            https://cdn.example.com/omid/verification.js
          ]]></JavaScriptResource>
          <VerificationParameters><![CDATA[{"integration":"playerXYZ"}]]></VerificationParameters>
        </Verification>
      </AdVerifications>
    </InLine>
  </Ad>
</VAST>

Example B - Wrapper that forwards the macro and demonstrates where to fill it

Version forwarding (player will fill):

Copy
<VAST version="4.3">
  <Ad id="wrap-001">
    <Wrapper>
      <AdSystem>NetworkY</AdSystem>
      <VASTAdTagURI><![CDATA[
        https://partner.adnet.com/getVAST?playback=[PLAYBACKMETHODS]&ua=[DEVICEUA]&cb=[CACHEBUSTING]
      ]]></VASTAdTagURI>
      <Impression><![CDATA[https://nety.example.com/imp?cb=[CACHEBUSTING]]]></Impression>

      <Creatives/>
    </Wrapper>
  </Ad>
</VAST>

Version resolving (wrapping server/SSAI knows it’s continuous play):

Copy
<VAST version="4.3">
  <Ad id="wrap-002">
    <Wrapper>
      <AdSystem>NetworkY</AdSystem>
      <VASTAdTagURI><![CDATA[
        https://partner.adnet.com/getVAST?playback=7&ua=[DEVICEUA]&cb=[CACHEBUSTING]
      ]]></VASTAdTagURI>
      <Impression><![CDATA[https://nety.example.com/imp?play=7&cb=[CACHEBUSTING]]]></Impression>
      <Creatives/>
    </Wrapper>
  </Ad>
</VAST>

Example C - SSAI populating macros server‑side

In SSAI, your stitcher often acts as the HTTP caller. Fill macros before requesting the downstream tag.

Copy
<VAST version="4.3">
  <Ad id="ssai-003">
    <Wrapper>
      <AdSystem>StitcherZ</AdSystem>
      <VASTAdTagURI><![CDATA[
        https://buyer.example.com/vast?play=7&ua=Mozilla%2F5.0&ip=[USERIP]&ts=2025-08-22T06:00:00Z
      ]]></VASTAdTagURI>
      <Impression><![CDATA[
        https://stitcherz.example.com/i?evt=imp&session=abc123&play=7
      ]]></Impression>
      <Creatives/>
    </Wrapper>
  </Ad>
</VAST>

---

Player logic: Detecting “continuous play”

A simple rule of thumb:

1. Initial play after a user action → use your existing [PLAYBACKMETHODS] value (1/2/3/etc.).
2. Auto‑advance to the next item in a series without a new user action → set 7.

Pseudocode:

Copy
const isContinuous = previousItemEnded && nextItemStartedAutomatically && !freshUserGesture;
const playbackMethod = isContinuous ? 7 : getStandardPlaybackMethod();

requestVAST({ playback: playbackMethod });

Edge case: If the user does interact in the interstitial between episodes (e.g., unpauses, seeks, or clicks “Next”), treat the next play as a fresh user‑initiated start.

---

Practical QA checklist

• Player (or SSAI) sets 7 only on true auto‑advance.
• Downstream ad servers log the new value and can target on it.
• Wrappers preserve or correctly resolve 7 depending on who performs the HTTP request.
• Tracking URLs and analytics include the playback method for consistent reporting.
• Validate your XML with a VAST validator and test in real players (web + CTV).

---

Migration tips

• Start by logging the new value in a canary release to confirm the rate of continuous play in your inventory.
• Coordinate with demand: communicate that you’ll be sending playback=7 so buyers can set creative sequencing/frequency strategies accordingly.
• SSAI at scale: ensure your stitcher can populate macros consistently (and that upstream Wrappers don’t accidentally double‑encode values).

---

FAQs

Q: Does this change the XML schema?
No. It’s a macro value addition, not a new element/attribute. Your VAST still validates as 4.3.

Q: Is this only for CTV?
No. Any environment with auto‑advance can use it, but CTV/OTT and long‑form benefit the most.

Q: Should I also use OMID/SIMID?
Yes - outside the scope of playback=7, but 4.x expects OMID for verification (via <AdVerifications>) and SIMID for interactivity (via <InteractiveCreativeFile> or separate execution environments).

---

Final takeaway

VAST 4.3’s [PLAYBACKMETHODS]=7 continuous play value is small, but it unlocks better pacing, targeting, and measurement for binge/auto‑advance experiences - especially on CTV. Wire it up once in your player/SSAI, pass it through Wrappers and trackers, and let your ad server do the smart stuff.

---

Continue reading the IAB technical spec for more details on the full VAST 4.3 changes