DEV Community: Aleksander Sekowski

A Pause NonLinear MP4 Without Duration Validates. Quartile Beacons Never Schedule.

Aleksander Sekowski — Sun, 27 Sep 2026 00:36:30 +0000

A streaming app launches pause inventory for the first time. The VAST tag validates. The frozen frame fills with a fifteen-second MP4. The buyer's dashboard shows delivered impressions.

Nobody sees midpoint or thirdQuartile in the verification feed. The trafficking sheet still lists quartile pixels because the DSP copied them from a preroll template. The player had no <Duration> to divide against, so it never scheduled those beacons.

This is not a broken CDN URL. It is the gap between what the CTV Ad Portfolio added to NonLinear delivery and what older pause tags assumed when pause meant a JPEG with no clock.

Optional on paper, required for video measurement

Before the portfolio work, many pause units were a <NonLinear> with a <StaticResource> image. Duration was genuinely unknown at response time. IAB's signaling guidance still allows omitting <Duration> when the creative is a static image whose on-screen time depends on how long the viewer stays paused.

Portfolio formats changed the payload. Pause, overlay, and several squeezeback layouts now ship <MediaFiles> with MP4 renditions the same way linear pods always have. Quartile events, overlayViewDuration, and skip-style timers all need a declared length on the NonLinear node.

The XSD does not always force that length. A <NonLinear> can contain a video/mp4 <MediaFile> and no sibling <Duration>. Schema validation returns OK. The AdCOM extensions can still echo plcmt=5 for Pause with legal playbackmethod 8 or 9.

Players behave differently once video is involved. Some infer duration from the container after download. Many CTV SDKs do not, because inferring length post-load would fire tracking late or twice. They treat missing Duration as "no timed events for this overlay," play the file, and move on.

What the creative subtree actually promises

plcmt in <Extension ext="adcom"> (or inside <Extension type="ctv_ad_portfolio"> on VAST 2.0) names which portfolio format was bought: 5 Pause, 6 Screensaver, 7 Overlay, 8 Squeezeback, 9 In-Scene. It does not tell the player how long to wait before firing midpoint.

<NonLinearAds> / <NonLinear> is the render contract. Portfolio guidance routes five of six formats through this branch. A linear <Creative> with the same extensions is a different failure mode: the player reads Linear, not plcmt.

<Duration> on the NonLinear element is the clock for overlay-style measurement. VAST expects HH:MM:SS or HH:MM:SS.mmm, the same lexical form as linear ads. Without it, <Tracking event="midpoint"> URLs may exist in the XML and never execute.

<MediaFile type="video/..."> under NonLinear means the player should treat the unit as timed media, not a static plate. That is the combination rule VAST-4.4-nonlinear-video-no-duration targets: video media present, Duration absent.

Static JPEG pause paths can still omit Duration by design. The bug shows up when teams reuse linear trafficking exports: they paste quartile tracking from instream, drop the MP4 into NonLinear <MediaFiles>, and delete <Duration> because the old image-based pause tag never needed it.

How I catch it before the verification vendor does

I start with the live ad tag in the VAST tag tester. Paste the ad server URL or the XML. The tester fetches wrappers, previews the media the player would choose, and lists tracking events on the resolved creative. If the preview shows a progress bar but the NonLinear node has no Duration in the source, quartile URLs are decorative.

Wrapped pause tags are common. Run the same URL through the VAST inspector to see which hop introduces the NonLinear MP4 and whether an upstream wrapper stripped Duration while copying <MediaFiles>.

For interactive pause units, the IAB-style VAST tester loads SIMID sample creatives and logs the player handshake. That workbench is an independent fork, not an IAB Tech Lab product, but it helps separate "SIMID never loaded" from "video played without timed tracking."

After preview, run vastlint check on the resolved InLine. The CTV Ad Portfolio rulepack flags VAST-4.4-nonlinear-video-no-duration when a video <MediaFile> sits under <NonLinear> without <Duration>. An implementation that lets a model emit VAST still has to run that check: the RPC or trafficking export can return OK while the wire contract omits the clock. vastlint is the package that owns this payload (cargo install vastlint, npm install vastlint). It is independent of IAB Tech Lab and of AAO; the spec does not require it, but it is the deterministic check on the XML the buy claimed.

Where to read the format rules

The CTV Ad Portfolio pack page maps each format to plcmt, pos, and playbackmethod, and shows whether delivery is NonLinear or Native Menu.

The pause ads guide walks a correct NonLinear structure: MediaFiles, Duration, and the 8/9 playbackmethod pair for sound on or off.

The 4.3 to 4.4 migration notes explain why NonLinear gained MediaFiles and why portfolio examples still declare version="4.2" while using the new content model.

Rule doc VAST-4.4-nonlinear-video-no-duration cites the portfolio guidance section on handling duration: optional for unknown static images, load-bearing once video MediaFiles are in the NonLinear.

If you are comparing schema-only validation against the July 2026 portfolio drop, the draft 4.4 schema write-up separates XSD findings from finalized signaling rules so you do not treat draft warnings as production blockers.

What I change in trafficking

When the pause or overlay unit is video, I add <Duration> next to the NonLinear <MediaFiles> block and match it to the longest declared rendition, not to the slot length on the media plan. I keep quartile tracking only when Duration is present; otherwise I drop those events or switch to overlayViewDuration with a player that documents how it fires without quartiles.

I do not assume SSAI will infer duration from mezzanine or progressive MP4 on the stitcher side. Stitchers often pass NonLinear through unchanged; if Duration was missing at ingest, it is still missing on the device.

Treat static and video pause tags as two templates. The same plcmt value does not mean the same tracking contract once <MediaFile type="video/mp4"> appears under NonLinear.

ARTF Envelope tmax as "150" Is Not OpenRTB bid_request.tmax. The Agent Still Gets Called.

Aleksander Sekowski — Sat, 26 Sep 2026 00:34:55 +0000

A sidecar agent mutates the publisher bid request before any DSP sees it. The host builds an ARTF RTBRequest, sets a deadline, and calls Mutate over gRPC. The agent returns mutations. The orchestrator applies them and forwards whatever OpenRTB object survives.

The failure I keep seeing is not in the mutations. It is in tmax on the envelope.

{
  "id": "ext-2026-09-26-001",
  "tmax": "150",
  "lifecycle": "LIFECYCLE_PUBLISHER_BID_REQUEST",
  "bid_request": { "id": "br-1", "tmax": 500, "imp": [{ "id": "imp-1", "video": { "mimes": ["video/mp4"], "w": 640, "h": 360 } }] },
  "applicable_intents": ["ACTIVATE_DEALS"]
}

That file looks fine in a diff review. The sample in the spec uses 150. Someone copied the sample into a YAML template and left quotes on the number. The OpenRTB object underneath still has its own tmax: 500, which is the auction timeout in milliseconds. Two different fields, two different jobs, and only one of them is quoted.

What ARTF tmax actually measures

On the ARTF envelope, tmax is how many milliseconds the exchange allocates for the extension point itself: serialize the payload, run the agent, deserialize mutations, and decide what to apply. Reference examples cluster around 120 to 150 ms because the call sits inside an auction the host is already timing out.

OpenRTB BidRequest.tmax is the bid timeout for the whole RTB hop. Values in the hundreds or low thousands are normal there. They are not interchangeable. Pasting bid_request.tmax onto the envelope without renaming the field is a unit confusion that still parses as JSON when both numbers are bare integers.

Protobuf JSON makes the string case worse. Field 3 on RTBRequest is an integer. A quoted "150" is not an integer on the wire. Some pipelines never parse the envelope strictly; they forward the blob to an agent that treats missing deadlines as "best effort." The RPC returns OK. The orchestrator may never learn the host promised 150 ms of budget in a form the contract accepts.

RTBlint reports a string as artf.tmax.not_integer:

$ rtblint validate --type artf-request rtb-request.json
FAILED (OpenRTB 2.6-202606 ARTF request envelope): 1 error(s), 0 warning(s).
- [error] tmax: tmax is the milliseconds the exchange allows for mutations;
  "150" is not an integer. (artf.tmax.not_integer)

Zero and negative values fail as artf.tmax.non_positive. A host that sets tmax: 0 because "we disabled the timeout" leaves the agent no time to answer at all.

When the integer is legal but the story is wrong

Even with a bare integer, magnitude matters. RTBlint warns above 1000 ms with artf.tmax.implausible. That is usually someone who copied auction seconds (30) thinking the field meant seconds, or who lifted bid_request.tmax without reading the ARTF definition. The warning does not block parsing; it flags a budget that does not match an in-auction sidecar call.

The other half of the envelope contract is what the orchestrator tells the agent it may return. An empty applicable_intents array is valid JSON and out of scope by definition: every mutation is undeclared. That is a warning, not a hard error, which matches production hosts that treat intent lists as documentation until something breaks in pass two.

How you catch it before the auction forwards

An implementation that lets a model or template emit the envelope still has to check that envelope against the ARTF contract and against the OpenRTB snapshot the exchange runs. RTBlint is that check for the OpenRTB object, the ARTF request and response envelopes, and the applied bid request after mutations (cargo install rtblint, npm install rtblint-core, MCP validate_artf_request / validate_artf_response with apply). It is independent of IAB Tech Lab and of AgenticAdvertising.org; the rules come from the public proto and the validation passes described in the ARTF material.

Run pass one on every RTBRequest at the host boundary, before gRPC leaves your network. Run pass two on RTBResponse mutations against the request you actually sent, not a cached copy from an earlier auction. Run pass three with --apply when you need to know whether a legal-looking ADD_METRICS patch broke imp[].metric[].value on the forward path.

The ARTF simulator walks the same three passes in a browser if you are debugging a single sample envelope. The longer primer is ARTF explained: lifecycle, semantic paths, and why response-stage intents need a bid_response on the wire.

Where to go next

If you host agents, log envelope tmax separately from OpenRTB tmax in your metrics. If you generate ARTF JSON from LLM tool output, type-check tmax as an integer before you call gRPC. If you inherit a sidecar from a vendor, ask whether they validate the envelope or only the mutations.

The auction only sees the OpenRTB object after your orchestrator applies patches. Getting tmax wrong does not always stop the RPC. It stops you from reasoning about whether the agent had a real deadline, which is the whole reason the field exists on the envelope in the first place.

AdCP Scopes the Buy in adagents.json. OpenRTB imp Does Not Carry That Scope Back.

Aleksander Sekowski — Fri, 25 Sep 2026 00:33:31 +0000

A buyer agent finishes an AdCP media buy against a publisher's Prebid Sales Agent. Negotiation narrowed the deal to one placement_id, US only, and a window that ends next quarter. The agent fetched /.well-known/adagents.json, found an authorized_agents row whose property_ids and optional placement_ids matched, and stored the authorization snapshot.

The sell side then emits an OpenRTB bid request. It validates. The exchange accepts it. Nobody compares the live imp object to the scoped slice that was authorized five minutes earlier in JSON on the publisher origin.

That gap is not a typo in one field. It is two layers answering different questions with different grammars.

What adagents.json actually scopes

In AdCP, publisher authorization is explicit. An authorized_agents entry names the sales agent URL, an authorization_type discriminator, and the selector that carries inventory scope: property_ids, property_tags, inline properties on the entry, or federated publisher_properties selectors. Optional qualifiers narrow further: placement_ids, placement_tags, countries, collections, effective_from, effective_until, and exclusive.

Those fields are machine-readable promises about which agent may represent which slice. They do not ride inside OpenRTB by default. The spec even calls out that inline_properties is the one authorization pattern whose companion array is named properties, not inline_properties, because validators reject the obvious-but-wrong shape. A model generating adagents.json from examples often emits the wrong array name, passes casual JSON lint, and still fails a strict AdCP validator. That is a file-level bug.

The failure this post is about happens after both files look fine: the buy was scoped in adagents.json, but the auction payload never had to repeat the scope.

What OpenRTB actually enforces

OpenRTB enforces what is on the wire at impression time: imp structure, video or banner constraints, deal objects under imp.pmp, privacy under regs and user, and supply path under source.schain. Sellers reconcile schain nodes against ads.txt and sellers.json. None of those objects require a copy of the publisher's placement_ids array or the effective_until timestamp from adagents.json.

You might map placement identity to imp.tagid or an extension. That mapping is integration policy, not a cross-file guarantee. If the agent stack omits it, constraint loss is silent: everything agreed in negotiation is not expressed in the impression, and anything not expressed is not enforced downstream no matter how precise the AdCP conversation was.

The same split shows up on the trust side. adagents.json answers whether this agent was allowed to sell this property slice. schain answers which seller domains handled this impression. A stack that validates schain syntax but never re-checks agent authorization has an auditable path and an unauditable agreement attached to it.

How I catch it

I treat the emitted bid request as the only observable output of the handoff. Paste the JSON into the OpenRTB tester or run rtblint validate on the bytes after serialization, not on the object you think you built.

That pass is structural. It catches version drift, type mistakes, and schain defects such as an empty node identifier (openrtb.schain.node.identifier_empty) or an unexpected ver value (openrtb.schain.ver_unexpected). It does not fetch adagents.json and prove the live imp still sits inside the authorized placement and country slice.

Agent workflows that let a model assemble AdCP output and OpenRTB in one pipeline still need that deterministic check on the RTB object. RTBlint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) is built for the OpenRTB payload, ARTF envelopes, and AdCP discovery via get_adcp_capabilities. It is independent of IAB Tech Lab and of AgenticAdvertising.org. It is not a substitute for comparing authorization time to execution time; it is the part that keeps the auction JSON from shipping with plausible-but-invalid shape while you write the policy layer that re-applies adagents scope.

My manual step stays boring: for each fixture product type, assert the fields you care about (tag id, deal id, geo, duration caps) are present on imp after mapping, then validate. If the mapping guide says video placement types become video.plcmt, confirm plcmt is set and that deprecated placement is not standing in for it.

Where to go next

The AdCP to OpenRTB mapping guide walks field-level handoffs and lists where the mapping silently breaks: version drift, names that look mapped but are not, constraint loss, and privacy signals that never leave the seller ad stack. Read that alongside the Ad Context Protocol explainer for where adagents.json sits relative to MCP tools and the Prebid Sales Agent.

For the execution-time trust stack that still runs in parallel, sellers.json, ads.txt, and schain explains how hop-level checks complement publisher agent authorization. IAB agentic advertising standards maps AAMP and ARTF next to AdCP without collapsing them into one file.

Until your emit boundary re-expresses every adagents qualifier on the impression, a scoped AdCP buy and a permissive OpenRTB request can both return 200. The authorization was real. The auction just was not required to remember it.

The Inline Logs Impressions. The Wrapper Hop Does Not. VAST Still Requires Both.

Aleksander Sekowski — Thu, 24 Sep 2026 00:31:32 +0000

The ad plays. The buyer's impression pixel fires on the inline. Finance still opens a ticket because the SSP's numbers are half of everyone else's.

The XML you pasted from the bottom of the chain looks fine. What nobody fetched was hop two: a thin wrapper with <AdSystem>, <VASTAdTagURI>, and no <Impression>.

One hop, one beacon

From VAST 2.0 onward, an <InLine> ad must carry at least one <Impression>. The same rule applies to <Wrapper>. Section 2.3.4 treats the wrapper as its own ad delivery record. The impression URL on that node is how this server proves the opportunity passed through this hop before the player follows <VASTAdTagURI>.

That is not redundant with the inline's pixels. Wrapper impressions and inline impressions answer different accounting questions. The reseller logs pass-through; the advertiser logs the served creative. Players that follow wrapper chains correctly fire both, in order, as they resolve redirects.

A wrapper that omits <Impression> is still well-formed enough to redirect. Many QA flows validate only the final inline, or only check that <VASTAdTagURI> returns 200. The missing element is on the document you never saved.

<VAST version="2.0">
  <Ad id="reseller-1">
    <Wrapper>
      <AdSystem>Reseller Ad Server</AdSystem>
      <VASTAdTagURI><![CDATA[https://buy-side.example/vast.xml]]></VASTAdTagURI>
    </Wrapper>
  </Ad>
</VAST>

The buyer inline downstream can include three impression URLs and a full <Linear>. The reseller still counts zero for the leg it controlled.

What breaks in production

Discrepancy meetings love this failure mode because every party has a defensible partial truth. The publisher saw the ad. The DSP has inline impressions. The intermediary wrapper never emitted a beacon, so its dashboard under-reports against the ad server that did log the serve.

Wrapper chains amplify it. Hop one might be clean. Hop three might be clean. The hop without <Impression> disappears from that partner's reporting while adjacent hops look healthy. Without walking the chain, the bug reads as "your player dropped tracking" instead of "this XML never declared tracking for that server."

<AdSystem> on the wrapper has the same structural role: the spec expects a named ad system on every wrapper document, not only on the inline. A wrapper missing identity metadata is a different error, but the same class of problem: the redirect container is incomplete even when the redirect works.

How you catch it

Start from the live tag URL, not the inline fixture in the ticket. The VAST tag tester fetches the response, follows <VASTAdTagURI> redirects, and shows the resolved documents with validation markers. That is where you see whether hop two ever declared an impression.

For depth and handoff between hops, the VAST inspector walks the wrapper chain step by step: which URL returned which document, where an inline finally appears, and where a hop is structurally thin.

On the file or paste path, vastlint flags the missing element as VAST-2.0-wrapper-impression (the same rule id applies across VAST versions that still use <Wrapper>):

$ vastlint check wrapper-no-imp.xml
error   VAST-2.0-wrapper-impression
        <Wrapper> must contain at least one <Impression>
        path: /VAST/Ad[0]/Wrapper
        spec: IAB VAST 2.0 §2.3.4

An implementation that lets a model emit VAST from a trafficking UI or an agent workflow still has to check the payload on the wire. vastlint (cargo install vastlint, npm install vastlint) is that check for the creative envelope. It is independent of IAB Tech Lab and of AAO; it does not replace your ad server's business rules, but it will not treat "redirect works" as "hop logged."

Where to go next

The wrapper missing impression example walks through the resale scenario, the primary finding, and the fix fragment: add a distinct impression URL on every wrapper so each party measures its own leg.

The VAST-2.0-wrapper-impression rule reference states the requirement and links the spec section. Pair it with VAST-2.0-wrapper-adsystem when you are auditing thin wrappers that lack both tracking and attribution.

For chain behavior (accumulating impressions, depth limits, when inline handoff happens), the VAST wrapper chains guide is the reference I send engineers before they blame the SDK for a missing pixel that was never in the wrapper XML.

Validate every hop. The inline is not a substitute for wrapper-level <Impression>.

exclusive: true in adagents.json Does Not Retire the ads.txt RESELLER Line

Aleksander Sekowski — Wed, 23 Sep 2026 00:30:18 +0000

A publisher migrates to AdCP and publishes /.well-known/adagents.json. One row in authorized_agents names their Prebid Sales Agent with delegation_type: "direct" and exclusive: true. The buyer agent treats that as the only path for the property.

The same week, nobody edits ads.txt. It still lists two other exchanges as RESELLER for the same seller account. A supply-path optimizer fetches ads.txt, sees an authorized resale hop, and green-lights a bid whose source.schain includes one of those exchanges. Both files return HTTP 200. Neither file's validator reads the other.

That is not a hypothetical layering bug in one vendor stack. It is two trust artifacts on the same origin answering different questions with no cross-check.

What exclusive actually scopes

In the AdCP adagents schema, exclusive on an authorized_agents entry means this agent is the publisher's sole authorized path for the inventory slice covered by that entry (property ids, placement tags, countries, and the rest of the scope fields). When exclusive is false or absent, other authorized agents in the same file may sell the same slice.

That boolean lives entirely inside adagents.json. It does not emit an HTTP DELETE to ads.txt. It does not flip a RESELLER row to DIRECT. It does not remove a seller id from the IAB flat file buyers have been crawling for a decade.

AdCP's own comparison table maps programmatic ads.txt to adagents.json with delegation_type on the publisher side. The spec explains that adagents.json is more expressive: properties, placements, delegation type, time bounds, and exclusivity inside one JSON document. None of that documentation promises that publishing adagents.json supersedes or reconciles ads.txt on the wire.

ads.txt still encodes relationship as a single token per line: DIRECT or RESELLER. A RESELLER line is an explicit statement that the listed advertising system may resell inventory for that publisher id. An exclusive direct agent in adagents.json is a parallel statement in a richer grammar. A buyer that only ingests AdCP can believe resale is closed. A buyer that still runs ads.txt plus schain validation can believe resale is open. Both can be "correct" relative to the file they read.

Where the hop still gets judged

Programmatic paths still arrive as OpenRTB. source.schain names the advertising systems that touched the impression. Supply-path products compare those nodes to ads.txt, sellers.json, and internal allowlists. They do not today fetch adagents.json on every bid and ask whether exclusive: true forbids the node they are staring at.

The inverse gap is also live: adagents.json can authorize an agent URL that never appears as asi on the schain attached to the impression you actually bought. Valid authorization in the well-known file and a valid seller node in schain are independent passes.

For the shape of schain itself, missing hp on a node under SupplyChain 1.1 expectations is a structural failure mode worth separating from authorization confusion. The openrtb.schain.node.hp_missing rule reference documents when a reader expects hp and the node omits it. Duplicate adjacent nodes are a different class of bug; see openrtb.schain.duplicate_node. Fixing schain syntax does not tell you whether the publisher meant to allow that seller in adagents.json or ads.txt.

How you catch it

My manual check for this mismatch is dull and effective: for the same registrable domain, fetch adagents.json and ads.txt, resolve the seller ids and agent URLs on the exclusive row, and list every ads.txt line that still says RESELLER for overlapping seller accounts. If any RESELLER row names a system that can still inject schain nodes on live traffic, exclusive in adagents.json did not close the path your SPO tool uses.

Once the buy collapses back to OpenRTB, paste the bid request into the OpenRTB tester on RTBlint's site or run rtblint validate on the JSON. That pass catches schain structure, version drift, and field placement. It does not fetch publisher adagents.json and diff it against ads.txt; nobody should pretend a schema pass on the request replaces the two-file comparison.

Agent stacks that emit AdCP or ARTF output face the same split. An MCP tool can return OK from get_adcp_capabilities while the downstream RTB request still carries a schain node ads.txt authorizes. RTBlint's OpenRTB validator MCP and get_adcp_capabilities discovery belong on the agent side; they check the payload the model or service emitted, not the publisher's twin trust files on the origin. If you are wiring an AdCP buyer, you still need an explicit policy step that reconciles adagents exclusivity with ads.txt before you trust exclusivity in a deal brief.

Implementation teams piping agent output through CI should treat rtblint (cargo install rtblint, npm install rtblint-core, or the MCP server) as the deterministic check on the OpenRTB object after the agent claims success. The wire contract for schain and imp objects does not move because the RPC returned OK. These packages are independent of IAB Tech Lab and of AgenticAdvertising.org; they do not replace reading both publisher files when the question is whether resale is still allowed.

Where to go next

The IAB agentic advertising standards guide situates adagents.json beside AAMP, ARTF, and AdCP without collapsing them into one file. For how schain nodes relate to bidstream identity fields once a request is in flight, what bidstream data is walks the object model buyers actually log.

If you already covered adagents.json versus schain, that post is about hop-level disclosure versus publisher authorization. This failure is earlier on the origin: exclusive in JSON versus RESELLER in plain text. A path can fail either test, both, or neither, while still clearing HTTP and JSON Schema on every fetch.

Until something compares those two files on every property migration, exclusive: true is a promise inside adagents.json, not a revocation in ads.txt. Buyers who still read both get two answers. Buyers who read only one get a false sense of closure.

gclid on the Next Page Does Not Grant ad_storage. URL Passthrough Is Not Consent.

Aleksander Sekowski — Tue, 22 Sep 2026 00:28:45 +0000

A shopper lands from Google Ads with gclid on the query string. Your CMP is still on default deny. Marketing enabled URL passthrough so the id survives the first internal click. The second page URL looks healthy in the address bar. Floodlight still behaves like tracking is off.

That is not a broken redirect. It is Consent Mode doing two different jobs at once.

Passthrough moves parameters. It does not flip ad_storage.

Google Consent Mode v2 split ad_storage from analytics_storage so tags can wait for a CMP signal before they set advertising cookies. URL passthrough is a separate gtag('set', 'url_passthrough', true) call. Google's consent guide describes it as a way to append click-related query parameters on same-registrable-domain outgoing links when consent mode is implemented and the tag is consent-aware. Typical parameters include gclid, dclid, gclsrc, _gl, and wbraid.

Passthrough helps the next page load carry the click id in the URL so a consent-aware tag can use it if storage becomes available later in the session. It does not change ad_storage from denied to granted. If your conversion tag fires on Container Loaded before the CMP calls gtag('consent', 'update', { ad_storage: 'granted' }), the tag still runs in denied mode even though the URL shows gclid.

ads_data_redaction is the other half teams enable in the same breath. When ad_storage is denied and redaction is true, Google documents that ad click identifiers sent in network requests by Google Ads and Floodlight tags will be redacted. Redaction has no effect when ad_storage is granted, or when you are not using gtag('consent') at all.

The hardened default many EEA sites ship looks like this:

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  wait_for_update: 500
});
gtag('set', 'url_passthrough', true);
gtag('set', 'ads_data_redaction', true);

Syntax is fine. Trigger order is where production breaks: a Conversion Linker or Google Ads conversion tag bound to All Pages races the banner. Passthrough preserves gclid on page two. Redaction strips the click id from the ad network request while storage is denied. Neither line grants ad_storage.

Why this is not TCF, GPP, or a CMP bug

IAB TCF and GPP strings describe vendor legal bases on the wire to adapters. Consent Mode is Google's tag-side interpretation for Google tags. You can decode a valid TC string on a Floodlight URL and still run gtag in denied ad_storage until the Google-specific update runs, if your CMP maps TC segments to Consent Mode incorrectly.

us_privacy and gpp / gpp_sid on the pixel are a different grammar again. A bid request can carry regs.gpp with sid 7 while the browser tag never forwarded the same composite string. Duplicate consent parameters are yet another class of failure: two gpp keys, or the same TC String copied into both gdpr_consent and gpp with conflicting bits.

The passthrough mistake is narrower: teams treat a visible gclid as proof conversions work, while Google's ad tags follow consent state, not the query bar alone.

Server-side Google hits have the same split. Consent Mode parameters must travel with the Measurement Protocol or Google Ads upload. A CAPI-style server payload that omits consent fields while the web tag had ad_storage denied is not repaired by passthrough on the browser. Passthrough never ran on the server hop.

How you catch it

Start with two captures on the same session: one network request from the conversion tag before the CMP update, one after grant. If redaction is on and ad_storage is denied, Google documents redacted click ids on ad tag requests even when the page URL still shows gclid.

Log gtag consent state at conversion fire time in Tag Assistant or your own consent log. URL parameters alone are not proof of granted ad_storage.

For third-party pixels on the same page, validate what each vendor actually received on that hop. I maintain Pixellint, an open source linter for pixels and conversion API payloads. The core privacy pack decodes gdpr_consent and gpp header bits on live URLs. It will not flip your CMP banner. It will tell you whether the Floodlight or affiliate URL you captured still carries a TC String that decodes to grant after the user rejected, or a malformed gdpr_consent=1 that is not a TC String at all:

$ pixellint validate url 'https://ad.doubleclick.net/ddm/activity/src=1234567;type=convr0;cat=purch0;gdpr=1;gdpr_consent=1'
  error   core.privacy.gdpr_consent_malformed
          `gdpr_consent` is `1`, whose first six bits decode to version 1.
          ...

That error is a wire contract check, not a substitute for Consent Mode debugging. Pair URL linting with trigger-order review: Consent Initialization first, CMP update before ad conversion tags, passthrough set consistently on every Google tag in the container. Google notes mixed containers where only one tag sets passthrough produce the same split-brain attribution as mixed pixel and CAPI clocks.

Paste a URL into the browser playground if you do not want a local install. For field tables that map TC, GPP, and tag parameters side by side, see consent on the wire.

Where to go next

The dated argument on passthrough versus redaction lives in the Consent Mode URL passthrough post. The Google Consent Mode v2 contract page lists ad_storage, analytics_storage, ad_user_data, and ad_personalization and repeats that Consent Mode is not a CMP.

If your stack also forwards IAB signals into OpenRTB, read the GPP guide for header type 3 and section ids. EU inventory still belongs on gdpr plus gdpr_consent, not a TC String pasted into gpp. OpenRTB regs.gpp and regs.gpp_sid must agree with what the pixel sent; mismatched section ids are a separate hop problem from passthrough, but the same QA habit applies: compare auction capture to fired tag URL on one page view.

For regulatory transparency fields arriving on bid requests, DSA transparency in OpenRTB is the server-side counterpart to consent strings on tags. Fix Google tag order first: default deny, passthrough and redaction as set calls, CMP update before conversion tags, then verify granted state on the tag that actually sends ad network requests.

The short version

url_passthrough keeps click ids on your URLs across same-domain navigations. It does not grant ad_storage. With ads_data_redaction true and storage denied, Google ad tags redact click identifiers on network requests anyway.

A visible gclid after an internal click is continuity on your site. Google conversion attribution follows consent state at fire time. Audit trigger order, log consent at conversion, and lint the non-Google pixels on the same page so you are not debugging the wrong contract.

Pixellint is independent of Google and IAB. Rule ids cite their docs because that is where the requirements live, not because this is an official tool.

Mezzanine-Only SIMID Validates for SSAI. Nobody Runs the Interactive Iframe.

Aleksander Sekowski — Mon, 21 Sep 2026 21:27:41 +0000

A CTV campaign ships SIMID for the expandable unit. Trafficking exports VAST 4.1 with a high-bitrate <Mezzanine>, an HLS <MediaFile delivery="streaming">, and <InteractiveCreativeFile apiFramework="SIMID" type="text/html">. The SSAI pipeline ingests the mezzanine, stitches the pod, and the stream plays. The interactive layer never appears. No VAST error code fires because every element the schema cares about is present.

The gap is not missing SIMID markup. It is which <MediaFile> delivery mode survives on the client after server-side insertion.

What Mezzanine and progressive actually mean

VAST 4.1 added <Mezzanine> so ad stitching platforms can transcode from a single high-quality source (VAST 4.1 §1.1.2). The mezzanine is the input to the stitcher. It is not a promise that the end device receives a progressive MP4 it can hand to a SIMID-capable player alongside an iframe.

<MediaFile delivery="streaming"> is the correct shape for HLS or DASH after stitch. <MediaFile delivery="progressive"> is the shape a client player downloads and decodes locally. SIMID 1.0 §3.4 still requires a real video or audio <MediaFile> sibling to the interactive file because the iframe does not replace linear media. On SSAI inventory the stitcher consumes the mezzanine and emits a stream. The device player may never see a progressive file at all.

When the only <MediaFile> in the tag is delivery="streaming" and the mezzanine sits next to it, the document satisfies many XSD checks and the SIMID-1.0-simid-mediafile-required rule (there is a media node). The SSAI-specific failure is different: there is no progressive asset for a client-side player to attach SIMID to after the break is already in the manifest. The interactive HTML URL is in the XML. Nothing in the SSAI path loads it.

That is what SIMID-1.0-simid-ssai-no-client flags at info severity: linear SIMID with a mezzanine present and no progressive <MediaFile>. It is easy to dismiss as informational until you realize the tag was authored for dynamic ad insertion, not for a browser that could have run SIMID on a downloaded MP4.

A minimal broken shape looks like the fixture vastlint uses:

<MediaFiles>
  <MediaFile delivery="streaming" type="application/x-mpegURL" width="1920" height="1080">
    <![CDATA[https://cdn.example.com/ad.m3u8]]>
  </MediaFile>
  <Mezzanine delivery="progressive" type="video/mp4" width="1920" height="1080">
    <![CDATA[https://cdn.example.com/ad-mezzanine.mp4]]>
  </Mezzanine>
  <InteractiveCreativeFile apiFramework="SIMID" type="text/html">
    <![CDATA[https://creative.example.com/simid.html]]>
  </InteractiveCreativeFile>
</MediaFiles>

The fix for mixed SSAI and SIMID is operational, not a one-line attribute swap: keep a progressive <MediaFile> in the tag for client players that still execute SIMID after stitch, or stop selling SIMID on pure SSAI paths where no client runtime exists (the same constraint that killed VPAID in the stitcher). The VPAID rule pack documents why script and iframe APIs fail server-side; SIMID is sandboxed, but it still needs a client.

How you catch it

Paste the live tag URL into the VAST tag tester. It fetches the chain, previews the linear media, and lists tracking URLs so you can see whether the break is empty or only the video layer rendered. For wrapped tags, run the same URL through the VAST inspector hop by hop. A mezzanine-only SIMID shape on the final InLine still breaks interactivity even when the wrapper hops are clean.

SIMID handshake debugging belongs in the IAB-style VAST tester. That workbench loads sample creatives, logs host transport, and exercises postMessage the way a spec-compliant player would. It is an independent fork, not an IAB Tech Lab product. If the workbench never enters SIMID mode on a pasted tag but the MP4 or HLS preview plays, delivery mode and apiFramework are the first suspects before you open the HTML creative.

CLI check on the fixture above:

$ vastlint check simid-ssai.xml
simid-ssai.xml  VAST 4.1
  info     Linear SIMID creative has a <Mezzanine> but no progressive
           <MediaFile>; an SSAI stitcher cannot execute the SIMID iframe
           SIMID-1.0-simid-ssai-no-client

Info severity does not mean optional on SIMID campaigns. It means the schema alone will not save you.

Where to go next

If the buy is CTV and the trafficking template still emits VPAID next to SIMID, read the VPAID-on-CTV example: deprecated script media and SSAI are incompatible for different reasons, but the revenue symptom is the same (video without the interactive or verification layer you sold). VAST 4.2 added interactiveStart tracking for the moment SIMID takes control; a tag that never mounts SIMID will not fire that event either, which shows up as a measurement gap rather than a parser failure.

vastlint is independent of IAB Tech Lab. The rule ids above cite SIMID and VAST because that is where the requirements live, not because this is an official tool.

mincpmpersec Without poddur Validates as JSON. OpenRTB Prices Dynamic Pods.

Aleksander Sekowski — Mon, 21 Sep 2026 21:26:40 +0000

A CTV pre-roll template ships "mincpmpersec": 5.0 on every video imp. There is no poddur, no maxseq, no sibling imp with a matching podid. The request parses. The exchange forwards it. A buyer's pod optimizer reads five dollars per second and bids as if the slot were part of a dynamic pod.

It is one linear ad in a fixed break. OpenRTB 2.6 defines mincpmpersec as a price floor for the dynamic portion of a video ad pod, relative to the duration of bids an advertiser may submit. Without poddur or maxseq, that float is pod vocabulary on inventory that never declared a pod.

IAB's Redefining Media Types (RMT) standard plans to classify impressions from fields that already exist on the bid request, including ad format via plcmt, linearity, and mtype. Pod economics use a parallel cluster: poddur, maxseq, mincpmpersec, slotinpod. When a trafficking snippet copies the per-second floor from a pod template onto every linear imp, format classifiers and pod bidders inherit conflicting stories from the same JSON object.

What mincpmpersec actually binds to

OpenRTB added pod bidding fields in 2.6. The ones that matter for this bug:

Field	Role
`poddur`	Total seconds advertisers may fill in a dynamic pod (or the dynamic half of a hybrid pod)
`maxseq`	Maximum number of ads served into a dynamic pod
`mincpmpersec`	Minimum CPM per second for the dynamic portion, relative to bid duration
`slotinpod`	Guaranteed slot position when the seller can commit to it

minduration and maxduration bound individual creatives. poddur bounds the whole break. mincpmpersec is not a generic CPM-per-second knob for linear video; the spec text ties it to dynamic pod filling.

A valid dynamic pod shape includes context, for example:

"video": {
  "mimes": ["video/mp4"],
  "protocols": [2, 3, 5, 6],
  "poddur": 120,
  "maxseq": 4,
  "mincpmpersec": 5.0
}

The broken shape I see in the wild drops the pod container and keeps the floor:

"video": {
  "mimes": ["video/mp4"],
  "protocols": [2, 3, 5, 6],
  "minduration": 15,
  "maxduration": 30,
  "mincpmpersec": 5.0
}

Schema validation often passes because mincpmpersec is an optional float on Video. Nothing in JSON Schema requires poddur when mincpmpersec is present.

How you catch it

I maintain RTBlint, an open source OpenRTB linter. Semantic checks run after schema validation. The pod warning is explicit:

$ rtblint validate --type request @bid.json
  warning openrtb.video.pod.mincpmpersec_without_pod_context
          mincpmpersec is meant for the dynamic portion of a video ad pod; it is present
          without poddur or maxseq, which normally accompany a dynamic pod.
          imp[0].video.mincpmpersec

Rule id: openrtb.video.pod.mincpmpersec_without_pod_context. It is a warning, not a hard error, because a single imp can represent an entire dynamic pod with no sibling imps to correlate (OpenRTB allows that shape when poddur or maxseq is present). The failure mode here is the opposite: pod pricing language without any pod duration or sequence cap.

Paste the imp into the OpenRTB docs hub and compare against the dated snapshot you actually validate (2.6-202606 versus 2.6-202303 changes pod-adjacent fields over time). Version drift on pod objects is easy to miss when only the top-level openrtb version string moves.

For live and event inventory, the same request often carries rqddurs arrays for dead-air control. The live event ad insertion walkthrough documents the mutual exclusivity between rqddurs and minduration/maxduration, plus this orphan mincpmpersec pattern, because rehearsal traffic copies pod defaults from on-demand templates.

Why RMT cares

RMT's operational layer wants binary answers from fields sellers already populate inconsistently. Ad format is mapped to plcmt, linearity, and mtype. That mapping assumes the video object describes one impression honestly.

An orphan mincpmpersec does not flip plcmt, but it does tell downstream systems the impression participates in dynamic pod pricing. Buyers that rank opportunities by effective CPM per second will compute a floor that the seller never intended for a single-slot linear break. Reporting that joins bid requests to delivery logs will bucket the imp with podded CTV paths.

Fix the template, not the bid: either add poddur or maxseq when the break is genuinely dynamic, or remove mincpmpersec and use bidfloor / durfloors for linear floors. If you are migrating snapshots, read which OpenRTB dated train you are on before you diff pod fields against an old integration guide.

Where to go next

What RTBlint checks separates schema errors from semantic pod and privacy rules.
Delisted CTV apps and blocklist gaps is a reminder that CTV bid requests carry app identity fields that must agree with trust lists; pod mislabeling and bundle mismatches often show up in the same trafficking export.

Run pod-shaped imps through validation in CI before you enable a new ad-server build. The HTTP 200 from your exchange partner does not mean the Video object tells one story.

Pinterest CAPI Requires event_id. Meta Only Warns on the Same Field.

Aleksander Sekowski — Mon, 21 Sep 2026 21:25:10 +0000

A thank-you page fires the browser Pinterest tag and a server POST to api.pinterest.com/v5/ad_accounts/{id}/events. Ads Manager on Meta looks healthy. Pinterest reporting shows two checkouts for one order.

The usual suspect is a duplicate GTM tag. The usual contract gap is event_id.

{
  "data": [
    {
      "event_name": "checkout",
      "action_source": "web",
      "event_time": 1770000000,
      "user_data": {
        "em": "6a7a73766627eb611720883d5a11cc62b5bfee237b00a6658d78c50032ec4aee",
        "client_ip_address": "203.0.113.42",
        "client_user_agent": "Mozilla/5.0"
      },
      "custom_data": {
        "value": "129.99",
        "currency": "USD"
      }
    }
  ]
}

That body is structurally close to what many teams already send to Meta's Graph events edge. It is not complete for Pinterest. Pinterest documents event_id on each event so the API can deduplicate against the Pinterest tag on the same conversion. Without it, the server event and the tag event are two rows.

Meta is different on the same field. Meta recommends event_id for deduplication between the pixel and Conversions API. Missing event_id on Meta is a warning, not a hard failure. The POST can still return 200 and the event can still land. Teams that wired dedup only because Meta's Events Manager nagged them often never add the field to the Pinterest branch of a shared template.

What Pinterest actually requires

Pinterest's v5 events payload wraps one or more events in data[]. Each object needs event_name, action_source, event_id, event_time, and user_data with at least one match key (em, hashed_maids, or IP plus user agent).

action_source for web is lowercase web, not Meta's website and not Snap's WEB. Copying Meta's enum verbatim is a silent routing bug before dedup even matters.

event_time is Unix seconds, ten digits, like Meta. Thirteen digits are milliseconds and belong on LinkedIn's clock, not Pinterest's.

Standard event names are lowercase strings such as checkout, add_to_cart, and page_visit. Meta's Purchase string is not Pinterest's purchase event. That naming split is its own failure mode; the short version is that checkout is not Purchase on the wire.

For dedup specifically, mint one stable id per conversion (order id, checkout token, UUID generated once on the thank-you page) and send the same value on the Pinterest tag and the CAPI POST. Retries should reuse the id; new ids on retry look like new conversions.

How you catch it before finance does

I maintain Pixellint, an open source linter for pixels and conversion API payloads. The Pinterest Conversions API pack (vendor/pinterest-conversions-api) contracts data[] against Pinterest's published parameter docs.

On the payload above, missing event_id:

$ pixellint validate json @pinterest-checkout.json
rulepack: vendor/pinterest-conversions-api (vendor: pinterest)
  error   vendor.pinterest-conversions-api.body.event_id.missing
          `event_id` is missing. It identifies the event for deduplication
          against the Pinterest tag.
    fix:  Send a stable id per conversion, such as an order number.
    docs: https://developers.pinterest.com/docs/track-conversions/track-conversions-in-the-api/

Run the same file against Meta's pack and you get a warning, exit code 0:

rulepack: vendor/meta-conversions-api (vendor: meta)
  warning vendor.meta-conversions-api.body.event_id.missing

That asymmetry is why CI that only fails on Meta errors misses Pinterest. Lint both packs on the same canonical event object, or store one internal event and map fields at the vendor edge.

Paste the body into the browser playground if you do not want a local install. Point the CLI at a saved URL that hits api.pinterest.com when you are testing the full path:

cargo install pixellint
# or: npm install pixellint
pixellint validate json @pinterest-checkout.json --rulepack vendor/pinterest-conversions-api

The field table and rule ids live on the Pinterest Conversions API pack page. For how the img tag and the POST share clocks and names, read the Pinterest tag and CAPI playbook.

Where to go next

If one JSON blob fans out to Meta, Pinterest, Snap, and Reddit from the same Cloud Function, read one CAPI JSON cannot serve every vendor: the adapter belongs at the edge, not in a shared schema everyone "mostly" accepts.

Event time units maps seconds, milliseconds, microseconds, and ISO 8601 across vendors so you are not guessing from one sample payload. Conversions API payloads covers batch shapes, when to fire from the order server, and how dedup ids should survive retries.

The short version

Pinterest requires event_id on every CAPI event for tag dedup. Meta recommends the same field but ingests without it. A shared worker that only enforces Meta's warnings will double-count on Pinterest while both endpoints return success. Send lowercase web, lowercase checkout, seconds on event_time, and the same dedup id on the tag and the POST.

Pixellint is independent of Pinterest and Meta. The rule ids cite their docs because that is where the requirements live, not because this is an official vendor tool.

VAST Extension type="pos" With a plcmt Child Still Validates. Stitchers Read type.

Aleksander Sekowski — Sat, 19 Sep 2026 00:03:31 +0000

A pause campaign ships. OpenRTB carried video.plcmt=5. The VAST InLine looks fine in a schema validator. Format reporting still shows squeezeback geometry, or nothing at all, because one extension copied the wrong attribute onto the wrapper.

<Extension type="pos" ext="adcom">
  <plcmt>5</plcmt>
</Extension>

The integer 5 is correct for Pause. The child tag name is correct for a placement subtype. The type attribute says this block is a pos signal. Anything that trusts type before it reads children will treat the payload as screen position, not as plcmt, or it will drop the block when the inner tag does not match the declared signal.

IAB Tech Lab finalized CTV Ad Portfolio signaling in July 2026. The VAST side round-trips four AdCOM enumerations inside <Extension ext="adcom">: plcmt, pos, playbackmethod, and attr. Each signal gets its own extension node. The type attribute names which signal the extension carries. The child element repeats that name and holds the integer value.

The canonical shape looks like this:

<Extension type="plcmt" ext="adcom"><plcmt>5</plcmt></Extension>
<Extension type="pos" ext="adcom"><pos>7</pos></Extension>
<Extension type="playbackmethod" ext="adcom"><playbackmethod>9</playbackmethod></Extension>

That pattern exists because the VAST response outlives the bid request. SSAI stitchers and measurement vendors downstream of the auction often never see OpenRTB. They learn what was sold from the creative envelope. Copy-paste from an older template, a merge conflict in a trafficking UI, or a single swapped attribute on export is enough to produce a tag where every integer is in range and the labels disagree.

Why type and tag name are not redundant

Schema validation cares about nesting and text content. It does not require type="plcmt" when the only child is <plcmt>. Many pipelines therefore green-light the mistake.

Production consumers are not symmetric. Portfolio guidance treats type as the selector. Rule VAST-4.4-adcom-extension-type-mismatch flags exactly this case: the declared AdCOM signal in type does not match the payload element name. The rule text notes that downstream stitchers key off type to decide what to read.

That is a different failure mode from inconsistent values across signals. You can ship plcmt=5 with playbackmethod=1 and every extension wrapper can be structurally perfect while the integers still describe incompatible formats. Value-level mismatch is its own QA problem. The bug here is mislabeling at the wrapper: the pause integer rode inside a node advertised as geometry.

A related defect is type="loudness" or any string outside the four signal names, which triggers VAST-4.4-adcom-extension-unknown-signal. The type-or-child swap is quieter because both strings are real AdCOM field names.

How I catch it before traffic

I start with the VAST tag tester. Paste the live ad tag URL or the resolved InLine XML. It fetches wrappers when needed, previews the NonLinear or video asset, and runs the portfolio rule pack alongside generic VAST checks. For a pause or overlay buy I confirm both render path and the AdCOM extensions in the same pass, not just that an MP4 bit rate exists.

Portfolio tags often chain. When the defect might live in a wrapper hop, I run the same URL through the VAST inspector. It walks each redirect, validates every hop, and shows where the InLine with extensions actually lands.

For NonLinear SIMID and IAB sample layouts, I also open the IAB-style VAST tester (SIMID studio and sample creatives). That workbench is an independent fork, not an IAB Tech Lab product. Live URL QA still belongs on vastlint.org/tester/; wrapper debugging stays on the inspector.

After browser QA I keep vastlint check on fixtures in CI. The type mismatch warning survives automation better than eyeballing four nearly identical extension blocks.

Where to read the contract

The type mismatch rule reference shows the wrong and right markup side by side. Pair it with unknown signal when type is not one of the four AdCOM names at all.

The CTV Ad Portfolio guide maps Pause, Screensaver, Overlay, Squeezeback, and In-Scene to the signal combinations each format allows. Use it when you need to verify that the integers inside correctly labeled extensions still belong to the same row in the table.

Legacy players that never implemented VAST 4.x NonLinear still expect portfolio creative inside <Extension type="ctv_ad_portfolio">. That path binds by creative id and carries its own required MediaFiles rules. The VAST 2.0 portfolio extensions write-up is the reference when your QA stack only understands 2.0-shaped XML. For how finalized signaling relates to the VAST 4.4 draft schema, see signaling versus schema validation.

Do not treat a converting draft-schema blog post as the only checklist. The failure mode in this article is visible on 4.2 tags today, which is where IAB's own portfolio examples still declare version.

Closing the loop with trafficking

When format mix dashboards disagree with the deal line, grep the resolved InLine for <Extension blocks before you reopen the player integration. One swapped type attribute is enough for pause spend to inherit overlay position reporting, with no player error to paste into a ticket.

Fix the wrapper, redeploy, and re-run the same URL in the tester so the extensions you see match the plcmt value the buyer actually purchased.

Publisher-Stage ARTF With bid_response on the Envelope Stages the Agent Wrong

Aleksander Sekowski — Fri, 18 Sep 2026 00:01:47 +0000

An SSP-side ARTF host labels the extension point LIFECYCLE_PUBLISHER_BID_REQUEST, keeps yesterday's bid_response on the envelope for debugging, and forwards ACTIVATE_DEALS mutations against the publisher bid_request. gRPC returns OK. The agent believes no buyer has answered yet. The orchestrator is staring at a seatbid it never told the agent existed.

That is not a deal-activation bug in the agent. It is a reused envelope whose lifecycle name and its OpenRTB members disagree.

The IAB Tech Lab Agentic Real Time Framework (ARTF) puts a containerized agent beside an SSP, exchange, or DSP. The host sends an RTBRequest with a lifecycle value, a tmax budget in milliseconds, the OpenRTB object under mutation, and applicable_intents. The agent returns Mutation messages with semantic paths. The orchestrator applies what it accepts and only then forwards the auction.

Publisher-stage calls run before any DSP has answered. Response-stage calls expect a bid_response member when intents such as BID_SHADE need seat and bid ids. The lifecycle enum names the stage. It does not delete extra members you left on the JSON from an earlier hop.

What the stage label actually promises

LIFECYCLE_PUBLISHER_BID_REQUEST means the extension point sits on the outbound publisher request. No DSP answer belongs on that wire yet. If bid_response is present anyway, RTBlint reports artf.lifecycle.payload_unexpected:

{
  "id": "ep-1",
  "tmax": 120,
  "lifecycle": "LIFECYCLE_PUBLISHER_BID_REQUEST",
  "bid_request": { "id": "a-1", "imp": [{ "id": "imp-1", "banner": { "w": 300, "h": 250 } }] },
  "bid_response": { "id": "a-1", "seatbid": [{ "seat": "dsp-1", "bid": [{ "id": "bid-abc", "impid": "imp-1", "price": 2.5 }] }] }
}

The envelope declares publisher bid request stage and carries a full bid_response. At that stage no DSP should have answered. The validator treats it as a warning, not a hard error, because a private host might deliberately pass prior context. For a default orchestrator, the warning is the point: the agent's model of where it sits in the auction is wrong even when protobuf JSON parses cleanly.

The inverse failure, response stage without bid_response, is artf.lifecycle.payload_mismatch. That one blocks shading paths that need a bid id the envelope never included. Together they are the same contract: lifecycle tells the agent which intents make sense; the carried OpenRTB members have to match that story.

Reusing one JSON blob across hops is how both show up in production. A team logs the full auction state, copies the object into the next ARTF fixture, and forgets to drop bid_response when the lifecycle moves back to publisher stage. gRPC still accepts the bytes.

tmax on the same envelope is a separate unit trap

ARTF tmax is milliseconds budgeted for the mutation RPC inside the auction, not the OpenRTB bid timeout copied from bid_request.tmax. Reference samples use roughly 120 to 150 ms. Values above 1000 ms trigger artf.tmax.implausible: the extension point runs inside an exchange timeout, and a budget measured in seconds usually means someone pasted an auction limit without converting units.

That warning does not fail the envelope by itself. It pairs badly with a mislabeled lifecycle: you can burn seconds of agent time on a call that still carries the wrong stage label and a ghost bid_response.

How you catch it before the orchestrator applies the wrong mutations

I maintain RTBlint, an open source OpenRTB and ARTF linter. Envelope checks run before mutation checks because lifecycle and intents define what the response is allowed to propose.

$ rtblint validate --type artf-request rtb-request.json
FAILED (OpenRTB 2.6-202606 ARTF request envelope): 0 error(s), 1 warning(s).
- [warning] bid_response: lifecycle is LIFECYCLE_PUBLISHER_BID_REQUEST, which runs
  before any DSP has answered, yet the envelope carries a bid_response.
  (artf.lifecycle.payload_unexpected)

If the document never parses, nothing downstream runs. Truncated fixtures and log line limits show up as artf.payload.invalid_json before lifecycle logic executes.

Pass two on responses pairs each mutation against applicable_intents and semantic paths in the payloads actually carried. Pass three applies accepted mutations and revalidates OpenRTB so field-level damage appears on the request the exchange will see.

The same rules run in the ARTF simulator, MCP tools, and gRPC on openadtech.rtblint.v1. ARTF already mandates gRPC for the extension point; validating on that channel beats discovering stage skew only after deals activate against the wrong document.

Where to read the rest of the surface

ARTF explained walks the request and response members without assuming you read the PDF first. The docs index links every ARTF rule id, including lifecycle, tmax, and mutation path checks, if you want stable ids in CI.

RTBlint is independent of IAB Tech Lab. The rule ids above come from the public ARTF proto and the v1.0 document; they exist because lifecycle and payloads are contracts you can violate while the RPC still returns OK.

Raw fbclid in user_data.fbc Is Not Meta's _fbc Cookie. The CAPI POST Can Still Return 200.

Aleksander Sekowski — Thu, 17 Sep 2026 01:00:18 +0000

A paid social checkout posts Purchase to the Meta Conversions API. Graph returns 200. Events Manager lists the event. Click-through attribution still shows nothing tied to the ad.

The access token is fine. The clock is in seconds. Email is hashed. The bug is the click id field.

"user_data": {
  "em": ["a1b2c3...64 hex..."],
  "fbc": "IwAR0abcdefGhijklmnop"
}

That string is the `fbclid` query parameter from the landing URL, copied server-side from the order record. Meta's [customer information parameters](https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/customer-information-parameters) document `fbc` as the `_fbc` browser cookie, not the naked click token. The documented shape is four dot-separated segments:

fb.{subdomain_index}.{creation_time}.{fbclid}


Example from a real cookie line:

fb.1.1758300000.IwAR0abcdef


A bare `IwAR…` token fails that contract even when it is the same characters Meta put on the ad click. Matching expects the cookie format Meta generates when `fbclid` hits a first-party page and something (Meta Pixel, Conversions API tag helper, or your own setter) writes `_fbc` with a creation timestamp.

## Why the landing hop matters

`fbclid` lives on the inbound ad URL. `_fbc` lives in first-party storage after that URL is processed. If the shopper lands on a intermediate domain, if the tag loads after your server already captured the query string, or if Safari ITP blocks the write, your order service may only see `fbclid` in the referrer log. Forwarding that raw value as `user_data.fbc` is a common server-side shortcut. It is not what Meta documents for CAPI.

The failure mode is quiet. HTTP succeeds. Parameter names match the sample JSON. Events Manager does not flash a schema error for every malformed `fbc`. You notice only when campaign reports stay blind to clicks you know happened.

More detail on the hop is in [Meta _fbc is empty unless fbclid hits the landing page](https://pixellint.org/blog/meta-fbc-needs-fbclid-at-landing/).

## What the linter checks

I maintain [Pixellint](https://github.com/aleksUIX/pixellint), an open source linter for pixels and conversion API payloads. The Meta Conversions API pack contracts `user_data.fbc` against Meta's documented regex shape when the field is present:

console
$ pixellint validate json @purchase.json
rulepack: vendor/meta-conversions-api (vendor: meta)
error vendor.meta-conversions-api.body.user_data.fbc.invalid
user_data.fbc is IwAR0abcdefGhijklmnop, which does not match
^fb\.[0-9]\.[0-9]+\..+$. Meta documents the click id cookie as
fb.${subdomain_index}.${creation_time}.${fbclid}.
fix: Send the _fbc cookie verbatim, or rebuild it in the documented format.


Paste the body into the [playground](https://pixellint.org/) if you do not want a local install. Artifacts you test may be stored; see [privacy](https://pixellint.org/privacy/).

sh
cargo install pixellint

or: npm install pixellint

pixellint validate json @purchase.json --rulepack vendor/meta-conversions-api




The field table and every rule id live on the [Meta Conversions API pack page](https://pixellint.org/packs/meta-conversions-api/). For how `fbc` and `fbp` differ from hashed email and from click ids on other vendors, read [Identity for ads](https://pixellint.org/docs/identity/).

## Fix the pipe, not just the string

Correct CAPI wiring forwards the `_fbc` cookie value from the browser session that converted. If you must rebuild server-side, Meta's parameter docs describe setting `_fbc` when `fbclid` is present on the landing URL: subdomain index (usually `1` on www), creation time in **seconds**, then the `fbclid` value. Do not reuse millisecond clocks from other vendors; that is a different class of bug covered in [event time units](https://pixellint.org/docs/timestamp-units/).

Browser-side, confirm the pixel or tag actually runs on the landing URL where `fbclid` appears, not only on checkout. [Facebook Pixel Helper vs Network](https://pixellint.org/docs/facebook-pixel-debugger/) is the split between what the extension shows and what the network tab proves. When Events Manager looks healthy but production matching is empty, walk [Conversions API not working](https://pixellint.org/docs/conversions-api-not-working/) before you rotate tokens.

Also scan for `test_event_code` left on live traffic. That routes events to the test tool, not production reporting. It is a separate silent miss documented in Meta's API guides and flagged as `vendor.meta-conversions-api.testing.test_event_code_present` in the same pack.

## Where to go next

[What is a conversion API](https://pixellint.org/docs/what-is-a-conversion-api/) is the envelope: match keys, clocks, and dedup ids across vendors. [Conversion API validator](https://pixellint.org/docs/conversion-api-validator/) is the CI-shaped entry point when you lint POST bodies on every deploy.

Pixellint is independent of Meta. The rule ids above cite Meta's Conversions API docs because that is where the requirements live, not because this is an official tool.

**Summary:** Send `_fbc` verbatim, or build `fb.1.{seconds}.{fbclid}` after `fbclid` hits first-party landing storage. Raw `fbclid` in `user_data.fbc` is not the documented click cookie, and a 200 from Graph does not prove click matching worked.