DEV Community: Aleksander Sekowski

A GA4 debug response can expose events your HTTP status hides.

Aleksander Sekowski — Fri, 06 Nov 2026 19:00:00 +0000

A GA4 Measurement Protocol request returning a successful HTTP status does not establish that its events were processed as intended. A transport check can pass while a malformed event disappears from the analytics you expected to see.

Google provides a validation endpoint at /debug/mp/collect. It returns diagnostic messages about the payload. Events sent there do not appear in reports, which makes it useful for development without mistaking a validation run for collected traffic.

A useful integration has two explicit tests: one for the validation response and another for collection in the intended stream. Their evidence and failure messages should remain separate.

Make the debug response part of the contract

Do not reduce the result to response.ok. Read the body and require the documented validationMessages array to exist. An empty array is materially different from a missing array or an unreadable response.

Preserve the field path, validation code and description for each finding. The status code alone cannot tell the developer which event parameter needs attention.

This complete Node.js example tests response handling without making any network requests:

import assert from 'node:assert/strict';

function inspectDebugResponse(status, text) {
  if (!Number.isInteger(status) || status < 200 || status >= 300) {
    return { kind: 'transport-failure', status };
  }
  let body;
  try {
    body = JSON.parse(text);
  } catch {
    return { kind: 'unexpected-response', reason: 'invalid JSON' };
  }
  if (!body || !Array.isArray(body.validationMessages)) {
    return { kind: 'unexpected-response', reason: 'missing validationMessages' };
  }
  if (body.validationMessages.length > 0) {
    return { kind: 'payload-findings', findings: body.validationMessages };
  }
  return { kind: 'no-payload-findings' };
}

const invalid = JSON.stringify({ validationMessages: [{
  fieldPath: 'events',
  validationCode: 'NAME_INVALID',
  description: 'Synthetic invalid event name'
}] });

assert.equal(inspectDebugResponse(200, invalid).kind, 'payload-findings');
assert.equal(inspectDebugResponse(200,
  '{"validationMessages":[]}').kind, 'no-payload-findings');
assert.equal(inspectDebugResponse(200, '{}').kind, 'unexpected-response');
assert.equal(inspectDebugResponse(200, 'null').kind, 'unexpected-response');
assert.equal(inspectDebugResponse(200, '<html>error</html>').kind,
  'unexpected-response');
assert.equal(inspectDebugResponse(503,
  '{"validationMessages":[]}').kind, 'transport-failure');

The result names are intentionally narrow. no-payload-findings does not claim that an event was collected, attributed or visible in a report. It states what this response established.

The fixture with an empty object is particularly useful. A loose check such as !body.validationMessages?.length would accept a missing field as if it were a clean diagnostic response.

Send the payload you intend to deploy

Construct the request through the same adapter used by your application. Then direct that serialized payload to the validation endpoint in your development test. A hand-written example can pass while the production adapter emits different field names or types.

Google recommends strict development checks using validation_behavior: "ENFORCE_RECOMMENDATIONS". Its guidance also distinguishes that development setting from production collection behavior. Record which mode produced the diagnostic result.

Use a dedicated test configuration and keep secrets outside fixtures and screenshots. An API secret included in a query string can leak into request logs if the full URL is printed indiscriminately.

Do not automatically send the same fixture to the collection endpoint after a clean debug response. Make collection an explicit integration-test step with controlled synthetic data and a known observation plan.

Design useful negative cases

Keep one valid baseline payload and change one property per failing fixture. For example, introduce an invalid event name, remove a required field for the tested contract or change a numeric parameter into a string.

Save the diagnostic response associated with each version. If Google returns several messages, preserve all of them rather than selecting the first and discarding potentially related findings.

Assert the field path and validation category that matter to your adapter. Avoid making the test depend on the exact punctuation of a human-readable description, which can change without changing the underlying finding.

Also test unexpected transport behavior. The local program covers a non-success status, invalid JSON and a missing diagnostic array. Your HTTP wrapper should additionally handle a timeout without reporting a payload-validation pass.

Verify collection in the intended stream

After the payload test passes, send a permitted synthetic event through the actual collection path. Record the stream identifier, occurrence time, event name and a non-sensitive correlation value supported by your test setup.

Observe the result in the appropriate destination tooling. Confirm that the event reached the intended stream and that the fields important to your application survived the trip. Choose the observation surface and waiting period explicitly rather than assuming every reporting view updates immediately.

The debug service does not validate api_secret or firebase_app_id. A clean debug response therefore cannot establish that those configuration values identify a working collection setup.

If a debug-endpoint event never appears in reports, that is expected behavior. Repeatedly sending it to the same debug URL will not turn it into a collected event.

Make CI results explain the failure

Give the integration separate result fields for transport, payload findings and collection observation. That lets a failing run distinguish an unreachable validation service from a rejected field or a configuration problem in the collection path.

Store a sanitized fixture hash and adapter revision with the result. When a developer asks whether a refactor changed the payload, the record should answer which exact serialized input was checked.

Keep locally executable response-parser tests in the fast test suite. Run the live validation test at an appropriate integration boundary rather than making every unit test depend on an external service.

When testing a batch, retain the event order and the complete diagnostic array. A field path referring to an event index is only useful if you can reconstruct the same batch. Reordering the saved events for readability can point the investigation at the wrong payload. Include a single-event reproduction once you have isolated the finding, and keep the original batch as evidence of how the adapter produced it.

I maintain Pixellint. The GA4 payload pack can provide local feedback before the request reaches Google's validation service. Use the external diagnostic result and the collection observation to close the remaining questions, with each result labeled by its scope.

Sources

Technical sources checked October 25, 2026. Drafted with AI; examples are synthetic unless explicitly stated otherwise.

VMAP gives ad break inventory a schedule that engineering and revenue teams can test.

Aleksander Sekowski — Fri, 06 Nov 2026 17:00:00 +0000

Originally published on VASTLint. Part 6 of 8 in this series on video standards and business outcomes.

A long-form video plan may promise a pre-roll and several mid-roll breaks. The sales forecast can look complete while the implementation still disagrees about when a break starts, which ad source it calls or what happens when no ad is available. The schedule becomes a commercial dependency because the opportunity cannot be sold and delivered reliably unless the player knows when to create it.

IAB Tech Lab's Video Multiple Ad Playlist, or VMAP, gives systems a shared way to describe ad breaks. VAST describes the ad responses used within that workflow. Following both standards can make a break plan easier to exchange and test. Demand, player behavior and the viewer's actual session still determine what is ultimately delivered.

A planned break is an opportunity that still needs execution.

The official VMAP overview describes the standard for multiple ad opportunities in video content. The useful distinction for a business team is between the break schedule and the ads returned for it. A valid schedule can identify an opportunity even when its ad source returns no eligible ad for the request.

For a product manager at a streaming publisher, this separates two kinds of problem. If the player never reaches the expected break, investigate scheduling and content behavior. If it reaches the break but no ad is returned, inspect the ad request and demand path. A single fill-rate number can obscure these different causes and send the wrong team to investigate.

The handoff should identify the intended content type, the relevant break positions and the implementation that consumes the schedule. Record whether the test uses on-demand playback, a live workflow or another supported mode. A successful result in one context does not automatically demonstrate identical break behavior in the others, especially when the content timeline can change.

Break scheduling and pod composition need separate acceptance checks.

A break can contain several ads, but the number and duration of those ads must suit the actual break and player configuration. The schedule alone cannot guarantee that the returned combination fits. Check how the destination handles an overlong ad, a partially filled break and an individual creative that fails after the break has started.

The campaign and content teams also need to agree what experience is being offered. A 30-second opportunity is not interchangeable with two 15-second opportunities in every commercial arrangement. Reporting should preserve the actual placement and delivered creative. If the player substitutes a different ad or returns to content early, keep that outcome visible in the record.

For implementation guidance on the ad side, the VAST 3.0 specification describes ad pods and sequences. Use the version and features supported by the destination. Do not assume that adding a sequence value to a document makes every player execute the same pod behavior or accept an otherwise incompatible creative.

The forecast needs to distinguish sessions from billable impressions.

An illustrative plan with 100,000 sessions and four possible breaks describes up to 400,000 break opportunities if every session reaches every break. Viewers who leave early change that count. Some breaks may contain multiple ads; others may be skipped or have no demand. None of those initial figures is automatically a count of billable impressions.

A useful model moves through the actual stages. Start with sessions that reach the position, identify breaks triggered, count eligible ad requests and record ads that actually render under the billing definition. Use observed rates for each stage where available. If a rate is an assumption, label it and show how sensitive the forecast is to that input.

For a simple illustrative calculation, assume a scheduling correction produces 20,000 additional billable impressions with no displaced paid demand at a net CPM of $8. The associated revenue is $160. The calculation requires that incremental impression evidence. Counting 20,000 repaired schedule entries would not establish the same outcome because some viewers may never reach those breaks.

A reproducible schedule can reduce launch and support work.

Without a shared representation, partners may exchange break positions in prose, screenshots or custom configuration files. Each translation creates a chance for disagreement about the intended schedule. A standard document gives both teams a common artifact to review, provided the consuming implementation supports the features used and the content timeline is identified correctly.

Retain a short acceptance record that pairs the intended schedule with observed player events. Record seeking behavior when it is relevant to the product, as well as the normal uninterrupted session. A player can appear correct during a simple playback test while behaving differently when a viewer seeks, resumes or enters content partway through a session.

The operational benefit can be measured in setup effort and defect resolution. Track time configuring a new content integration, schedule-related launch issues and manual steps needed to reproduce them. Keep those figures separate from demand troubleshooting. A lower count of scheduling incidents is useful evidence even when market demand makes a revenue comparison inconclusive for the same period.

VASTLint can check the schedule before the player test.

VASTLint's VMAP guide describes document checks for the scheduling handoff. Run the supplied schedule through the validator and inspect the relevant ad responses as well. A schedule that passes its own checks can still point to a VAST document with a different problem. Preserve both inputs when explaining the result.

Then test the actual player or insertion workflow against known content. Save the scheduled position, observed break event, returned ad and outcome. Include a valid no-ad case so the test can distinguish an intentional empty response from an execution problem. The useful result is an explainable sequence of events that someone else can reproduce.

Static validation cannot establish how many viewers reached a break or whether an ad was billed. It also cannot guarantee that a particular player implements every permitted schedule feature. Match the document result with the runtime record before accepting the integration. This keeps a clean validation report from being used as evidence for a delivery promise it did not test.

Engineering and revenue should review the same break record.

Give the break a stable operational identity within the content and campaign records. Engineering needs to trace its execution; revenue teams need to understand which opportunity was sold. If the meaning changes during a release, document the change and check the reporting mapping. A familiar label is not enough if it now refers to a different position or configuration.

After rollout, monitor the funnel from reached break positions to accepted billable impressions. Investigate changes at the stage where they occur. A fall in triggered breaks is a different problem from a fall in eligible demand. This view makes it easier to assign work and prevents a scheduling issue from being hidden inside an aggregate monetization metric.

VMAP adherence supports a break plan that participants can exchange, inspect and test. Its business value can appear as more predictable implementation and clearer inventory accounting. Revenue benefits require actual incremental delivery under the agreed billing rules. Keep the schedule, the observed session and the commercial outcome connected so the team can tell which result the standard helped produce.

The IAB Privacy String Cheat Sheet Every Ad Ops Engineer Needs

Aleksander Sekowski — Fri, 06 Nov 2026 00:08:16 +0000

On 23 October 2025 IAB Tech Lab opened public comment on H2 2025 Global Privacy Platform updates: four new U.S. state sections and a rearchitected state-string layout with explicit section headers. That is not a CMP banner story. It is a wire-format story. The same month, traffickers still paste TC Strings into gpp, leave us_privacy=1YNN on CM360 pixels that expect GPP National, and ship OpenRTB bids where regs.gpp_sid survives a hop but regs.gpp does not. Every one of those URLs can look "privacy complete" in a spreadsheet while the downstream callee runs the wrong decoder.

This sheet is for ad ops and bid engineers who own the live tag URL, the Floodlight path, or the OpenRTB regs object and need one place to map parameter name → grammar → where it must land. One malformed field is never the whole job; the job is knowing which family you actually have before you argue with fill or attribution.

The sheet

Signal family	Typical pixel / ad-server slot	OpenRTB 2.6 home	How you know the grammar	Wrong cousin engineers swap in
IAB TCF v2 TC String	`gdpr_consent` (with `gdpr=1`)	`user.consent` (TC String)	Decoded TC version field is 2; core segment is long (not a single digit)	`gdpr_consent=1` or `true` (valid base64, not a TC String)
Global Privacy Platform	`gpp`	`regs.gpp`	GPP string header type 3 after decode	TC String copied into `gpp` (decodes as type 2, wrong parameter)
GPP section in force	`gpp_sid`	`regs.gpp_sid` (array of section ids)	Integer(s): e.g. 7 US National, 8 California, 2 TCF section inside GPP	`gpp_sid` present while `gpp` is empty or a TC-only blob
IAB US Privacy (legacy)	`us_privacy`	`regs.us_privacy` (deprecated)	Four characters: version digit + three `Y`/`N`/`-`	Treating `1YNN` as GPP National v2 on products that read GPP only
GDPR scope flag	`gdpr`	`regs.ext.gdpr` / impression regs	0 or 1 only	`gdpr=1` with missing or placeholder `gdpr_consent`
Google Additional Consent	`addtl_consent`	exchange-specific extensions	AC string for Google ATP vendors	Used as a stand-in for TC on tags that still require `gdpr_consent`
Duplicate consent keys	same URL twice	duplicate `regs` fields	At most one authoritative value per signal	Two `gdpr_consent` or `gpp` values on one pixel (callee must guess)

OpenRTB and the pixel are parallel hops, not aliases. A CMP can be correct in the page and still wrong on the request the vendor logs if the ad-server macro never expanded. Floodlight-style path parameters count the same as query keys: if the string is not on the HTTP request the collector sees, it does not exist for billing or restriction logic.

For the October GPP release specifically, new state sections and subsection headers change what parsers must expect inside a type-3 container. Our write-up on the new sections and OpenRTB regs.gpp tracks what landed in that comment package; your CMP version and your bid adapter version can drift on different calendars.

Three rows that validate and still fail in production

gdpr_consent=1. Alphabet and base64 validators green-light it. A TC decoder rejects it immediately because there is no version-2 bitfield and no purpose vector. Google tags interpret gdpr=1 as "TC applies"; an empty or numeric placeholder is how personalized ads quietly turn off while the tag still "has a consent param."

TC String in gpp with gpp_sid=2. The blob is long, base64-safe, and familiar. Decoded header type is 2 (TC), not 3 (GPP). Campaign Manager 360's own documentation says TCF strings sent through GPP are not accepted on that hop; the section id names TCF while the product still wants National or supported state sections on gpp / gpp_sid. We walked through that mix-up on CM360 GPP National v2 versus us_privacy.

regs.gpp_sid without regs.gpp on the bid. Diff tools flag it as incoherent OpenRTB: you told the exchange which GPP section is in force but did not ship the string. Prebid Server and exchange normalizers do not always drop both fields together; one side of the hop can inherit a section id from a template while the GPP body was stripped for size. Buyers read that as "restrict processing" with no payload to parse.

How you catch it

An LLM implementing tag macros or OpenRTB regs can emit plausible key names and still ship the wrong grammar. The RPC or the ad server can return 200. The wire contract does not move.

Pixellint (cargo install pixellint, npm install pixellint) decodes IAB consent strings on the pixel URL and path-shaped tags instead of treating them as opaque base64. It checks TC version bits, GPP header type, deprecated us_privacy, duplicate signals, and template macros that never expanded. It is independent of IAB Tech Lab and of AAO; it is the deterministic check on the string your tag actually fired.

Paste a live URL into the playground or run CLI validation in CI on exported tag templates before traffickers clone them across regions.

Where to go next

GPP strings and gpp_sid (header type 3, section ids, TC-in-GPP mistakes)
TCF v2 on pixels (gdpr flag, TC String length and version)
Consent on the wire (query vs path, empty macros, vendor-specific dialects kept separate)
Consent overview and deprecated US Privacy (31 January 2024 deprecation vs tags that still emit 1YNN)

When the bug is on the bid object rather than the pixel, pair this sheet with OpenRTB privacy field docs on the exchange side; the header rules are the same even when the parameter names move from gdpr_consent to user.consent and from gpp to regs.gpp.

OpenRTB Content Taxonomy Explained: How cat, cattax, and gtax Version the Bid

Aleksander Sekowski — Thu, 05 Nov 2026 00:54:21 +0000

On October 28, 2026, Digiday reported that most CTV bid requests still carry genre as free text or channel-level labels that do not match the program. IAB Tech Lab’s answer on the wire is not a longer string. It is a pair of integer arrays plus a version field: cat with cattax, and genres with gtax. If you treat 712 as “Sports” without reading which taxonomy table applies, you are guessing about inventory the buyer will block or bid on.

OpenRTB never promised that category codes were stable across releases. It promised that the receiver could look up the code in the table named by cattax or gtax. That lookup is the versioning story practitioners skip when they copy CMS tags into site.cat and call the request done.

What `cat` actually is

cat is an array of integers. Each integer is a row in an IAB Content Taxonomy spreadsheet, not a universal label. The taxonomy in use is declared separately, on the same object, in cattax.

You can attach categories at several layers on one bid request:

Site or App: site.cat / app.cat with matching site.cattax / app.cattax for the property.
Publisher: publisher.cat and publisher.cattax when the exchange models the seller separately.
Content: content.cat and content.cattax for the specific video, article, or episode in view.
Producer: producer.cat and producer.cattax when the production entity differs from the publisher.
Bid response: bid.cat and bid.cattax when the buyer echoes what they believe they bought.

OpenRTB 2.6 standardized cattax on all of those objects. A validator that only checks “is this integer in any taxonomy CSV” will pass codes that mean different verticals depending on which object omitted cattax.

The spec text is explicit: if no cattax is supplied, IAB Content Category Taxonomy 1.0 is assumed. That default is not a hint. It is the table your partner’s block list uses when they never upgraded from 1.0 mappings.

Genre is a different column, with a different default

Long-form video added a second labeling path on Content. Legacy genre remains free text. For programmatic genre targeting, OpenRTB 2.6-202501 added:

content.genres: integer array of genre ids from the taxonomy named by gtax.
content.gtax: which AdCOM category taxonomy applies to those ids.

Implementation guidance in the OpenRTB 2.x implementation notes tells sellers to keep property-level categories in site.cat / app.cat, use content.genres for program genre, and declare gtax so DSPs know which table to read. The CTV genre list is a subset of Content Taxonomy 3.1, not a reuse of cat codes from 1.0.

Here is the asymmetry that breaks production QA. cattax defaults to Taxonomy 1.0. gtax defaults to Content Taxonomy 3.1 (AdCOM list value 9). On one Content object you can therefore ship 3.1 genre ids that receivers interpret correctly while 3.1 category ids in content.cat are read as 1.0 rows because content.cattax was omitted. Schema validation often stays green; the buyer’s suitability engine does not.

Example shape (one field is wrong on purpose):

"content": {
  "title": "Friday Night Match",
  "cat": [483],
  "genres": [712],
  "gtax": 9
}

Without content.cattax, 483 is a 1.0 category. With gtax: 9, 712 is read against 3.1’s CTV genre subset. A DSP blocking “Sports” in 1.0 does not see the same signal as a contextual buyer targeting genre 712 in 3.1. Loss reason 209 (category blocked) without the cattax from that request is unreadable noise.

How AdCOM lists tie the wire together

OpenRTB 2.6 moved enumerated lists into AdCOM. The Category Taxonomies list is what cattax and gtax index. Values cover Content Taxonomy 1.0, 2.0, 2.2, 3.0, 3.1, vendor tables, and custom taxonomies when both sides agree.

When Google Ad Manager started populating site.cat, site.pagecat, and app equivalents on Authorized Buyers traffic, it also set cattax to the 1.0 mapping on those requests. Header bidding paths that map CMS tags into ortb2.site.content without the same cattax create a split brain: ADX sees 1.0-labeled inventory while Prebid-sourced requests look valid but label a different vertical. Our write-up on GAM pagecat on ADX versus Prebid ortb2 walks through that hop mismatch.

Migrating to 2.2 or 3.1 category ids requires setting cattax to the matching list value everywhere you send cat, not only on content. Copying 2.2 ids into cat while leaving the default 1.0 assumption is how “valid” requests fail brand suitability silently.

The 2.6-202501 release is the dated snapshot that added gtax and genres. Partners on older OpenRTB builds may ignore those fields entirely and fall back to free-text genre, which is exactly the signal Digiday described as unreliable.

How you catch it

An LLM generating OpenRTB from a brief can emit plausible integers and still pick the wrong default table. The RPC or the exchange adapter can return OK while the downstream DSP reads a different category than the seller intended.

RTBlint is the deterministic check on the bid object: cattax enums, co-occurrence of cat with cattax, genres with gtax, and dated-snapshot fields for the OpenRTB version you declare. It is independent of IAB Tech Lab and of AgenticAdvertising.org; it does not replace their specs, and they do not require it. It is what you run when the agent’s JSON needs to match what the exchange actually parses.

$ rtblint validate --version 2.6-202606 bid.json

Use the OpenRTB version picker before you argue about a field: 2.6-202501 added genre taxonomy fields; 2.6-202606 added liveness attributes on Content that do not replace gtax.

Rule docs for the 202501 content additions live under content.gtax and content.genres. For broader AdCOM context on where cat and cattax sit in the object model, see the AdCOM reference. The guides index collects supply-path and OpenRTB migration notes when you need a checklist beyond one malformed attribute.

Where to go next

Read the 2.6-202501 content object review before you map CTV genre ids.
Align header bidding ortb2 category mapping with the cattax your ADX or SDK path sends.
When debugging blocks, log cattax and gtax alongside cat and genres on the same request id.
Pick a dated snapshot in OpenRTB versions and validate fixtures against it in CI.

The integer was never the category. The selector beside it was.

OMID browserOptional describes the JavaScript environment.

Aleksander Sekowski — Wed, 04 Nov 2026 19:00:00 +0000

The name browserOptional is easy to misread as permission to skip verification JavaScript. It describes the script's execution environment. Confusing those meanings can leave a player showing video while the required verification resource never runs.

This is especially relevant when a player moves from a browser test page to an app or another environment with a different JavaScript runtime. The same resource URL does not establish the same available APIs.

VAST 4.3 section 3.17.1 provides the selection rules. The integration work is to apply them to a real environment, preserve the selected resource and verify what actually executed.

Describe the environment precisely

A resource marked browserOptional="true" declares support for execution without DOM and other browser built-ins. The resource remains JavaScript. The flag does not replace it with a native measurement vendor SDK.

For browser or webview execution, the specification prefers resources marked false when both forms are available. A non-browser JavaScript environment may execute only resources marked true. If it receives only unsuitable resources, the associated not-executed reporting must remain visible.

Start an integration record with the player build, OM SDK integration, runtime and supported framework. Avoid a single isNative variable that attempts to represent all those properties. An app can host a webview, and a platform label alone does not tell you which environment executes verification code.

Validate the XML attribute before selecting a resource

An XML parser usually returns attribute text. In JavaScript, Boolean("false") evaluates to true. The string is nonempty, so ordinary truthiness does not interpret its XML meaning.

The following complete Node.js example accepts XML Schema boolean forms and then applies a narrow resource-selection rule:

import assert from 'node:assert/strict';

function parseXmlBoolean(value) {
  if (typeof value !== 'string') {
    throw new TypeError('browserOptional attribute is missing');
  }
  const lexical = value.trim();
  if (lexical === 'true' || lexical === '1') return true;
  if (lexical === 'false' || lexical === '0') return false;
  throw new TypeError('invalid XML boolean');
}

function selectForEnvironment(resources, environment) {
  if (resources.some(r => typeof r.browserOptional !== 'boolean')) {
    throw new TypeError('resources must contain validated booleans');
  }
  if (environment === 'browser') {
    return resources.find(r => r.browserOptional === false) ?? resources[0] ?? null;
  }
  if (environment === 'non-browser-js') {
    return resources.find(r => r.browserOptional === true) ?? null;
  }
  throw new Error('unknown execution environment');
}

const resources = [
  { id: 'portable', browserOptional: parseXmlBoolean('true') },
  { id: 'browser', browserOptional: parseXmlBoolean('false') }
];
assert.equal(selectForEnvironment(resources, 'browser').id, 'browser');
assert.equal(selectForEnvironment(resources, 'non-browser-js').id, 'portable');
assert.equal(selectForEnvironment([resources[1]], 'non-browser-js'), null);
assert.equal(parseXmlBoolean('0'), false);
assert.equal(parseXmlBoolean(' 1 '), true);
assert.throws(() => parseXmlBoolean(undefined));
assert.throws(() => parseXmlBoolean('False'));
assert.throws(() => selectForEnvironment([{ browserOptional: 'false' }], 'browser'));

The selector deliberately assumes that the caller already filtered resources for the relevant verification entry and supported API framework. It illustrates environment selection, not the complete VAST verification algorithm.

The parser preserves missing or invalid values as errors. Supplying a default at this stage would hide a malformed declaration and make the later selection look justified.

Keep eligibility separate from successful execution

Selecting the portable resource establishes that it is eligible under this environment rule. Several later questions remain: did the player fetch it, did loading complete, did its execution succeed and did it participate in the expected measurement session?

Record these as separate outcomes. A resource that was eligible but failed to load needs a different investigation from a resource the player never selected.

Keep the verification vendor, selected URL, resource position in the document and environment in the diagnostic record. If wrappers add verification entries, preserve which document introduced each one. Otherwise a report can identify the wrong vendor script when several resources are present.

Do not conclude that measurement worked merely because a global JavaScript object exists. Check the integration's documented session and event observations. The exact instrumentation depends on the SDK and platform, so retain the build and test environment with that evidence.

Test the matrix that your deployment will use

Create one fixture with a browser-only resource, one with a portable resource and one containing both. Run them against each execution environment your product supports.

For the browser environment, verify the selection preference when both forms are offered. For the non-browser environment, verify that the browser-only fixture cannot accidentally pass because a desktop test harness supplies a DOM.

Add a fixture with a missing attribute and another containing the text false. The latter specifically guards against a future refactor replacing deliberate parsing with Boolean(value).

Keep environment selection deterministic. If two resources are equally eligible, document the implementation's selection behavior rather than allowing iteration order from an unrelated data structure to choose the script accidentally.

Use runtime failures to narrow the next step

If a resource is never selected, inspect the parsed declaration and framework filtering first. If it is selected but never requested, inspect the player's execution policy and instrumentation. If the request occurs but execution fails, inspect the response, loading restrictions and runtime diagnostics.

A script can also depend on browser APIs despite declaring portability. Retain a minimal reproduction in the actual non-browser runtime, with the vendor resource revision. Changing the flag in your local XML without checking the script's behavior does not repair that dependency.

When no verification executes, preserve the associated failure reporting. Missing measurement is an operational result that needs explanation, not a successful session with zero measured activity.

Put the declaration and observation in the same review

A useful acceptance record includes the XML fixture, parsed boolean, selected resource, runtime identity and measurement-session observation. Another engineer should be able to determine where the check stopped without rerunning the entire campaign.

I maintain VASTlint. Use the VAST XML validator to inspect the declaration before the environment test. Keep its structural result beside the player evidence, so each result supports the question it actually checked.

Sources

Technical sources checked October 25, 2026. Drafted with AI; examples are synthetic unless explicitly stated otherwise.

SSAI VAST Ingest vs CSAI Ad Tag: The Fill Gap Your Browser QA Cannot See

Aleksander Sekowski — Wed, 04 Nov 2026 00:03:13 +0000

IAB Tech Lab finalized CTV Ad Portfolio signaling in July 2026 with a blunt operational requirement: SSAI vendors, exchanges, and measurement partners have to carry the same VAST and AdCOM enumerations as client-side players. That is not a cosmetic metadata upgrade. It is an admission that two delivery rails read the same campaign name and not the same creative contract. One rail fetches a tag in the living room. The other pulls a master into a transcode farm before the break airs. When fill drops on CTV but desktop web looks fine, the mismatch is usually between those two payloads, not a mysterious SSP bug.

What SSAI ingest actually consumes

In server-side ad insertion, the ad decision may still start from a VAST URL, but the money moment is transcode and splice. The stitcher wants a mezzanine or a high-bitrate master it can normalize to the publisher's ladder, a Duration that fits the pod slot, HTTPS-delivered media, and often a UniversalAdId block so downstream reconciliation can tie the stitched bytes back to the trafficking row. VPAID and other script-based apiFramework values are dead on arrival: there is no JavaScript runtime in the packager.

That is a different readiness bar than "the IMA SDK played an MP4 in Chrome." A tag can validate against VAST 4.x, expose a single progressive MediaFile, and never include <Mezzanine> at all. Browsers do not need the mezzanine child; many SSAI pipelines treat its absence as a hard reject before the first frame is encoded. The same InLine can also declare a Duration of :30 while the mezzanine asset is :29.97, which passes XML schema checks and still breaks slot math on the stitcher.

Tracking is part of the contract too. SSAI often fires quartile and complete URLs from the packager's clock, not from the player's JavaScript timer. If your QA only watches the client-side VAST response, you may never notice that midpoint or complete beacons were authored for a player that never runs in the SSAI path. The midpoint event doc is a reminder that those URLs are pixels on the wire whether the stitcher or the device fires them.

What CSAI and browser QA actually test

Client-side insertion is the path most trafficking teams know. You paste a VAST URL into a tag tester, the player selects a MediaFile, and someone watches quartiles tick in the network panel. Wrappers get peeled until an InLine appears. Click-through and verification resources load in a real DOM.

That workflow is valuable. It is also incomplete for any inventory that monetizes through SSAI on CTV. The tag the browser resolves may be a wrapper chain whose final InLine is optimized for desktop bitrates. The mezzanine the stitcher needed might live only on an upstream hop your QA never fetched, or never existed because the creative was built for CSAI-only supply. Verification markup can load in a web player while the stitched stream carries no measurable verification resource at all, because the transcode step stripped interactive files the living-room device never executes.

Teams migrating off deprecated APIs feel this split directly. A VPAID migration guide matters because the interactive file that survives browser QA is exactly what SSAI cannot run. Passing validation on the client tag is not evidence the CTV break will accept the creative.

Where the two paths disagree without looking "broken"

Same trafficking ID, two environments, four common divergences:

Check	CSAI / browser QA	SSAI ingest
Primary media	First playable `MediaFile`	Mezzanine or approved master
Interactive API	VPAID or SIMID may load	Script APIs rejected
Duration	Player tolerance	Pod slot and ad server clock
Identity	Optional in older tags	`UniversalAdId` for reconciliation

None of these rows fail XML schema by themselves. That is why the problem shows up as silent fill loss on CTV while reporting still shows the creative as "ready."

New portfolio formats make the split sharper. Pause, overlay, and squeezeback buys expect NonLinear VAST shapes and AdCOM placement signals that a linear-only CSAI tag never exercised. Preparing for VAST 4.4 CTV formats is about proving partner acceptance on the path you will actually use, not only proving a desktop wrapper parses. When you QA portfolio NonLinear delivery, the IAB-style VAST tester (an independent fork, not an IAB Tech Lab product) exercises SIMID studio and sample creatives alongside host transport logs.

How you catch it

An LLM or MCP task can emit VAST that looks plausible and still miss mezzanine, duration drift, or HTTPS on the master URL. The wire contract does not move because the tool call returned OK. You still need a deterministic check on the creative the buy claimed.

Start with the live tag URL in the VAST tag tester: fetch, preview, and confirm tracking and media URLs resolve the way a player would. Then run the same entry point through the VAST inspector so wrapper hops surface the InLine the stitcher would see, not just the first response your browser cached.

vastlint (cargo install vastlint, npm install vastlint, or the MCP server) applies versioned rules to the XML itself: mezzanine expectations on SSAI-bound tags, deprecated API frameworks, duration and media consistency. It is independent of IAB Tech Lab and of AgenticAdvertising.org; it is the package that owns the VAST payload after your agent or trafficking UI emits it.

When verification vendors QA the tag separately from the video team, align on what the verification manager actually checks versus what the stitcher transcodes. Measurement OK in a browser is not SSAI readiness.

Where to go next

VPAID migration for VAST 4.1+ when interactive files still ride the tag SSAI will reject.
Validate OMID inside VAST AdVerifications before you assume CTV measurement survives transcode.
Prepare VAST 4.4 CTV formats before you commit portfolio traffic to partners that only tested linear CSAI tags.

Fill on CTV is not a single tag. It is the ingest path you never opened in the browser.

Persistent creative IDs make video campaign reconciliation easier to repeat.

Aleksander Sekowski — Tue, 03 Nov 2026 17:00:00 +0000

Originally published on VASTLint. Part 5 of 8 in this series on video standards and business outcomes.

An agency receives four reports for one video campaign. Each system has assigned the creative a different local identifier. Someone opens a spreadsheet, matches names, checks durations and asks whether two similar filenames refer to the same version. The campaign's delivery may be healthy while the reporting process still depends on a person remembering how the assets were renamed.

IAB Tech Lab's UniversalAdId and Ad Creative ID Framework, or ACIF, address the problem of identifying creative across a supply chain. Following that approach can support more dependable reconciliation and asset management. The business benefit comes when participants preserve and use the identity, rather than merely including an identifier-shaped value in one document.

A shared identifier needs to survive each handoff.

The ACIF overview describes persistent creative identification and registration as a basis for workflows including reconciliation, frequency management and competitive separation. A VAST UniversalAdId supplies the registry context and creative identifier. These capabilities give systems something consistent to join on when their own campaign and creative keys differ.

That join only works if the parties preserve the same identity and agree what it identifies. A local ad-server key can remain useful inside its own system. A file checksum can identify exact bytes. Neither necessarily represents the registered creative in the way a cross-platform workflow expects. Retain those different identifiers as separate fields and describe the mapping explicitly.

For a reporting analyst at an agency, the practical improvement is a less ambiguous path from a delivery row back to the intended creative. The analyst can trace the registry and identifier through the submission and receiving reports. A missing value or conflicting mapping becomes an exception to investigate rather than a reason to manually reconstruct every creative relationship.

Identity errors can send work in the wrong direction.

Consider an illustrative campaign with a national video and several local variants. If two different variants incorrectly share an identity, a report can collapse distinctions that the campaign team needs. If the same creative acquires unrelated identities along the path, the report can split one asset into several apparent creatives. Both outcomes can make an otherwise simple question expensive to answer.

The question might be which version ran in a region, whether an old offer is still active or which asset should be replaced. Before changing delivery, compare the identifier with the actual source asset and the campaign's version record. An identity field provides a reference. It does not guarantee that the media file behind a URL is the intended version.

This is why identity controls belong in the handoff process. Decide who requests or supplies the registered ID, who maps it to local systems and who confirms that a creative change requires an updated record. Preserve the mapping with the approved asset. A spreadsheet maintained by an unidentified person is a fragile dependency even when every cell currently happens to be correct.

Frequency control needs more than a creative identifier.

A persistent ID can help a system recognize the creative it is considering. It does not independently reveal who has already seen the ad, how often a household should see it or whether two devices belong to the same household. Frequency policy requires additional permitted signals, state and decisioning. Creative identity is one input to that process.

The same qualification applies to competitive separation. Identifying the ad consistently can help retrieve or associate relevant metadata. The decision still depends on the metadata, the rules and the system enforcing them. A valid UniversalAdId does not automatically prevent competing brands from appearing in the same break, and it does not establish that the brand classification is correct.

When evaluating an integration, test the actual decision. Use a known creative mapping and an agreed expected outcome, then inspect the result in the destination system. If the system cannot show which identifier informed the decision, describe that gap. A clean document validation result alone cannot demonstrate that a downstream frequency or competitive-separation policy ran as intended.

The first useful business metric is the unmatched share.

Start by measuring how many relevant reporting rows can be linked automatically to an approved creative record. Define the population and the meaning of a successful match. Include conflicting matches and incorrectly merged records in the quality review. A higher match rate is not an improvement if it comes from treating unrelated assets as the same creative.

Track the time spent resolving unmatched records and how often resolution requires another company. This can reveal a process improvement sooner than a campaign-level revenue metric. The useful outcome may be a report prepared earlier, fewer assets mislabeled or less effort answering a buyer's question. State which result was observed instead of combining them into a general claim of higher ROI.

For illustration, assume a team processes 600 exception rows in a reporting period and a verified identity change removes 400 of them. At an assumed two minutes per row, the potential reduction is about 13.3 hours. Multiply by a measured labor rate only if a monetary estimate helps the decision. The example does not establish actual savings or a typical industry workload.

Correct mappings can reduce the cost of changing a campaign.

A campaign adjustment often touches several systems at once. The operations team needs to know which local creative records correspond to the asset that must be paused, replaced or reviewed. A preserved cross-platform identity can make that search more reliable. It also gives a second reviewer a way to check that the intended creative was changed everywhere in scope.

Measure the work required for a defined change, including the number of systems and the records inspected. Keep the result tied to the specific workflow. If a team reduces manual lookup steps but still needs publisher confirmation, it has improved part of the task. That is useful evidence without claiming that campaign updates are now automatic across the entire market.

Revenue consequences require an additional record. If an old offer remained live, document its actual delivery and the commercial response. If faster identification enabled a replacement before a fixed deadline, retain the relevant times and what was delivered afterward. The presence of an identifier defect does not prove that the wrong asset ran or that any budget was wasted.

Validate the declaration, then verify the identity behind it.

VASTLint's UniversalAdId guide explains the declaration checks in VAST documents. Use the validator to inspect supplied values and their placement. A result can help identify an empty field, an invalid structure or another document issue before the tag is accepted into a campaign workflow.

A document check is not a registry lookup, proof of ownership or confirmation that the ID belongs to the referenced video. Those questions need the relevant registration and asset records. The VAST CTV Addendum 2024 also describes ways to carry newer capabilities through legacy VAST versions. Confirm which representation the actual receiver supports.

Keep a test in which a known identity survives the path from submission to the receiving report. Add a case that deliberately introduces a conflicting mapping and confirm that the workflow exposes it. Retain the original documents and report rows privately where necessary. The evidence should show that the intended identity reached the system that needs to act on it.

The business asset is a maintained creative record.

Assign an owner to the mapping and give changes a review process. Preserve the approved identity, source asset, local system keys and relevant campaign version together. This creates a record another operator can use when the original campaign manager is unavailable. It also makes recurring discrepancies easier to identify without relying on naming conventions that partners may change.

Review the exceptions after introducing persistent identification. Count unresolved mappings, time spent on reconciliation and errors found in completed reports. If the workload changes, normalize the comparison to a relevant campaign or row population. Report whether the gain came from a technical mapping change, a cleanup project or a different mix of campaigns.

Persistent creative IDs provide a common reference that businesses can build on. The operational value appears when reports join correctly, changes reach the right assets and teams can explain exceptions with less reconstruction. Those outcomes are measurable. Broader claims about reduced waste or better campaign performance need the downstream evidence that connects the identity improvement to what actually happened.

11 Curated Deal Mistakes That Clear as Open Auction and Kill Fill

Aleksander Sekowski — Tue, 03 Nov 2026 00:01:52 +0000

IAB Tech Lab marked the Deals API at version 1.0 in February 2026, and trade coverage picked it up again in late October. The API finally names the curator, the origin seller, and the curation fee type. None of that rides on the live bid request. On the wire you still get imp.pmp.deals with a deal id, a floor, and maybe wseat. The audience filter, the inventory bundle, and the data fee you negotiated live upstream, or in a spreadsheet, or in the DSP deal UI. When that upstream layer slips, the auction can clear as open traffic while finance still books a curated CPM. Fill drops because you are bidding the wrong auction, and money leaks because you are paying for packaging that never reached the impression.

Here are eleven ways that happens in production.

private_auction left at 0 on a deal-only buy. OpenRTB 2.6 defaults pmp.private_auction to 0, which means outside bidders may compete. A curated package sold as exclusive should carry private_auction: 1 so only listed deals qualify. If the SSP omits the flag, your deal bid can win, but so can anyone else on the open exchange at a lower price. You thought you bought a walled garden; the request says otherwise.
Deal Sync metadata promises a segment the bid request cannot prove. The Deals API and Deal Sync objects can describe segments, inventory lists, and curator roles. The bid request has no field that says "this impression passed filter X." You validate the deal id in the DSP, not the filter graph. When the curator loosens targeting to recover volume, the first signal is often a win without the audience you sold to the client.
dealid missing on the bid even though imp.pmp.deals listed your deal. The response must echo the deal id when you transact against an in-request deal. Without it, reporting attributes spend to open auction, pacing rules misfire, and loss analytics blame creative filters instead of deal mismatch. Loss reason 213 (not allowed in PMP deal) is real, but so is the quieter case: you win, and finance cannot tie the impression back to the curated line item.
Multiple deals in the array when the buyer activated one. Some exchanges broadcast every PMP they could serve on an impression. Your seat bids deal A; the request also advertises deals B and C for other buyers. That is legal OpenRTB, but it confuses deal-level QA if you sample one id and assume the path is exclusive. You optimize against the wrong floor and wonder why margin disappeared.
wseat or wadomain stripped between curator and exchange. Deal objects can restrict which buyer seats or advertiser domains may bid. Curators sometimes normalize requests for latency and drop optional arrays. Your bid goes in from an allowed seat, loses to a cheaper open bidder, and the seller swears the deal was "activated." The payload tells a different story.
Impression-level bidfloor undercuts the per-deal floor you synced. Floors can live on imp.bidfloor and again on each pmp.deals[].bidfloor. A curated package often sets a higher deal floor to cover data and curation fees. If only the impression floor survives the hop, open auction bids above the low floor and below your economic deal floor steal wins you cannot serve profitably.
Duration floors on video deals ignored after curation repackaging. OpenRTB 2.6 dated snapshots added durfloors and related video deal pricing. A curator bundles long-form CTV with a 30-second creative requirement. The repackaged request drops durfloors because the downstream exchange runs an older profile. Your bidder passes schema checks; the player rejects the creative length.
Curator fee embedded in UI, invisible on the request. TripleLift’s October 2026 Uber audience packages and Multilocal’s FouAnalytics curated PMPs both describe bundled data plus inventory. Neither OpenRTB nor the winning bid exposes how much of the CPM is inventory versus data versus curation margin. When fill softens, buyers cannot tell whether to renegotiate the package or fix targeting.
Supply-side targeting miscounted as "curation." OpenX’s 2026 reporting split audience and content targeting from inventory-only curation. Deals sold as curated bundles may be executed as supply-side targeting packages with different fee and auction rules. Your operational runbook says PMP; the SSP’s internal taxonomy says something else. Spend lands on the wrong report row.
Deal id rotation without DSP sync. Curators rotate ids after package changes. The Deals API row updates; your DSP still bids last month’s id. The exchange treats the bid as non-deal or maps it to a generic PMP with weaker filters. Wins look fine in aggregate until you audit domain and app bundle mix.
Protobuf JSON privateAuction: false on a gRPC hop. On gRPC bid streams the same flag serializes as boolean camelCase. A spec-JSON validator says private_auction: 1; a proto hop silently reads open auction if the field name or type drifts. Curated exclusivity dies in transport, not in the sales contract.

How you catch it

An LLM wiring AdCP, ARTF, or AAMP can emit an OpenRTB request that parses clean and still misrepresents the curated buy. The RPC or MCP task can return OK while private_auction, deal floors, and dealid are wrong for what finance sold.

RTBlint is the deterministic check on that object: imp.pmp.deals, per-deal floors, seat restrictions, and the bid response dealid. It is independent of IAB Tech Lab and of AgenticAdvertising.org; the spec does not require it, but someone has to diff the live request against the deal terms you think you bought.

Run rtblint validate on sampled bid requests from the curated line item, or npm install rtblint-core in CI on fixtures your SSP provides. For ARTF paths that mutate deals, validate the patched request before it hits the exchange, not only the agent’s success bit.

Where to go next

What is curation in programmatic? walks how a curated package collapses to an ordinary deal id on the wire.
Bid floors in OpenRTB covers impression floors versus pmp.deals[].bidfloor and video duration floors.
PMP vs preferred deal vs programmatic guaranteed separates auction types so you know when open competition is allowed by design.
OpenX CTV supply-side targeting vs curation shows why the word "curation" on a rate card may not match IAB’s taxonomy.
Dark pooling and authorized seller id is a supply-path angle when the curated deal’s seller chain does not match the inventory you thought you bought.

An OpenRTB bid floor keeps its own currency.

Aleksander Sekowski — Mon, 02 Nov 2026 19:00:00 +0000

A bid request can allow EUR responses while an impression's floor is still denominated in USD. If an integration reads the response currency list and silently applies it to the floor, its arithmetic can look correct while comparing different units.

The problem is easy to miss because both values are ordinary JSON numbers. Their meaning depends on the currency attached to each field.

This walkthrough uses OpenRTB 2.6's June 2026 specification snapshot. The examples focus on currency handling and are not complete bid requests or production pricing logic.

Follow the field that owns the currency

The request's cur field describes allowed bid response currencies. The impression's bidfloorcur describes the currency of that impression's floor. In the referenced snapshot, the latter defaults to USD when omitted.

Those are separate contracts. Setting cur to ["EUR"] does not rewrite an omitted bidfloorcur to EUR.

Consider this fragment:

{
  "cur": ["EUR"],
  "imp": [
    { "id": "video-1", "bidfloor": 3.20 }
  ]
}

For the impression floor, the omitted currency resolves to USD under the cited specification. A bid price expressed in EUR needs an explicit conversion before a numerical floor comparison makes sense.

There is another scope to review when deals are involved. A deal has its own floor fields. Inspect the applicable deal and exchange contract rather than applying an impression-level assumption everywhere.

Preserve the amount and currency together

Avoid passing a bare number called floor through several functions. Use a structure that carries the amount, currency and source. That makes it harder for a later step to lose the unit or confuse an explicit value with a default.

The following complete Node.js example performs a narrow comparison. The exchange rate is synthetic and is supplied by the caller:

import assert from 'node:assert/strict';

function impressionFloor(imp) {
  const amount = imp.bidfloor === undefined ? 0 : imp.bidfloor;
  const currency = imp.bidfloorcur === undefined ? 'USD' : imp.bidfloorcur;
  if (!Number.isFinite(amount) || amount < 0) {
    throw new TypeError('invalid floor amount');
  }
  if (!['USD', 'EUR'].includes(currency)) {
    throw new TypeError('unsupported currency in this example');
  }
  return {
    amount, currency,
    currencySource: imp.bidfloorcur === undefined ? 'default' : 'explicit'
  };
}

function convertFloor(floor, target, rates) {
  if (floor.currency === target) return floor.amount;
  const rate = rates[`${floor.currency}:${target}`];
  if (!Number.isFinite(rate) || rate <= 0) {
    throw new Error('usable conversion rate missing');
  }
  return floor.amount * rate;
}

const request = { cur: ['EUR'], imp: [{ id: 'video-1', bidfloor: 3.2 }] };
const floor = impressionFloor(request.imp[0]);
const rates = { 'USD:EUR': 0.9 };
const floorInEUR = convertFloor(floor, 'EUR', rates);

assert.equal(floor.currency, 'USD');
assert.equal(floor.currencySource, 'default');
assert.ok(Math.abs(floorInEUR - 2.88) < 1e-12);
assert.equal(3.0 >= floorInEUR, true);
assert.equal(3.0 >= floor.amount, false);
assert.throws(() => convertFloor(floor, 'EUR', {}));
assert.throws(() => impressionFloor({ bidfloor: '3.20' }));
assert.throws(() => impressionFloor({ bidfloor: -1 }));
assert.equal(impressionFloor({ bidfloor: 0 }).amount, 0);

The two comparisons deliberately produce different answers. With this invented rate, a EUR 3.00 bid exceeds the converted EUR 2.88 floor. Comparing the same bid directly with the unconverted USD 3.20 number would reject it.

The example supports only two currencies so that unsupported inputs fail visibly. A production implementation needs a maintained currency set, a rate source and an explicit rounding policy.

Define the direction and age of the rate

A rate named 0.9 is incomplete. State that it means EUR per USD, record when it became effective and identify the source. Multiplying by an inverse rate can produce plausible values without immediately revealing the error.

Attach that metadata to the pricing decision or a retrievable rate snapshot. A later replay should use the rate policy that applied to the original decision, rather than whichever rate happens to be current when a developer investigates it.

Do not treat a missing rate as one-to-one conversion. Decide whether the application should skip the impression, stop the calculation or route the case for review. That decision is business policy and should appear in the diagnostic result.

Likewise, do not round a floor for display and reuse the displayed number in auction logic. Define the precision and comparison behavior required by your integration. Binary floating point, exchange rounding rules and boundary prices need deliberate treatment beyond this small example.

Test defaults and explicit values separately

An omitted currency and an explicit USD currency can lead to the same effective value while carrying different diagnostic meaning. Preserve which path was taken so you can find producers that rely on defaults unexpectedly.

Include fixtures for a missing floor, a zero floor, an explicit non-USD currency and a malformed numeric string. Zero must survive as zero. A truthiness check such as amount || fallback can replace a legitimate value.

Then add a request with multiple impressions and different floor currencies. This catches helpers that compute one request-wide currency and apply it to every impression.

For deal traffic, keep dedicated cases with the deal identifier and applicable floor fields. The test should establish which floor the integration selected before it tests the comparison arithmetic.

Debug a rejected bid with the normalized record

When a bid appears to clear a floor but is rejected, collect the matched impression or deal, raw floor amount, effective floor currency, response currency, conversion snapshot and final comparison value.

Check the units as well as the currency. OpenRTB pricing uses CPM conventions in these fields. An amount interpreted as a per-impression charge introduces a separate scale error that currency conversion cannot fix.

Finally, distinguish your local eligibility calculation from the exchange's auction result. Clearing this one floor check does not establish that the bid is otherwise valid or that it should win.

I maintain RTBlint. Its OpenRTB mistakes reference is useful for reviewing the surrounding request and response contract. Keep the currency decision in your own replay fixture so that a pricing investigation can reproduce the exact comparison.

Sources

OpenRTB 2.6-202606, BidRequest and Imp

Technical sources checked October 25, 2026. Drafted with AI; examples are synthetic unless explicitly stated otherwise.

The AdCP OpenRTB and VAST Mapping Cheat Sheet Every Agentic Bid Ops Engineer Needs

Aleksander Sekowski — Mon, 02 Nov 2026 00:39:03 +0000

On October 22, 2026 AgenticAdvertising.org closed its October town hall with AdCP 3.2 in production and agent-to-agent TV buys moving from demos to repeat campaigns. Fox and Simulmedia alone reported more than 300 spot-level orders executed over A2A this quarter. Every one of those stories ends the same way in engineering: a media buy object, then an ad server or exchange that speaks OpenRTB, then a player that still reads VAST. The MCP task can return OK while the wire objects drift.

This sheet is for engineers wiring buyer agents, sell-side execution, or Prebid-style real-time modules: the people who need to know which AdCP field is supposed to show up as which integer, deal id, or XML child before traffic scales.

AdCP negotiation fields and where they must land

AdCP names constraints in agent tasks (get_products, create_media_buy, sync_creatives). Programmatic execution still uses OpenRTB on the auction hop and VAST on the creative hop. The specification defines several enums by reference to OpenRTB 2.6 and AdCOM; treat the table as the contract your emit layer must satisfy.

AdCP surface	Wire target	What the buyer expects
`video_placement_types` (e.g. `instream`)	`imp.video.plcmt` (1–4)	Same placement class the product filter selected; not deprecated `video.placement`
`audio_distribution_types` (e.g. `podcast`)	`imp.audio.feed`	AdCOM feed type on the impression that clears the auction
Media buy / package deal reference	`imp.pmp.deals[].id`	Bid `dealid` must name a deal actually offered on that impression
Negotiated price and auction type	`deals[].bidfloor`, `bidfloorcur`, `at`, `guar`	Deal floor beats impression floor; PG vs open auction must match the buy
Creative format from `sync_creatives`	`imp.video` / `imp.audio` mimes, duration, protocols	Creative accepted upstream must fit the emitted impression or loss reasons 203/204 apply
Duration-priced video	`imp.video.durfloors`, `mincpmpersec`	Pod pricing fields require pod context on the impression
VAST asset from creative tasks	VAST `InLine` / `Wrapper`, `Duration`, `MediaFile`	Agentic brief does not replace a servable tag the player can fetch
`adagents.json` authorization	Paired with `source.schain` at serve time	Agent allowed to sell ≠ chain complete on this impression
AXE segment response (`axei`, `axex`, `axem`)	OpenRTB user/data and substituted creative URLs	Malformed AXE context fails segment lookup quietly

One cell is the example people paste wrong daily: instream negotiated on the buy but emitted as video.placement instead of video.plcmt. AdCP names align with plcmt; the older field uses a different enum. Schema validators that only know XML or a loose JSON schema will not catch the semantic swap.

Rows that pass agent tests and still break fill

video_placement_types: ["instream"] with only placement: 1 on the bid request. The integer might look plausible. Buyers filtered on plcmt semantics. Downstream reporting that reads AdCOM placement class sees a deprecated signal or none at all. The migration table lives in placement versus plcmt.

create_media_buy success with a deal id never copied into imp.pmp.deals. The agreement exists in the agent transcript. The auction request offers no private deal. Bids that cite the negotiated id die with loss reason 4. Nothing in AdCP task JSON proves the emit layer ran.

sync_creatives OK while the VAST asset URL 404s or omits Duration. Creative governance in AdCP is a different document from the tag the SSAI stitcher or client player pulls. I run those URLs through the VAST tag tester and wrapper chains through the VAST inspector because MCP success on the creative task does not fetch the tag.

How you catch it

Split the check by payload owner. rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) validates the OpenRTB bid request and the bid response against the request that produced it, including AdCP-oriented discovery via get_adcp_capabilities. vastlint (cargo install vastlint, npm install vastlint) validates the VAST or VMAP creative the buy claimed. An implementation that lets a model emit either object still needs that deterministic pass: tool success and RPC OK are not the wire contract. These packages are independent of IAB Tech Lab and of AAO; the specs do not require them.

Practical loop: fixture one product type per placement class, validate the serialized bytes at the emit boundary, then validate the creative URL before launch. For agent stacks, call validation as an MCP tool in the same turn you assemble the request.

Where to go next

Field-level walkthrough of the media-buy handoff: AdCP to OpenRTB mapping guide.
How AdCP sits above VAST and OpenRTB without replacing them: AdCP and VAST on vastlint.org.
When the exchange runs an older dated snapshot than your agent: OpenRTB version mismatch.
AdCOM asset subtype gaps on 2.6 impressions: assetformat subtype required.
MCP tools and capability discovery: rtblint MCP docs.

Agentic buying moved the negotiation up a layer. Fill still reads the same objects it always did.

Creative Readiness Explained: How VAST Becomes Servable on SSAI and CTV

Aleksander Sekowski — Sun, 01 Nov 2026 21:37:34 +0000

On 26 October 2026, TF1 PUB said its streaming pause format AdPause would sell through programmatic pipes, not only direct deals (VideoWeek). That is the same shift Netflix and other CTV sellers pushed earlier in the year: the buyer keeps using the same DSP, but the creative arrives as VAST chosen at auction time. The XML still has to survive a server-side insertion path and a TV-class player. Schema validation is the floor. Creative readiness is whether the tag matches the environment that was bought.

If you have only trafficked browser pre-roll, "valid VAST" feels like a green check in a QA tool. On SSAI and most CTV stacks, the stitcher may fetch your wrapper chain, pull a mezzanine master, transcode renditions, and only then hand the player a MediaFile. The player schedules pods from <Duration>, refuses cleartext media when the app is HTTPS-only, and skips interactive APIs that never had a JavaScript runtime on the device. None of that is optional polish. It is the servability contract.

What the stitcher reads that your browser tag never needed

Server-side ad insertion exists so the manifest stays smooth. The ad decision might still be OpenRTB on the buy side, but the delivery hop is VAST: wrappers collapse to an InLine, media is prepared ahead of the break, and impressions often fire from infrastructure that looks like a data center rather than a laptop browser.

VAST 4.x separates playback renditions from source masters. <MediaFile> is what the player (or the stitcher's output manifest) is supposed to play: delivery, type, width, height, and a reachable HTTPS URL. <Mezzanine> is the high-quality source the SSAI platform uses to generate those renditions. IAB's CTV programmatic guidance treats mezzanine as the asset that lets transcoding happen before the impression window closes. A tag that only lists a single progressive MP4 might be fine on desktop CSAI. On a major SSAI operator, the same tag can be rejected because there is no mezzanine to feed the transcoder, or because the mezzanine URL is HTTP on an HTTPS-only fetch policy.

The gap shows up in attributes, not only in missing elements. A mezzanine node with a URL but without the width, height, or type metadata the operator documents is still a failed handoff: the stitcher cannot queue a job it cannot describe. The mezzanine missing attributes example is the shape of that failure: legal XML, unusable master.

Duration, codec, identity, and transport

Duration is how pod logic knows whether the spot fits the break. SSAI systems allocate slot length from the declared <Duration> in the InLine that will actually play. A wrapper that never resolves, or an InLine whose duration disagrees with the mezzanine by more than the operator tolerance, produces empty avails or mid-roll overruns. Players on CTV also use duration for quartile tracking even when the stitcher normalized the file.

Codec and container ride on MediaFile@type and on what the device decode chain accepts. H.264 in an MP4 container is still the common denominator on living-room hardware, but operators publish allow lists. A creative that validates as video/mp4 while the bytes are an unsupported profile, or a mezzanine the transcoder cannot ingest, dies after the auction with a transcode error your DSP never sees.

HTTPS is not pedantry. Many players and stitchers refuse to fetch http:// media when the app context is secure. A single cleartext redirect in the chain fails the whole creative even when every XML element is present.

UniversalAdId ties the served asset back to the record trafficking, finance, and brand safety expect. VAST 4.x places <UniversalAdId> under <Creative> with a registry such as ad-id.org. Duplicate IDs across flights, missing registry, or an ID that does not match the CDN object name are readiness bugs: the spot might play once while downstream systems treat it as the wrong creative. The Universal Ad Id guide walks the element and registry pairing practitioners still mix up.

Interactive APIs are part of readiness too. VPAID as an apiFramework on a linear <MediaFile> was deprecated in VAST 4.1 and has no runtime on SSAI or on most CTV devices. Tags that still declare VPAID validate against older samples and fail at serve time. If you are migrating off script-based units, the VPAID deprecation write-up is the policy context; readiness work is replacing the script path with SIMID or plain video plus <TrackingEvents>.

How the buy signal meets the tag

Programmatic CTV adds a second layer: the format signal on the bid must match the VAST shape. Pause, overlay, and squeezeback placements use NonLinear or companion structures with AdCOM extensions for plcmt, pos, and playbackmethod. A linear InLine trafficked into a pause deal validates as VAST and fails the player because the environment expected a static or NonLinear unit. TF1's note about differing seller specs is the business version of the same problem: one campaign ID cannot assume every publisher accepts the same NonLinear timing or asset type. Our Netflix programmatic pause ads and NonLinear VAST post is the sibling pattern for another publisher surface; the readiness lesson is identical: narrowest route wins, and the tag must encode that route.

The CTV Ad Portfolio signaling and validation article connects portfolio metadata to the VAST payload: the signal tells the player which format was bought, but it does not transcode your mezzanine or fix HTTP media.

How you catch it before fill drops

Start with a live fetch, not a pasted fragment from last year's template. The VAST tag tester pulls the tag URL, shows the resolved creative, surfaces tracking and click URLs, and lets you preview what the player would receive after redirects. Wrapper-heavy paths belong in the VAST inspector, which walks each hop, shows depth, and pinpoints where the chain stops before an InLine.

After preview, run vastlint (cargo install vastlint or npm install vastlint) on the same document. An LLM implementing AdCP, AAMP, or a trafficking assistant can emit VAST that looks plausible and still miss mezzanine, duration, or HTTPS rules; the RPC or the upload endpoint can return OK while the stitcher rejects the asset. vastlint is the deterministic check on the creative the buy claimed. It is independent of IAB Tech Lab and of AgenticAdvertising.org; it is not an official conformance harness, and the spec does not require it. It is how you catch wire-level mistakes before they become zero-fill lines on CTV.

When the placement is portfolio interactive (SIMID on InteractiveCreativeFile, sample IAB creatives, host transport logs), use the IAB-style VAST tester for handshake debugging. That workbench is an independent fork, not an IAB Tech Lab product; linear mezzanine readiness still starts with the tag tester and inspector above.

For trafficking into Google Ad Manager or other SSAI-backed video, the VAST and Google Ad Manager guide maps common GAM expectations to the elements above. Rewarded and other non-standard breaks add player constraints on top; the rewarded VAST guide is the place to align skip and completion semantics with duration.

Where to go next

Treat readiness as a checklist per destination: mezzanine present and described for SSAI, MediaFile attributes complete for the player, HTTPS end to end, UniversalAdId aligned with trafficking, duration matching the break, and no deprecated interactive APIs on living-room inventory. When programmatic opens a new CTV format, copy the narrowest creative spec across DSP routes before you widen assets. Validation green in a desktop tool is not evidence the stitcher queued your master; fetch, inspect, and lint the same URL the player will use on the night the campaign goes live.

VAST errors 301, 302 and 303 need different debugging steps.

Aleksander Sekowski — Sat, 31 Oct 2026 18:00:00 +0000

A blank video slot is an observation. It is not a diagnosis. If the creative travels through VAST Wrappers, the useful starting point is the document sequence the player actually attempted to resolve.

VAST 4.3 distinguishes several wrapper-related failures. Error 301 concerns a wrapper URI timeout or unavailability. Error 302 concerns the player's wrapper limit. Error 303 concerns no ads returned after one or more wrappers. Those categories lead to different experiments.

The investigation below uses synthetic responses and a controlled player. The trace format is application-owned, not a VAST schema.

Capture the chain the player used

A top-level tag can return different content depending on the request context. Save the URL template, the relevant expanded request values and the returned documents for the test run. Remove credentials from the copy attached to a public ticket.

Record one row per attempted VAST fetch. Include the start time relative to the run, elapsed time, HTTP outcome, response type and whether resolution continued. Keep HTTP redirects distinguishable from VAST Wrapper transitions.

A useful minimal record looks like this:

{
  "run_id": "synthetic-wrapper-run-01",
  "player_build": "test-build-8",
  "configured_wrapper_limit": 5,
  "configured_fetch_timeout_ms": 1500,
  "hops": [
    { "hop": 1, "kind": "Wrapper", "elapsed_ms": 22 },
    { "hop": 2, "kind": "Wrapper", "elapsed_ms": 31 },
    { "hop": 3, "kind": "empty_VAST", "elapsed_ms": 18 }
  ],
  "observed_error": 303
}

The configured values are illustrative. They are not universal player defaults. Put the actual values in the record because a result dependent on a timeout or depth limit cannot be reproduced without them.

Also preserve the terminal response body. An empty VAST document, an HTML error page and an unreachable server are different inputs even when the user sees the same empty slot.

Investigate 301 by locating the failed fetch

Start with the request that did not yield the next usable VAST response. Did the player make it? Did DNS resolution, connection setup or response transfer fail? Did a server return a response after the player had already stopped waiting?

Use the request timing and server logs together when available. A successful request in a server log does not prove that the player received it before its deadline. Conversely, a missing server log does not identify which network layer prevented the request.

Reproduce the case with a deterministic endpoint that deliberately responds beyond the configured timeout. Keep the document sequence unchanged. If you also change wrapper depth or creative content, you will have several possible explanations for a changed result.

Then move the response delay just inside the test budget. Observe whether resolution continues and which document the player processes next. The result should establish a timing boundary for that player configuration, not a promise about every production device.

Investigate 302 with a low-latency chain

A wrapper limit is about the chain the player is willing to follow. To test it, serve a deterministic sequence of quickly returned Wrapper documents and increase the depth one transition at a time.

Record how the player counts wrappers. Does the configured value represent the maximum followed transitions or another documented convention? Preserve the observed terminal hop rather than assuming every player uses the same counting rule.

Keep latency low enough that the test reaches the depth boundary. A long chain of slow endpoints can fail on time before it exercises the configured wrapper limit. Calling that a depth regression would send the investigation in the wrong direction.

Also check for a loop. A chain that alternates between the same serving endpoints may eventually hit a limit, but the practical repair is to remove the loop. Log normalized diagnostic identities carefully: removing query parameters can conceal the values that distinguish two legitimate requests.

Investigate 303 by inspecting the terminal document

For this scenario, preserve a chain that reaches a well-formed empty VAST response after a wrapper. Verify the response bytes and the context in which the player requested them.

An empty response can represent no available ad. Ask whether the serving system intended that outcome for the supplied targeting, consent and inventory context. A tag pasted into a different environment may not reproduce the same eligibility decision.

Do not repair an empty response by manufacturing an Inline ad or changing the error code in a dashboard. The useful result is an explanation for why the downstream system returned no ad and whether that was expected.

Keep the player observation with the terminal document. Error handling depends on serving context, wrapper options and implementation behavior. Avoid labeling every empty VAST response as 303 without checking how it was reached.

Build a small regression matrix

Use a single baseline chain that resolves to a known test Inline. Then create three separate fixtures:

Delay one wrapper endpoint beyond the configured fetch budget.
Extend the chain beyond the configured wrapper limit while keeping responses fast.
Replace the terminal response with an empty VAST document after a wrapper.

For each run, save the fixture revision, player build, relevant settings, hop trace and emitted error. State the expected category and compare it with the observation. If they differ, keep the failed run rather than editing the expected result to match.

After a repair, rerun the baseline and the affected failure case. Also verify that the fix did not merely skip a wrapper carrying required tracking or verification resources.

Write a ticket someone else can reproduce

A useful report names the failing hop, includes sanitized request context and attaches the terminal response or transport failure. It distinguishes the player's emitted code from your diagnosis.

For example, observed 301 at hop three is evidence. Supplier outage is a hypothesis until logs or a controlled reproduction support it. Keeping those separate makes the ticket easier for another team to act on.

I maintain VASTlint. The wrapper-chain guide provides a reference for inspecting the document sequence. Pair that inspection with the player trace: a clean fetch from a server-side tool does not reproduce the device's network path, timeout settings or runtime behavior.

Sources

VAST 4.3, error reporting and wrapper handling

Technical sources checked October 25, 2026. Drafted with AI; examples are synthetic unless explicitly stated otherwise.

DEV Community: Aleksander Sekowski

A GA4 debug response can expose events your HTTP status hides.

Make the debug response part of the contract

Send the payload you intend to deploy

Design useful negative cases

Verify collection in the intended stream

Make CI results explain the failure

Sources

VMAP gives ad break inventory a schedule that engineering and revenue teams can test.

A planned break is an opportunity that still needs execution.

Break scheduling and pod composition need separate acceptance checks.

The forecast needs to distinguish sessions from billable impressions.

More break opportunities can change the content business too.

A reproducible schedule can reduce launch and support work.

VASTLint can check the schedule before the player test.

Engineering and revenue should review the same break record.

The IAB Privacy String Cheat Sheet Every Ad Ops Engineer Needs

The sheet

Three rows that validate and still fail in production

How you catch it

Where to go next

OpenRTB Content Taxonomy Explained: How cat, cattax, and gtax Version the Bid

What cat actually is

Genre is a different column, with a different default

How AdCOM lists tie the wire together

How you catch it

Where to go next

OMID browserOptional describes the JavaScript environment.

Describe the environment precisely

Validate the XML attribute before selecting a resource

Keep eligibility separate from successful execution

Test the matrix that your deployment will use

Use runtime failures to narrow the next step

Put the declaration and observation in the same review

Sources

SSAI VAST Ingest vs CSAI Ad Tag: The Fill Gap Your Browser QA Cannot See

What SSAI ingest actually consumes

What CSAI and browser QA actually test

Where the two paths disagree without looking "broken"

How you catch it

Where to go next

Persistent creative IDs make video campaign reconciliation easier to repeat.

A shared identifier needs to survive each handoff.

Identity errors can send work in the wrong direction.

Frequency control needs more than a creative identifier.

The first useful business metric is the unmatched share.

Correct mappings can reduce the cost of changing a campaign.

Validate the declaration, then verify the identity behind it.

The business asset is a maintained creative record.

11 Curated Deal Mistakes That Clear as Open Auction and Kill Fill

How you catch it

Where to go next

An OpenRTB bid floor keeps its own currency.

Follow the field that owns the currency

Preserve the amount and currency together

Define the direction and age of the rate

Test defaults and explicit values separately

Debug a rejected bid with the normalized record

Sources

The AdCP OpenRTB and VAST Mapping Cheat Sheet Every Agentic Bid Ops Engineer Needs

AdCP negotiation fields and where they must land

Rows that pass agent tests and still break fill

How you catch it

Where to go next

Creative Readiness Explained: How VAST Becomes Servable on SSAI and CTV

What the stitcher reads that your browser tag never needed

Duration, codec, identity, and transport

How the buy signal meets the tag

How you catch it before fill drops

Where to go next

VAST errors 301, 302 and 303 need different debugging steps.

Capture the chain the player used

Investigate 301 by locating the failed fetch

Investigate 302 with a low-latency chain

Investigate 303 by inspecting the terminal document

Build a small regression matrix

Write a ticket someone else can reproduce

Sources

What `cat` actually is