DEV Community: Aleksander Sekowski

AAMP vs AdCP: The Two Standards Stacks Racing to Define Agentic Advertising

Aleksander Sekowski — Sun, 05 Jul 2026 22:29:10 +0000

Eighteen months ago, agent-driven ad buying was a keynote topic. Today it is two competing standards stacks with shipped software, published by two different organizations that are openly not coordinating.

If you build adtech, both are about to show up in your pipes. Here is the short version.

Stack one: IAB Tech Lab's AAMP

AAMP (Agentic Advertising Management Protocols) launched in January 2026 and hit 2.0 in June. The philosophy: build on the rails that already move money. It wires OpenRTB, AdCOM, OpenDirect, and VAST together, with MCP and Google's Agent2Agent protocol as the agent interfaces.

Version 1.0 could only transact direct deals. The 2.0 release added programmatic: a Buyer Agent SDK with a three-layer agent hierarchy (orchestration, channel specialists, functional agents), a Seller Agent SDK that turns a static media kit into a storefront that adapts pricing to the buyer, and a Deals Library as the system of record with OpenDirect 2.1 support. Approval gates and audit logs keep humans at the sign-off points.

Stack two: AAO's AdCP

The Ad Context Protocol launched in October 2025 from a consortium including Yahoo, PubMatic, Optable, Scope3, Swivel, and Triton Digital. It is now governed by AgenticAdvertising.Org (AAO), a trade association with four equally weighted voting classes: brands, agencies, publishers, and technology providers. The reference sell-side implementation lives with the Prebid community.

AdCP was designed agent-native from the start. It is built directly on MCP, runs asynchronously so humans can approve while agents negotiate, and version 3.0 (April 2026) covers the full campaign lifecycle: discovery, media buys, creative production with brand.json, governance, and reporting across 20 media channels. It is in production at Snap, Pinterest, Reddit, Netflix, and Vox Media.

The actual differences

Governance. Tech Lab is the incumbent that already maintains VAST and OpenRTB. AAO is a new association built specifically for agentic advertising.
Design center. AAMP layers agents onto existing programmatic rails. AdCP defines new MCP-native tasks first and treats legacy systems as integration targets.
Coverage. AAMP is deepest at the transaction layer, with ARTF agent containers running inside bidder infrastructure. AdCP is broadest across the lifecycle, planning through reporting.
Interfaces. Both name MCP as a core protocol. A tool exposed as an MCP server serves agents on either stack without modification.
Verification. Neither stack validates the creative payload. Deal state and context move between agents; the correctness of what ships is out of scope for both specs.

The layer they share

Follow a video buy through either stack and the endpoint is identical: an ad server returns VAST XML. An InLine or Wrapper, MediaFiles, Impression pixels, TrackingEvents. Twenty channels of protocol surface on one side, one XML document on the other.

That document is where delivery fails. A missing Duration, an HTTP media URL on a CTV device that requires HTTPS, a wrapper chain past the player's depth limit: none of it is visible at the protocol layer. The deal confirms cleanly, the agents log success, and the impression dies at runtime with a VAST error code nobody is watching.

Human traffickers used to be the backstop. In an agent-to-agent transaction there is no trafficker. Validation has to be a tool the agent calls before the deal confirms, not a QA pass after launch.

The practical takeaway

You do not need to bet on a winner. MCP is the shared interface: AAMP's Buyer Agent SDK accepts additional MCP tool servers, and AdCP is MCP-native end to end. Anything you expose over MCP works in both stacks today.

That is how we ship vastlint: 187 rules grounded in the IAB VAST, OMID, and SIMID specs, deterministic JSON output, available as a hosted MCP endpoint, CLI, and libraries. Point either stack's agent at it and gate deal confirmation on a clean tag.

The protocols will keep changing. The payload has been VAST for two decades and will still be VAST when the governance questions settle.

The full comparison, with sources, is on the vastlint blog: AAMP vs AdCP: What IAB Tech Lab and AAO Are Each Building for Agentic Advertising.

The VAST Macros Cheat Sheet Every Ad Ops Engineer Need

Aleksander Sekowski — Sun, 28 Jun 2026 16:46:17 +0000

If you have ever stared at a tracking URL full of [CACHEBUSTING], [TIMESTAMP], and [ADPLAYHEAD] and wondered which of those the player actually fills in, this post is for you.

VAST macros are substitution tokens of the form [MACRO] that ad servers and players replace inside tracking, click, error, impression, and media URLs at request time. They are how a static VAST tag carries dynamic, per-impression context: the device ID, the consent string, the playhead position, the error code. Get them wrong and you lose attribution, break frequency capping, or fire tracking pixels that a cache silently collapses into one.

I have debugged enough broken tags to know the failure modes are always the same handful. Here is the working reference, grouped the way you actually reason about them.

The mental model

A macro only has a defined value in the context where the spec says it does. [ERRORCODE] means nothing inside an Impression pixel. [REASON] means nothing outside a verificationNotExecuted URI. If you drop a macro into the wrong element, the player either leaves the literal [ERRORCODE] string in the URL or substitutes an empty value, and your reporting goes sideways.

The second rule: anything that is itself a URL or contains reserved characters must be percent-encoded when nested inside another URL. [PAGEURL], [ASSETURI], [TIMESTAMP], and the various user-agent macros are the usual offenders.

That is most of the bugs right there. Context and encoding.

Cache busting and timing

The two macros that belong on nearly every tracking URL:

CACHEBUSTING resolves to a fresh random 8-digit number per request. Without it, proxies and browser caches happily collapse repeated tracking calls into a single hit, and your impression counts come in low.
TIMESTAMP is the ISO 8601 time the request fired. Useful for ordering events and as a secondary cache buster. Percent-encode it, because the colons in 18:30:00Z are reserved.

Playhead: the one everyone gets wrong

This is the single most common source of legacy-tag confusion.

ADPLAYHEAD is the current position inside the ad creative, in HH:MM:SS.mmm. This is the VAST 4.1 macro you should be using.
CONTENTPLAYHEAD is the pre-4.1 macro. It was ambiguous about whether it meant ad time or content time, so 4.1 deprecated it in favour of [ADPLAYHEAD]. Newer players may not populate it at all.

If your quartile reporting is empty on modern CTV players, a stale [CONTENTPLAYHEAD] in your tracking URLs is the first thing to check.

Errors and verification

ERRORCODE substitutes the numeric VAST error code (303, 401, and friends) and only has a defined value inside an <Error> URI. Put it anywhere else and it stays literal.
REASON carries why a verification script did not run (1 could not load, 2 could not verify, 3 rejected) and is only valid inside a verificationNotExecuted tracking URI.

Identity and privacy

Everything attribution and consent depends on:

IFA is the resettable device advertising identifier: IDFA on iOS/tvOS, AAID on Android, a platform ID on CTV. Empty when the user has opted out.
GDPR is the 1/0 flag for whether GDPR applies, and GDPRCONSENT carries the IAB TCF consent string. If [GDPR] is 1 you should be sending a valid consent string alongside it.
LIMITADTRACKING reports the device limit-ad-tracking setting. When it is 1, the [IFA] is typically zeroed and personalised targeting must be suppressed.

Context: where and how the ad served

DEVICEIP is the end-user device IP, central to geolocation and fraud detection in server-side flows.
DOMAIN and PAGEURL identify the supply. Remember to percent-encode [PAGEURL] when it rides inside another URL as a query parameter.
PLAYERSIZE gives width,height for viewability context and creative selection.

Identifiers that tie the supply chain together

ADSERVINGID is a single identifier from the InLine ad that every party in the chain can log, which is the fastest path to debugging a discrepancy across SSP, DSP, and verification logs.
UNIVERSALADID uniquely identifies the creative across systems for creative-level frequency capping.
ADCOUNT is the ad's position within a pod, for pod-level reporting and pacing.

The deprecated ones still hiding in production

VAST 4.1 deprecated the older playhead macros. [CONTENTPLAYHEAD] and [MEDIAPLAYHEAD] were both folded into [ADPLAYHEAD]. They still appear constantly in tags copied from older ad servers, and they are a silent failure: the URL looks fine, but the value never arrives on a player that only implements the 4.1 macro.

How to actually catch these

Reading macro tables by hand does not scale past a few tags. The cases that bite are the boring ones: a macro in the wrong element, an unencoded URL, a deprecated token nobody noticed. Those are exactly what a linter is good at.

I run tags through vastlint, an open VAST validator that flags unknown macros, lowercase casing mistakes, missing percent-encoding, deprecated tokens, and context violations (an [ERRORCODE] outside <Error>, a [REASON] outside verificationNotExecuted). The full per-macro reference, with the value each one resolves to and where it is valid, lives at vastlint.org/docs/vast-macros.

If you maintain VAST tags, bookmark the macro index and wire the validator into CI. The discrepancies you prevent are the ones you never have to explain on a reconciliation call.

VASTlint on PyPI: in-process VAST validation for Python backends

Aleksander Sekowski — Sun, 28 Jun 2026 16:27:56 +0000

TL;DR

pip install vastlint

import vastlint

result = vastlint.validate(vast_xml)
print(result.valid)            # True / False
print(result.summary.errors)   # 0
print(result.issues)           # [Issue(...), ...]

A VAST XML validator that runs in-process, returns structured dataclasses, and shares one Rust core with the CLI, the Go binding, the Ruby gem, the MCP server, and the web validator. No subprocess. No HTTP call to anyone. No Rust toolchain at install time.

The problem if you do video ad tech in Python

VAST is the IAB standard a video player uses to fetch and track an ad. The trouble is that a broken VAST tag is still well-formed XML. It parses fine. It just does not serve.

Missing <Impression>? You do not get paid for the view.
<MediaFile> over HTTP in a secure context? Blocked.
A malformed wrapper five hops deep? Dead impression in production.
VAST 2.0 through 4.3 each moved elements around, so your hand-rolled lxml checks rot. 1 None of that throws. You learn about it from a revenue dip, not a traceback. A linter exists to close the gap between "parses" and "is actually valid VAST."

Until now the Python options were: shell out to a binary, call an external service, or maintain your own pile of lxml rules forever. All three have a tax.

What you get

validate() takes str or bytes and returns a Result. Everything is a frozen dataclass.

import vastlint

result = vastlint.validate(vast_xml)

if not result.valid:
    for issue in result.issues:
        print(issue.severity, issue.id, issue.message, f"line {issue.line}")

print(result.to_json())

Each issue is specific enough to act on:

{
  "id": "VAST-2.0-inline-impression",
  "severity": "error",
  "message": "<InLine> must contain at least one <Impression>",
  "path": "/VAST/Ad[0]/InLine",
  "spec_ref": "IAB VAST 2.0 §2.2.1",
  "line": 4,
  "col": 3
}

Rule ID, message, document path, the IAB spec citation, plus line and column. "Your VAST is invalid" helps nobody. "Line 4, your InLine has no Impression, per VAST 2.0 §2.2.1" is a thirty-second fix.

Why in-process matters

vastlint runs inside your process. Not a subprocess, not a microservice, not a call to vastlint.org.

Approach	Cost
Subprocess per request	spawn cost, stdout parsing, lifecycle management, falls over under QPS
External validation service	network hop, timeouts, retries, a dependency that can take you down, and you ship every tag off-box
Hand-rolled `lxml`	you own the entire IAB spec across six versions, forever
In-process binding	call a function, get a dataclass, no hop, no daemon, rules maintained upstream

The wheel bundles a platform-matched shared library (macOS and Linux, ARM and x86), so pip install needs no compiler and no Rust. It wraps the stable vastlint-ffi C API behind the same core everything else uses, so the result on your backend matches the web validator byte for byte.

Drop it into FastAPI

from fastapi import FastAPI
from pydantic import BaseModel
import vastlint

app = FastAPI()


class ValidateRequest(BaseModel):
    xml: str
    wrapper_depth: int = 0
    max_wrapper_depth: int = 5
    rule_overrides: dict[str, str] | None = None


@app.post("/validate")
def validate(req: ValidateRequest):
    result = vastlint.validate(
        req.xml,
        wrapper_depth=req.wrapper_depth,
        max_wrapper_depth=req.max_wrapper_depth,
        rule_overrides=req.rule_overrides,
    )
    return result.to_dict()

The result shape is JSON-compatible and stable, so it goes straight to a frontend. to_dict() and to_json() are on the result. Same story in Flask or a Django admin: it is just a library import.

Things this unlocks:

Gate creative onboarding before a tag enters your serving path.
Lint at trafficking time with no new infrastructure.
Batch-scan stored inventory to find how much is quietly out of spec.

A deterministic verifier for model and agent harnesses

If you point a language model at "produce a valid VAST tag" (drafting, repair, template fill), you need a checker that is faster than the model, never hallucinates, and returns the same verdict every time. A generated tag can parse fine and still be wrong with no exception to catch it. That is what a linter is, and vastlint returns structured detail, not a vibe, so you can build a real signal.

As a reward function in a training or rejection-sampling loop:

import vastlint

def vast_reward(generated_xml: str) -> float:
    result = vastlint.validate(generated_xml)
    if result.valid:
        return 1.0
    s = result.summary
    return -1.0 * s.errors - 0.25 * s.warnings   # partial credit, not just pass/fail

Per-rule detail lets you shape the reward: hard-fail on errors, weight HTTPS heavier than a missing mezzanine, or reward ten errors down to one. Binary valid/invalid throws away signal the validator already computed.

As a verifier in an agent repair loop, the issues are the feedback. Each one has a message, a path, a line, and a spec citation, exactly what a model can read and act on:

def repair_loop(model, broken_xml, max_turns=4):
    xml = broken_xml
    for _ in range(max_turns):
        result = vastlint.validate(xml)
        if result.valid:
            return xml
        feedback = "\n".join(
            f"{i.severity} at {i.path} (line {i.line}): {i.message} [{i.spec_ref}]"
            for i in result.issues
        )
        xml = model.revise(xml, feedback)
    return xml

Generate, validate, feed the structured issues back, revise, repeat. The validator is the part of the loop that does not drift.

Same shape works as an eval harness: run a model over a held-out set of dirty tags, score not just how many came out valid but which rules each model gets wrong most. And because validation is in-process and sub-millisecond, you can run thousands of rollouts without the validator becoming the bottleneck. A subprocess or network call per rollout would dominate the loop. A function call does not.

Agent-shaped harness instead of a training loop? The same core is also an MCP server, so an agent can call validation as a tool. Same rules, two ways in.

Tune severities per environment

result = vastlint.validate(
    vast_xml,
    rule_overrides={
        "VAST-2.0-mediafile-https": "error",
        "VAST-4.1-mezzanine-recommended": "off",
    },
)

Map a rule ID to error, warning, info, or off. Full catalog at vastlint.org/docs/rules, and those IDs are the ones you pass here.

wrapper_depth and max_wrapper_depth control how far the validator follows wrapper chains.

The full API

vastlint.validate(xml, *, wrapper_depth=0, max_wrapper_depth=5, rule_overrides=None) -> Result
vastlint.version() -> str

Result exposes .version, .issues (list of Issue), .summary (Summary), .valid, .to_dict(), and .to_json().

How it ships

Published from GitHub Actions: vendor the platform libraries from the matching vastlint release, run the tests, build sdist and wheel, twine check the metadata, publish to PyPI with trusted publishing over OIDC. No long-lived token. The wheel you install is the artifact that passed the checks.

Try it

pip install vastlint

import vastlint
print(vastlint.version())

Web validator: vastlint.org/validate
Rules: vastlint.org/docs/rules
Source: github.com/aleksUIX/vastlint-python

If you have a Python ad tech backend and kept putting off VAST validation because every option was bad, it is one pip install and one function call now.

VMAP and DAAST Validation Just Landed in vastlint Core

Aleksander Sekowski — Sun, 14 Jun 2026 03:01:14 +0000

If you work in video or audio ad serving, you have met VAST: the IAB XML template that tells a player what ad to show and where to fire tracking. But VAST rarely travels alone. It usually arrives wrapped in a schedule (VMAP) or shows up with an audio sibling (DAAST), and those two formats break in production just as often as VAST does, with far less tooling watching them.

vastlint is an open-source, Rust-based linter for IAB ad tags. As of 0.5.0 it validates VMAP 1.0 and DAAST 1.0 alongside VAST 2.0 through 4.3, from the same CLI, library, and MCP server. The catalog is now 182 rules, 53 of them new for these two formats.

What shipped

There is nothing new to install or wire up. The same validate() entry point that handles a VAST tag now recognises a <vmap:VMAP> or <DAAST> root and routes the document to the right rule chain:

24 new VMAP 1.0 rules: ad-break structure, timeOffset / breakType / repeatAfter formats, <AdSource> content constraints, CDATA requirements, VMAP tracking events, and conflict detection.
29 new DAAST 1.0 rules: required <Category>, audio MediaFile attributes, <AdInteractions>, the DAAST tracking event set, audio pricing models, and detection of VAST elements that do not belong.
A new document_type field on the result (Vast, Vmap, or Daast) so you always know which chain ran.

Every rule keeps the vastlint contract: a stable ID, a default severity, a spec reference, and a docs page with examples and fix guidance.

VMAP: the where and when of ad breaks

VMAP (Video Multiple Ad Playlist) is the IAB standard a content owner uses to describe ad-break structure when they do not control the player. It was published on July 19, 2012 and has had exactly one version since. The mental model: VMAP handles the where and when of ad placement (pre-roll, mid-rolls at specific offsets, post-roll), and VAST handles the what (the creative inside each break).

A VMAP document is a playlist of <AdBreak> elements. Each break carries a timeOffset, a breakType, and an <AdSource> that either embeds a VAST document inline, points at an ad tag URI, or carries custom data. That flexibility is exactly where it breaks.

Here is a VMAP snippet that looks fine and is not:

<vmap:VMAP xmlns:vmap="http://www.iab.net/videosuite/vmap" version="1.0">
  <vmap:AdBreak timeOffset="15:00" breakType="linear">
    <vmap:AdSource id="mid-1">
      <vmap:AdTagURI templateType="vast3">
        https://ads.example.com/vast?cb=[CACHEBUSTER]&pos=mid
      </vmap:AdTagURI>
    </vmap:AdSource>
  </vmap:AdBreak>
</vmap:VMAP>

vastlint reports:

VMAP-1.0-adbreak-timeoffset-format (error): timeOffset="15:00" is not a valid hh:mm:ss[.mmm], n%, start, end, or #m value. The mid-roll will not schedule where you think.
VMAP-1.0-adtaguri-cdata (error): the AdTagURI contains an unescaped ampersand and is not inside a CDATA block, so the document stops being well-formed the moment the macro expands.

The best part: when an <AdSource> embeds VAST inline, vastlint validates that VAST with the full VAST rule chain and reports issues with /VMAP/AdBreak[i]/AdSource/VASTAdData paths plus document-absolute line and column. A wrapper problem two levels deep points straight at the break it lives in.

Common VMAP failures vastlint catches:

Malformed timeOffset that silently drops a break.
An <AdSource> with more than one payload, or none (the spec requires exactly one of <VASTAdData>, <AdTagURI>, or <CustomAdData>).
AdTagURI / CustomAdData not wrapped in CDATA.
Structurally invalid VAST inside a structurally valid VMAP.
repeatAfter that has no effect because timeOffset is start or end.

DAAST: deprecated, but the tags did not go away

DAAST (Digital Audio Ad Serving Template) is the audio counterpart the IAB released for public comment in 2014. It mirrors VAST 3.0 but swaps video assumptions for audio ones: <Category> is required, creatives carry audio MediaFiles, <VideoClicks> becomes <AdInteractions>, and the tracking event set is audio-specific.

Here is the catch: DAAST 1.0 is formally deprecated. In November 2018 the IAB merged audio support into VAST 4.1 via an optional adType attribute on <Ad>, and the recommendation since then is to serve audio with VAST 4.1 or later.

So why validate DAAST in 2026? Because the money never stopped and neither did the legacy tags. IAB and PwC put US digital audio ad spend at $8.4 billion in 2025, up 10.2% year over year, with podcast revenue alone growing 17.6% to roughly $2.9 billion. A market that large still has long-lived DAAST inventory and ad-server templates in circulation. When a DAAST tag shows up, you want to know whether it is clean, a DAAST document with VAST leftovers, or a VAST tag someone mislabeled.

Here is a VAST tag pretending to be DAAST:

<DAAST version="1.0">
  <Ad id="audio-1">
    <InLine>
      <AdTitle>Morning drive spot</AdTitle>
      <Impression><![CDATA[https://t.example.com/imp]]></Impression>
      <Creatives>
        <Creative>
          <Linear>
            <Duration>00:00:30</Duration>
            <MediaFiles>
              <MediaFile delivery="progressive" type="video/mp4">
                <![CDATA[https://cdn.example.com/spot.mp4]]>
              </MediaFile>
            </MediaFiles>
            <VideoClicks>
              <ClickThrough><![CDATA[https://example.com]]></ClickThrough>
            </VideoClicks>
          </Linear>
        </Creative>
      </Creatives>
    </InLine>
  </Ad>
</DAAST>

vastlint's verdict:

DAAST-1.0-inline-category (error): <Category> is required in DAAST and is missing.
DAAST-1.0-mediafile-audio-type (warning): the MediaFile type is video/mp4 on an audio creative.
DAAST-1.0-videoclicks-element (warning): <VideoClicks> is a VAST element; DAAST uses <AdInteractions>. This is the tell that the tag was lifted from a video flow.

Other DAAST-specific checks include the <AudioInteractions> to <AdInteractions> rename, audio pricing models (DAAST adds cpo to the usual cpm / cpc / cpe / cpv set, and requires model plus currency), required <DAASTAdTagURI> on wrappers, and [ERRORCODE] macro presence so failed audio impressions are reportable.

Why this belongs in core, not a separate tool

Ad ops teams do not deal with one format at a time. A single campaign can ship a VMAP schedule whose breaks wrap VAST 4.x creatives, while the audio line item delivers a DAAST tag. Asking people to remember which validator handles which format, and to paste tags into three different web tools, is how broken tags reach production.

Putting all three formats behind one entry point removes that decision. You hand vastlint a document, it tells you what the document is, and it validates it against the right spec with consistent rule IDs and severities. One engine, one report format, three formats covered, and it runs everywhere you already run vastlint:

CLI: validate VMAP and DAAST files in a pre-flight step or a git hook.
Library: call validate() and branch on document_type; the result shape is identical across formats.
CI: gate merges so a malformed timeOffset or a DAAST tag with VAST leftovers never reaches a release.
MCP server: an AI agent doing campaign QA can validate a playlist or an audio tag through the same tool surface it uses for VAST.

Try it

Paste a VMAP playlist or a DAAST audio tag into the validator at vastlint.org/validate. It detects the document type and returns every issue with a rule ID, severity, and the exact fix, the same way it does for VAST. vastlint is free and open source: github.com/aleksUIX/vastlint.

References

OMID Explained: How IAB's Open Measurement SDK Works with VAST AdVerifications

Aleksander Sekowski — Wed, 10 Jun 2026 12:27:08 +0000

You've probably seen apiFramework="omid" inside a VAST tag and wondered what it actually does. This is the practical explanation — what OMID is, how it fits into VAST 4.1+, what each field means, and what breaks when you get it wrong.

What is OMID?

OMID (Open Measurement Interface Definition) is the API layer inside the IAB Tech Lab Open Measurement SDK (OM SDK). It defines a standardised way for third-party measurement vendors — DoubleVerify, IAS, Moat, etc. — to collect viewability, audio, and fraud signals from any video or audio player, whether that's a web browser, a mobile app, or a CTV device.

The key distinction: OMID is the protocol. OM SDK is the implementation (native libraries for iOS, Android, and web). In practice, most people use the terms interchangeably.

Why it replaced VPAID for measurement

Before OMID, the common approach to third-party measurement was to piggyback a verification script inside a VPAID unit. VPAID gave that script full access to the player's JavaScript context and DOM — which meant it could read page data, fire arbitrary pixels, redirect users, and slow down load times. The IAB's own audit found VPAID ranked among the primary vectors for ad fraud.

OMID draws a hard boundary. Measurement scripts load into an isolated context and communicate through a standardised API. The player reports media events and geometry data to the OM SDK; the SDK forwards them to vendor scripts via the OMID API. No DOM access, no shared JS context, no ability to do anything outside the defined event model.

It also runs on CTV and SSAI environments where VPAID simply can't execute. That's the main reason the industry migrated.

How it fits into VAST

VAST describes the ad: media files, tracking URLs, companion ads. OMID describes who measures the ad and how.

Starting with VAST 4.1, the <AdVerifications> element carries one or more <Verification> entries, each pointing to a vendor's OMID-compatible script. Players that support OM SDK parse this automatically and begin reporting signals once the ad enters the viewport. Players that don't support it skip the element gracefully — OMID degrades without breaking playback.

The XML structure

Here's a complete example with two vendors:

<AdVerifications>
  <Verification vendor="doubleverify.com-omid">
    <JavaScriptResource apiFramework="omid" browserOptional="true">
      <![CDATA[https://cdn.doubleverify.com/dvtp_src.js]]>
    </JavaScriptResource>
    <VerificationParameters>
      <![CDATA[ctx=12345678&cmp=DV123456]]>
    </VerificationParameters>
    <TrackingEvents>
      <Tracking event="verificationNotExecuted">
        <![CDATA[https://cdn.doubleverify.com/not_executed.js?ctx=12345678&reason=[REASON]]]>
      </Tracking>
    </TrackingEvents>
  </Verification>

  <Verification vendor="ias.com-omid">
    <JavaScriptResource apiFramework="omid" browserOptional="false">
      <![CDATA[https://pixel.adsafeprotected.com/jload]]>
    </JavaScriptResource>
    <VerificationParameters>
      <![CDATA[anId=12345&advId=67890]]>
    </VerificationParameters>
    <TrackingEvents>
      <Tracking event="verificationNotExecuted">
        <![CDATA[https://pixel.adsafeprotected.com/jload?not_executed=1&reason=[REASON]]]>
      </Tracking>
    </TrackingEvents>
  </Verification>
</AdVerifications>

Breaking down each field

vendor (required)
Identifies the measurement vendor. Must follow the domain-omid format — e.g. doubleverify.com-omid, ias.com-omid. This is how players deduplicate vendors across wrapper chains and how the OM SDK routes signals to the right script.

<JavaScriptResource apiFramework="omid">
The URL to the vendor's OMID-compatible measurement script. apiFramework must be lowercase omid. Some players treat this attribute as case-sensitive, so OMID or Omid may be silently ignored.

browserOptional
When true, native iOS and Android players can skip loading the JS file and use the vendor's native SDK integration instead. When false (the default), the script is required even in app contexts — and if the player can't execute it, it should fire verificationNotExecuted.

<VerificationParameters>
A CDATA block with vendor-specific initialisation params — typically placement ID, publisher ID, campaign ID. The format is vendor-defined; VAST doesn't prescribe it. If this element is present but empty, it's usually a configuration mistake.

<TrackingEvents> / verificationNotExecuted
The [REASON] macro is replaced by a numeric code when measurement fails:

Code	Meaning
1	API not supported
2	JavaScript resource not executed
3	Verification not supported for this media type
4	Player/SDK does not support OM SDK

This event is how vendors know measurement failed rather than just inferring it from missing signals. Missing it means you have no visibility into non-executing scripts.

VAST version support

Version	Support	Notes
VAST 2.0, 3.0	None (native)	Some players accept AdVerifications inside an `<Extensions>` block — non-standard and not reliable
VAST 4.0	Partial	AdVerifications exists but placement differs from 4.1+
VAST 4.1	Full	Canonical placement; the version most OM SDK integrations target
VAST 4.2, 4.3	Full	Inherited from 4.1 without structural changes

If you're serving tags to CTV or app inventory, target VAST 4.1+. Anything below that and you're relying on non-standard extension handling.

OMID in wrapper chains

<AdVerifications> can appear in both <InLine> and <Wrapper> documents. When a wrapper chain is involved:

The player accumulates <Verification> entries from every hop in the chain — outermost wrapper down to InLine.
Duplicate vendor values (same vendor attribute at multiple hops) should be deduplicated by the player. Only one instance per vendor should run. "Should" — behaviour varies.
If you're debugging a live chain, a hop-by-hop inspector will show you exactly which vendors are introduced at which level.

OMID vs VPAID for measurement — side by side

	VPAID	OMID
Security model	Script runs in shared player JS context	Script runs in isolated context via OM SDK API
DOM access	Full access to publisher DOM	None
CTV / native players	Not supported	Supported via native OM SDK libraries
SSAI environments	Not possible	Supported
Multiple vendors	Each vendor wraps the whole ad	Multiple `<Verification>` elements in one tag
Failed measurement signal	No standard mechanism	`verificationNotExecuted` tracking event
Fraud risk	High	Low — constrained to OMID event model
Status	Deprecated	Current standard (v1.5)

Common mistakes

These are the issues that actually show up in production tags:

apiFramework="OMID" (uppercase)
Case-sensitive players fail to recognise the vendor. Always lowercase: omid.

HTTP script URL
Mixed-content block in modern browsers. The script never loads. Use HTTPS.

Missing vendor attribute
Players can't deduplicate vendors or route scripts correctly. Always include it.

vendor not in domain-omid format
Values like "DoubleVerify" or "DV" are non-standard. Strict OM SDK implementations may silently ignore them.

Missing verificationNotExecuted tracking URL
The vendor has no signal when measurement fails. Discrepancies go undetected.

Duplicate vendor at multiple wrapper hops
Some players run both instances and double-count. Use your inspector to catch this before it hits production.

AdVerifications in VAST 2.0 / 3.0 without an Extensions wrapper
Structurally invalid — most players ignore the block entirely.

Validation

If you want to catch these issues before a tag goes live, paste it into VASTlint. It checks vendor format, apiFramework casing, HTTPS enforcement, empty VerificationParameters, and duplicate vendor detection. It won't execute the script or validate the runtime OM SDK session — that requires a live player — but it catches the structural mistakes that account for most OMID failures.

The IAB Tech Lab OM SDK docs are the authoritative reference if you need the full protocol details: iabtechlab.com/standards/open-measurement-sdk. The OMID API v1.5 spec is worth reading if you're integrating on the player or vendor side.

CTV Fraud Has an IPv6 Business Problem

Aleksander Sekowski — Sat, 30 May 2026 16:01:32 +0000

Most discussions about CTV fraud start with threat actors, fake apps, or suspicious traffic spikes.

That is useful, but it misses a more expensive problem: bad fraud decisions.

If your fraud stack still treats one IP address as a durable identity, IPv6 is already making those decisions worse. That creates two kinds of cost at the same time. Fraud slips through when rotating addresses look new, and legitimate traffic gets penalized when broad network blocks catch more than they should.

That is not just a security issue. It is a business problem for the whole ad ecosystem.

A small watchlist, a useful lesson

Pixalate's May 2026 AdFraud IOC-DB workbook for IPv6 addresses is a good example of the problem.

The workbook is small. It contains 25 populated high-risk indicators, not a market census. But the mix is still useful:

21 entries are tagged displayImpressionFraud
2 are tagged IABcrawler
1 is tagged appSpoofing
1 is tagged deviceIdStuffing

The provider distribution is what makes the dataset interesting:

11 entries are associated with Spectrum
3 with Verizon Fios
3 with T-Mobile USA
2 with Comcast Cable
1 each with AT&T Internet, Comcast Business, Play, AT&T Wireless, Hetzner Online, and Starlink

That does not mean those providers are fraud networks. It means suspicious ad activity can show up across residential broadband, mobile access, satellite access, and data-center infrastructure.

The repeated prefixes matter even more. Four of the listed addresses sit inside the same Spectrum /64. Nine sit inside the same Spectrum /32. Two Verizon Fios addresses share a /64. Two Comcast Cable addresses share a /64.

That is the operational lesson.

The single address can change. The surrounding network context can still repeat.

Why IPv6 changes the economics

IPv6 was built to make long-term address correlation harder.

RFC 8981 describes temporary IPv6 addresses that rotate randomized interface identifiers over time. That is a privacy improvement. It reduces the value of using one full address to track the same host across many sessions.

That is good network design. It is bad news for simplistic fraud models.

If a system still assumes one address equals one stable endpoint, it will make two predictable mistakes:

It will miss abuse when suspicious actors rotate through new /128s.
It will overblock when one suspicious /128 gets expanded to a much broader prefix without enough evidence.

Both errors are expensive.

One leaks money to bad traffic. The other blocks revenue from good traffic.

The false positive problem is bigger than most teams admit

In ad tech, false negatives get the attention because they look like fraud losses.

False positives are quieter. They look like lower match rates, lower fill, lower bid density, underdelivery, or weaker reach. That makes them easier to misdiagnose.

If a buyer, platform, or verification layer decides that a broad IPv6 prefix is bad because one address in that space was flagged, the blast radius can be large.

For publishers, that can mean rejecting legitimate demand or discounting inventory quality for users who are not actually fraudulent.

For SSPs and exchanges, it can mean pushing overly broad risk labels downstream, which changes auction behavior without proving the underlying case.

For DSPs, it can mean excluding reachable households from a campaign, weakening delivery and frequency goals while making optimization look worse than it should.

For agencies and brands, it can mean paying for expensive fraud controls that suppress real audience access.

This is where IPv6 becomes a business issue instead of a pure detection issue.

When identity assumptions get weaker, the cost of blunt enforcement gets higher.

CTV makes those errors harder to unwind

CTV already has fragmented observability.

The IP visible to a content request is not always the same IP seen by the ad server, the SSAI stitcher, the player, or the downstream reporting system. By the time the logs disagree, the impression is gone.

That matters because network signals are often treated as if they are closer to ground truth than they really are.

A suspicious IPv6 indicator can tell you something useful about origin, recurrence, or likely abuse. It does not tell you, on its own, whether:

the inventory description was false
the app was spoofed
the supply path was misrepresented
the VAST was runnable
the ad rendered successfully on the device that mattered

That means a weak IP decision can ripple across multiple business systems.

It can affect eligibility, scoring, pacing, billing, discrepancy reviews, partner escalations, and renewal conversations.

In practice, many of those downstream failures show up as execution problems that have nothing to do with IP identity by themselves: too many redirects in a wrapper chain, insecure HTTP media URLs on HTTPS inventory, or a tag that passes a quick glance but fails in a real live-tag test flow.

Where the ecosystem feels the damage

The biggest implication of IPv6 in fraud detection is not technical complexity by itself. It is decision quality across the market.

Publishers

Publishers care about fill, yield, and trust.

If network-based controls are too aggressive, good traffic can get downgraded or blocked. If the controls are too weak, invalid traffic still makes it into sold inventory. Either way, the publisher absorbs the economic damage first.

SSPs and exchanges

SSPs and exchanges sit in the middle of the trust chain.

If they pass along weak identity assumptions as if they were strong fraud signals, they distort auction quality and partner scoring. If they do not cluster recurring signals above the single address level, they also miss repeat patterns that should trigger closer review.

DSPs and buyers

DSPs need accurate suppression, not maximum suppression.

Overblocking broad IPv6 space can quietly reduce addressable reach and campaign efficiency. Underblocking lets suspicious activity continue long enough to waste budget and pollute performance models.

Verification and fraud vendors

Vendors that still lean too heavily on single-address reputation will face the hardest tradeoff. Their models can look decisive while being economically blunt.

The market increasingly needs cluster logic, recurrence logic, and stronger correlation across network, app, device, and execution signals.

What better operations look like

The answer is not to throw away IP intelligence.

The answer is to use it more carefully.

An IPv6 IOC feed is most useful as an escalation surface, not a standalone verdict engine.

That means a few practical shifts:

1. Treat the /128 as a lead

Keep the exact address. It still matters.

But do not stop there. Enrich it with bundle ID, app ID, supply path, user agent data, session timing, creative identifiers, SSAI markers, and execution outcome.

2. Cluster above the single address

Review /64, /48, /32, ASN, ISP, and time-window recurrence together.

That is where repeated behavior becomes visible without pretending the full address is a stable identity token.

3. Separate ranking from enforcement

A network signal can justify lower trust, tighter review, or increased measurement before it justifies a hard block.

This is especially important in consumer broadband and mobile access space, where the collateral damage of overbroad enforcement can be substantial.

4. Connect detection to business outcomes

For any suspect impression, teams should be able to connect:

request context
network context
winning creative
final VAST or stitched instruction
execution result
billing consequence

If those records do not join cleanly, the organization is not really evaluating behavior. It is comparing disconnected logs and making partial decisions.

If you want to go deeper into the VAST side of the problem

The network side is only part of the story. If you want to connect business outcomes back to execution quality, these are the most useful vastlint.org pages to start with:

VAST Tag Validator for raw XML validation
VAST Tag Tester for live tag QA, creative preview, and click tracking
VAST Inspector for hop-by-hop wrapper debugging
How to validate VAST XML for the practical decision tree between validator, tester, and inspector
VAST versions guide for version drift, VPAID removal, and CTV addendum context
IAB VAST validator guide for where pure spec compliance stops and platform behavior starts
VAST-2.0-wrapper-depth for one of the most common delivery blockers in wrapped tags
VAST-2.0-mediafile-https for the portability and CTV playback risk of insecure media URLs
Rule derivation methodology if you want to see how the validation rules are grounded in specs and standards

The bigger market implication

The ad ecosystem has spent years building better fraud controls around identifiers that were never as stable as people wanted them to be.

IPv6 makes that harder to ignore.

It forces a more honest model of what a network signal is.

It is evidence.

It is context.

It is sometimes a strong clue.

It is not identity by default.

That matters because the market does not only pay for fraud that gets through. It also pays for misclassification, suppressed reach, broken partner trust, and slow dispute cycles caused by bad assumptions.

So the real business question is no longer just, "Can this IP be flagged?"

It is, "What happens to revenue, delivery, trust, and reconciliation when we act on that signal?"

That is the right question for CTV.

And increasingly, it is the right question for the broader ad ecosystem too.

Sources

Pixalate, AdFraud IOC-DB - IPv6 Addresses, May 2026 workbook reviewed from the IOC database export
RFC 8981, Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6, https://www.rfc-editor.org/rfc/rfc8981

Source note

The IPv6 IOC workbook reflects Pixalate's published watchlist data and disclaimer language for internal operational use. It is useful as an indicator set, not as a standalone market estimate or a definitive claim about any ISP, subscriber, or platform.

How vastlint's Validation Rules Were Extracted from the VAST PDF Specs and XSD Schemas

Aleksander Sekowski — Fri, 01 May 2026 15:39:18 +0000

The IAB Tech Lab publishes VAST as two artifacts: a PDF specification document and a set of XSD schema files. The PDF is the normative authority. It defines what a conformant VAST response must, should, and may contain. The XSD describes the document structure in machine-readable form but has gaps; it does not cover business logic, ordering constraints, or anything involving URLs. Building a linter against VAST meant reading both and treating them as complementary sources of truth, not interchangeable ones.

The PDF extraction was manual and slow. Each version of the spec (2.0, 3.0, 4.0, 4.1, 4.2, 4.3) was read cover to cover and every normative statement was tagged by element, attribute, and constraint type. A rule like "InLine must contain AdTitle" comes directly from section language in the 2.0 spec that predates all subsequent versions and has never been relaxed. Deprecations were tracked version by version: conditionalAd deprecated in 4.1, Survey deprecated in 4.1, the fullscreen/exitFullscreen tracking events removed in 4.0. Each one becomes a versioned rule rather than a blanket error, so a VAST 3.0 document is not penalised for things that only matter in 4.x.

The XSD pass was more systematic. The schemas enumerate valid attribute values, allowed child elements, and content models for every element across spec versions. These became structural rules: unknown attributes, unknown child elements, invalid enum values for things like delivery, adType, renderingMode, and tracking event names. A third category of rules does not come from either the PDF or the XSD. It comes from what goes wrong in production. HTTPS enforcement on MediaFile and tracking URLs, duplicate Impression URLs causing billing disputes, missing quartile tracking events, the VPAID-in-CTV footgun: these are rules sourced from patterns that show up repeatedly in real VAST traffic. The source tag on each rule (VastSpec, VastXsd, IndustryBestPractice, Inferred, etc.) reflects exactly where it came from.

The full rule set is listed below. Each rule ID links to its dedicated page on vastlint.org with the exact spec section, severity, fix guidance, and examples.

Rule ID	Description	Source
VAST-2.0-root-element	Root element must be `<VAST>`	VAST Spec
VAST-2.0-root-version	`<VAST>` must have a version attribute	VAST Spec
VAST-2.0-root-version-value	VAST version attribute must be a recognised version string	VAST XSD
VAST-2.0-root-has-ad-or-error	`<VAST>` must contain at least one `<Ad>` or `<Error>`	VAST Spec
VAST-4.0-wrapper-root-error	`<VAST>` root contains both `<Ad>` and `<Error>` elements (invalid per VAST 4.0)	VAST Spec
VAST-2.0-ad-has-inline-or-wrapper	Each `<Ad>` must contain exactly one `<InLine>` or `<Wrapper>`	VAST Spec
VAST-2.0-inline-adsystem	`<InLine>` must contain `<AdSystem>`	VAST Spec
VAST-2.0-inline-adtitle	`<InLine>` must contain `<AdTitle>`	VAST Spec
VAST-2.0-inline-impression	`<InLine>` must contain at least one `<Impression>`	VAST Spec
VAST-2.0-inline-creatives	`<InLine>` must contain `<Creatives>` with at least one `<Creative>`	VAST Spec
VAST-4.1-adservingid-present	`<InLine>` must contain `<AdServingId>` (VAST 4.1+)	VAST Spec
VAST-4.0-universaladid-present	`<Creative>` must contain `<UniversalAdId>` (VAST 4.0+)	VAST Spec
VAST-4.0-universaladid-idregistry	`<UniversalAdId>` must have an idRegistry attribute	VAST Spec
VAST-4.0-universaladid-idvalue	`<UniversalAdId>` missing required idValue attribute (VAST 4.0)	VAST Spec
VAST-4.1-universaladid-idvalue-removed	`<UniversalAdId>` idValue attribute was removed in VAST 4.1	VAST Spec
VAST-4.1-universaladid-content	`<UniversalAdId>` must have text content in VAST 4.1+	VAST Spec
VAST-2.0-linear-duration	`<Linear>` must contain `<Duration>`	VAST Spec
VAST-2.0-linear-mediafiles	`<Linear>` must contain `<MediaFiles>` with at least one `<MediaFile>`	VAST Spec
VAST-2.0-mediafile-delivery	`<MediaFile>` must have a delivery attribute	VAST Spec
VAST-2.0-mediafile-delivery-enum	`<MediaFile>` delivery must be "progressive" or "streaming"	VAST XSD
VAST-2.0-mediafile-type	`<MediaFile>` must have a type attribute	VAST Spec
VAST-2.0-mediafile-dimensions	`<MediaFile>` must have width and height attributes	VAST Spec
VAST-2.0-wrapper-adsystem	`<Wrapper>` must contain `<AdSystem>`	VAST Spec
VAST-2.0-wrapper-impression	`<Wrapper>` must contain at least one `<Impression>`	VAST Spec
VAST-2.0-wrapper-vastadtaguri	`<Wrapper>` must contain `<VASTAdTagURI>`	VAST Spec
VAST-2.0-companion-resource	`<Companion>` must contain at least one StaticResource, IFrameResource, or HTMLResource	VAST Spec
VAST-2.0-nonlinear-resource	InLine `<NonLinear>` must contain at least one StaticResource, IFrameResource, or HTMLResource	VAST Spec
VAST-2.0-wrapper-depth	Wrapper chain depth exceeds the configured maximum	VAST Spec
VAST-2.0-ad-sequence	Mixed use of sequence attribute across `<Ad>` elements in a pod	VAST Spec
VAST-2.0-duration-format	`<Duration>` value does not match HH:MM:SS[.mmm] format	VAST Spec
VAST-2.0-text-only-element	Text-only element contains a child element	VAST XSD
VAST-2.0-unknown-attribute	Element has an attribute not defined in the VAST spec	VAST XSD
VAST-2.0-inline-unknown-child	`<InLine>` contains an unrecognised child element	VAST XSD
VAST-2.0-wrapper-unknown-child	`<Wrapper>` contains an unrecognised child element	VAST XSD
VAST-2.0-creatives-unknown-child	`<Creatives>` may only contain `<Creative>` elements	VAST XSD
VAST-2.0-creative-unknown-child	`<Creative>` contains an unrecognised child element	VAST XSD
VAST-2.0-linear-unknown-child	`<Linear>` contains an unrecognised child element	VAST XSD
VAST-2.0-trackingevents-unknown-child	`<TrackingEvents>` may only contain `<Tracking>` elements	VAST XSD
VAST-2.0-mediafiles-unknown-child	`<MediaFiles>` contains an unrecognised child element	VAST XSD
VAST-2.0-extensions-unknown-child	`<Extensions>` may only contain `<Extension>` elements	VAST XSD
VAST-2.0-videoclicks-unknown-child	`<VideoClicks>` contains an unrecognised child element	VAST XSD
VAST-2.0-nonlinearads-unknown-child	`<NonLinearAds>` contains an unrecognised child element	VAST XSD
VAST-2.0-nonlinear-unknown-child	`<NonLinear>` contains an unrecognised child element	VAST XSD
VAST-2.0-companionads-unknown-child	`<CompanionAds>` may only contain `<Companion>` elements	VAST XSD
VAST-2.0-companion-unknown-child	`<Companion>` contains an unrecognised child element	VAST XSD
VAST-2.0-creativeextensions-unknown-child	`<CreativeExtensions>` may only contain `<CreativeExtension>` elements	VAST XSD
VAST-2.0-extension-misplaced-element	`<Extension>` contains an element that has a dedicated location in the VAST spec	VAST Spec
VAST-2.0-creative-extension-misplaced-element	`<CreativeExtension>` contains an element that has a dedicated location in the VAST spec	VAST Spec
VAST-2.0-mediafile-https	`<MediaFile>` URL uses HTTP instead of HTTPS, blocked by mixed-content policy on secure inventory	Industry Best Practice
VAST-2.0-tracking-https	Tracking or click URL uses HTTP instead of HTTPS, blocked by mixed-content policy, measurement signal lost	Industry Best Practice
VAST-2.0-url-empty	URL field is empty	VAST Spec
VAST-2.0-url-invalid	URL field does not appear to be a valid URI	RFC 3986
VAST-2.0-parse-error	XML parse error, document may be malformed	XML
VAST-2.0-version-mismatch	Declared version does not match structural signals	Inferred
VAST-2.0-duplicate-impression	Duplicate `<Impression>` URL within the same `<Ad>`, causes double-counted billing and disputes	Industry Best Practice
VAST-2.0-nonlinear-dimensions	`<NonLinear>` missing width or height	VAST Spec
VAST-2.0-companion-dimensions	`<Companion>` missing width or height	VAST Spec
VAST-2.0-flash-mediafile	Flash-based MediaFile type is no longer supported	Inferred
VAST-2.0-linear-tracking-quartiles	`<Linear>` has no standard quartile tracking events, impression serves but measurement system receives no signal	Industry Best Practice
VAST-3.0-icons-unknown-child	`<Icons>` may only contain `<Icon>` elements	VAST XSD
VAST-3.0-icon-unknown-child	`<Icon>` contains an unrecognised child element	VAST XSD
VAST-3.0-iconclicks-unknown-child	`<IconClicks>` contains an unrecognised child element	VAST XSD
VAST-3.0-progress-offset	`<Tracking event="progress">` requires an offset attribute	VAST Spec
VAST-3.0-progress-offset-format	Tracking progress offset does not match required format	VAST Spec
VAST-3.0-icon-attrs	Icon missing recommended attributes (program/width/height/position)	VAST Spec
VAST-3.0-icon-program	`<Icon>` missing required program attribute	VAST Spec
VAST-3.0-icon-width	`<Icon>` missing required width attribute	VAST Spec
VAST-3.0-icon-height	`<Icon>` missing required height attribute	VAST Spec
VAST-3.0-icon-xposition	`<Icon>` missing required xPosition attribute	VAST Spec
VAST-3.0-icon-yposition	`<Icon>` missing required yPosition attribute	VAST Spec
VAST-3.0-icon-resource	`<Icon>` must have at least one resource element	VAST Spec
VAST-3.0-skipoffset-format	Linear skipoffset does not match HH:MM:SS[.mmm] or n% format	VAST Spec
VAST-3.0-skip-event-no-skipoffset	skip tracking event present but Linear has no skipoffset attribute	VAST Spec
VAST-3.0-minmaxbitrate-pair	`<MediaFile>` must have both minBitrate and maxBitrate or neither	VAST Spec
VAST-3.0-bitrate-conflict	`<MediaFile>` has both bitrate and minBitrate/maxBitrate	VAST Spec
VAST-3.0-pricing-model	`<Pricing>` missing required model attribute	VAST Spec
VAST-3.0-pricing-currency	`<Pricing>` missing required currency attribute	VAST Spec
VAST-3.0-pricing-model-case	`<Pricing>` model value should be lowercase in VAST 3.0 (cpm/cpc/cpe/cpv)	VAST XSD
VAST-3.0-pricing-currency-format	`<Pricing>` currency attribute must be a 3-letter ISO-4217 code	ISO 4217
VAST-3.0-companion-required-attr	`<CompanionAds>` required attribute must be all, any, or none	VAST XSD
VAST-4.0-conditionalad	conditionalAd attribute is deprecated as of VAST 4.1	VAST Spec
VAST-4.0-wrapper-clickthrough	`<ClickThrough>` inside Wrapper `<VideoClicks>` was removed in VAST 4.0 (re-allowed in 4.2)	VAST Spec
VAST-4.0-tracking-event-removed	fullscreen/exitFullscreen tracking events were removed in VAST 4.0	VAST Spec
VAST-4.0-mediafile-apiframework	`<MediaFile apiFramework>` is deprecated in VAST 4.0+, use `<InteractiveCreativeFile>`	VAST Spec
VAST-4.0-category-authority	`<Category>` missing required authority attribute	VAST Spec
VAST-4.0-companion-clicktracking-id	`<CompanionClickTracking>` missing required id attribute	VAST Spec
VAST-4.0-interactive-creative-no-api	`<InteractiveCreativeFile>` should have an apiFramework attribute	VAST Spec
VAST-4.1-adservingid-present	`<InLine>` must contain `<AdServingId>` (VAST 4.1+)	VAST Spec
VAST-4.1-ad-serving-id-empty	`<AdServingId>` is present but empty	Inferred
VAST-4.1-survey-deprecated	`<Survey>` is deprecated as of VAST 4.1	VAST Spec
VAST-4.1-vpaid-apiframework	apiFramework="VPAID" is deprecated as of VAST 4.1	VAST Spec
VAST-4.1-mezzanine-delivery	`<Mezzanine>` missing required delivery attribute	VAST Spec
VAST-4.1-mezzanine-type	`<Mezzanine>` missing required type attribute	VAST Spec
VAST-4.1-mezzanine-width	`<Mezzanine>` missing required width attribute	VAST Spec
VAST-4.1-mezzanine-height	`<Mezzanine>` missing required height attribute	VAST Spec
VAST-4.1-mezzanine-recommended	`<MediaFiles>` has no `<Mezzanine>`, ad-stitching servers may reject in CTV/SSAI contexts	Industry Best Practice
VAST-4.1-verification-no-resource	`<Verification>` should have JavaScriptResource or ExecutableResource	VAST Spec
VAST-4.1-verification-vendor	`<Verification>` is missing required vendor attribute	VAST Spec
VAST-4.1-blockedadcategories-no-authority	`<BlockedAdCategories>` should have authority attribute	VAST Spec
VAST-4.1-interactive-creative-type	`<InteractiveCreativeFile>` should have a type attribute identifying the MIME type	IANA Media Types
VAST-4.1-js-resource-apiframework	`<JavaScriptResource>` is missing required apiFramework attribute	VAST Spec
VAST-4.1-exec-resource-apiframework	`<ExecutableResource>` is missing required apiFramework attribute	VAST Spec
VAST-4.1-exec-resource-type	`<ExecutableResource>` is missing required type attribute	VAST Spec
VAST-4.1-tracking-event-value	Tracking event attribute not in the valid set for this VAST version	VAST XSD
VAST-4.1-adtype-value	Ad adType must be video, audio, or hybrid	VAST XSD
VAST-4.1-companion-renderingmode-value	Companion renderingMode must be default, end-card, or concurrent	VAST XSD
VAST-4.1-vpaid-in-interactive-context	VPAID MediaFile alongside InteractiveCreativeFile, VPAID unsupported in CTV, zero fill	Industry Best Practice
VAST-4.2-closedcaptionfiles-unknown-child	`<ClosedCaptionFiles>` may only contain `<ClosedCaptionFile>` elements	VAST XSD
VAST-4.2-icon-fallback-image-width-height	`<IconClickFallbackImage>` should have width and height attributes	VAST Spec
VAST-4.3-js-resource-browser-optional	`<JavaScriptResource>` should have a browserOptional attribute	VAST Spec
SIMID-1.0-simid-type-required	`<InteractiveCreativeFile apiFramework="SIMID">` must have type="text/html"	SIMID Spec
SIMID-1.0-simid-url-empty	`<InteractiveCreativeFile apiFramework="SIMID">` must contain a non-empty URL	SIMID Spec
SIMID-1.0-simid-url-https	`<InteractiveCreativeFile apiFramework="SIMID">` URL must use HTTPS	SIMID Spec
SIMID-1.0-simid-variable-duration-value	`<InteractiveCreativeFile>` variableDuration attribute must be "true" when present	SIMID Spec
SIMID-1.0-simid-mediafile-required	Linear SIMID ad must include a video/audio `<MediaFile>` alongside the interactive creative	SIMID Spec
SIMID-1.1-nonlinear-simid-no-iframe	`<NonLinear apiFramework="SIMID">` must contain an `<IFrameResource>`	SIMID Spec
SIMID-1.1-iframe-simid-type-required	`<IFrameResource>` in SIMID `<NonLinear>` should have type="text/html"	SIMID Spec
SIMID-1.1-iframe-simid-url-empty	`<IFrameResource>` in SIMID `<NonLinear>` must contain a non-empty URL	SIMID Spec
SIMID-1.1-iframe-simid-url-https	`<IFrameResource>` in SIMID `<NonLinear>` URL must use HTTPS	SIMID Spec

I Built a VS Code Extension That Validates VAST XML as You Type

Aleksander Sekowski — Mon, 20 Apr 2026 04:13:48 +0000

If you work in ad tech you've probably seen VAST XML. It's the IAB standard that carries every video and CTV ad impression: the tag that tells a player what to show, where to fire tracking pixels, and how to handle wrappers. $30B+ in annual US ad spend runs through it.

It's also surprisingly easy to ship a broken one. The spec is six versions deep (2.0 through 4.3), touches several other standards (XML, RFC 3986, IANA media types, ISO 4217), and the tooling for validating it has historically been: read the PDF, or find out from your partner's discrepancy report.

So I built vastlint, an open-source VAST linter with 108 rules written in Rust. Last week I shipped the VS Code extension.

What it does

Install it from the VS Code Marketplace. Open any .xml file that contains a VAST tag.

You get squiggles on the exact element or attribute that violates the spec, hover tooltips with the rule ID and the fix, and Problems panel integration with file path and line number. VAST version is auto-detected. No config, no CLI, no external service. The validator runs entirely in-process via WebAssembly.

What it actually catches

Here's a broken tag in the editor. This one is missing on the element, a required field since VAST 2.0 that's easy to drop when templating:

<Linear>
  <!-- Duration is required — VAST-2.0-linear-duration -->
  <MediaFiles>
    <MediaFile delivery="progressive" type="video/mp4" width="640" height="360">
      <![CDATA[https://example.com/video.mp4]]>
    </MediaFile>
  </MediaFiles>
</Linear>

The squiggle lands on . Hovering shows:

VAST-2.0-linear-duration · Error
<Linear> is missing required <Duration>
IAB VAST 2.0 §3.7.2

Other rules are less obvious than a missing required element:

VAST-2.0-mediafile-https: HTTP URL on HTTPS inventory (mixed-content, ad won't play)
VAST-2.0-duration-format: is 00:30 instead of 00:00:30 (strict players reject this, others misfire tracking events at the wrong times)
VAST-4.1-mezzanine-recommended: no on a 4.1 tag (SSAI platforms reject these for CTV)
VAST-4.1-vpaid-apiframework: VPAID apiFramework in a 4.1 tag (deprecated, Roku and Fire TV skip it)
VAST-2.0-duplicate-impression: same impression URL appears twice (both sides double-count, neither report is technically wrong, they just never match)

The core library is vastlint-core on crates.io, a pure Rust library with no external dependencies. The VS Code extension loads it as a WebAssembly module so validation runs locally with no network calls.

string in -> parse XML -> detect VAST version -> run rule set -> issues out

Typical validation time on a real-world CTV tag is under 100 microseconds. The WASM overhead adds a bit in the editor context but it's imperceptible while typing.

The same core powers a CLI (cargo install vastlint), a REST API on RapidAPI, an MCP server for Claude/Cursor/Windsurf, and the online validator at vastlint.org.

Per-rule configuration

Not every rule applies to every context. Mezzanine is noise for browser-only inventory but critical for Roku. You can tune per-rule in settings.json:

{
  "vastlint.rules": {
    "VAST-4.1-mezzanine-recommended": "error",
    "VAST-2.0-mediafile-https": "error",
    "VAST-4.1-vpaid-apiframework": "error"
  }
}

Valid levels: "error", "warning", "info", "off".

Why I built it

I ran into this problem at work. The available tooling was either proprietary, behind a paywall, or only checked structure against the XSD. The spec is public. The failure modes are documented. There was no good reason an open-source implementation didn't exist.

The other thing: these errors get caught way too late. A malformed tag makes it through QA, gets sent to the partner, fails on their platform, and shows up three weeks later in a discrepancy report. The campaign has already run, the impressions are gone. Catching it in the editor before the file leaves your machine is the right fix.

Try it

The 10 VAST Errors That Silently Kill Your CTV Ad Revenue

Aleksander Sekowski — Wed, 08 Apr 2026 01:35:58 +0000

Originally published on Medium.

Samsung TV Plus just crossed 100 million monthly active users. Netflix ended 2024 with 277.6 million subscribers worldwide, 70 million on its ad-supported tier. Amazon Prime Video had 230 million users. Roku reported 89.8 million active accounts in Q4 2024. The ad spend flowing through all of it: $33 billion in the US alone in 2024 runs on VAST XML.

Every impression, every pixel, every billing event depends on a tag being parsed correctly by players, ad servers, and measurement vendors that were built by different teams to different tolerances. Penthera found that 40% of VOD ads fail. Google Ad Manager flags any gap larger than 25% between impressions served and impressions counted as a sign of systemic VAST errors. Most of these failures trace back to a handful of tag-level mistakes that are trivially detectable before the ad ever reaches a player.

I built an open-source tool that catches all errors mentioned below: vastlint. 108 rules across VAST 2.0 through 4.3. Free, no account, runs in CI in about 100 microseconds per tag.

aleksUIX / vastlint

vastlint

A VAST XML validator. Checks ad tags against the IAB Tech Lab VAST specification so you don't have to read it. Over $30 billion in annual CTV and video ad spend flows through VAST XML, and malformed tags are one of the most common causes of lost impressions, broken tracking, and revenue discrepancies between platforms. There is no widely adopted open-source tool that validates VAST XML against the full IAB specification across all published versions.

Validates VAST documents against:

IAB Tech Lab VAST 2.0, 3.0, 4.0, 4.1, 4.2, and 4.3 -- structural rules derived from the published XSD schemas and spec prose
W3C XML 1.0 well-formedness (malformed documents are rejected before any spec rule runs)
RFC 3986 URI syntax (all URL fields)
IANA Media Types (MediaFile and resource MIME types)
ISO 4217 currency codes (Pricing elements)
Ad-ID registry format (UniversalAdId)

108 rules across required fields, schema validation, structural correctness…

View on GitHub

Here are the ten I see most often.

Missing attributes
delivery, type, width, height — all four are required. Leave one out and the player guesses. CTV devices don't guess well. A tag that plays fine in Chrome fails on Roku because the device won't infer the delivery method from context. The XML is valid. The spec is violated. The blank slot is yours.
HTTP media URLs on HTTPS inventory
A pointing at http:// gets blocked by mixed-content policies on any HTTPS page or app. The ad doesn't play, the impression doesn't fire, fill rate drops. The tag is valid XML. It's technically spec-compliant. It just won't work on most real inventory. This one is invisible to any validator that only checks structure.
Bad format
The spec requires HH:MM:SS or HH:MM:SS.mmm. Tags show up with 00:30, 30s, plain 30, or empty. Strict players reject the creative outright. Loose players guess wrong and fire progress events — firstQuartile, midpoint, complete — at the wrong times. Your reporting looks fine but the measurement is off.
No element
No URL means the ad plays but nobody gets paid. The DSP doesn't know it rendered, the SSP can't bill. Both sides pull discrepancy reports and argue. On wrapper chains it's worse. A missing impression at any level means that link in the transaction goes unrecorded. The outer wrapper fires, the inner wrapper doesn't, the numbers never reconcile.
Wrapper without
A with no redirect URL is a dead end. The slot goes unfilled, no error fires, the demand partner reports zero delivery. Usually happens when a template renders a wrapper variant but the URL variable is null or empty. At scale, that's thousands of lost impressions per minute with nothing in the logs pointing at the cause.
missing or malformed
Required on every since VAST 4.0. Needs an idRegistry attribute and a non-empty value. Without it, frequency capping and competitive separation break. The ad server can't tell two creatives apart, so it can't enforce exclusion rules between competing brands or cap a user who's already seen the ad five times. The ads still serve. The contracts you're supposed to be honoring don't.
VPAID apiFramework on VAST 4.1+ tags
VPAID was deprecated in VAST 4.1. Google, Amazon, and most major SSPs block VPAID execution entirely. Tags declaring apiFramework="VPAID" pass XML validation. They may even pass some linting tools that only check structure. They get filtered before reaching a screen. Fill rate craters and the root cause is a single attribute value that no one thought to check.
Tracking event typos
The spec defines a fixed set: creativeView, start, firstQuartile, midpoint, thirdQuartile, complete, and so on. Misspell one — Midpoint, mid_point, MidPoint — and no player fires it. The pixel silently never calls. VAST 4.0 also removed fullscreen and exitFullscreen. Tags copied from 3.0 templates still carry those events. They worked. They don't anymore.
Malformed XML
Unescaped &, unclosed elements, bad UTF-8. Common when tags are assembled by string concatenation instead of an XML library. Many ad servers have lenient parsers that silently fix this. CTV devices don't. You debug a blank slot for an afternoon and the problem is & instead of & in a click URL buried three wrappers deep.
Version declaration doesn't match content
The tag says but contains and , which are 4.x elements. The player applies 2.0 parsing rules and skips what it doesn't recognize. Happens constantly when templates are copied between projects without updating the version attribute. Everything looks fine in dev. In production the player is running a different code path than you think.

Every one of these is detectable before the tag reaches a player. None of them require a live ad server, a real device, or a debugging session.