DEV Community: Aleksander Sekowski

Unity loss codes 1213 through 1222 are the offensive-content bucket.

Aleksander Sekowski — Sat, 17 Oct 2026 15:00:00 +0000

Offensive content on Unity Exchange is a range, not a single code. The loss notification still carries one integer, and that integer is what shows up in a bidder's loss report.

1213, 1214, 1215, 1216, 1217, 1218, 1219, 1220, 1221, and 1222 are the ten codes in the middle of that bucket. Unity's table uses the same review reason for each of them. 1224 through 1226 continue it.

A price change will not clear these. The creative Unity reviewed is the thing the status is attached to. A new asset gets a new review. The same asset keeps the same code.

9 CTV Creative Readiness Mistakes That Pass Validation and Still Kill Fill

Aleksander Sekowski — Sat, 17 Oct 2026 00:20:33 +0000

On 13 October 2026, Pixalate shipped Ad Fraud API 3.0 with named invalid-traffic reason codes, including SSAI Misrepresentation for requests that claim server-side insertion but fail metadata checks. That is progress on the bid object. It is not proof that the VAST the stitcher pulls next carries playable media. Court TV and other publishers are rolling out Yospace-style SSAI while buyers still QA tags with XSD and a green dashboard. The gap between those two checks is where CTV revenue quietly disappears.

Creative readiness means the tag matches the environment that was bought: SSAI transcode paths, HTTPS-only players, pod clocks, and identity fields on the deal. A document can validate and still never serve. These nine mistakes show up in production more often than hard XML syntax errors.

Treating SSAI Misrepresentation clearance as VAST clearance. A pre-bid block or allow on reason code SSAI Misrepresentation runs on request metadata, not on the stitched response. The same operator can pass the filter and still forward wrappers whose inline never collapses to a servable MediaFile. We wrote up that split in SSAI misrepresentation reason codes versus VAST proof.
Shipping only a progressive MediaFile when the stitcher expects a mezzanine. VAST 4.1+ recommends a mezzanine file for downstream transcoding. SSAI operators often ingest mezzanine and emit renditions. A tag with a single MP4 and no mezzanine can validate while the transcode queue has nothing to work with. See mezzanine rules and attributes.
Mezzanine present but missing delivery, type, width, or height. Stitchers skip files that look like URLs without the attributes their packager reads. Demo tags copied from IAB samples often include the shape; production swaps the URL and drops dimensions during CMS export.
HTTP media on HTTPS-only CTV surfaces. Schema checks rarely enforce TLS on every MediaFile and tracking URL. Living-room players and many SSAI edges refuse mixed content. The tag fetches in a desktop validator and dies on device.
VPAID or legacy interactive flags on a live CTV stitch. Interactive creatives belong in a controlled player context. Server-side insertion paths on CTV commonly block VPAID outright. An InteractiveCreativeFile with apiFramework="VPAID" can pass XSD and fail at stitch time. VPAID on CTV blocked documents the environment rule. If you replace VPAID with SIMID, handshake QA belongs in the independent IAB-style VAST tester fork (not an IAB Tech Lab product).
Duration longer than the ad break slot. VMAP and pod logic use declared duration to schedule slots. A 60-second Duration inside a 30-second break does not always fail validation; it fails scheduling and yields an empty pod or a skipped ad.
Duration that disagrees with the encoded asset. Players that trust the XML clock can cut off early or hold black frames. Billing and quartile trackers desync from what the viewer saw. Pod guides cover how sequence and duration interact in VAST ad pods.
Missing or empty UniversalAdId on a deal that requires ACIF identity. Registration frameworks and buyer macros assume a registry and value pair. A blank id or wrong registry validates structurally and fails clearance, so the impression never bills.
QAing the client-side wrapper while SSAI ingests a different hop. Trafficking pastes a VAST URL into a DSP; the stitcher resolves a wrapper chain on the server. Impression nodes on outer wrappers, missing InLine handoff, or depth limits bite on the path the stitcher walks, not the path someone opened in a browser. Rules such as wrapper impression placement matter on the chain SSAI actually follows.

How you catch it

Start with the live tag URL in the VAST tag tester: fetch, preview the creative, and confirm tracking and click URLs resolve. When the tag is a wrapper, open the VAST inspector and walk hops until you hit the InLine the stitcher must collapse to.

After that, run the same XML through vastlint (cargo install vastlint or npm install vastlint) in CI or on the saved response. An LLM or agent can emit VAST that looks plausible and still miss mezzanine, HTTPS, duration, or identity rules. vastlint checks the creative payload the buy claimed. It is independent of IAB Tech Lab and of AgenticAdvertising.org; it is not an official harness and the spec does not require it.

Where to go next

Mezzanine file requirements for SSAI transcode paths.
VAST ad pods when duration and sequence must fit the break.
SSAI misrepresentation versus VAST proof when fraud filters and tag QA disagree.
Wrapper impression rules on chains the server resolves.
Start tracking event semantics once media actually plays.

Migrate VPAID interactivity to SIMID when your delivery partners can support it.

Aleksander Sekowski — Fri, 16 Oct 2026 16:36:35 +0000

Originally published on VASTLint. This article is part of the Migrate video standards with evidence series.

An interactive video campaign becomes expensive to operate when every destination needs a different creative package. The sales team sells one experience, the studio builds several implementations, and operations discovers the exceptions near launch. A migration should reduce that repeated work while preserving the experience the advertiser bought.

SIMID is a useful destination for interactive video, but a migration decision needs more than a newer acronym. Start with the placements you can actually serve, the interactions those placements support, and the evidence required to call the campaign ready. A format that passes a document check can still encounter an unsupported player.

Separate the interactive experience from video playback.

IAB Tech Lab describes SIMID as the interactivity component of the move away from VPAID. The interactive layer communicates with the player through defined messages while the media remains separate. The player controls playback and handles requests from the creative. Measurement belongs in the Open Measurement path.

That separation gives a migration team a concrete engineering objective. The video should play through the destination's normal media pipeline. The interaction should add the approved behavior without taking ownership of the whole playback implementation. The test plan can then distinguish a media failure from an interaction failure.

Treat any claimed commercial benefit as a hypothesis to measure. If one reusable package replaces several destination-specific builds, record the builds avoided and the remaining exceptions. If the same engineering work merely moves into a new adapter, the operating cost may not have improved yet.

Start with one interaction you can sell and test.

Choose a narrow experience, such as a product information panel with an approved destination link. Write down the required user actions, the allowed player responses and the behavior when the interaction cannot run. Avoid making the first release depend on every feature of an existing VPAID creative.

Ask each publisher or platform to confirm support for that exact experience on the intended app, device and delivery method. A general statement that a platform supports VAST or interactive video does not answer whether the proposed SIMID package will execute there. Save the tested player and SDK versions with the acceptance record.

Specify the business fallback too. If the interactive feature was an optional enhancement, ordinary video may be acceptable. If the advertiser bought a particular interaction, losing that feature can change the delivered product. Operations should not silently count the fallback as equivalent fulfillment.

Keep verification on its own migration track.

Inventory everything the old creative does. Some VPAID packages combine an interaction, a measurement vendor integration and media handling. Replacing only the interaction does not demonstrate that the verification requirement has been met.

Create a separate acceptance record for measurement. Identify the destination integration, the verification resource and the provider that must receive usable signals. Require a runtime test in addition to checking the VAST declaration. A successful interaction is evidence about the interaction, not about the provider's measurement report.

Keep this distinction in the handoff to commercial teams. An experience can be visually correct while failing a buyer's verification requirement. Conversely, a properly measured video may lack the interactive feature that the campaign proposal promised.

Run a small pilot with an explicit failure path.

First, save the current creative, VAST response and expected behavior. Build the SIMID version against the published interface specification, then validate its document with VASTLint. Retain the findings and corrected document so the next reviewer can see what changed.

Next, run the package in each approved destination. Test normal playback, the intended interaction, a blocked interaction resource and a slow response. Record what the user sees, whether the video continues as agreed and which events reach the relevant reporting systems. Include an ordinary non-interactive video as a control.

Release only to the destinations that passed those checks. Keep a routing rule and a tested rollback package. A practical pilot produces a list of approved environments with evidence, rather than a global switch labeled migrated.

Measure the work saved before projecting revenue.

Compare the pilot with a similar recent campaign. Count creative packages produced, review rounds, destination-specific fixes and support time. Record the campaign scope so a small two-placement pilot is not compared directly with a large multi-market launch.

Suppose, as an illustration, a team normally spends six hours adapting one experience and spends four hours on the new route. The observed result would be two hours less work for that comparison. It would not establish a universal reduction, additional impressions or increased sales. Include any extra player integration work before claiming net savings.

For an advertiser, the commercially relevant question may be whether the requested interactive product can reach the booked placements. For a publisher, it may be whether the feature can be accepted without custom creative execution. Those are specific outcomes that a pilot can document.

Expand from an approved delivery contract.

Write the accepted media requirements, interaction behavior, verification requirements and fallback policy into the creative brief for the next campaign. Give the studio and trafficker the same test record. Require an explicit review when a new device or delivery path is added.

Use VASTLint to repeat the document checks at each handoff. Keep player execution and provider reporting as separate acceptance steps. The migration earns its place when a second campaign can reuse the approved route with less uncertainty and a clear explanation of its remaining limits.

Unity uses one review reason for loss codes 1200 through 1208.

Aleksander Sekowski — Fri, 16 Oct 2026 15:00:00 +0000

Unity's creative-review codes look like a long enum. For user security they are not. The public loss table assigns the same sentence to every integer from 1200 through 1208: the exchange review rejected the creative for a user-security issue. 1227 is the same bucket later in the list.

Read the number you actually received. 1200, 1201, 1202, 1203, 1204, 1205, 1206, 1207, and 1208 are that run. 1227 is the later user-security code.

Resubmitting the same asset returns the same integer. Unity does not publish which security check inside the bucket failed. The practical step is a new creative, then a check that the new crid is the one in the bid.

The CTV Ad Portfolio Cheat Sheet Every Video Ad Ops Engineer Needs

Aleksander Sekowski — Fri, 16 Oct 2026 00:17:52 +0000

On October 9, 2026, The Trade Desk framed pause ads as the next leg of a broader CTV portfolio: formats beyond the midroll break, each with its own moment on the glass. Netflix had already said pause would move onto partner DSPs in October. The hard part is not finding budget. It is matching three layers that were finalized separately: AdCOM integers on the bid request, the VAST envelope in adm, and what the player or stitcher actually schedules. IAB Tech Lab closed the CTV Ad Portfolio signaling guidance on July 22, 2026. That document is a table of enumerations, not a creative QA checklist. Programmatic pause in particular still splits by route, which we mapped in Netflix pause ads go programmatic, and each buying route accepts a different NonLinear creative.

This sheet is for video ad ops and trafficking engineers who receive a DSP export, an SSAI template, or an agent-generated VAST blob and need to know, in one screen, which OpenRTB signals and which VAST subtree belong together. Bookmark it next to your plcmt reference. One wrong integer pair can validate and still never render.

Format-to-signal and VAST shape

Five portfolio formats ride imp.video and return NonLinear VAST in adm. Menu and tile units ride imp.native and may embed VAST inside video.vasttag; they do not use the NonLinear container. Values below come from IAB's Signaling Implementation Guidelines format table.

Format	`video.plcmt`	Typical `pos`	Typical `playbackmethod`	VAST delivery	Tracking the player expects
Pause	5	7 fullscreen, 8 partial	8 sound on, 9 sound off (user pause)	`<NonLinearAds>` with static, cinemagraph, or video asset	`creativeView`, `overlayViewDuration`; quartiles only when `<Duration>` is present on video
Screensaver	6	7 or 8	10 sound on, 11 sound off (idle)	`<NonLinearAds>`; often static	Same NonLinear set; duration optional for stills
Overlay	7	9, 10, 14, 15, or 5 by geometry	Often 1 or 2 (autostart sound on/off)	`<NonLinearAds>` with image or video	`creativeView`, `overlayViewDuration`; include `<Duration>` when time-based beacons matter
Squeezeback	8	11, 12, 13, 16, or 17 by layout	Often 1 or 2	`<NonLinearAds>`; content frame shrinks	Same as overlay; `pos` must match squeezeback layout, not pause fullscreen
In-scene	9	(format-specific)	Often 1 or 2	`<NonLinearAds>` insert in scene	`bid.attr` should declare motion; NonLinear tracking as above
Menu / tile	Native `plcmttype` 1 or 3	N/A on video object	N/A	Native `img.url` and/or `video.vasttag` (may wrap linear VAST)	Native `eventtrackers` plus embedded VAST pixels

Downstream, DSPs echo plcmt, pos, playbackmethod, and attr into VAST AdCOM extensions so stitchers that never saw the bid can still read what was sold. The child element name must match the extension type. A type="pos" wrapper with a <plcmt> child is well formed XML and wrong semantics.

Interactive portfolio units that use SIMID declare <InteractiveCreativeFile apiFramework="SIMID"> under <NonLinear> in the VAST 4.4 pattern, with a renderable <MediaFile> fallback. That handshake is separate from the signal table, but the same rule applies: the buy must match the container.

Three table rows that pass schema and lose the impression

Pause plcmt with a linear <Linear> creative. OpenRTB can carry plcmt=5 while adm is a standard instream MP4 under <Linear>. XSD checks pass. CTV portfolio players look for <NonLinearAds>. The spot does not enter the pause overlay path; the impression disappears without a trafficking error code. This is the most common copy-paste failure when a team reuses a :15 preroll tag for a pause deal.

plcmt=5 paired with squeezeback pos and instream playbackmethod. Each integer is legal AdCOM. Together they describe pause, squeezeback, and ordinary autoplay at once. Stitchers that enforce portfolio rules reject the mismatch; lenient parsers attach the wrong geometry. vastlint flags cross-format pairs such as pause plcmt with playbackmethod 1 instead of 8 or 9.

Video <MediaFile> under <NonLinear> with no <Duration>. IAB allows omitting duration for static pause and screensaver assets when display time is unknown at response time. Add a looping MP4 for a cinemagraph pause, and quartile URLs plus overlayViewDuration have no timeline. The tag validates; measurement flatlines. That row is easy to miss because the same NonLinear subtree works for a JPEG.

How you catch it

Schema validation alone cannot enforce the table. You need the resolved tag the player sees, including wrapper hops.

Paste the live tag URL into the VAST tag tester to fetch, preview the NonLinear asset, and confirm tracking URLs fire on the events your MMP expects. When the ad server returns wrappers, open the VAST inspector and walk the chain hop by hop until you hit the InLine that carries <NonLinearAds>.

For SIMID or IAB sample creatives on portfolio placements, use the IAB-style VAST tester (SIMID studio and sample tags). It is an independent fork, not an IAB Tech Lab product, but it exercises the interactive NonLinear path the portfolio spec describes.

After preview, run vastlint on the final XML (cargo install vastlint or npm install vastlint). An agent or MCP task can emit portfolio VAST that parses clean while plcmt, pos, and playbackmethod still disagree. vastlint is the deterministic check on the creative the buy claimed. It is independent of IAB Tech Lab and of AAO; the spec does not require it, but it encodes the same format-to-signal rows as rules you can run in CI.

Where to go next

VAST 4.4 and CTV portfolio changes for NonLinear <MediaFiles>, duration, and AdCOM extension typing.
CTV Ad Portfolio pack for format-by-format notes and rule ids.
Pause ads guide with a full static pause NonLinear example and signal checklist.
OpenRTB video.plcmt reference for values 1 through 9 on the bid side.
Wrapper chains guide when the portfolio creative sits three hops deep and the InLine never reaches QA.

Unity loss 1011 means the bid never named a billing URL.

Aleksander Sekowski — Thu, 15 Oct 2026 15:00:00 +0000

Unity 1011 is the loss code bidders look up as a Unity RTB error after a bid that otherwise parsed. The bid had no billing notice on burl and no impression trackers on ext.imptrackers. Unity wants one of those.

1011 is the page for that check. The codes around it are different failures that show up in the same hour of a log.

1010 is an IAB category the publisher blocked. 1012 is a bid that arrived after Unity's auction window. 1200 starts the user-security review bucket: Unity uses 1200 through 1208 for that one reason and does not publish a separate cause per integer. 1209 is a blank creative or a 1x1 pixel. 1210 is a performance disapproval. 1212 is a creative with no media file. 1213 starts the offensive-content bucket. 1234 is a quality rejection from Unity's automated review. 1235 is a quality rejection from a human reviewer.

If the integer is 1011, the fix is the tracker. The other nine are the codes it gets confused with.

GPP Explained: How Privacy Strings on the Bid and Tag Gate Creatives

Aleksander Sekowski — Thu, 15 Oct 2026 00:16:13 +0000

IAB Europe set October 23, 2026 as the deadline for consent management platforms to ship the new TCF v2.4 disclosures on the web, with mobile and CTV following in February 2027. The timeline letter confirms the spec and Global Vendor List update landed July 23, 2026. Disclosed-vendor bits and clearer feature text change what a TC string is allowed to mean. That matters downstream because exchanges and DSPs do not re-run your CMP UI. They read whatever string arrived on the bid request or the pixel URL and decide whether the creative's vendors may fire.

Programmatic fill is not only codec and duration. It is also whether the privacy signal grants the measurement and ad tech companies embedded in the tag. A VAST InLine can validate, a bid can win, and the buyer still records a loss or a blank when consent does not cover vendor 755 on the GVL.

What rides on the OpenRTB bid request

OpenRTB 2.6-202211 gave GPP a first-class home. You put the encoded consent container in regs.gpp and the applicable section identifiers in regs.gpp_sid. GDPR traffic still pairs regs.gdpr with the IAB Europe TC string in user.consent. The OpenRTB privacy field guide walks the same paths for 2.5 extension placements versus 2.6 top-level fields.

A common failure mode is half a signal. An SSP forwards regs.gpp_sid: [7] after an edge rewrite but drops regs.gpp. The section id tells the bidder which grammar to expect; without the string there is nothing to decode. RTBlint flags that pattern as incoherent on the wire. Another failure is the inverse: a long base64 blob in user.consent while regs.gdpr is omitted, so the exchange treats the auction as non-GDPR and applies the wrong policy.

US state and national signals increasingly ride inside GPP rather than the legacy four-character regs.us_privacy string IAB Tech Lab deprecated on January 31, 2024. During transition many stacks still read both. If GPP section 7 says opt-out of sale and us_privacy still reads 1YNN, you have contradictory instructions and no deterministic winner unless the buyer documents precedence.

Google's creative status codes in the 200 range include cases where the TC string does not consent to a vendor present in the creative. That is not a VAST schema error. The XML is fine. The privacy contract on the bid is not.

What rides on the tag and the pixel

Not every hop runs OpenRTB. Impression pixels, verification scripts, and server-side conversion posts carry the same strings through query parameters and macros. TCF expects the TC string to propagate as-is. A tag manager that truncates, re-encodes, or substitutes a placeholder breaks vendor-level checks even when the page looked compliant at banner time.

The Global Privacy Platform wraps multiple jurisdiction-specific sections in one transport string. Section type lives in the header; decoders must read that header before they interpret payload bits. Treating a GPP blob like a raw TC string, or passing gdpr_consent=1 because the macro defaulted to a boolean, produces values that are syntactically plausible and semantically empty. Pixellint's GPP documentation and TCF v2 guide separate those grammars so you can lint the string itself, not just whether the HTTP request returned 200.

Server-side stacks amplify the risk. Edge auctions and Trusted Server-style paths rebuild OpenRTB after the browser blocked sync pixels. If the reconstructed regs.gpp and user.consent disagree with what the CMP emitted on the page, the compliance failure moves from DevTools to logs buyers never see. The enforcement point changed; the requirement that the string match user choice did not.

Video adds a third surface: VAST Impression and Tracking URLs often expand ${GDPR_CONSENT_xxx} macros at serve time. The consent string on that URL must still match the bid the DSP won with.

How decoders turn strings into serve / no-serve

For GDPR, regs.gdpr=1 tells the bidder to apply TCF rules. The TC string encodes purposes, vendors, and (since v2.3) which vendors were actually disclosed in the CMP UI. TCF v2.4 tightens GVL feature text and removes ambiguous legitimate-interest shortcuts for certain vendor classes. A bidder comparing your creative's AdVerification vendor list against the consent bitmap is implementing that policy, not XML validation.

For US and multi-state traffic, GPP section IDs in regs.gpp_sid tell the decoder which slice of the container applies. New sections continue to land; the GPP sections update for 2026 is the map for what showed up in recent IAB Tech Lab revisions versus what your exchange still ignores.

COPPA and child-directed inventory add a parallel gate: regs.coppa=1 tells buyers to suppress behavioral use regardless of what a generic consent string says. Sending rich user.eids under COPPA is a policy violation even when the JSON schema accepts the fields.

One concrete mistake: copying a consent macro from a display template into a video tracking URL without the vendor id the video partner registered. The string validates as base64; the vendor bits are zero for that id; measurement never starts and nobody gets a VAST error code.

How you catch it before fill drops

An LLM wiring AdCP, ARTF, or a Prebid adapter can emit regs.gpp and user.consent that parse and still misrepresent what the CMP showed. The RPC or the adapter callback can return OK while the exchange applies a stricter decode.

rtblint owns the OpenRTB object: cargo install rtblint or npm install rtblint-core, then validate the bid request JSON against the dated snapshot your partner runs. pixellint owns the string on the beacon or tag URL: cargo install pixellint or npm install pixellint for TC, GPP, and legacy US privacy formats. These packages are independent checks; they are not IAB Tech Lab or AAO official harnesses, and the specs do not require them, but they catch the drift an agent implementation will miss.

When consent rides a live VAST tag, use the VAST tag tester to fetch the served XML and inspect expanded impression URLs, and the VAST inspector when wrappers strip or rewrite macros hop by hop.

Start from consent on the wire when you need to compare CMP output, ad tag macros, and SSP forwarding on the same request id. The consent overview ties IAB formats to the fields your pixels actually fire.

Where to go next

Privacy signals in OpenRTB for field-by-field placement across 2.5 and 2.6 snapshots.
GPP on pixellint for header types and section decoding before you trust a macro expansion.
TCF v2 on pixellint for disclosed vendors and purpose bits that changed under v2.4.
GPP new sections in 2026 when your gpp_sid list outgrows what your bidder's policy table knows.

Fix the string on the same hop as the creative decision, not after the loss report shows "consent vendor mismatch" with a perfectly valid VAST file attached.

Unity's first ten loss codes are validator failures and publisher blocks.

Aleksander Sekowski — Wed, 14 Oct 2026 15:00:00 +0000

A Unity loss code in the 1000s never appears in the OpenRTB table. Unity Exchange returns it in ${AUCTION_LOSS} when the bid failed Unity's own checks before price mattered.

The first four are on the bidder. 1000 means Unity's OpenRTB validator rejected the payload. 1001 means the body was not JSON. 1002 is the catch-all marketplace block, the code Unity uses when it will not name a narrower rule. 1003 is specific: the advertised app's age rating is above the publisher's maximum.

The next six are publisher blocks, still on Unity's integers. 1004 and 1005 are crtype on a consolidated request: missing, or not one of the ad types Unity sent. 1006 is the region. 1007 is the platform, iOS or Android. 1008 is a sensitive attribute such as real-money gambling. 1009 is a Unity subcategory the publisher turned off.

The full list, including 1010 through the creative-review codes, is the Unity loss index.

AdCP Video Buy vs VAST InLine: The MCP Task Can Finish Before the Player Has a Spot

Aleksander Sekowski — Wed, 14 Oct 2026 01:41:28 +0000

On October 7, 2026 AdCP shipped v3.2.3 with a security fix that finally enforces request signing on spend-committing calls such as create_media_buy. That closes a governance hole on the negotiation layer. It does not fetch the tag behind a VAST asset URL or compare <Duration> to the duration_ms in the manifest. The buy can be signed, schema-valid, and complete while the InLine the stitcher needs is still wrong.

Agentic CTV workflows are moving from demos to production spend. Trade coverage of MCP-enabled buying on platforms like Vibe.co describes agents that read reporting and order actions from a dashboard. The wire split underneath is older: Ad Context Protocol (AdCP) negotiates products, format capabilities, and creative manifests over MCP or A2A. Video delivery still ends in a VAST document (or a wrapper chain that must terminate in one). Treating a green tool response as creative readiness is how you bill for thirty seconds and serve sixty-five.

What the AdCP side proves

AdCP sits above the auction and the tag. A buyer agent discovers inventory with get_products, checks get_adcp_capabilities, and commits with create_media_buy. Success means the seller accepted the terms, returned a manifest, and echoed the negotiated adcp_version. Conformance storyboards grade whether your server speaks the protocol: auth headers, idempotency, schema on each response, and now, on 3.2.x, signatures where the trust model says they are required.

For video, the manifest typically carries a VAST asset object rather than inline XML:

{
  "asset_type": "vast",
  "delivery_type": "url",
  "url": "https://adserver.example/vast?pl=12345",
  "vast_version": "4.2",
  "duration_ms": 30000
}

The schema marks duration_ms as optional ("if known"). delivery_type: url means the bytes were not part of the MCP payload. Format capabilities from AdCP 3.1 add a parallel contract: a capability like video_hosted_16x9 can declare duration_ms_range or duration_ms_exact so buyers select slots with explicit bounds.

None of that is what a CTV player or SSAI packager executes. It is what two agents agreed should be true about a URL. The AdCP conformance guide tells you whether your agent returns valid JSON on those tools. Passing it is not a substitute for opening the tag.

What the VAST side actually runs

The player, the SSAI stitcher, and the verification SDK read XML. They follow wrapper hops until they find an InLine (or fail). Inside <Linear> they need a <Duration>, <MediaFiles> the environment can decode, and, on many CTV paths, attributes and companion structures the buy never mentioned in JSON.

Example mismatch that every layer can "pass" independently:

<Linear>
  <Duration>00:01:05</Duration>
  <MediaFiles>
    <MediaFile delivery="progressive" type="video/mp4" width="1920" height="1080">
      https://cdn.example/spot.mp4
    </MediaFile>
  </MediaFiles>
</Linear>

Thirty thousand milliseconds in the manifest satisfies a sixty-second format capability bound. Sixty-five seconds in <Duration> is what the SDK schedules. Quartile tracking fires on the wrong clock. Some stacks reject the break outright.

Wrappers make the gap wider. The manifest stores one URL. Hop one can be a <Wrapper> with no <Duration>. Duration lives on the terminal InLine. QA that stops at the first response approves a redirect graph, not a servable creative. Identity fields diverge too: AdCP may reference a creative id in JSON while the tag omits UniversalAdId or ships a registry value the SSAI path cannot resolve. Deprecated VPAID flags can validate against an older XSD while the CTV player ignores or blocks the interactive layer entirely.

The format capabilities write-up walks the three-number problem (capability bound, manifest field, XML duration). The declared versus verified asset post states the same blind spot at the asset record: every field on the VAST asset is a claim about a document nobody parsed during the buy.

Same flight, two verdicts

Layer	What "success" means	Typical check
AdCP / MCP	Tool returned 200, manifest validates, buy id issued	Storyboard, `get_adcp_capabilities`, signature on `create_media_buy`
Format capability	Selected `capability_id` matches declared bounds	JSON Schema on capability objects
VAST InLine	Player can parse, schedule, and render	XSD or linter rules on fetched XML
SSAI / CTV readiness	Mezzanine, HTTPS, codec, pod rules	Environment-specific rules beyond XSD

An LLM implementing the buyer agent can hallucinate a plausible manifest, call MCP, and still get an OK from a stub seller. An LLM generating "VAST" can emit well-formed XML with a broken MediaFile URL. Neither model is a deterministic check on the wire contract.

When the buy also has to become OpenRTB (display or mixed agentic flows), the same stack may emit bid requests through MCP tools. rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) owns that object, AdCP discovery helpers, and ARTF envelopes. vastlint (cargo install vastlint, npm install vastlint) owns the creative envelope the video buy referenced. They are independent checks, not IAB Tech Lab or AAO official harnesses, and the specs do not require them. You still need both when an agent closes both legs.

How you catch it before the flight

Split the job the way players split it.

Step one: live URL in the VAST tag tester. Paste the URI from the manifest, not XML copied from an earlier debug session. The tester fetches what the endpoint serves now, previews when it can, and shows tracking URLs. Compare parsed <Duration> to the duration_ms you think you bought.

Step two: the same URL in the VAST inspector. Resolve wrapper hops through to the InLine. If duration or mezzanine attributes only appear on the last hop, hop-one QA is a false green.

Step three: wire validation into the agent loop. After fetch, run vastlint CLI or MCP on the terminal document. Reject missing <Duration>, HTTP media on imp.secure inventory, or capability mismatches before the buy writes to your system of record. The AdCP and VAST handoff docs map where protocol negotiation ends and creative verification begins. For agents that also validate OpenRTB in the same session, the OpenRTB validator MCP doc shows how to keep bid objects on the same deterministic footing.

Treat "manifest accepted" as an intermediate state, not launch clearance. Signed create_media_buy on AdCP 3.2.3 proves the seller authenticated the commit. It still does not prove the tag behind delivery_type: url is the spot you sold.

OpenRTB loss reason 206 changed from an app bundle exclusion to a store ID exclusion.

Aleksander Sekowski — Tue, 13 Oct 2026 20:52:45 +0000

A loss dashboard that labels 206 as an app bundle exclusion is reading the OpenRTB 2.5 table. A bidder that labels the same integer as a store ID exclusion is reading the current list. Both integrations are following a published spec. They are following different editions.

What 2.5 printed

OpenRTB 2.5 section 5.25 introduced the loss reason list. In that table, 206 is Creative Filtered - App Bundle Exclusions. The list ends at 213, Creative Filtered - Not Allowed in PMP Deal. There is no 214 and no 215. Exchange-specific values start at 1000.

If your exchange integration was written against that PDF and never updated, a blocked bundle still arrives as 206.

What the current list says

In September 2021 the OpenRTB 3.0 list renamed 206 from Bundle to App Store ID Exclusions, and added 215 for App Bundle Exclusions. The change log describes the rename as keeping 206's intent consistent across 2.x and 3.x. The printed 2.5 table still says bundle. Treat the September 2021 list as the current definition, and treat a partner who cites 2.5 as still on the older one.

OpenRTB 2.6 does not print its own loss list. The ${AUCTION_LOSS} macro in 2.6 points at the OpenRTB 3.0 table. On that table:

206 is Creative Filtered - App Store ID Exclusions. The exchange compared the promoted app's store id, bid.bundle, with bapp or a publisher block. Play ids are package names. Apple ids are numeric.
215 is Creative Filtered - App Bundle Exclusions. This is the condition 2.5 reported as 206.

The current list also marks exchange-specific values at 500 and above, where 2.5 marked them at 1000 and above.

What to do with a 206 in production

Ask the exchange which list it implements before you build the alert. An exchange on the current list is telling you the store id was excluded, and a bundle exclusion from that same exchange arrives as 215. An exchange still on the 2.5 table is telling you the bundle was excluded, and it will not send 215 at all.

Drop the blocked id from the campaign on that inventory, and check the id format before you call it a policy block. A Play package name and an Apple numeric id are both legal bid.bundle values, and a block on the wrong form looks like a 206 when the campaign was never going to match.

The loss reason 206 page and the loss reason 215 page spell out the field each code checks. The loss reason code table is the current list, with the 2.5 difference called out above the range notes.

The other codes worth splitting out

Once 206 and 215 are labeled against the right list, the rest of a falling win rate sorts by range. These four are the ones that usually explain the drop, and each one names the field to inspect:

100 compares bid.price with imp.bidfloor in imp.bidfloorcur. The request cur array does not set the floor currency. A yen floor sent without JPY is read as USD.
102 is a loss to a higher bid. ${AUCTION_MIN_TO_WIN} on the loss notice, when the exchange fills it, is the price that would have won.
203 is a size mismatch against banner.w and banner.h, or any pair in banner.format.
212 is an animation longer than the placement allows. The request does not carry that limit. It lives in the creative policy, and a looping banner keeps drawing 212 until the creative changes.

202 and 207 sit in the same creative range: a crid the exchange already disapproved, and an http URL inside a creative served where imp.secure is 1.

10 Curated PMP Mistakes That Drop Paid Filters and Kill Fill

Aleksander Sekowski — Tue, 13 Oct 2026 00:18:40 +0000

On October 6, 2026, the IAB Tech Lab opened a public comment period aimed at simplifying programmatic plumbing. Curated private marketplace lines are a big part of that conversation: buyers pay for packaging, not just a deal id. On the wire, packaging still collapses to imp.pmp and a deals array. When operations treat that shape like a generic PMP row, the upstream filter disappears and fill still clears against the deal name on the IO. That is unbillable confusion at scale, not a UI typo.

Programmatic curation is sold as inventory plus data, assembled before the auction. OpenRTB never got a "curator" field in the bid request. IAB put terms, scope, and fee disclosure in the Deal Sync sidecar. The auction object remains an ordinary Deal entry. These ten mistakes are where curated buys silently downgrade to plain PMP traffic.

Treating Deal Sync copy as live targeting. The sidecar feed is reconciliation metadata. The spec is explicit that criteria pushed through Deal Sync are not guaranteed to match the next bid request. If QA only diffs the sync export, you can ship traffic that never carried the segment or site list the buyer signed.
Leaving private_auction unset on invite-only packages. In OpenRTB 2.x, imp.pmp.private_auction defaults to 0, which means open auction competition is allowed unless you set 1. Curators often sell "PMP-only" packages while the SSP still emits the default. Bidders who did not buy the package can win, and the curated filter never applied.
Winning on a deal id that was not on the impression you billed. Reporting joins on dealid in the bid response, but finance should trace back to imp.pmp.deals[].id on the request that actually ran. Multi-imp pods and duplicated deal ids across imps make it easy to attribute fill to a curated line that was not on the imp that cleared.
Expecting curator fee disclosure inside the OpenRTB Deal object. Fee and origin fields live in Deal Sync's Curation object, not in imp.pmp.deals. A bid request validator will never prove fee transparency; conflating the two objects sends buyers looking for fields that are not in the schema.
Assuming user.data segments prove the curator filter ran. When a curator applies segments only as an upstream supply filter, those segments may never appear in the bid request at all. Seeing unrelated Data objects on the request is attribution by convention, not proof that the MFA exclusion list from the one-pager executed.
Deploying floor changes from the sync file without diffing live bidfloor. Deal floors in traffic are on the Deal object in the request. A mismatch between the sidecar export and live imp.pmp.deals[].bidfloor means you can underbid curated inventory or overbid open paths while dashboards still show the old package terms.
Swapping white-label curator ids for publisher-direct ids without updating seat maps. The same inventory sometimes clears under different deal ids depending on which SSP node packaged it. Seat allow lists (wseat) and advertiser block lists (wadomain) on the Deal object are per id. A seat cleared for one id may be illegal on the renamed curated id.
Validating only the first impression in a pod. CTV and long-form video requests often carry multiple imps. Curated deals frequently attach to a mid-roll imp while preroll stays open market. Checking imp index zero alone misses the deal attachment the buyer actually purchased.
Patching deal floors or activations on the wrong JSON path. Agent and ARTF workflows mutate live objects under time pressure. A mutation aimed at /imp/0/pmp when the curated deal sits on /imp/1/pmp/deals/0 returns RPC success while the exchange still runs the uncurated object. Path precision matters more than envelope parse status.
Trusting schain completeness on curated resale without matching deal terms. Curators resell across SSPs with different SupplyChain 1.1 habits. A valid-looking source.schain does not replace at, floor, and seat constraints on the Deal object. You can pass chain validation and still serve inventory outside the curated scope.

One field is worth memorizing: imp.pmp.private_auction omitted means open auction. That default has burned more curated packages than any single bad segment id, because the buyer still sees a deal id on the line item and assumes exclusivity.

How you catch it

An LLM implementing AdCP, ARTF, or AAMP can emit a bid request that parses and still drop the filter the buy described. The tool call can return OK while the exchange runs a different shape. rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) is the deterministic check on the OpenRTB object: PMP containers, deal ids, floors, and the dated snapshot your partner actually enforces. It is independent of IAB Tech Lab and of AAO; the specs do not require it, but someone has to diff live requests against the deal terms you sold.

Ingest Deal Sync if you use it, then validate every production template against the same snapshot you pin in CI. The OpenRTB docs index and what rtblint checks list the deal and PMP rules that show up on curated lines first.

Where to go next

What is curation in programmatic? for the Deal Sync versus bidstream split (companion to the October 2026 simplification comment).
IAB Tech Lab 2026 roadmap and OpenRTB for where the Curation object lives relative to imp.pmp.deals.
OpenRTB version trains when curated traffic crosses SSPs on different 2.6 snapshots.
Agentic buying and OpenRTB when negotiation closes above the auction but execution still materializes as deal ids.
Guides index for PMP vocabulary and schain migration notes on multi-SSP curated packages.

The OpenRTB Native Assets Cheat Sheet Every In-App Bid Ops Engineer Needs

Aleksander Sekowski — Mon, 12 Oct 2026 00:16:47 +0000

In early October 2026 the IAB Tech Lab opened public comment on Programmatic Best Practices v1, including guidance to stop rotating placement IDs when one slot accepts native, display, and video. Multiformat impressions are the norm on in-app feed inventory. The native contract still lives in a string inside imp.native.request, and the creative answer still lives in another string in bid.adm. Trade coverage of the comment period landed around October 6, 2026. When you debug fill, you need the asset map on one page, not another lecture about JSON escaping.

This sheet is for engineers who validate bid requests in a dashboard, write bidder adapters, or triage SDK render failures. OpenRTB 2.x transports the Native Ads specification as serialized JSON. Version 1.2 is the production baseline most exchanges cite today. The table below pairs what the publisher asks for in the inner request object with what must come back in the Native Markup Response inside adm.

Request asset to response field map

Each row is one assets[] entry in the inner native request JSON (the payload inside imp.native.request after you parse the string once). The response mirrors the same id values under assets[] in adm.

Request asset	`required` on asset	Key request fields	Response object	What must come back
Title	`1` = must serve	`title.len` (max characters)	`assets[].title.text`	Non-empty `text` within `len`
Image (icon)	`1` or `0`	`img.type` = 1, optional `w`, `h`	`assets[].img` with same `id`	`url`, width and height matching constraints
Image (main)	`1` or `0`	`img.type` = 3, `wmin`/`hmin` or ratio	`assets[].img` with same `id`	`url`; main image aspect per Native 1.2 types list
Data (description)	often `1`	`data.type` = 2, `len`	`assets[].data.value`	Copy within `len`; type 2 is description
Data (sponsored by)	common	`data.type` = 1	`assets[].data.value`	Brand or sponsor line
Video (native asset)	`1` when offered	`video.mimes`, `minduration`, `maxduration`, `protocols` (all required in request)	`assets[].video.vasttag`	VAST XML string the SDK can hand to a player
Link	not an asset row	`link` optional in request	top-level `link.url`	Landing URL; required in response even when request omits it
Event trackers (1.2)	per `eventtrackers[]`	`event`, `methods` bitmask	`eventtrackers[]` with `event`, `method`, `url`	Match requested viewability or impression events

Also keep imp.native.ver aligned with the inner "ver" field (typically "1.2"). A bid response whose outer OpenRTB validates can still ship adm at "1.1" while the request asked for event tracker objects that only exist in 1.2.

Rows that validate and still break in production

Title asset required: 1 with a missing id in adm. OpenRTB only requires that imp.native.request be a string and that adm be a string when mtype declares native. Nothing in the core schema asserts that asset id 2 in the request appears in the response. The exchange accepts the bid; the SDK renders a blank card. Pairing checks belong on the decoded native objects, documented under openrtb-native-asset-required_missing.

Main image type 3 requested, type 1 icon returned. Both sides pass type checks as generic img objects. The mediation SDK expected a 1200×627 main image and received a 80×80 icon. Fill counts as served; viewability and CTR do not recover.

Legacy { "native": { ... } } wrapper inside request. Native 1.1 dropped the root wrapper from 1.0, but older publisher SDKs still emit it. Parsers that expect a flat object accept the string and never descend into assets. See openrtb-native-request-legacy_wrapper and the walkthrough at native-request-is-a-json-string.

How you catch it

An LLM implementing a bidder or an AdCP-to-OpenRTB mapper can emit plausible JSON for both strings and still miss asset ids, required flags, or Native 1.2 event trackers. The RPC and the exchange ACK do not re-run that pairing for you.

RTBlint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) validates the OpenRTB object, decodes imp.native.request, and checks native markup in adm against the request assets. It is independent of IAB Tech Lab and of AAO; the spec does not mandate it, but it is the deterministic check on the wire shape agents keep getting wrong.

When the response row is Video (native asset), assets[].video.vasttag is a full VAST envelope, not a hint. Paste the decoded XML into the VAST tag tester to fetch media and tracking from a live URL, and use the VAST inspector if that tag is a wrapper chain. Native fill often dies on the VAST half after the OpenRTB half already cleared QA.

Start from a known-good fixture in the native bid request example, then diff your production traffic with rtblint validate on the bid response direction.

Where to go next

Native ads in OpenRTB: imp.native fields, asset type lists, and 1.1 versus 1.2 deltas.
Blog: request is a JSON string: why double encoding on the way in and out breaks naive parsers.
Rule references above for required asset pairing and legacy wrappers when you need the exact finding id in CI.

Bookmark the table. When multiformat placements share one ID, the native string is still the only place that says which headline and main image the renderer must get back.