DEV Community: Aleksander Sekowski

I ran the AdCP conformance suite against my own agent. It found eight bugs.

Aleksander Sekowski — Sun, 09 Aug 2026 16:09:01 +0000

Agentic advertising picked up a governance layer this year. PubMatic shipped one on AgenticOS: platform-wide constraints plus per-buyer policies, pre-approved creative and inventory libraries, human approval workflows with authenticated approvers, full audit logging, and drift detection that flags anomalous agent behaviour before it executes. For buyers on the Ad Context Protocol, it runs an independent check on transactions touching the platform, whichever agent initiated them.

Every one of those controls answers the same question: was this agent allowed to do that?

None of them answers a different one: is the thing it produced actually valid?

Budget caps, inventory allowlists, and geo constraints say nothing about whether the VAST document that ends up in the bid response has a valid Impression node, HTTPS media files, or a wrapper chain under the depth limit. Drift detection is anomaly detection over agent behaviour, not schema conformance. Policy governance and payload conformance are different layers, and the second one has been mostly empty.

I maintain vastlint, a VAST validator, and it exposes an AdCP governance surface: create content standards, calibrate creative against them before launch, validate that delivered creative met them. So I'd been quietly claiming to fill that gap.

Then I actually ran the conformance suite against it.

Declaration is not conformance

An AdCP agent declares what it supports in get_adcp_capabilities:

{
  "supported_protocols": ["governance"],
  "specialisms": ["content-standards"]
}

That's a claim, not a credential. The protocol treats it as one: declaring a protocol or specialism commits you to passing the matching storyboards. A storyboard is a scripted sequence of tool calls with a response-schema assertion on every step, plus cross-step invariants. The runner reads your declaration, selects the storyboards it obligates, and executes them against your live endpoint.

The whole thing ships as a CLI:

npx @adcp/sdk@latest storyboard run https://your-agent.example.com/mcp \
  --test-kit dist/compliance/3.1.1/test-kits/acme-outdoor.yaml

I expected a clean run. The tools worked. I'd tested them. I'd been using them.

Eight things it found

1. Unauthenticated calls returned HTTP 200. Protected tools answered an anonymous caller with a 200 carrying {"adcp_error": {"code": "REQUIRES_AUTH"}} in the body. There was even a comment explaining why, so runners could branch on the error code instead of treating it as a protocol failure. The security baseline is explicit that anything other than 401 or 403 is non-conformant, and 401 has to carry WWW-Authenticate. My reasoning had been confidently backwards, in writing, for months.

2. The creative library was readable anonymously. list_creatives was excluded from the protected set because it always returned an empty collection, so what was the harm. The spec designates it the default probe target for exactly this test. It was the one endpoint guaranteed to be checked.

3. A capability filter could violate its own schema. get_adcp_capabilities takes an optional protocols filter. Mine intersected it with what the agent supports, so filtering for something unsupported returned "supported_protocols": []. The response schema sets minItems: 1. The filter is meant to scope which capability blocks come back, not to narrow the declaration of what the agent implements.

4. No release-precision version anywhere. The protocol moved to MAJOR.MINOR version negotiation, with sellers advertising adcp.supported_versions and echoing adcp_version on each response. I emitted neither. Advisory at 3.1, required at 3.2, so this was a deadline I hadn't noticed.

5. A response shape that had drifted. list_creatives was missing the required query_summary and pagination.has_more, and returned two pagination fields the schema forbids. It had been valid once.

6. An enum hole that broke reads permanently. create_content_standards accepted a scope with any channel value. Store {"channels": ["video"]}, which is not in the AdCP channel enum, and every subsequent list_content_standards for that brand fails schema validation forever, because the bad value gets replayed on read. Write-side validation was missing, so one bad request poisoned a tenant. This one was found by accident: a record from an old test run was sitting in my local database and blocked the first run I attempted.

7. A table that grew without bound. Idempotency replay rows had a TTL that was only ever checked on read. Nothing deleted expired rows. Fine at my traffic, until I registered for a compliance heartbeat that mutates with a fresh idempotency key every hour, forever.

8. A plain GET that never terminated. This is my favourite. GET /mcp opened the legacy MCP HTTP+SSE stream: correct behaviour for that transport, 200 with text/event-stream, keepalive pings every 25 seconds, connection held open indefinitely. The conformance runner never touched it, because it POSTs over Streamable HTTP. The registry's capability crawler does issue a plain GET, and reads the response to completion. So it hung, timed out, and recorded the agent as offline while the compliance suite reported everything passing on the same URL. Two probes, two transports, opposite verdicts.

The fix was to serve SSE only to clients that actually negotiate it:

if (request.method === "GET") {
  const accept = request.headers.get("Accept") ?? "";
  if (accept.includes("text/event-stream")) {
    return handleMcpSse(request);
  }
  return mcpEndpointDescriptor(request);  // bounded JSON, ~100ms
}

What I take from this

Every one of these was invisible to me. Not hard to find, not subtle, invisible. My own tests passed because they tested the behaviour I'd implemented, against the shape I believed was correct. Six of the eight were failures of my belief about the spec, not failures of code against my intent. Tests you write yourself cannot catch that class of error, because the same misunderstanding authors both the code and the test.

That is the entire argument for machine-checkable conformance, and I've been making it in the abstract for a while. Making it about my own code is considerably more persuasive, mostly to me.

It generalises past this one agent. The advertising stack runs on specs that are enormous, widely implemented, and almost entirely unenforced. VAST, OpenRTB, adagents.json, brand.json: all of them documents people implement from, none of them documents anything checks you against, unless somebody builds the checker. Where a conformance suite exists, running it against a well-intentioned implementation still finds eight things. Where one doesn't exist, nobody finds anything, and everyone assumes it's fine.

The governance layer being built for agentic buying inherits that problem directly. You can enforce that an agent stayed inside its budget and its allowlist and still ship a creative that no player will render, because nothing in the policy layer parses the payload. Those are complementary jobs and only one of them is currently being built.

Running it yourself

If you operate an AdCP agent, the suite takes minutes:

# see what your declarations actually obligate you to
npx @adcp/sdk@latest storyboard show --specialism content-standards

# run it
npx @adcp/sdk@latest storyboard run <your-url> --test-kit <kit.yaml>

Two traps worth knowing. --test-kit is required for the security baseline to grade at all, and it's missing from the CLI's help output. Without it the auth phases skip silently and the storyboard fails with "no auth mechanism verified", which reads like an auth bug in your agent when nothing is wrong. And local runs need --allow-http, which stamps the result as not publishable, so anything you intend to cite has to come from an HTTPS endpoint.

After the eight fixes, vastlint passes 28 steps with 0 failures: Core Protocol 34 of 34 scenarios, Governance 8 of 8, on the AdCP 3.1.1 bundle. There's a longer writeup of how the grading works and what the content-standards specialism covers in the docs.

I'd genuinely like to know whether other people's agents fare better than mine did. My guess is that the ones nobody has graded are in roughly the same shape, and simply don't know it yet.

Validate OpenRTB Bid Requests in CI With ajv and a Schema You Did Not Have to Write

Aleksander Sekowski — Sun, 09 Aug 2026 08:18:38 +0000

OpenRTB is a JSON protocol with no official JSON Schema. The IAB publishes the specification as prose and tables, plus a protobuf definition, and that is it. If you want to validate a bid request structurally, you write the schema yourself.

So most teams have a partial one. It covers the objects they touch, it was correct against whichever version was current when someone wrote it, and it silently accepts everything it does not know about. It works right up until a partner sends a field type you never modelled.

I generate these from the spec as part of building an OpenRTB linter, and they are published as static files. You can use them without the linter, without Rust, and without me.

What is there

Thirty-four schemas, request and response, across seventeen versions:

2.0  2.1  2.2  2.3  2.3.1  2.4  2.5
2.6-202210  2.6-202211  2.6-202303  2.6-202309  2.6-202402
2.6-202409  2.6-202501  2.6-202505  2.6-202606
3.0

Each one is JSON Schema draft 2020-12 with a resolvable $id:

$ curl -s https://rtblint.org/schemas/openrtb-2.6-202606-bid-request.schema.json | jq '{$schema, $id, title, required}'
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://rtblint.org/schemas/openrtb-2.6-202606-bid-request.schema.json",
  "title": "OpenRTB bid request (2.6-202606)",
  "required": ["id", "imp"]
}

32 named definitions in that one (App, Audio, Banner, Channel, Content, DOOH, Data, Deal, Device, DurFloors, and so on), so you can $ref individual objects rather than pulling the whole request in.

The version matters more than you might expect. OpenRTB 2.6 ships as dated snapshots that add and occasionally rename fields, so "2.6" alone does not pin a field set. The schemas are per snapshot for that reason.

With ajv

Nothing special required. Point ajv at it and go:

import Ajv from 'ajv/dist/2020.js';

const schema = await (
  await fetch('https://rtblint.org/schemas/openrtb-2.6-202606-bid-request.schema.json')
).json();

const ajv = new Ajv({ strict: false, allErrors: true });
const validate = ajv.compile(schema);

const req = {
  id: '1',
  imp: [{ id: '1', banner: { w: '300', h: 250 } }],
  site: { id: 's' },
  at: '1',
};

console.log(validate(req));
for (const e of validate.errors ?? []) console.log(e.instancePath, e.message);

false
/at must be integer
/imp/0/banner/w must be integer

Both of those are the classic OpenRTB failure: a numeric field arriving as a string. It is the single most common type error in real bid traffic, it is invisible to a lenient parser, and any partner enforcing the type drops you from the auction without telling you why.

Use strict: false. The schemas use constructs ajv's strict mode complains about, and the complaints are about the schema's style rather than its correctness.

Vendor the file rather than fetching it at runtime if this is on a hot path. It is 43 KB and it does not change unless you change versions.

In CI without writing any JavaScript

If all you want is a check on fixture files, check-jsonschema is a single step:

- run: pipx install check-jsonschema
- run: |
    check-jsonschema \
      --schemafile https://rtblint.org/schemas/openrtb-2.6-202606-bid-request.schema.json \
      fixtures/requests/*.json

That catches drift in your own test fixtures, which is worth more than it sounds. Fixtures rot: someone hand-edits one to reproduce a bug, gets the type wrong, and the fixture now encodes an invalid request that your tests happily assert against forever.

What a schema cannot do

Being straight about the ceiling here, because pointing a schema at OpenRTB and declaring the problem solved is how you end up with the partial-schema situation again.

A schema checks one document's structure. It does not check:

Cross-field rules. site, app and dooh are mutually exclusive. A schema can express that with oneOf, awkwardly, but most of these rules are conditional in ways that get unreadable fast.

Cross-document rules. Whether a bid response's impid matches an imp in the request that produced it. The other document is not in scope, so it is unreachable in principle.

Enum membership across 500-plus documented values. Technically expressible, genuinely unpleasant to maintain by hand, and this is where AdCOM lists and vendor ranges live.

Deprecation and version drift. A field can be structurally perfect and removed three snapshots ago. Schemas say valid or invalid, not "valid but you should stop."

String contents. bid.adm is typed string, so a schema is finished with it. Whether the string contains the markup type that bid.mtype declares, or whether it got JSON-encoded twice on the way through your stack, is beyond the type system.

Those are the checks rtblint exists for, and it is the same catalog underneath, so the schema and the linter agree about what a version contains:

$ cargo install rtblint
$ rtblint validate --version 2.6-202606 request.json

The rules reference lists every check with its id and severity, and there is a browser tester if you would rather paste one payload than install anything.

Take the schemas

They are static files under rtblint.org/schemas/, no key and no rate limit. Use them in whatever validator you already have. If you find a field the spec has and the schema does not, that is a bug worth reporting, since both come out of the same extraction and a gap in one is usually a gap in both.

OpenRTB 2.6 Spelled a Device Field 'didshal' for Six Months. Which Snapshot Are You Validating Against?

Aleksander Sekowski — Sun, 09 Aug 2026 08:17:27 +0000

Most people treat "OpenRTB 2.6" as a version number. It is closer to a release train. Since 2022 the IAB has published dated snapshots of 2.6, each one adding fields, and occasionally fixing the previous one.

Here is what that looks like as field-level drift across the snapshots, diffed from the generated schemas:

2.6-202210 -> 2.6-202211:  +10 -0
   added:   dooh, dt, gpp, gpp_sid, inventorypartnerdomain, multiplier,
            qty, sourcetype, venuetype, venuetypetax
2.6-202303 -> 2.6-202309:  +13 -3
   added:   acat, count, didsha1, dpidsha1, durfloors, guar, maxdur,
            mindur, minint, plcmt, refresh, refsettings, reftype
   removed: didshal, dpidshal, kwarry
2.6-202309 -> 2.6-202402:  +1 -0
   added:   poddedupe
2.6-202409 -> 2.6-202501:  +3 -0
   added:   inserter, matcher, mm
2.6-202501 -> 2.6-202505:  +3 -0
   added:   cids, genres, gtax
2.6-202505 -> 2.6-202606:  +2 -0
   added:   firstbroadcast, realtime

That November 2022 row is a real feature release: dooh brought digital out-of-home into 2.6, and gpp / gpp_sid brought the Global Privacy Platform. Fine, expected, that is what version numbers are for.

Now look at the removals in the second row. didshal, dpidshal, kwarry. Those are not deprecated features. They are typos in the specification that were live for two snapshots and then corrected.

The typos

From the March 2023 snapshot of the OpenRTB 2.6 spec, in the Device object table:

<td><code>didshal</code></td>
<td>string; DEPRECATED</td>
<td>Hardware device ID (e.g., IMEI); hashed via SHA1.</td>

The description says SHA1. The field name ends in a lowercase L. It should be didsha1, and the same slip hit dpidshal. Two fields, one wrong character each, in the canonical table that implementers read to build their bidders.

The other one is subtler because the correct spelling was in the same document:

<!-- in the Site object -->
<td><code>kwarray</code></td>
<td>Array of keywords about the site.</td>

<!-- in the Content object, same document -->
<td><code>kwarry</code></td>
<td>Array of keywords about the site.</td>

kwarray under Site and App, kwarry under Content, with the Content entry also carrying the copy-pasted "about the site" description. Both spellings live in the March 2023 snapshot at once.

All three were fixed in the September 2023 snapshot. The current spec has didsha1 and kwarray and no trace of the others:

$ curl -s https://raw.githubusercontent.com/InteractiveAdvertisingBureau/openrtb2.x/main/2.6.md \
  | grep -c 'didshal\|kwarry'
0

Why this is not just trivia

Consider what a validator built against the March 2023 snapshot does when a real bidder sends the field everyone actually implemented:

{ "device": { "didsha1": "5f4dcc3b5aa765d61d8327deb882cf99" } }

It rejects it as an unknown field, because in that snapshot the field is called didshal. And it accepts didshal, which nothing in production sends.

That is not a thought experiment. Same payload, two catalogs:

$ rtblint validate --version 2.6-202303 dev.json
FAILED (OpenRTB 2.6-202303 bid request): 1 error(s), 0 warning(s).
- [error] device.didsha1: Device.didsha1 is not defined in the canonical
  OpenRTB 2.6-202303 catalog. (openrtb.field.undefined) · spec 3.2.18

$ rtblint validate --version 2.6-202606 dev.json
OK with warnings (OpenRTB 2.6-202606 bid request): 1 warning(s).
- [warning] device.didsha1: device.didsha1 is deprecated in OpenRTB 2.6-202606.
  (openrtb.field.deprecated)

A hard error on the left, a correct deprecation notice on the right, for a field name that has been the real one all along.

The failure is inverted. Your validator is strictest about the thing it has wrong. Anyone shipping code from that snapshot got a validator that punishes correct behaviour, and because unknown-field handling is usually a warning rather than a hard failure, the signal is easy to tune out.

This generalises past the typos. Every one of those +N rows is a field that a bidder might send you and that an older catalog will call unknown. poddedupe arrived in February 2024. mm and inserter in January 2025. firstbroadcast and realtime in June 2026. If you validate a 2026 bid request against a 2023 catalog, you get a pile of unknown-field noise that is entirely your own tooling's fault, and the natural reaction is to disable unknown-field checking altogether, which is exactly the check you wanted.

Pin the snapshot deliberately

The fix is not "always use the newest." It is to make the version an explicit, visible choice rather than whatever your library happened to vendor.

rtblint is an OpenRTB linter I maintain, and it carries a separate extracted catalog per snapshot rather than one merged superset:

$ rtblint validate --version 2.6-202303 request.json   # what your partner implemented
$ rtblint validate --version 2.6-202606 request.json   # what the spec says today

Running both is the useful move. The diff between the two reports is your compatibility surface with that partner, expressed as a list rather than a guess.

It tracks 2.0, 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, nine dated 2.6 snapshots, and 3.0. One snapshot, 2.6-202204, says so out loud rather than silently passing payloads:

$ rtblint validate --version 2.6-202204 dev.json
FAILED: OpenRTB 2.6-202204 has no canonical BidRequest catalog in this build;
bid request validation is not supported for this version.
(openrtb.version.unsupported)

That is a deliberate choice. A validator that falls back to a neighbouring version when it does not have the right catalog is worse than one that refuses, because the first kind produces confident wrong answers and the second kind produces a bug report.

If you want to check your own stack

Two questions worth answering today, both cheap:

Which snapshot is your validator using? If the answer is "2.6" with no date, that is the finding. Something in your dependency tree picked a date for you.

Does it accept didsha1? A one-line test against a request containing that field tells you whether you are on a pre-September-2023 catalog:

$ echo '{"id":"1","imp":[{"id":"1","banner":{"w":300,"h":250}}],
  "site":{"id":"s"},"device":{"didsha1":"abc"}}' \
  | rtblint validate --stdin

The generated JSON Schemas are published per snapshot if you would rather diff them yourself, and the version reference lists what changed at each step.

The broader habit

Dated snapshots inside a version number are an unusual pattern, and tooling ecosystems handle them badly because most versioning assumes a single ordered sequence of releases. OpenRTB 2.6 has nine of them and counting, they are not semver, and nothing in a package.json will tell you which one your validator believes in.

Treat the snapshot date as part of the version. Write it down in the integration doc next to the endpoint URL. When a partner says "we support 2.6," the useful follow-up is "as of when."

Your Bid Response Is Valid JSON, Passes Its Schema, and Is Still Wrong

Aleksander Sekowski — Sun, 09 Aug 2026 08:16:16 +0000

Here is a bid response. It is well-formed JSON, every field has the right type, every required field is present, and it validates against the OpenRTB 2.6 bid response schema without complaint.

{
  "id": "req-1",
  "cur": "EUR",
  "seatbid": [{
    "seat": "dsp-9",
    "bid": [{
      "id": "b1",
      "impid": "99",
      "price": 2.5,
      "mtype": 1,
      "adm": "<VAST version=\"4.2\"><Ad/></VAST>",
      "dealid": "deal-does-not-exist"
    }]
  }]
}

Run it through a validator on its own:

$ rtblint validate --type response resp.json
OK (OpenRTB 2.6-202606 bid response): no issues found.

Now run the same file with the bid request that produced it:

$ rtblint validate --type response --request req.json resp.json
FAILED (OpenRTB 2.6-202606 bid response): 2 error(s), 0 warning(s).
- [error] cur: Response currency "EUR" is not among the currencies the request
  allows (USD). (openrtb.response.cur_not_allowed) · spec 4.2.1
- [error] seatbid[0].bid[0].impid: impid "99" does not match the id of any Imp
  in the bid request. (openrtb.bid.impid_unknown) · spec 4.2.3

Same bytes. Same schema. Two errors that will get this bid discarded by every exchange that checks, and no-bid by the rest.

Why the first run cannot find them

This is not a gap in the validator. It is a property of the data.

"impid": "99" is a string, which is what the spec requires. Nothing about the value "99" is malformed. Whether it is correct depends on the set of imp[].id values in a document the validator was not given. The same is true of cur: "EUR" is a valid ISO 4217 code, and whether it is allowed depends on the request's cur array.

A schema describes one document. These are relational facts spanning two. No amount of JSON Schema will express them, because the other side of the relation is not in scope.

That distinction is worth naming precisely, because it decides where you put your effort. Structural validity is a property of a document. Coherence is a property of an exchange. Most OpenRTB tooling only checks the first one, which is why most OpenRTB bugs are in the second.

The cross-document checks that matter

Given the request alongside the response, a validator can check things that are otherwise invisible:

impid resolves to a real imp. The single most common one. An off-by-one in imp indexing, a stale cached response, or a bidder that reuses ids across auctions all produce this, and all of them look fine in isolation.

cur is in the request's allowed list. The request advertises the currencies the exchange will settle in. Bidding outside that list is not a rounding problem, it is a discarded bid.

mtype matches what the imp offered. If the imp only carried a video object, a bid with mtype: 1 (banner) is bidding on inventory that does not exist in that slot.

dealid corresponds to a deal on that imp. A private deal id that the imp never listed will not clear at the deal price, and depending on the exchange may not clear at all.

seat is one the request permits, where the request constrains seats.

The middle two produce output like this, from a bid that declares banner markup against a video-only imp and cites a deal the imp never listed:

- [error] seatbid[0].bid[0].mtype: mtype 1 declares banner markup, but imp "1"
  does not offer a banner subtype. (openrtb.bid.mtype_not_offered) · spec 4.2.3
- [warning] seatbid[0].bid[0].dealid: dealid "nope" references a deal, but imp
  "1" carries no pmp object at all; verify the deal was arranged out of band.
  (openrtb.bid.dealid_unknown) · spec 4.2.3

Note the severities. An mtype the imp never offered is an error, because no reading of the request makes that bid servable. An unknown dealid is a warning, because deals genuinely do get arranged out of band and a validator that called that an error would be wrong often enough to get switched off.

What a single document can still tell you

Cross-validation is not the only thing missing from a plain schema check. Some incoherence lives entirely inside the response and is still beyond structural validation, because it requires interpreting a string field's contents.

adm is the obvious case. It is typed as a string, so a schema is done thinking about it the moment it confirms the type. But mtype declares what kind of markup that string is supposed to contain, and the two can disagree:

$ rtblint validate --type response resp3.json
FAILED (OpenRTB 2.6-202606 bid response): 2 error(s), 0 warning(s).
- [error] seatbid[0].bid[0].adm: mtype 4 declares native markup, but adm does not
  parse as a JSON object; a native response must be the JSON Native Markup
  Response. (openrtb.bid.adm.native_not_json) · spec 4.2.3
- [error] seatbid[0].bid[1].adm: mtype 2 declares video markup (VAST XML), but
  adm is a JSON payload. (openrtb.bid.adm.markup_type_mismatch) · spec 4.2.3

And the one that costs the most debugging time per occurrence, double encoding:

- [error] seatbid[0].bid[2].adm: adm parses to another JSON string rather than
  markup; it looks like the creative payload was JSON-encoded twice.
  (openrtb.bid.adm.double_encoded) · spec 4.2.3

Double encoding happens when a service serialises the creative, then a downstream service serialises the already-serialised string again. The result is a valid JSON string containing a valid JSON string, so every type check passes, and the player receives "{\"native\":...}" where it expected an object. It renders as nothing. There is no error anywhere in the chain.

Wiring it in

The reason to do this in CI rather than in a postmortem is that both documents are already sitting in your integration tests. You have a request fixture and an expected response fixture, and right now you are probably asserting on a handful of fields by hand.

$ cargo install rtblint

# one response against its request
$ rtblint validate --type response --request req.json resp.json

# many responses against one request, one JSON payload per stdin line
$ cat responses.jsonl | rtblint validate --batch --type response --request req.json

# machine-readable, for a CI annotation step
$ rtblint validate --type response --request req.json --format json resp.json

Exit codes are 0 for valid, 1 for validation errors, 2 for usage or I/O problems, so it drops into a pipeline without a wrapper script.

If you would rather look at one payload in a browser first, the OpenRTB tester takes a request and a response and shows the findings with JSON paths. The CLI docs cover the batch and version-pinning flags, and what rtblint checks is the full list if you want to know what you are getting before installing anything.

The point

Schema validation answers "is this a well-formed OpenRTB document." That is a real question and worth answering automatically. It is just a narrower question than "will this bid win, and will the creative render," and the gap between the two is where the revenue is.

If you are only validating responses in isolation, you are checking the half of the problem that rarely breaks.

VPAID Is Deprecated. Here Is How to Find Out How Much You Are Still Serving.

Aleksander Sekowski — Sun, 09 Aug 2026 08:11:02 +0000

VPAID has been deprecated since VAST 4.1. There will not be a VPAID 3.0. It cannot execute in server-side ad insertion, it cannot execute on connected TV, and the IAB has published two separate replacement standards for the two things it used to do.

None of that stops it from being in your tags. Deprecation is a statement about a specification. It has no effect on the XML your ad server emitted this morning.

So the useful question is not "should we move off VPAID," which was settled years ago. It is "how much of it are we still serving, and where is it costing us fill." That is answerable in an afternoon.

Why it stopped working, briefly

Four independent reasons, and they compound:

It runs in your page's JavaScript context. A VPAID unit has full access to the publisher's DOM, cookies and globals. That is not a sandbox with holes, it is the absence of a sandbox, and it was routinely used for exactly what you would expect.

SSAI has no JavaScript runtime. Server-side ad insertion stitches the ad into the media stream at the server. There is no browser there. VPAID cannot run in principle, not as an implementation gap.

CTV has no browser-compatible JavaScript runtime either. Smart TVs, sticks and set-top boxes use native media players. VPAID is not slow on CTV, it is non-executable. And CTV is where premium video budget went.

It costs latency on every impression that does work. Because the VPAID script controls media loading, the player cannot pre-cache the video. Every impression waits for the unit to initialise before anything can buffer.

The replacements split the job. SIMID handles interactivity in a sandboxed iframe talking over postMessage, so the player keeps control of the media. OMID handles verification and viewability. Neither one needs access to your page.

The four signatures

VPAID does not announce itself in one place, which is why audits miss it. There are four distinct patterns, and a tag can match some without the others.

1. The explicit declaration

<MediaFile delivery="progressive" type="application/javascript"
           apiFramework="VPAID" width="640" height="360">
  <![CDATA[https://cdn.example.com/vpaid-unit.js]]>
</MediaFile>

apiFramework="VPAID" is the honest case. Easy to grep, easy to count.

2. The JavaScript media file with no apiFramework

<MediaFile delivery="progressive" type="application/javascript">
  <![CDATA[https://cdn.example.com/unit.js]]>
</MediaFile>

A <MediaFile> whose type is application/javascript or application/x-javascript is a script, not a video, whatever it declares. Some ad servers omit apiFramework here, and a search that only looks for the string "VPAID" will miss every one of them.

Same for application/x-shockwave-flash, which you will still find in long-tail inventory and which has been unplayable in every browser since 2021.

3. VPAID sitting next to its own replacement

<MediaFiles>
  <MediaFile type="application/javascript" apiFramework="VPAID">...</MediaFile>
  <MediaFile type="video/mp4">...</MediaFile>
  <InteractiveCreativeFile type="text/html" apiFramework="SIMID">...</InteractiveCreativeFile>
</MediaFiles>

This is the most common shape in tags that have been half-migrated. Both the old and new interactive paths are present. On a player that supports SIMID it works fine. On one that prefers VPAID you are back to the original problem, and on CTV the VPAID entry is dead weight that some stitchers reject the whole tag over.

4. AdParameters with no interactive file

<AdParameters> exists to pass configuration into an interactive unit. A tag with <AdParameters> and no <InteractiveCreativeFile> is almost always feeding a VPAID creative, even if nothing else in the document says so.

Counting it

Grep gets you the first pass over a corpus of saved tags:

$ grep -rlE 'apiFramework="VPAID"|application/(x-)?javascript|x-shockwave-flash' tags/ | wc -l

That undercounts signature 4 and overcounts anything that mentions those strings in a tracking URL, so for a real number use a validator that understands the document structure. Running the half-migrated example above through vastlint:

$ vastlint check vpaid.xml
vpaid.xml  VAST 4.2
  warning  apiFramework="VPAID" is deprecated as of VAST 4.1, use SIMID or OMID instead
           VAST-4.1-vpaid-apiframework
           /VAST/Ad[0]/InLine/Creatives/Creative[0]/Linear/MediaFiles/MediaFile[0]:20:15
  warning  <MediaFile apiFramework="VPAID"> alongside <InteractiveCreativeFile>, VPAID is not
           supported in CTV and should be removed when SIMID/OMID is present
           VAST-4.1-vpaid-in-interactive-context
           /VAST/Ad[0]/InLine/Creatives/Creative[0]/Linear/MediaFiles/MediaFile[0]:20:15

✓ 0 errors, 2 warnings, 1 info

Note that both are warnings, not errors. A VPAID tag is still perfectly valid VAST. The schema has no opinion about deprecation, which is exactly why this survives in inventory: nothing in the validation path fails, so nothing forces the cleanup.

Over a directory, with JSON out so you can count by rule:

$ vastlint check --format json tags/*.xml \
  | jq -r '.issues[].id' | sort | uniq -c | sort -rn
   2 VAST-4.1-vpaid-in-interactive-context
   2 VAST-4.1-vpaid-apiframework
   2 VAST-4.1-mezzanine-recommended

(JSON mode emits one object per file, so jq reads it as a stream rather than an array.)

Install with cargo install vastlint, brew install aleksUIX/tap/vastlint, or a pre-built binary from the releases page. There is a WASM build on npm as vastlint if you would rather call it from Node than shell out.

What each signature costs

Not all of these are equally urgent, and treating them as one bucket is how audits stall.

Signature	CTV	SSAI	Desktop web	Priority
VPAID with no video fallback	No fill	No fill	Plays	Fix now
VPAID alongside an MP4	Falls back	Falls back	Plays VPAID	Fix soon
VPAID next to SIMID	Depends on player	Falls back	Ambiguous	Remove the VPAID entry
Flash media file	No fill	No fill	No fill	Delete

The first row is the one that is actually costing money right now. A creative whose only rendition is a VPAID script gets zero fill on the majority of premium video inventory, and because it is a no-bid rather than an error, it shows up in your reporting as absence rather than failure.

The third row is the cheapest fix in the table: the SIMID path already exists, so removing the VPAID <MediaFile> is a deletion, not a migration.

Doing the migration

The full path is documented here, and the VPAID reference has the version history and the compatibility matrix by VAST version. Compressed:

Interactivity moves to <InteractiveCreativeFile apiFramework="SIMID">.
Verification and viewability move to <AdVerifications> with OMID.
Anything you were tracking from inside the VPAID unit moves to <TrackingEvents>, which the player fires and which works in SSAI.
Every creative gets a real video <MediaFile>, so there is always something to play.
Declare the VAST version you are actually emitting.

Step 4 is the one to do first if you do nothing else. A native rendition alongside the VPAID unit turns a zero-fill creative into one that at least serves as video everywhere, and it does not require touching the interactive build at all.

The honest summary

VPAID is not going to stop working on a particular date. It stopped working in the environments that matter, gradually, over several years, and it will keep half-working on desktop web indefinitely. That is worse than a hard cutoff, because there is never a day when the problem becomes visible.

The signal to watch is not an error rate. It is fill on CTV and SSAI inventory for creatives that carry a script where a video should be. Count those first.

Playing VAST Ads in Video.js Without the Google IMA SDK

Aleksander Sekowski — Sun, 09 Aug 2026 08:10:00 +0000

The usual way to put ads in Video.js is videojs-ima, which wraps Google's IMA SDK. It works, it is well maintained, and for most people it is the right answer.

It is also a third-party runtime you do not control, loaded from imasdk.googleapis.com, that brings its own VAST parser, its own wrapper-following policy, its own error handling and its own opinions about VPAID. There are reasons to want out: bundle and network budget, environments where the SDK is blocked or unavailable, a need to control wrapper depth and timeouts yourself, or simply not wanting a Google dependency in the playback path.

This is what the do-it-yourself path involves. I am not going to pretend it is less work, because it is more. But the work is bounded and the pieces are legible, which is not always true of the alternative.

contrib-ads is a state machine, not an ad player

The first thing to get straight, and the project says it plainly in its own README:

videojs-contrib-ads is not a stand-alone ad plugin. It is a library that is used by other ad plugins in order to fully support video.js.

And from the integration docs, on startLinearAdMode:

During this time, your ad plugin plays ads. videojs-contrib-ads does not handle actual ad playback.

So contrib-ads handles the hard, boring, easy-to-get-wrong parts of being an ad plugin in Video.js: pausing content, showing the spinner, restoring player state after the break, timing out if ads take too long, and redispatching media events so the rest of your app does not see ad playback as content playback. That last one alone justifies using it.

What it does not do is fetch VAST, parse VAST, choose a rendition, or fire a tracking pixel. That is your half.

The control flow

Initialise contrib-ads in the same tick as the player. This is a real constraint, not a style preference. The plugin relies on loadstart and will emit an error if it missed one.

import videojs from 'video.js';
import 'videojs-contrib-ads';

const player = videojs('content_video', {
  controls: true,
  sources: [{ src: '/content.mp4', type: 'video/mp4' }],
});

player.ads(); // same tick as videojs(), not in a ready callback

The handshake is: you tell contrib-ads when your ad logic is initialised, it tells you when a break is due.

// You fetch and parse, then announce readiness.
loadVast(AD_TAG_URL).then((ad) => {
  currentAd = ad;
  player.trigger('adsready');
});

// contrib-ads fires this once both `play` and `adsready` have happened.
player.on('readyforpreroll', () => {
  if (!currentAd) return;

  player.ads.startLinearAdMode();
  player.src({ src: currentAd.mediaFile.url, type: currentAd.mediaFile.type });

  player.one('adplaying', () => {
    player.trigger('ads-ad-started'); // clears the loading spinner
    fire(currentAd.impressions);
  });

  player.one('adended', () => {
    player.ads.endLinearAdMode(); // content resumes
  });
});

readyforpostroll gives you the postroll slot. Midrolls you drive yourself off timeupdate, calling startLinearAdMode and endLinearAdMode around each break.

That is the whole integration surface. Everything else is VAST.

Parsing the tag

VAST is XML, so DOMParser gets you most of the way. The parts you need for linear playback:

async function loadVast(url, depth = 0) {
  if (depth > 3) throw new Error('wrapper limit');

  const xml = new DOMParser().parseFromString(
    await (await fetch(url)).text(),
    'text/xml'
  );

  // A wrapper points at another tag. Follow it, and keep its trackers.
  const next = xml.querySelector('Wrapper > VASTAdTagURI');
  if (next) {
    const inner = await loadVast(next.textContent.trim(), depth + 1);
    return merge(collectTrackers(xml), inner);
  }

  const linear = xml.querySelector('InLine Creative Linear');
  return {
    impressions: [...xml.querySelectorAll('InLine > Impression')]
      .map((n) => n.textContent.trim()),
    errors: [...xml.querySelectorAll('Error')].map((n) => n.textContent.trim()),
    duration: parseDuration(linear.querySelector('Duration').textContent),
    mediaFile: pickMediaFile([...linear.querySelectorAll('MediaFile')]),
    trackers: collectTrackers(xml),
  };
}

Four things about that which are easy to get wrong.

Wrapper trackers accumulate, they do not get replaced. Every hop in the chain contributes its own <Impression>, <Error> and <TrackingEvents>. If you follow a wrapper and keep only the inline document's pixels, you have silently dropped the SSP's and the DSP's tracking, which is the kind of bug that surfaces as a discrepancy meeting three weeks later.

You need a depth limit. Wrapper chains can loop. The IMA SDK defaults to 4 redirects. Pick a number and enforce it.

<Duration> is HH:MM:SS or HH:MM:SS.mmm, not seconds.

const parseDuration = (s) =>
  s.trim().split(':').reduce((acc, part) => acc * 60 + parseFloat(part), 0);

Everything is CDATA-wrapped and whitespace-padded. Always .trim(). A URL with a leading newline fails silently as an image request and you will not see it in the network tab without looking for it.

Picking a media file

<MediaFile> is repeated, and choosing badly is the most common cause of "the ad does not play on this device."

function pickMediaFile(files) {
  const playable = files
    .map((n) => ({
      url: n.textContent.trim(),
      type: n.getAttribute('type'),
      bitrate: +(n.getAttribute('bitrate') || 0),
      width: +(n.getAttribute('width') || 0),
      delivery: n.getAttribute('delivery'),
    }))
    .filter((f) => document.createElement('video').canPlayType(f.type));

  // Closest rendition at or below the player's width, then highest bitrate.
  const target = player.currentWidth();
  return playable
    .sort((a, b) => b.bitrate - a.bitrate)
    .find((f) => f.width <= target) ?? playable[0];
}

Filter on canPlayType before anything else. A tag will happily offer you video/x-flv and application/javascript alongside the MP4. That second one is a VPAID creative, which you do not want here and which is deprecated anyway.

Firing trackers at the right time

This is the part that separates a working integration from one that plays ads but reports nothing.

const QUARTILES = [
  ['start', 0],
  ['firstQuartile', 0.25],
  ['midpoint', 0.5],
  ['thirdQuartile', 0.75],
  ['complete', 1],
];

function attachTracking(player, ad) {
  const fired = new Set();

  const send = (event) => {
    if (fired.has(event)) return;
    fired.add(event);
    (ad.trackers[event] || []).forEach(beacon);
  };

  player.on('adplaying', () => send('creativeView'));

  player.on('timeupdate', () => {
    const pct = player.currentTime() / ad.duration;
    for (const [event, at] of QUARTILES) {
      if (pct >= at) send(event);
    }
  });
}

const beacon = (url) => {
  if (navigator.sendBeacon) navigator.sendBeacon(url);
  else new Image().src = url;
};

The fired set is not optional. timeupdate fires several times a second, and a quartile pixel that fires forty times is worse than one that never fires, because the first looks like fraud and the second looks like a bug.

Two more:

Use the ad's declared <Duration>, not the media element's. They disagree more often than you would expect, and when they do, the declared duration is what the buyer paid against.

Do not derive quartiles from player.duration() during an ad. Depending on how the source switch went, that may still be the content duration, which puts every quartile in the wrong place with no error anywhere.

Reporting errors back

VAST has an error reporting mechanism that almost nobody implements on the do-it-yourself path, and it is the one that makes your tag debuggable for the ad server that sent it.

function reportError(ad, code) {
  ad.errors.forEach((tpl) => beacon(tpl.replace('[ERRORCODE]', code)));
}

// no playable rendition after filtering
reportError(ad, 403);
// media file failed to load
player.one('aderror', () => reportError(ad, 405));

[ERRORCODE] is a macro the player substitutes. If you send the URL without substituting it, the ad server logs a literal [ERRORCODE] and learns nothing. The codes are a defined registry, and the wording is specific enough to be worth matching:

403 "Couldn't find MediaFile that is supported by this media player, based on the attributes of the MediaFile element." Your canPlayType filter emptied the list.
405 "Problem displaying MediaFile. Media player found a MediaFile with supported type but couldn't display it." You picked one and it failed anyway.
301 "Timeout of VAST URI provided in Wrapper element." Use this for wrapper hops that time out, not for wrapper documents that parse badly.

What you give up

Being straight about the tradeoff:

VPAID. Which is fine. It is deprecated as of VAST 4.1, blocked in most CTV environments, and not worth building an isolation boundary for in 2026.
VMAP ad rules. IMA can take a VMAP document and schedule the whole break structure for you. On this path you parse VMAP yourself or hardcode your break times.
Measurement integrations. OMID viewability, in particular, expects a certified integration. If you have OM SDK obligations, the DIY path is not a shortcut.
Someone else's compatibility matrix. IMA has been run against more devices than your code will be. That is a real asset and the main argument for staying with it.

Validate the tag before you debug the player

The failure mode I would flag hardest: when an ad does not play, the instinct is to instrument the player. Half the time the tag is malformed and no player would have played it. That is an especially easy trap here, because you wrote the parser, so you assume the parser is the suspect.

Check the tag first. I maintain vastlint, an open source VAST validator, largely because of this pattern. The tag tester takes a live ad tag URL, follows the wrapper chain, and shows you the resolved XML with the errors marked, which tells you in a few seconds whether you are debugging your code or someone else's tag.

If you would rather stay in your terminal, the CLI takes a URL directly and follows the wrapper chain for you:

$ cargo install vastlint
$ vastlint check "https://your-ad-server/vast?..."

The Video.js VAST guide covers the videojs-ima route in detail if you decide the DIY path is not worth it, including the plugin options that matter for wrapper depth and timeouts.

Worth it?

If you need VPAID, full VMAP scheduling, or certified viewability, use the IMA SDK. If you need a small, inspectable ad path with no third-party runtime, the code above is close to the whole shape of it. Roughly 200 lines for prerolls with tracking, and every one of them is yours to step through, which on the day something goes wrong is the entire point.

There Is No VAST 4.3 Schema, and the 4.4 Draft Accepts a Completely Empty Ad

Aleksander Sekowski — Sun, 09 Aug 2026 08:08:48 +0000

If you validate VAST tags, you probably assume there is a schema behind the version number. For 4.3 there is not, and for the 4.4 draft there is one that accepts an ad containing nothing at all.

Both are checkable in about thirty seconds. Neither is a hypothetical.

The 4.3 schema is one byte

IAB Tech Lab publishes VAST in a public repo, with schemas under schemas/. Ask the API what is in the 4.3 file:

$ curl -s https://api.github.com/repos/InteractiveAdvertisingBureau/vast/contents/schemas/vast_4.3.xsd \
  | jq '.size'
1

One byte. Pull it down and it is a single newline. The file was created, committed, and never filled in.

So when a tool says it validated your tag "against VAST 4.3," it did not mean against a 4.3 XSD, because none exists. In practice tools do one of three things: fall back to the 4.2 schema, check structure they encoded by hand from the specification PDF, or check nothing version-specific at all. All three are defensible. None of them is what most people picture.

This is worth knowing mostly because 4.3 is the current released version. The version people are told to target is the one with no machine-readable definition.

The 4.4 draft validates an empty wrapper

4.4 is a draft, and drafts are allowed to be rough. This one has a specific defect that is worth understanding because it is a good lesson in how XSD actually behaves.

Take the smallest wrapper ad you can write, one with no children whatsoever:

<?xml version="1.0" encoding="UTF-8"?>
<VAST xmlns="http://www.iab.com/VAST" version="4.4">
  <Ad id="empty">
    <Wrapper/>
  </Ad>
</VAST>

Against the 4.4 draft schema:

$ xmllint --noout --schema vast_4.4.xsd ew.xml
ew.xml validates

The same document, retargeted at 4.2:

$ xmllint --noout --schema vast_4.2.xsd ew42.xml
ew42.xml:4: element Wrapper: Schemas validity error : Element
'{http://www.iab.com/VAST}Wrapper': Missing child element(s).
Expected is ( {http://www.iab.com/VAST}AdSystem ).
ew42.xml fails to validate

A wrapper with no <AdSystem>, no <VASTAdTagURI>, no <Impression>. It has no ad server to attribute, nowhere to go next, and nothing to track. Under the draft schema it is a valid ad.

Why it happens

Here is the content model in the draft:

<xs:complexType name="vastWrapper_type">
  <xs:choice minOccurs="0" maxOccurs="unbounded">
    <xs:element name="AdSystem"     type="vastAdSystem_type"/>
    <xs:element name="VASTAdTagURI" type="vastURIElement_type"/>
    <xs:element name="Impression"   type="vastImpression_type"/>
    ...

xs:choice minOccurs="0" maxOccurs="unbounded" says: zero or more of any of these, in any order, any number of times. The per-element minOccurs and maxOccurs that would normally express "exactly one AdSystem, at least one Impression" are not there, and adding them would not help much, because a repeating choice group reasons about the group, not the branch.

So the model has thrown away three separate things at once: which children are required, how many of each are allowed, and what order they come in. <Wrapper/> satisfies it by taking the choice zero times. So does a wrapper with fourteen <VASTAdTagURI> elements.

The 4.2 schema does not have this problem because it uses xs:sequence with explicit occurrence constraints on each element, which is the ordinary way to say "one of these, then one or more of those."

The fix that looks right and is not

The instinct when you see an order-independent content model is to reach for xs:all. It exists precisely to say "all of these, in any order."

It does not work here, and it is worth knowing why before you suggest it to anyone.

In XSD 1.0, every particle inside xs:all is capped at maxOccurs="1". That is not a stylistic limit, it is in the language. VAST needs <Impression> to repeat, since a wrapper routinely carries several impression pixels from different parties. Model it with xs:all and the schema will reject the second <Impression>, turning a cardinality bug that is too loose into one that is too strict.

I suggested xs:all in the issue I filed, then tested it against libxml2 and had to retract it in a follow-up comment. The correct fix is the boring one: xs:sequence with real minOccurs and maxOccurs per element, which is what 4.2 already does and what the draft moved away from.

I filed this as issue #58 and opened PR #59 restoring required elements and ordering. Both are open at the time of writing. The patch is +22/-22 and keeps every IAB sample tag passing, which I checked by running the full sample set before and after.

The larger point about schema validation

Even a correct XSD would only get you part of the way, and this is the thing worth internalising if you are building tag QA.

A schema can express structure: which elements exist, how they nest, how many times, what type the text is. It cannot express most of what the VAST specification actually requires, because those requirements are conditional, cross-referential, or written in prose. A few examples:

apiFramework="VPAID" is deprecated as of VAST 4.1. Schema-legal, still a problem.
sequence on <Ad> is typed xs:integer, so sequence="0" and sequence="-1" validate. Nothing in the schema requires sequence values to be unique across a pod either, so two ads can claim the same slot.
A skipoffset larger than the creative's <Duration> is two valid fields that contradict each other.
An <Icon> positioned outside the player dimensions is arithmetic, not structure.
Wrapper chain depth limits are a runtime property of a document you have not fetched yet.

None of that is a schema's job. It means the schema check is a floor, not a ceiling, and "it validates" answers a narrower question than most people are asking when they say it.

This is why I ended up writing a linter rather than shipping an XSD. vastlint is open source, written in Rust, and its rules come from the specification prose as much as from the schemas, with each rule tracing back to the version and source it came from. The tradeoff is honest: rules extracted from prose require judgment and can be wrong, whereas a schema check cannot be wrong about the thing it checks. It just checks less than you need.

If you want to reproduce any of this

Everything above is one command each.

# the 4.3 placeholder
curl -s https://api.github.com/repos/InteractiveAdvertisingBureau/vast/contents/schemas/vast_4.3.xsd | jq .size

# the empty wrapper, against the draft schema
xmllint --noout --schema vast_4.4.xsd ew.xml

For the prose-level rules, the IAB VAST validator guide sets out what spec compliance covers and where platform-specific behaviour takes over, and the tag tester will fetch a live tag and follow its wrapper chain so you can see the resolved document rather than the one you started with.

To be clear about affiliation: vastlint is independent and not an IAB Tech Lab product. The issue and the PR above are ordinary contributions to a public repo, filed because the bug was easier to fix than to work around.

Your Ad Pod Lost Half Its Ads and the VAST Still Validates

Aleksander Sekowski — Sun, 09 Aug 2026 08:08:45 +0000

A publisher tells you the pre-roll break is 90 seconds and takes four ads. Your ad server builds a pod of four. Reporting shows two impressions. You pull the VAST response, run it through a validator, and it comes back clean.

Nothing is broken in the sense a validator understands. The document is well-formed, schema-valid, and complete. It just describes two ads instead of four, and there is nothing in the XML that says it was ever supposed to describe four.

VAST has no pod container

This is the part that surprises people who have only read about ad pods rather than parsed them.

An ad pod in VAST is not an element. There is no <AdPod>, no maxAds, no maxDuration. A pod is a convention: several sibling <Ad> elements under <VAST>, each carrying a sequence attribute.

You can check this yourself against the schemas IAB Tech Lab publishes:

$ grep -c 'AdPod\|maxAds\|maxDuration' vast_2.0.1.xsd vast_4.0.xsd \
    vast_4.1.xsd vast_4.2.xsd vast_4.4.xsd
vast_2.0.1.xsd:0
vast_4.0.xsd:0
vast_4.1.xsd:0
vast_4.2.xsd:0
vast_4.4.xsd:0

Zero, from 2.0 through the 4.4 draft. (4.3 is absent from that list because IAB Tech Lab never published a 4.3 XSD. The file in the repo is a one-byte placeholder, which is its own interesting problem and not this article's.)

The only pod-related construct in the schema is one optional attribute on <Ad>:

<xs:attribute name="sequence" type="xs:integer" use="optional">
  <xs:annotation>
    <xs:documentation>
      Identifies the sequence of multiple Ads that are part of an Ad Pod.
    </xs:documentation>
  </xs:annotation>
</xs:attribute>

That is the whole feature. An integer, optional, with no relationship to any other ad in the document expressed anywhere.

I mention this because a fair amount of writing on ad pods, including a page on my own site until I checked it this week, describes an <AdPod> element with maxAds and maxDuration children. That element does not exist in any released VAST version. The names are real, but they come from the request side, and mixing them up sends people looking for a validation error that no validator can produce.

Pod size lives in the request, not the response

If you want to know how many ads a break should hold, you have to look at what was asked for, not what came back.

In OpenRTB 2.6 that is on the impression object:

{
  "imp": [{
    "video": {
      "podid": "midroll-1",
      "poddur": 90,
      "maxseq": 4,
      "podseq": 0,
      "mincpmpersec": 0.05
    }
  }]
}

poddur is the total seconds available. maxseq is the maximum number of ads. In VMAP it is the <AdBreak> that owns the slot, with allowMultipleAds sitting on its <AdSource>.

The VAST response then fills the slot and carries none of that context forward. So when you hold a VAST document in your hand, you are holding something that cannot tell you whether it is complete. A two-ad pod and a truncated four-ad pod are byte-for-byte the same kind of object.

That asymmetry is the whole problem. Validation answers "is this document legal." It cannot answer "is this document all of what was sent," because the document does not carry its own expected size.

The four ways ads disappear

1. A wrapper collapses the pod

The most common one. Your pod passes through an SSP wrapper, and that wrapper sets:

<Wrapper allowMultipleAds="false" followAdditionalWrappers="true">

The player keeps the first ad and discards the rest. One impression where you expected four.

The subtler version is a wrapper that omits the attribute entirely. Here is the declaration in the 4.2 XSD:

<xs:attribute name="allowMultipleAds" type="xs:boolean">
  <xs:annotation>
    <xs:documentation>
      a Boolean value that identifies whether multiple ads are allowed
      in the requested VAST response.
    </xs:documentation>
  </xs:annotation>
</xs:attribute>

Note what is not there: no default. The schema does not say what an absent allowMultipleAds means. Some players read the absence as permission, some as refusal, and both readings are schema-valid. You will see the same tag pod correctly on one device and collapse on another, with no error on either.

Set it explicitly on every wrapper you control. Absence is not a default, it is a coin flip.

2. Sequence collisions and gaps

sequence is typed xs:integer, not xs:positiveInteger. That means all of these are schema-valid:

<Ad id="a" sequence="0">
<Ad id="b" sequence="-1">
<Ad id="c" sequence="2">
<Ad id="d" sequence="2">

Two ads with sequence="2" give the player no defined order between them. Most implementations fall back to document order, some drop one, and a few reorder unpredictably across sessions. Negative and zero values are accepted by the schema and handled inconsistently in the wild.

Mixing sequenced and unsequenced ads in one response is its own trap. An <Ad> with no sequence is a standalone ad, not pod member zero. A response containing both is asking the player to decide whether it received one pod or a pod plus a loose ad, and implementations split on the answer.

3. Duration overflow

The publisher owns the break length. If your four ads sum to 100 seconds and the break is 90, something has to give, and the player decides what. Usually it plays until the break is exhausted and drops the remainder, which means your last ad in sequence order is the one that silently never runs.

Nothing in the VAST document flags this, because the document has no idea what the break length is. The only place the mismatch is visible is by comparing poddur from the request against the sum of <Duration> values in the response, and that requires holding both at once.

Worth knowing: the VAST error code registry has a code for exactly this outcome. Code 206, introduced in VAST 4.1, reads "Ad Break shortened. Ad was not served." If your player emits 206, it is telling you the break ran out before your ad did. It is one of the more useful codes in the registry and one of the least commonly implemented, so treat its absence as no evidence either way.

4. One ad fails and takes the rest with it

A broken media file or an unreachable wrapper endpoint in the middle of a pod should cost you one ad. In several player implementations it costs you the remainder of the pod, because the error handling unwinds the whole break rather than skipping to the next sequence.

This is not spec-mandated behaviour, it is an implementation choice, and it is the reason pod position matters commercially. An ad in sequence 1 that fails is much more expensive than the same failure in sequence 4.

What you can actually check before it ships

Statically, from the response alone, you can catch:

Duplicate sequence values across <Ad> elements
Mixed sequenced and unsequenced ads in one response
Zero and negative sequence values
Wrappers in the chain that set allowMultipleAds="false" or omit it
Per-ad validity, so that no single ad in the pod is the one that unwinds the break

The mixed-sequence case is the one I see most in real tags, and it has a rule ID: VAST-2.0-ad-sequence. The others fall out of ordinary per-ad validation, which matters more in a pod than anywhere else precisely because of failure mode 4.

What you cannot check statically is whether the pod is complete. That comparison needs the request. If you are debugging a short break, get poddur and maxseq from the bid request and put them next to the response before you start reading XML. Half the pod investigations I have watched went thirty minutes deep into a document that was never going to contain the answer.

Getting hands on it

I maintain vastlint, an open source VAST validator written in Rust, which is where the rule IDs above come from. Two things on the site are useful for pods specifically:

The VAST tag tester fetches a live tag URL, follows the wrapper chain, and shows you the resolved response. That is how you find the wrapper that set allowMultipleAds="false", since it will not be in the tag you started with.
The ad pods guide has the full sequenced-pod example and the checklist.

There is also a CLI if you would rather keep this in CI than in a browser:

$ cargo install vastlint
$ vastlint check pod.xml

The short version

A VAST response describes what was returned. It does not describe what was requested, and a pod is defined entirely by what was requested. Any tool that only reads the response is structurally unable to tell you an ad is missing, which is why "the tag validates" and "the break is short" are statements that can both be true at once.

Check the response for the things it can prove, and go to the request for the thing it cannot.

An Empty VAST Wrapper Is Schema-Valid in 4.4. It Was Not in 2.0.

Aleksander Sekowski — Sun, 09 Aug 2026 06:30:53 +0000

A VAST wrapper with no AdSystem, no VASTAdTagURI and no Impression validates against the VAST 4.4 draft schema. The same document has been invalid in every version from 2.0 through 4.2. It is one line of XSD, and it is almost certainly a side effect of the CTV Ad Portfolio restructure rather than a decision anyone made on purpose.

I have filed it with IAB Tech Lab. This post is the working, because the reproduction is short enough that anyone can check it in about a minute.

The change

In vast_4.4.xsd on master, both vastInLine_type and vastWrapper_type wrap their children in a single compositor: an xs:choice with minOccurs zero and maxOccurs unbounded.

That looks harmless. It is the idiom people reach for when they want to say "these children may appear in any order". What it actually says is stronger than that. In XSD, the cardinality on the compositor governs the content model, and the minOccurs on the individual child elements only describes a single selection from the choice. Set the choice itself to zero-or-more and every constraint underneath it stops binding.

So the children still declare minOccurs="1". They are still, in effect, optional.

The compositor in question

<!-- vast_4.4.xsd, vastWrapper_type and vastInLine_type -->
<xs:choice minOccurs="0" maxOccurs="unbounded">
  <xs:element name="AdSystem"     type="vastAdSystem_type"/>
  <xs:element name="VASTAdTagURI" type="vastURIElement_type"/>
  <xs:element name="Impression"   type="vastImpression_type"/>
  <xs:element name="Creatives"    type="vastCreatives_type"/>
  <!-- ... -->
</xs:choice>

Three consequences, not one

The empty wrapper is the headline, but the compositor gives up three separate guarantees at once. Each is reproducible with xmllint against the published schema.

What now validates in 4.4

Everything is optional. An empty <Wrapper/> validates. So does an empty <InLine/>, with no AdSystem, no AdTitle, no Impression and no Creatives.
Everything repeats. maxOccurs="unbounded" on the choice means any branch can be selected repeatedly, so three <AdSystem> elements in one InLine validate, even though AdSystem has always been exactly one.
Order stops mattering. 4.2 used xs:sequence, so the order was fixed. A choice imposes none, so <Impression> before <AdSystem> validates.

Reproduction: all three validate against the published 4.4 schema

<!-- 1. empty wrapper -->
<VAST version="4.4" xmlns="http://www.iab.com/VAST">
  <Ad id="a"><Wrapper/></Ad>
</VAST>

<!-- 2. empty inline -->
<VAST version="4.4" xmlns="http://www.iab.com/VAST">
  <Ad id="a"><InLine/></Ad>
</VAST>

<!-- 3. AdSystem three times -->
<VAST version="4.4" xmlns="http://www.iab.com/VAST">
  <Ad id="a">
    <InLine>
      <AdSystem>A</AdSystem>
      <AdSystem>B</AdSystem>
      <AdSystem>C</AdSystem>
    </InLine>
  </Ad>
</VAST>

Check it yourself

curl -sO https://raw.githubusercontent.com/InteractiveAdvertisingBureau/vast/master/vast_4.4.xsd
xmllint --noout --schema vast_4.4.xsd empty-wrapper.xml
# empty-wrapper.xml validates

# the same shape against 4.2
xmllint --noout --schema vast_4.2.xsd empty-wrapper-42.xml
# Element 'Wrapper': Missing child element(s). Expected is ( AdSystem ).

What 4.2 actually required

The contrast is worth being precise about, because the requirement did not live where you might expect. In 4.2, Wrapper_type extends AdDefinitionBase_type, and it is the base type that carries the required fields: AdSystem exactly once, Impression once or more. Wrapper_type then adds VASTAdTagURI as required and Creatives as optional. Both use xs:sequence.

Impression in particular has been required on wrappers since 2.0. That is a twenty-year-old constraint, and the wrapper is exactly where it matters most, because a wrapper that fires no impression is a measurement hole in the middle of a chain.

The schema went from expressing a content model to enumerating a vocabulary. Those are different jobs, and only one of them can gate anything.

vastlint standards note

Why this matters if you gate on the XSD

Plenty of teams treat the published XSD as an acceptance gate: ad server ingest checks, partner certification, QA rigs that reject anything the schema will not accept. For those, 4.4 currently passes wrapper responses that cannot deliver an ad and cannot record an impression.

It also sharpens a question the working group was already asking in a separate thread about whether the XSD is meant to be usable as a validator at all. My answer has not changed: it is not, and it never fully was. The prose has always carried requirements the schema does not express, which is the reason a rule-based validator exists in the first place. But there is a difference between a schema that is incomplete and a schema that is more permissive than the version it supersedes.

The practical takeaway for anyone shipping 4.4 today: do not loosen your own checks to match the draft. Keep requiring AdSystem, Impression and VASTAdTagURI on wrappers, because the prose still does and every prior version did.

The likely fix

If the intent was order-independence, xs:all expresses that while keeping per-element cardinality intact. XSD 1.0 limits xs:all particles to maxOccurs one, so repeating elements like Impression need handling, but the required ones stay required.

If the intent really was a fully open content model, then the schema and the prose have diverged and the annotation should say so out loud, so that nobody builds a gate on top of it expecting otherwise.

Either way it is a small patch. I have offered to write it.

Validate a 4.4 tag against the prose, not just the schema

vastlint checks VAST 2.0 through the 4.4 draft against rules derived from the specification text, not only the XSD, so a wrapper missing AdSystem or Impression still fails. Paste a tag and see. Nothing is stored.

Open the VAST validator

Sources and further reading

IAB Tech Lab VAST issue #58 (GitHub) The filed report, with the full reproduction and the 4.2 comparison table.
vast_4.4.xsd on master (IAB Tech Lab) The published draft schema. See vastInLine_type and vastWrapper_type.
VAST 4.4: what actually shipped (vastlint) The full technical breakdown of the 4.4 draft, content model by content model.
VAST 4.3 to 4.4 migration guide (vastlint) Element-by-element changes with a migration checklist.
Wrapper chains and where they break (vastlint) What a wrapper has to carry for a chain to resolve and measure correctly.

Top 10 OpenRTB Mistakes That Are Costing You Money

Aleksander Sekowski — Tue, 28 Jul 2026 04:57:24 +0000

OpenRTB has a property that makes it uniquely painful to debug: almost nothing in it fails loudly. The spec tells parsers to ignore unknown fields. The version travels in an optional HTTP header most parties drop. A malformed bid request does not bounce with a 400; it just gets no-bid by every partner that enforces the rule you broke, while lenient partners keep the traffic flowing and convince you everything is fine.

That is the revenue mechanic behind every mistake on this list. Each broken field removes some set of bidders from the auction, and every removed bidder lowers your clearing price. You do not see an error. You see CPMs that are a little worse than they should be, forever.

I build RTBlint, an open source OpenRTB linter, and these are the ten failures I see most in real traffic. Each one maps to a stable rule ID, so you can catch all of them in CI instead of in a quarterly revenue review.

1. Strings where the spec says integers

{ "at": "1", "tmax": "120", "test": "0" }

Every one of those values is wrong. at, tmax, test, and the various flag fields are integers. JSON has real numbers, but request builders that template their way through string concatenation ship quoted digits, and a typed parser (Go structs, Java POJOs, anything protobuf-backed) rejects the entire request. Not the field. The request.

This is the most expensive mistake on the list because it costs you 100% of the bidders that parse strictly, and those tend to be the larger, better-engineered ones.

RTBlint flags every occurrence as openrtb.type.mismatch with the exact JSON path.

2. An impression that never says what is for sale

Each object in imp[] must carry at least one of banner, video, audio, or native. An imp with none of them is an auction for nothing: the bidder has no idea what creative form is acceptable, so it does not bid. This usually comes from a request builder that assembles imp objects conditionally and has a branch where every condition is false.

Rule: openrtb.imp.media_type.required.

3. Still sending video.placement instead of plcmt

The 2.6-202303 update deprecated imp.video.placement in favor of imp.video.plcmt, with values from the AdCOM Plcmt Subtypes list: 1 instream, 2 accompanying content, 3 interstitial, 4 no content / standalone. The two enums do not map one to one, so this is a re-declaration, not a rename.

Why it costs money: buyers now key their instream vs outstream classification off plcmt, and instream commands a multiple of outstream pricing. If you sell instream inventory but only declare the old placement field, buyers that follow the current spec classify you as undeclared and price you like outstream.

Rule: openrtb.field.deprecated, three years running the most common finding in video traffic.

4. Privacy signals stuck at their 2.5 paths

OpenRTB 2.6 promoted the GDPR signals into core objects:

2.5 era	2.6
`regs.ext.gdpr`	`regs.gdpr`
`user.ext.consent`	`user.consent`
`source.ext.schain`	`source.schain`

Requests built on 2.5-era code keep writing the ext paths, and 2.6-native consumers never look there. The failure mode for privacy fields is worse than a lost bid: a buyer that cannot find a GDPR signal on EU traffic has two options, drop the request or bid non-personalized. Both pay you less. Some legal teams mandate the first.

Rule: openrtb.field.moved, which also tells you the replacement path.

5. Half a GPP pair

regs.gpp carries the Global Privacy Platform consent string and regs.gpp_sid says which GPP sections apply. They only mean something together. A gpp string without gpp_sid cannot be interpreted (which section governs this user?), and a gpp_sid without the string is an empty claim.

As US state privacy laws multiply, buyers increasingly treat an uninterpretable consent signal the same way they treat a missing one: suppress personalization or skip the request.

Rules: openrtb.regs.gpp_without_gpp_sid and openrtb.regs.gpp_sid_without_gpp.

6. site and app in the same request

A bid request must contain at most one of site, app, or dooh. They answer the same question about what kind of inventory this is, and a request carrying two of them is ambiguous, so many bidders drop it outright. The usual cause is a request builder that merges publisher defaults with placement data and keeps both branches.

Rule: openrtb.fields.mutually_exclusive.

7. Floors in a currency you did not declare

imp.bidfloor is a CPM, and imp.bidfloorcur is its currency, defaulting to USD. It does not inherit from cur or from your account settings or from anything else.

A floor of 120 that you meant as Japanese yen but sent without "bidfloorcur": "JPY" reads as a 120 USD floor. Every bid loses to it. Your fill for that placement goes to zero and nothing anywhere tells you why. The mirror image also happens: a floor meant in USD declared in a minor currency invites bids far below what you intended.

Rules: openrtb.imp.bidfloorcur_format_invalid for malformed currency codes, openrtb.imp.bidfloor_negative for negative floors.

8. A tmax nobody can meet

tmax is the total time in milliseconds you allow for bids to arrive, network latency included. Two failure modes show up in traffic:

tmax: 0 or a negative value, which technically gives bidders no time at all. Rule: openrtb.request.tmax_non_positive.
tmax: 300000, which is five minutes and means someone is sending seconds. Bidders either clamp it or distrust the request. Rule: openrtb.request.tmax_implausible, which fires above 10,000 ms.

Either way you distort the auction: too low and slow-but-high-paying bidders never make it back, too high and you are the exchange whose requests look broken.

9. A supply chain that fails audit

Buyers cross-check source.schain against sellers.json and ads.txt before spending. Three defects break that audit:

The same asi/sid node appearing twice: openrtb.schain.duplicate_node
A node missing the required hp flag: openrtb.schain.node.hp_missing
Empty asi or sid strings, which make the node unverifiable: openrtb.schain.node.identifier_empty

An unverifiable supply chain is indistinguishable from a suspicious one, and post-adselect, buyers do not give the benefit of the doubt. They route spend to paths they can verify.

10. Bid responses that contradict themselves

Everything above is the request side. The response side has its own money leaks, and they hit DSPs and bidders instead of publishers:

adm present but mtype missing, so the exchange cannot classify the creative: openrtb.bid.mtype_missing
VAST XML or native JSON that was JSON-encoded twice, arriving as a string of escaped quotes no player can render: openrtb.bid.adm.double_encoded
A native bid whose adm is not parseable JSON: openrtb.bid.adm.native_not_json
An impid that does not match any imp in the request, which wins nothing ever: openrtb.bid.impid_unknown
Bidding in a currency the request did not allow: openrtb.response.cur_not_allowed

These are the worst kind of expensive because you paid to get here: QPS, bid computation, sometimes even the win, and then the creative fails to serve and you get billed with nothing rendered. RTBlint validates responses on their own or cross-checked against the originating request, where every bid's impid, mtype, markup, deal ID, seat, and currency are verified against what the request actually offered.

Catching all of this before it ships

Every finding above has a stable rule ID, a severity, a message, and a JSON path, which means you can gate a deploy on it:

cargo install rtblint
rtblint validate request.json
rtblint validate --type response --request request.json response.json
rtblint validate --version 2.6-202606 --format json request.json

Or from Node via WASM:

import { validate } from "rtblint-core";

const report = validate(JSON.stringify(bidRequest), "2.6-202505");
for (const issue of report.issues) {
  console.log(issue.id, issue.path, issue.message);
}

There is also a browser tester that runs the same rules client-side (your payloads never leave the page), an MCP server if you want your coding agent to validate bid requests while it works, and the full rule reference with fix guidance per rule. The validator covers every OpenRTB snapshot from 2.0 through 2.6-202606, plus 3.0.

Source is on GitHub. If you run traffic through it and hit a false positive, an issue with the payload shape is the fastest way to get it fixed.

The pattern behind all ten mistakes is the same: OpenRTB does not tell you when you are wrong, it just pays you less. A linter in CI is the cheapest way to find out first.

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.

Working with VAST tags?

Paste XML into the validator to check it against the full IAB rule catalog.
Test a live tag URL and watch it render in a real player.
Walk a wrapper chain hop by hop to find where it breaks.

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.

Working with VAST tags?

Paste XML into the validator to check it against the full IAB rule catalog.
Test a live tag URL and watch it render in a real player.
Walk a wrapper chain hop by hop to find where it breaks.