DEV Community: Aleksander Sekowski

hp=0 in SupplyChain 1.1 Marks Custody Hops. ads.txt Checks on Them False-Fail.

Aleksander Sekowski — Sun, 06 Sep 2026 00:40:32 +0000

A CTV bid request arrives with a three-node source.schain. The middle node names an SSAI platform the buyer has never heard of. Your supply-path optimizer flags it: sid not in sellers.json, ads.txt lookup fails, chain rejected.

The partner adopted SupplyChain 1.1 early. That middle node carries hp: 0. It was never supposed to pass ads.txt. Your reader treats it like a payment hop because that is what six years of 1.0 chains trained everyone to assume.

What hp was supposed to mean

The hp field on a SupplyChainNode is an integer: 1 if this node is involved in the flow of payment, 0 if not. Required on every node.

SupplyChain 1.0 then adds the sentence that shaped every implementation since: for version 1.0, this property should always be 1. The flag became a boolean with one legal value. Builders hardcoded hp: 1. Validators asserted it. Buy-side audit walked every node against sellers.json and ads.txt because, in a 1.0 chain, every node is a seller account.

The result is a chain that describes money and nothing else. A request that crossed a header-bidding wrapper, a publisher ad server, an SSAI stitcher, and two SDKs might disclose two nodes. Both are payment nodes. Four systems took custody of the payload. None of them are named.

SupplyChain 1.1 (IAB Tech Lab public comment, June 2026) keeps the same nodes array and lets custody-taking systems append themselves with hp: 0. Prebid, ad servers, SSAI platforms, SDKs: the plumbing everybody runs and nobody currently discloses.

One clause in the proposal matters for anyone running authorization checks: hp=0 nodes are not expected to pass ads.txt validation. Referencing a sellers.json entry for a non-payment handler is strongly recommended, not required. A custody node is disclosure, not an authorization claim.

The chain before and after

A publisher ad server, an SSAI platform, and an exchange on the same impression:

"source": {
  "schain": {
    "ver": "1.0",
    "complete": 1,
    "nodes": [
      { "asi": "pubadserver.example", "sid": "8842", "hp": 1 },
      { "asi": "exchange.example", "sid": "pub-42", "hp": 1 }
    ]
  }
}

Same path under 1.1:

"source": {
  "schain": {
    "ver": "1.1",
    "complete": 1,
    "nodes": [
      { "asi": "pubadserver.example", "sid": "8842", "hp": 1 },
      { "asi": "ssai.example", "sid": "net-19", "hp": 0 },
      { "asi": "exchange.example", "sid": "pub-42", "hp": 1 }
    ]
  }
}

Three consequences fall out immediately. A supply-path model that scores by chain length now sees a longer path for the same inventory and will penalize the more honest disclosure unless it filters on hp first. Duplicate bid detection gets better: the same request arriving through two routes now carries evidence of which systems it crossed. An authorization check that walks all three nodes against ads.txt finds one that was never supposed to be there.

That third outcome is the bug I keep seeing in production readers, not in the payload.

What your validator actually checks today

Under SupplyChain 1.0 rules, a node with hp: 0 triggers openrtb.schain.node.hp_unexpected:

$ rtblint validate bid-request.json
warning  openrtb.schain.node.hp_unexpected
         hp is 0; version 1.0 of the SupplyChain object expects every node
         on the declared path to be marked as part of the payment flow
         with hp set to 1.
         path: source.schain.nodes[0].hp

That warning is correct for a chain that declares ver: "1.0". It is the wrong verdict for a chain that declares ver: "1.1" and uses hp as real data.

The structural checks survive the migration: asi and sid required, adjacent duplicate nodes still fail (openrtb.schain.duplicate_node), complete still means something (though new enumerations are proposed, so read the final text before branching on it). What breaks is anything that assumed every node resolves in sellers.json or passes ads.txt.

When you run resolution with a local cache, RTBlint skips sellers.json lookup on hp=0 nodes entirely. Only payment hops get openrtb.resolve.sid_not_in_sellers. That matches the spec intent: authorization applies to the payment path, not to custody disclosure.

How you catch it before a partner ships 1.1

Paste the bid request into the OpenRTB tester. It flags structural schain issues with the JSON path attached, including chains left in the pre-2.6 source.ext.schain location (openrtb.field.moved) and misspelled node fields (openrtb.field.undefined).

For a corpus of what your stack actually emits:

$ rtblint validate --resolve --cache ./trust-cache/ ./outbound/*.json

The same checks run as MCP tools an agent can call on its own output, and over gRPC on openadtech.rtblint.v1. Agentic stacks (AAMP buyer agents, ARTF hosts) still end the hop as an OpenRTB bid request. The agent handshake succeeding does not mean source.schain matches the reader on the other side.

Grep your codebase for the habits that will false-fail honest 1.1 chains:

hp.*[:=]\s*1          # hardcoded payment claims
"1\.0"                # ver comparisons that silently drop 1.1
schain.*length        # hop-count policies without an hp filter
adsTxt|ads_txt        # authorization scoped chain-wide

Every hit is a decision, not a mechanical find-and-replace.

Where to go next

The SupplyChain 1.1 analysis walks the check-by-check split between 1.0 assumptions and 1.1 semantics: which rules survive, which ones were wearing a 1.0 assumption as clothing.

The migration checklist separates sell-side builder steps from buy-side reader steps. If you read chains for SPO or verification, the reader half is the one that prevents manufactured violations on hp=0 nodes.

Field definitions and the 2.5 vs 2.6 placement (source.schain vs source.ext.schain) live in the schain reference. Overclaiming completeness is its own failure mode: openrtb.schain.incomplete fires when complete: 1 does not match what the nodes actually disclose.

For how schain sits beside ads.txt, sellers.json, and the newer trust artifacts, the supply chain trust stack guide maps which file answers which question. None of them cross-check each other automatically; schain records the path, the other files authorize it.

The short version

hp=0 is not a broken seller ID. It is a custody hop that never touches payment. Running ads.txt or mandatory sellers.json resolution on those nodes rejects good supply. Split hop counting from money counting. Accept ver: "1.1" or reject it loudly. The silent third option, dropping an unrecognized version and proceeding without the chain, is worse than either.

RTBlint is independent of IAB Tech Lab. The rule ids above cite the SupplyChain object spec and the 1.1 public comment proposal because that is where the requirements live.

Reject on the Banner Can Still Be Grant in gdpr_consent. Withdraw Has to Change the Hop.

Aleksander Sekowski — Sat, 05 Sep 2026 00:38:59 +0000

QA clicks Accept, copies the Floodlight hop from DevTools, clicks Reject, copies again, and compares screenshots. The banner flipped. The two URLs are identical.

That is not a flaky CMP skin. The vendor that received the second hop received the same grant string it got on accept. GDPR says consent must be as easy to withdraw as to give. The wire half of that sentence is not the modal copy. It is whether the next pixel, collect ping, or CAPI post carries a different payload, or no payload at all.

Accept is already instrumented. Withdraw usually is not

The grant path is wired. A CMP callback expands gdpr_consent, gtag('consent', 'update', …) runs, Meta gets an fbp write, Floodlight fires with gdpr=1 and a TC String. Teams paste that URL into tickets and call consent done.

Withdraw is supposed to be the same class of artifact with different bits, or silence. If the only thing that changes is banner text, every vendor that heard yes keeps processing on the old string. Cookies written on grant still exist. Pixels that read _fbp or a CMP cookie do not poll the banner. They read the next HTTP request.

Researchers auditing Tranco top sites treated revocation as its own object, not the inverse screenshot of accept. On TCF sites they could read after revoke, 22 of 136 still stored a TC String that encoded positive consent. That is not a missing parameter. That is a yes that outlived the user's no. On another subsample, third parties that had been told about accept were not informed of withdraw on 101 of 136 sites. Vendors do not call __tcfapi on a schedule. They see the hop you fire, or they do not.

What gdpr_consent actually carries

gdpr_consent is not a boolean. It is a URL-safe base64 TC String whose core segment fixes version 2 in the first six bits, then encodes purpose consent, legitimate interest, vendor flags, and timestamps in the bit field IAB Europe documents for TCF v2.

gdpr_consent=1 passes a character-set check and fails the contract: those bits decode to version 1, not a TC String. A real string that still encodes grant after reject is a different failure. The alphabet looks like TCF. The purposes still read yes.

The macro name matters too. ${GDPR_CONSENT_123} must expand with vendor 123's GVL id in the macro suffix. A template that still holds [GDPR_CONSENT_123] at serve time is empty consent. A populated grant macro after revoke is worse: the ad server did expand something, and what it expanded is still yes.

Floodlight, Meta /tr, LinkedIn pixels, and server-side CAPI each need their own signal or their own hold. Consent Mode on gtag does not write gdpr_consent. dpo=LDU does not write a TC String. A Purchase queued at accept and retried after revoke is new processing unless the webhook gates on the current CMP state.

How you catch it

Do not stop QA at refuse-on-landing in a fresh profile. Run the returning-user sequence: accept, capture, revoke, capture again.

After revoke, facebook.com/tr, a Floodlight activity, and /g/collect should be gone, redacted, or carrying a string that no longer encodes grant. If they match the accept capture byte for byte, withdraw did not travel. Redirect chains matter: if hop two drops the updated string, hop three is still the old grant.

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 delete cookies or rule on lawful basis. It will tell you whether the URL you captured after revoke is still a granted IAB hop.

On a placeholder after accept or revoke:

$ pixellint validate url 'https://ad.doubleclick.net/ddm/activity/src=1234567;type=convr0;cat=purch0;gdpr=1;gdpr_consent=1'
rulepack: core
  error   core.privacy.tc_string_version
          `gdpr_consent` is `1`, whose first six bits decode to version 1.
          The TC String spec fixes the version to 2, so this is not a TC String.
    fix:  Pass the TC String from the CMP. A placeholder such as `1` is
          base64-shaped but carries no consent.

On a syntactically valid string, core checks pass. That is where you compare captures. Paste the post-revoke Floodlight URL into the playground beside the accept capture. Same core segment, same purpose bits: the banner lost to the macro. Different LastUpdated deciseconds with grant still set: the CMP updated the timestamp without flipping consent.

Server-side GTM and CAPI get the second paste too. A Graph 200 after revoke means Meta accepted JSON. It does not mean you had a basis to send it.

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1770000000,
    "action_source": "website",
    "user_data": {
      "em": ["7b52009b64fd0a2a49e6d8a939753079792b5a1"],
      "fbp": "fb.1.1770000000.123",
      "client_ip_address": "203.0.113.42"
    }
  }]
}

pixellint validate json on that body after revoke flags shape errors (seconds on event_time, hashed IP rules) and missing website fields. It does not know your CMP state. You gate the webhook: when the basis is gone, skip the postback or send a redacted event. Meta documents opt_out for attribution-only use; that is not a substitute for stopping match keys you no longer have permission to send.

cargo install pixellint
# or: npm install pixellint
pixellint validate url 'https://...' 
pixellint validate json @capi-after-revoke.json

Where to go next

The consent revocation guide walks the full accept-then-revoke pass: cookies that survive reject, third parties that never hear no, and why a CMP callback update alone is incomplete.

TCF v2 on pixels covers gdpr=0 vs gdpr=1, macro expansion, truncation, and sunset v1 strings. That is the accept-side contract this article assumes you already fire correctly.

What counts as a pixel separates impression beacons from click trackers and from CAPI posts so you know which artifact must change on withdraw for each vendor.

The Meta Conversions API pack lists event_source_url, hashing rules, and opt_out with citations. Use it on the server body in the same session where you lint the browser hop.

Process docs describe storing the CMP choice with the session so retries and batch jobs do not replay grant-era payloads after reject.

The short version

Withdraw is a request class, not a banner state. Capture the pixel URL after accept and after revoke; they must differ, or the revoke hop must be absent. Decode gdpr_consent on both. A grant string after reject is a fail even if the UI flipped. Repeat for CAPI JSON and for every third party that heard yes. Fix the CMP callback, the ad-server macro, or the webhook gate, not the screenshot.

Pixellint is independent of IAB Europe and of the audit literature cited on our docs site. The rule ids above cite the TC String spec and vendor parameter docs because that is where the wire contract lives.

A VAST Tag Can Ship AdVerifications and Still Deliver Zero OMID Measurement

Aleksander Sekowski — Fri, 04 Sep 2026 00:13:55 +0000

The CTV campaign cleared delivery. The ad server counted the impression. The verification partner's dashboard stayed empty for three days before anyone opened the VAST XML.

The tag was not missing measurement. It had an <AdVerifications> block, a <Verification> node, and a URL inside <JavaScriptResource>. Visually, the buy included Open Measurement. On the wire, the OM SDK had nothing it could bind to.

That gap is common enough that I treat <AdVerifications> as a checklist, not a boolean. VAST 4.1 introduced the block when IAB moved verification off VPAID. The video creative and the measurement script are separate jobs now. SIMID handles interactivity. OMID handles viewability and IVT through the Open Measurement SDK. A tag that still routes measurement through a VPAID <MediaFile> is on the wrong path entirely; the VPAID reference and the deprecation timeline spell out why CTV inventory rejects it.

What AdVerifications actually promises

Under <InLine> or <Wrapper>, <AdVerifications> holds one or more <Verification> elements. Each verification is a contract with four parts the player and OM SDK read together:

vendor on <Verification>: a domain-qualified key such as measureco.com-omid. Required in VAST 4.1+. Without it, the session cannot be attributed to a measurement provider even if a script loads.
A loadable resource: <JavaScriptResource> for web and most OM SDK integrations, or <ExecutableResource> on native paths. VAST 4.1 requires apiFramework on both.
apiFramework="omid": lowercase, exactly. This is not the same attribute as apiFramework="SIMID" on <InteractiveCreativeFile>. SIMID is the interactive layer; OMID is the verification layer. They solve different problems and live in different elements.
<VerificationParameters>: bootstrap JSON or key/value data the vendor's script expects at init. Empty or missing parameters are schema-legal and still leave the script with no config.

VPAID used to hide all of this inside one JavaScript <MediaFile>. The migration guide splits the work: interactivity to SIMID, verification to <AdVerifications>. Tags that only half-migrate often carry both paths, which is its own class of failure on CTV.

Here is the shape that looks complete and is not:

<AdVerifications>
  <Verification vendor="company.com-omid">
    <JavaScriptResource>
      <![CDATA[https://verificationvendor.com/omid.js]]>
    </JavaScriptResource>
  </Verification>
</AdVerifications>

The URL is there. The OM SDK does not treat this as an OMID resource because apiFramework is missing. vastlint reports VAST-4.1-js-resource-apiframework as an error: the attribute is required on verification resources in 4.1+.

The fix is not decorative:

<Verification vendor="company.com-omid">
  <JavaScriptResource apiFramework="omid" browserOptional="true">
    <![CDATA[https://verificationvendor.com/omid.js]]>
  </JavaScriptResource>
  <VerificationParameters>
    <![CDATA[{"partner":"abc123"}]]>
  </VerificationParameters>
</Verification>

The failures that survive a visual QA pass

Missing or wrong apiFramework. Omitting the attribute is an error. Setting apiFramework="OMID" or apiFramework="VPAID" is XML that validates in some pipelines and fails at runtime. The OM SDK match is lowercase omid. VAST-4.1-js-resource-apiframework-value fires when the value is anything else.

Verification shell with no resource. Trafficking sometimes inserts <AdVerifications> during creative build and never injects the vendor script URL. You get <Verification vendor="company.com-omid"> with no <JavaScriptResource> and no <ExecutableResource>. The structure exists. Nothing executes. Buyers blame the publisher; the XML shows an empty node.

HTTP verification URLs. Mixed content blocks the script on HTTPS inventory. The linear MP4 plays. Measurement is blank with no player error. Same class of silent failure as SIMID interactive URLs; the SIMID rule reference covers the interactive side, while OMID rules such as VAST-4.1-js-resource-https cover verification scripts.

Empty <VerificationParameters>. Vendors ship init data in this element: partner IDs, feature flags, session hints. An empty tag is often still schema-valid. VAST-4.1-verification-parameters warns because the script starts without the config it was written for.

Duplicate vendor values. Two <Verification> entries with the same vendor string can spawn conflicting OM SDK sessions. Dedup matters when wrappers chain and each hop adds its own block.

Wrapper chains that drop verification. <AdVerifications> on a wrapper should pass verification metadata to the resolved inline. If your QA stops at the first hop, you can approve a wrapper that never forwards the vendor script the inline actually serves. That is a chain problem, not a creative problem.

How I catch it before the campaign runs

I start with the live tag URL in the VAST tag tester. It fetches the response, renders the linear creative, and surfaces tracking and click URLs. AdVerifications shows up in the parsed tree. I can see whether <JavaScriptResource> declares apiFramework="omid" and whether a URL is present before anyone presses play in a staging player.

Wrapper-heavy CTV paths go through the VAST inspector next. It follows each <VASTAdTagURI> hop and shows where the chain breaks, how deep it ran, and which inline finally handed back creatives. Verification stripped at hop two is invisible if you only ever pasted the top-level XML.

After that, CLI or CI:

$ vastlint check omid-tag.xml
omid-tag.xml  VAST 4.1
  error    <JavaScriptResource> is missing required apiFramework attribute
           VAST-4.1-js-resource-apiframework
  warning  OMID <Verification> should include non-empty <VerificationParameters>
           VAST-4.1-verification-parameters

The broken example for missing apiFramework walks through the same tag with the full finding list. The OMID overview maps each element back to VAST 4.1 §3.17 if you need spec anchors for a ticket.

What this is not

<AdVerifications> is not proof that viewability ran. It is instructions for the player to load a vendor script in an OM SDK sandbox. SSAI and many CTV native players never execute that JavaScript at all; verification has to be negotiated at the deal and player level, not assumed from XML presence.

SIMID interactivity does not substitute. A tag with a correct <InteractiveCreativeFile apiFramework="SIMID"> and a broken verification block still plays the interactive creative and still fails independent measurement.

The short version

Presence of <AdVerifications> is not measurement. Every <Verification> needs vendor, a resource with apiFramework="omid", and the vendor's <VerificationParameters>. Test the live URL, walk wrapper chains, then lint the XML. The video will play either way. The buyer's verification invoice is what tells you the contract was hollow.

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

OpenRTB 3.0 Placement With Only tagid Has No AdCOM Subtype

Aleksander Sekowski — Thu, 03 Sep 2026 00:35:57 +0000

A supply-side adapter ships its first OpenRTB 3.0 bid request. The envelope validates. domainspec is adcom. Each item has an id and a spec.placement with the same tagid the 2.x integration used on imp.banner.tagid. The exchange accepts the HTTP 200 and returns no bids.

Nothing in that JSON is syntactically wrong. The failure is semantic: AdCOM never learned what format the placement is.

{
  "openrtb": {
    "ver": "3.0",
    "domainspec": "adcom",
    "domainver": "1.0",
    "request": {
      "id": "req-3-0-no-subtype",
      "item": [
        {
          "id": "item-1",
          "spec": {
            "placement": {
              "tagid": "banner-atf"
            }
          }
        }
      ]
    }
  }
}

The Placement object names the ad slot. It does not declare banner, video, or audio inventory. Under AdCOM that is an incomplete object, not a minimal valid one.

What "subtype" means in AdCOM

OpenRTB 2.x kept format fields as siblings on imp: imp.banner, imp.video, imp.audio, imp.native. OpenRTB 3.0 folds the inventory description into AdCOM objects under item.spec on the request side and under bid.media on the response side.

AdCOM models several core objects as a discriminated union. A Placement must include at least one of:

display (banner or similar display placement)
video (video placement constraints)
audio (audio placement constraints)

An Ad on the bid response side has the same rule: at least one of display, video, or audio under media.ad. A Native Asset needs at least one of title, image, video, data, or link. An AssetFormat in a native request template needs at least one of title, img, video, or data.

These are not optional decoration fields you add when you have time. They are how AdCOM knows which branch of the object you mean. tagid, id, w, and h are metadata on top of a branch that must exist first.

The migration trap is copying 2.x shape into 3.0 paths without moving the format block. On 2.x, imp[0].video.mindur beside imp[0].tagid was enough. On 3.x that same video block belongs under item[0].spec.placement.video. Leaving only placement.tagid is the 3.0 equivalent of an imp with no banner, no video, and no native.

OpenRTB 2.6 also moved many enumerated lists into AdCOM (plcmt, pos, content taxonomies). That work is about value lists. The subtype rules are about object shape: which child object carries the format contract. Both matter, and they fail in different ways.

How you catch it

Schema validation that only checks required keys on Placement will miss this. The object has an id path. JSON parsers are happy.

I maintain RTBlint, an open source OpenRTB linter. On the fixture above it reports:

$ rtblint validate --version 3.0 bid-request.json
FAILED (OpenRTB 3.0 bid request): 1 error(s), 0 warning(s).
- [error] openrtb.request.item[0].spec.placement: A Placement needs at
  least one of display, video, or audio.
  (adcom.placement.subtype_required)

The same pattern fires on responses. A bid that prices against item-1 but returns an Ad shell with only id fails adcom.ad.subtype_required:

"media": {
  "ad": {
    "id": "creative-no-subtype"
  }
}

Native paths have parallel rules. An Asset with only id and no title, image, video, data, or link triggers adcom.asset.subtype_required. A native request template whose AssetFormat lists sizes but no asset type triggers adcom.assetformat.subtype_required.

Paste the payload into the browser tester if you do not have the CLI handy. The rule id names the AdCOM object and the missing branch, which is faster than diffing against the PDF when you are debugging a 3.0 adapter for the first time.

Where to go next

Start with the placement subtype rule reference for the exact request-side requirement and example invalid payloads.

If you are mapping 2.6 video fields forward, read how AdCOM 1.0-202607 renamed content objects and extended enum lists on the AdCOM 1.0-202607 enums blog post. That snapshot is separate from subtype shape, but the same migration project usually touches both.

For response-side QA, keep the Ad subtype rule beside your seatbid fixtures. A valid price and item reference does not rescue an Ad object with no creative branch.

RTBlint is independent of IAB Tech Lab. The rule ids above cite the published AdCOM object definitions because that is where the requirements live, not because this is an official tool.

A TC String in the gpp Parameter Decodes as Header Type 2, Not Type 3

Aleksander Sekowski — Wed, 02 Sep 2026 00:34:05 +0000

A CMP upgrade leaves one consent string on the page. Engineering copies it into every ad-server macro that mentions privacy. The impression pixel fires. Network tab shows a long base64 blob on gpp. QA signs off.

The vendor reading GPP decodes the first six bits of the header and stops. Those bits are 2, not 3. The string is a valid TCF v2 TC String. It is not a GPP string.

https://example.com/px?id=1&gpp=CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA&gpp_sid=2

Nothing in that URL looks broken if you only check that gpp is URL-safe base64. The mix-up is structural, not cosmetic.

Two parameters, two encodings

IAB privacy signals are not interchangeable keys for the same value.

TCF v2 puts the TC String in gdpr_consent (or a Floodlight path equivalent) alongside gdpr=1. The first six bits of the core segment are the TC String version, fixed at 2 for v2.

GPP puts a composite string in gpp, with sections joined by tildes (~). The first section is a header whose first six bits are fixed at 3 as the GPP Header field. The next six bits are the GPP specification version (currently 1). A well-formed v1 header often starts with the letters DB.

One CMP callback can produce both outputs. They belong on different query keys:

https://example.com/px?id=1
  &gdpr=1
  &gdpr_consent=CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA
  &gpp=DBACNYA~CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA~1YNN
  &gpp_sid=2

Copying gdpr_consent into gpp because both are long base64 strings is the usual post-migration bug. It reads thorough in a ticket screenshot. On the wire it tells the GPP decoder it received a TC String in the wrong slot.

The GPP docs on pixellint.org walk through header type 3, version 1, and what happens when a TC String lands in gpp. The TCF v2 page covers the mirror mistake: gdpr_consent=1 passes a character check and is not consent because the version bits do not read 2.

What gpp_sid is for

gpp_sid carries the section ID or IDs in force for this transaction. Normally one integer, at most two comma-separated. It is not a table of contents for every section encoded in the string.

The GPP spec does not require gpp_sid to match every section inside gpp. A string can encode more sections than the callee applies on this hop. gpp_sid says which section applies now.

During a US Privacy cutover you may still send deprecated us_privacy alongside GPP. That is two generations of US signal, not a duplicate of the same key. Duplicate consent parameters on one URL (two gpp keys, or gpp plus a second copy of the same TC String in gdpr_consent with conflicting bits) are a different failure mode than putting one string in the wrong parameter.

IAB deprecated the standalone US Privacy string on 31 January 2024 in favor of GPP. Keeping us_privacy=1YNN while you roll out GPP is a documented migration path. Dropping it before every partner reads gpp_sid looks like you went silent in California.

How you catch it

Character-set checks will not save you. Both TC Strings and GPP strings are URL-safe base64. You need to decode the header bits.

I maintain Pixellint, an open source linter for pixels and conversion API payloads. The core privacy pack decodes those first six bits on gpp and gdpr_consent. On a TC String pasted into gpp, it prints:

$ pixellint validate url 'https://example.com/px?id=1&gpp=CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA&gpp_sid=2'
rulepack: core
  error   core.privacy.gpp_header_type
          `gpp` is `CPXxRfAPXxRfAAfKABENB-CgAAAAAAAAAAYgAAAAAAAA`,
          whose header decodes to type 2. The GPP spec fixes the header type
          to 3, so this is not a GPP string.
    fix:  Send the GPP string from the CMP. A TC String belongs in
          `gdpr_consent`, not here.

Paste the fired pixel URL into the browser validator if you do not want a local install. Nothing you paste leaves the browser.

Fix the CMP-to-ad-server mapping, not the alphabet. The TC String is fine. It belongs in gdpr_consent. The GPP string from the same CMP belongs in gpp with a matching gpp_sid.

Unexpanded macros are a separate class. A URL that still holds ${GPP} never sent GPP. Empty gpp= is an unfilled template slot. Core privacy rules skip those so a creative is not scored as a malformed string before serve. After the impression fires, the live request needs a decoded header type 3 and a populated sid. Consent on the wire is the request the vendor sees, not the banner state in the page.

OpenRTB uses the same strings

OpenRTB 2.6 added regs.gpp and regs.gpp_sid alongside the older regs.us_privacy and user.consent fields. The encoding rules do not change because the container is JSON. A TC String in regs.gpp fails the same header-type check. A placeholder in user.consent fails the same version-bit check as gdpr_consent=1 on a pixel.

Programmatic and pixel teams often fix one path and leave the other. Bid requests and impression trackers should carry the same consent contract, on the keys each spec names.

Where to go next

Consent and privacy overview maps TCF, GPP, US Privacy, and vendor-specific dialects.
GPP header type is 3 covers gpp_sid shape, migration macros, and why sid does not have to list every section in the string.
TCF v2 consent strings on pixels covers gdpr=0 vs gdpr=1, truncation, and sunset v1 strings.
Core rulepack reference lists every core.privacy.* finding with spec citations.

The short version: GPP header type is 3. TC String version is 2. Same CMP, two parameters, two encodings. A perfect TC String in gpp is still wrong.

Pixellint is independent of IAB Tech Lab. The rule ids above cite the GPP and TCF specs because that is where the bit layouts live, not because this is an official IAB tool.

plcmt=5 in the VAST Tag Does Not Make a Linear MP4 a Pause Ad

Aleksander Sekowski — Tue, 01 Sep 2026 00:32:28 +0000

A CTV buyer wins a pause placement. The bid request carried video.plcmt=5. The VAST response comes back schema-valid, passes the trafficker's eyeball check, and the campaign goes live.

The viewer hits pause. A thirty-second preroll starts in the content frame.

Nothing in the trafficking UI threw an error because nothing in the XML was malformed. The bug is a contract mismatch: the tag declared a pause buy and shipped an instream linear creative.

Two layers that do not auto-align

IAB's CTV Ad Portfolio finalised in July 2026 with a design goal the guidance states plainly: no one should accidentally purchase a pause ad. Buyers opt in through AdCOM's Plcmt Subtypes (Video) list. Values 5 through 9 map to Pause, Screensaver, Overlay, Squeezeback, and In-Scene.

Five of those six formats deliver through VAST <NonLinearAds>. Menu ads go through OpenRTB Native and never touch VAST NonLinear.

The plcmt integer travels in the bid request. Downstream of the auction, the VAST tag often outlives the bid object. SSAI stitchers and measurement vendors may never see the original OpenRTB payload. So the DSP echoes the format context back into the creative as AdCOM signals inside <Extension> elements.

On VAST 4.x that looks like one signal per extension:

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

On VAST 2.0, the same five formats can ship through a single back-port container:

<Extension type="ctv_ad_portfolio">
  <CreativeId>creative-pause-001</CreativeId>
  <plcmt>5</plcmt>
  <playbackmethod>9</playbackmethod>
  <MediaFiles>
    <MediaFile delivery="progressive" type="image/jpeg" width="1920" height="1080">
      <![CDATA[https://cdn.example.com/pause.jpg]]>
    </MediaFile>
  </MediaFiles>
</Extension>

That extension block is not decorative metadata. On 2.0 it is how the portfolio carries the media delivery model the base schema never had. On 4.x the <NonLinear> node itself can hold <MediaFiles>, but the AdCOM echo still has to match what actually renders.

Here is the failure I keep seeing: the extensions declare plcmt=5, and the only <Creative> in the ad is <Linear> with a preroll MP4.

<Creative id="creative-001">
  <Linear>
    <Duration>00:00:30</Duration>
    <MediaFiles>
      <MediaFile type="video/mp4" delivery="progressive">
        <![CDATA[https://cdn.example.com/preroll.mp4]]>
      </MediaFile>
    </MediaFiles>
  </Linear>
</Creative>

Schema validators that only check element order and types will accept this. The plcmt value itself is legal anywhere from 1 to 9. Rule VAST-4.4-adcom-plcmt-value only fires when the integer is outside that range, not when it disagrees with the creative subtree.

The player does not read plcmt. It reads <Linear> versus <NonLinearAds>. A linear MP4 in a pause slot either plays as instream video over frozen content or gets dropped when the app expects a static overlay. Either way the buy and the delivery diverged silently.

What each field actually commits you to

plcmt answers which portfolio format was transacted. Value 5 is Pause. Value 7 is Overlay. Value 8 is Squeezeback. This is an OpenRTB / AdCOM contract surfaced in VAST so downstream hops can see it.

<NonLinearAds> answers how the player should render the asset: static image, timed video under NonLinear, SIMID interactive layer, squeezeback geometry. VAST 4.4 expanded NonLinear to accept <MediaFiles> the way Linear always has, which is why a pause ad can now be a fifteen-second MP4 instead of only a JPEG. The 4.3 to 4.4 migration notes walk that content-model change field by field.

playbackmethod adds pause-specific semantics on top of plcmt: value 8 is pause with sound on, 9 is pause with sound off. Overlay and squeezeback reuse the older instream playbackmethod values. Mixing pause plcmt with instream playbackmethod is another silent mismatch buyers filter on even when the XML validates.

attr (Creative Attributes 21, 22, 23) separates static, cinemagraph, and full-motion delivery. A publisher blocking full-motion pause inventory sets battr accordingly. Shipping attr=23 on a static JPEG pause creative mislabels motion expectations the other way.

On VAST 2.0 with multiple <Creative> elements, each <Extension type="ctv_ad_portfolio"> needs a <CreativeId> that matches a real creative id. Without it, the extension binds to whichever creative the platform picks. Rule VAST-2.0-ctv-portfolio-creative-id-required catches the two-creative, no-id case. Rule VAST-2.0-ctv-portfolio-mediafiles-required catches an extension that declares plcmt but carries no <MediaFiles> and no native NonLinear resource to render.

None of those rules replace the structural check: does this tag actually contain a NonLinear creative for a NonLinear buy?

How I catch it before the player does

I start with the live tag URL in the VAST tag tester. Paste the ad server's response URL or the XML itself. The tester fetches wrappers, shows which creative type loaded, surfaces tracking URLs, and previews the media file the player would pick. On a pause buy I expect NonLinear preview behavior, not a linear progress bar counting to thirty seconds.

If the tag is wrapped, I run the same URL through the VAST inspector. Portfolio tags often chain through a DSP wrapper before the InLine with the actual creative. The inspector walks each hop and shows where Linear handoff happens versus where the wrapper still carries only AdCOM extensions with no renderable NonLinear node.

After that I run vastlint check in CI on the resolved InLine. The AdCOM signal rules confirm integers are in range. The 2.0 portfolio rules confirm extension binding and media presence. I still grep the XML for <Linear> under a creative that should be portfolio inventory.

Where the spec splits 2.0 and 4.x

You do not need version="4.4" to use portfolio NonLinear content. IAB's own examples ship on version="4.2" with the expanded NonLinear model. The CTV Ad Portfolio overview maps each format to its OpenRTB object and VAST response shape.

Legacy stacks that only parse VAST 2.0 rely on the ctv_ad_portfolio extension path: AdCOM signals, MediaFiles, and Duration live inside <Extension type="ctv_ad_portfolio"> while the creative may still expose a minimal NonLinear StaticResource for players that ignore extensions.

The signaling versus validation split matters here: the July 2026 signaling guidance is final; vast_4.4.xsd is still draft. Value-level checks from the final guidance apply regardless of version declaration. Structural checks on the NonLinear content model apply on any 4.x document using those nodes. Read the VAST 4.4 draft index when you need the rule ids tied to each element.

The short version

plcmt=5 in an extension records that the buy was a pause placement. It does not convert a Linear preroll into a pause ad. The creative has to live under <NonLinearAds> (or the 2.0 extension has to carry renderable <MediaFiles> bound to the right <CreativeId>).

Validate the signal integers. Then validate the shape. The tester shows what renders; the inspector shows where the wrapper hid the InLine; the linter catches binding and range defects the player never reports.

I maintain vastlint independently of IAB Tech Lab. The rule ids above come from the published CTV Ad Portfolio guidance and the VAST 4.4 draft schema notes in the repo, not from a vendor QA checklist.

MCP validate_bid_request Defaults to profile spec. Google AB Needs at: 3 and billing_id.

Aleksander Sekowski — Mon, 31 Aug 2026 00:17:50 +0000

A coding agent wiring Google Authorized Buyers integration calls validate_bid_request on the RTBlint MCP server. The tool returns "valid": true. The payload still fails on Google's side.

The request is not malformed OpenRTB. It is the wrong contract for the exchange you are targeting:

{
  "id": "req-1",
  "at": 3,
  "imp": [{
    "id": "1",
    "banner": { "w": 300, "h": 250 }
  }]
}

at: 3 is FIXED_PRICE in Google's Authorized Buyers OpenRTB guide. The IAB spec's auction type value set is {1, 2} plus vendor values from 500 upward. Three sits in the gap. Without Google's profile declared, a linter correctly flags it as illegal.

The imp is also missing ext.billing_id. Google documents that array as required: the billing IDs a winning bid may attribute the impression to. The specification treats it as an optional extension. A spec-only validator has nothing to complain about.

profile is not dialect

MCP exposes both knobs on validate_bid_request and validate_bid_response:

dialect: spec-json (integer flags like secure: 1) vs proto-json (boolean flags for gRPC protobuf JSON).
profile: spec (default), google-ab, prebid-server, xandr, or magnite.

Dialect is encoding. Profile is the extra protocol an exchange publishes on top of the same JSON shape. Google Authorized Buyers still uses integer flags. It still needs profile=google-ab because the auction type table and required extensions differ.

An agent that learned OpenRTB from spec PDFs and training snapshots will produce at: 1 or at: 2 and skip billing_id. An agent that learned from Google's docs will emit at: 3 and expect billing fields. Point both at MCP with defaults and only the second payload looks broken, even though only the first is deliverable to Google without fixes.

What the default tool call actually checks

I maintain RTBlint, an open source OpenRTB linter. The hosted MCP server wraps the same core as the CLI and the browser tester.

Against the default profile:

$ rtblint validate bid.json
FAILED (OpenRTB 2.6-202606 bid request): 1 error(s), 0 warning(s).
- [error] at: at is 3, which is not among the allowed values {1, 2}.
  (openrtb.value.invalid) · spec 3.2.1

No mention of billing_id, because the spec does not require it.

Pass the profile Google documents:

$ rtblint validate --profile google-ab bid-with-at3.json
FAILED (OpenRTB 2.6-202606 bid request): 1 error(s), 0 warning(s).
- [error] imp[0].ext.billing_id: Google Authorized Buyers requires
  imp.ext.billing_id. (openrtb.profile.field_required) · profile google-ab

$ rtblint validate --profile google-ab google-ready.json
OK (OpenRTB 2.6-202606 bid request): no issues found.

Same JSON. Three different verdicts depending on whether you declared the exchange protocol.

Over MCP the shape is identical. The agent passes profile in the tool arguments:

{
  "payload": "{ ... }",
  "profile": "google-ab"
}

The OpenRTB MCP validator docs and the full MCP tool reference list every argument. The server card at /.well-known/mcp/server-card.json enumerates the profile enum for clients that auto-wire tools.

Why this shows up on agent loops

Registering an MCP server is not validating against the exchange that will receive the traffic. get_adcp_capabilities tells an AdCP pipeline that RTBlint computes openrtb_error_count and related metrics. It does not pin google-ab, prebid-server, or any other profile. Discovery answers what the tool can do, not which protocol variant your deployment targets.

That gap matters in agentic buying stacks where the same MCP host validates bid requests coming out of an AdCP media buy. The AdCP to OpenRTB mapping guide is where field-level translation lives. Profile selection is the step after mapping: once the object looks like OpenRTB, you still have to name the exchange extras.

Prebid Server is the same class of bug under a different profile. Each imp must name a bidder or stored request, and several Prebid-only extensions become required. Xandr expects ext.appnexus.seller_member_id. Magnite expects ext.rp identity fields. Default profile=spec validates none of that.

How I wire it in practice

For a human review pass, paste request and response into the tester with the profile dropdown set to Google AB. The UI surfaces the same rule ids as MCP.

For CI or a local agent loop:

$ cargo install rtblint
$ rtblint validate --profile google-ab --type request req.json

The CLI docs cover batch mode, version pinning, and dialect flags. The OpenRTB overview ties profiles, dialects, and dated spec snapshots together.

If payloads must not leave the network, run rtblint-mcp over stdio with the same tool names. The hosted endpoint may store stripped samples under its privacy policy; local stdio does not.

The short version

validate_bid_request without profile checks the IAB specification, not Google Authorized Buyers, not Prebid Server, not Xandr, not Magnite.

For Google AB, pass profile=google-ab before you trust valid: true. FIXED_PRICE (at: 3) becomes legal. Missing Imp.ext.billing_id becomes an error instead of silence.

An MCP tool registration proves the agent can call a validator. It does not prove the validator ran against the exchange that will answer the auction.

RTBlint is independent of Google and IAB Tech Lab. The rule ids above cite the public spec and Google's OpenRTB guide because that is where the requirements live.

Reddit CAPI v3 Wants Milliseconds. Meta's Seconds Helper Lands in 1970.

Aleksander Sekowski — Sun, 30 Aug 2026 18:13:06 +0000

A purchase handler posts to Reddit's Conversions API. The request returns 200. Reddit Ads stays empty, or the conversion sits in 1970.

The access token is fine. The Pixel ID in the path is fine. The payload is the Meta helper with the host changed.

{
  "data": {
    "events": [
      {
        "event_at": 1770000000,
        "action_source": "website",
        "type": { "tracking_type": "PURCHASE" },
        "user": { "email": "buyer@example.com" }
      }
    ]
  }
}

That JSON is legal. It is also the wrong clock and the wrong action_source enum.

event_at is milliseconds, not Meta seconds

Reddit CAPI v3 documents event_at as Unix time in milliseconds. Thirteen digits. Date.now() is already that unit.

Meta's Conversions API wants the inverse. event_time is seconds, ten digits, at most seven days old. The Meta fix is Math.floor(Date.now() / 1000). Copy that line into a Reddit worker and 1770000000 is January 1970 as milliseconds.

Reddit will still accept the POST. A 1970 conversion is older than any attribution window you care about. The status line does not mention the unit.

v2 used an ISO event_at. v3 does not. A string timestamp that used to work is a type error on the new envelope. Do not mix the two.

// Wrong on Reddit CAPI v3 (right on Meta)
event_at: Math.floor(Date.now() / 1000)

// Right on Reddit CAPI v3 (wrong on Meta)
event_at: Date.now()

LinkedIn's conversionHappenedAt is also thirteen digits. Pinterest's event_time is ten, like Meta. There is no shared helper that is correct for all four without a branch.

action_source is WEBSITE, not website

v3 makes action_source required. Reddit documents WEBSITE, APP, PHYSICAL_STORE, and OTHER. Meta writes website. Pinterest writes web. Snap writes WEB.

"action_source": "website"

That is Meta's spelling. On Reddit it is not in the enum. A shared action_source column without a per-vendor map is a silent invalid on at least one hop.

type.tracking_type is the event name, in UPPER_SNAKE_CASE: PAGE_VISIT, VIEW_CONTENT, SEARCH, ADD_TO_CART, ADD_TO_WISHLIST, PURCHASE, LEAD, SIGN_UP, or CUSTOM plus custom_event_name. Meta's Purchase and Pinterest's checkout are different strings. Purchase copied into tracking_type is a custom name here, not a purchase, unless you also send CUSTOM.

The pixel on alb.reddit.com/rp.gif is a different pipe. id is the advertiser ID. event is a name like PageVisit or Purchase. That image GET is not the CAPI JSON. Dedup between them is weaker than Meta's event_id pair. Mint a stable id for retries of the same Reddit CAPI event so a 500 does not become two PURCHASE rows. Replays keep the original event_at.

Hash email if you want. Do not hash the IP.

Reddit CAPI v3 allows email and phone raw or hashed. That is not permission to send a raw address to Meta, Pinterest, or TikTok. Convert at the edge.

user.ip_address and user.user_agent stay in the clear. A SHA-256 looking digest in those fields is an unmatchable event. The "hash everything in user_*" helper that made Meta's em valid is how Reddit matching dies.

"user": {
  "email": "buyer@example.com",
  "ip_address": "17af1cf3d1b5332c53349fc789abdc853bbeea7ed33eff727ff794ab741ccac9",
  "user_agent": "Mozilla/5.0"
}

metadata.currency, when present, is an ISO 4217 code (USD), not $.

The path is /api/v3/pixels/{pixel_id}/conversion_events on ads-api.reddit.com. The Pixel ID lives in the path, not in a JSON field named pixel_id next to Meta's Graph token. Pointing a Meta client at that host with a data[] of event_name / event_time objects is a different miss from the clock bug. The envelopes do not overlap.

How you catch it before Ads Manager is empty

I maintain Pixellint, an open source linter for pixels and conversion API payloads. The Reddit CAPI pack (vendor/reddit-conversions-api) contracts data.events[] against Reddit's v3 parameter docs. This is what it prints on the seconds-and-website payload above:

$ pixellint validate json @reddit-capi.json
rulepack: vendor/reddit-conversions-api (vendor: reddit)
  error   vendor.reddit-conversions-api.body.event_at.invalid
          `event_at` must be at least 13 digits, but `1770000000` has 10.
          Reddit CAPI v3 documents `event_at` as Unix time in milliseconds.
          A 10-digit value is seconds and lands in 1970.
    fix:  Send milliseconds: a JavaScript `Date.now()` is already in the
          right unit.
  error   vendor.reddit-conversions-api.body.action_source.invalid
          `action_source` is `website`, which is not one of the documented
          values: WEBSITE, APP, PHYSICAL_STORE, OTHER.
    fix:  Send `WEBSITE`, `APP`, `PHYSICAL_STORE`, or `OTHER`.

A hashed IP prints vendor.reddit-conversions-api.body.hashed_plaintext_field. A Reddit Pixel URL with no advertiser id prints vendor.reddit.param.id.missing on vendor/reddit, which is a different pack.

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

Paste the body into the playground if you do not want a local install. Artifacts you test may be stored; see privacy.

The Reddit CAPI playbook is how both pipes share a clock and an event name. The Reddit CAPI pack page is the field table. The Reddit Pixel pack is the image GET.

Where to go next

A conversion API is a POST the browser never made. What is a conversion API is the envelope, the clock, and the match keys across vendors. One conversion API JSON cannot serve every vendor is the adapter argument: store one UTC instant, convert at the edge.

Event time units maps Meta seconds, Reddit and LinkedIn milliseconds, GA4 microseconds, and TikTok ISO 8601 so you are not guessing from one vendor's sample. Pinterest is seconds again, with lowercase web and lowercase standard events (checkout, not Checkout); that contrast lives in the Pinterest standard events playbook.

The short version

Reddit CAPI v3 event_at is Date.now() in milliseconds, not Meta's seconds. action_source is WEBSITE. tracking_type is PURCHASE, not Purchase. Email may be raw or hashed. IP and user-agent must not be digests. The Pixel ID is in the path. Do not POST Graph-shaped JSON to ads-api.reddit.com.

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

A Companion With No Width Is Not a 300x250. The Player Cannot Match It.

Aleksander Sekowski — Sat, 29 Aug 2026 19:00:33 +0000

A publisher page exposes a 300x250 slot. The VAST player walks <Companion> elements and keeps the first whose width and height match that slot. A Companion with a JPEG and no dimensions is not a 300x250. It is a banner the player cannot name.

Trafficking often pastes <StaticResource> and skips the attributes. The video plays. The slot stays empty. If CompanionAds is required="all", some players also drop the linear.

That is not a CDN miss. The image URL can 200. The match never ran.

Width and height are how the slot matches

VAST requires width and height on every <Companion>. The spec does not default them from the image file. The player is not required to HEAD the JPEG to learn 300 by 250. If the attributes are missing, the match set is empty.

IAB display still clusters on a small set of sizes. 300x250 is the default mid-page rectangle. 728x90 is the desktop leaderboard. 160x600 is the wide skyscraper. 320x50 is the mobile banner. One size is not enough if you traffic both desktop and mobile.

A copyable block that a player can actually match:

<CompanionAds required="none">
  <Companion width="300" height="250">
    <StaticResource creativeType="image/jpeg">
      <![CDATA[https://cdn.example.com/300x250.jpg]]>
    </StaticResource>
  </Companion>
  <Companion width="728" height="90">
    <StaticResource creativeType="image/jpeg">
      <![CDATA[https://cdn.example.com/728x90.jpg]]>
    </StaticResource>
  </Companion>
</CompanionAds>

The broken form looks present in a text editor:

<CompanionAds required="all">
  <Companion>
    <StaticResource creativeType="image/jpeg">
      <![CDATA[https://cdn.example.com/banner.jpg]]>
    </StaticResource>
  </Companion>
</CompanionAds>

There is a resource. There is no size. There is no slot.

I maintain vastlint, an open source VAST linter. On that second snippet it reports VAST-2.0-companion-dimensions. Severity is warning, because the XSD leaves the attributes optional while the prose requires them. The player still has nothing to match.

$ vastlint check companion.xml
companion.xml  VAST 4.2
  warning  Companion is missing width or height. Required by spec, optional in XSD.
           VAST-2.0-companion-dimensions

--fail-on-warning is how you make that a launch gate.

The size list, and why one rendition is not enough, is on VAST companion sizes. The XML checklist is How to Validate Companion Ads.

required=all is a kill switch for the linear

required on <CompanionAds> is all, any, or none.

none keeps the video if the banner misses. any wants at least one companion to render. all means every companion in the block has to be usable, and a miss can take down the break.

An empty Companion plus required="all" is how a missing banner becomes a missing ad. That is the failure mode on companion ads not showing.

Most CTV runtimes ignore companions. Do not set required="all" for a CTV-only tag unless the platform documents companion support.

Wrappers can drop the banner you QA'd

CompanionAds on the inline you pasted is not proof the player received it. A wrapper hop can omit companions. followCompanions on a Wrapper is the flag that says whether to keep them. If the live chain drops the block, the page slot stays blank and your fixture still looks fine. QA the document at the bottom of the chain, not the first URL in the ticket.

Paste checks the document you have. A live tag URL still has to unwrap. Use the VAST tester for the fetch and preview. Use the inspector when the player printed 303 or the banner vanished after a hop.

The OpenRTB side can be clean the whole time. imp.video and bid.adm can pass a bid-stream linter while the VAST inside is a wrapper that returns no ads, or a companion with no width. That split is A spec-valid video bid can still fill with empty VAST.

CompanionClickThrough is a click tracker

The banner has its own click URL. It should 302 until the landing page. It should not be the Impression pixel with a different cache buster. If you are debugging the collector rather than the XML, impression pixels vs click trackers is the slot contract.

What to run

Paste resolved XML. Catch missing width/height and empty Companion before you blame the page.
Fetch the live URL in the tester. Confirm the companions that survived the chain.
If a hop ate them, walk the chain in the inspector.
Ship more than one IAB size. Then look at the page slot. Size mismatch after valid XML is trafficking, not schema.

LIFECYCLE_DSP_BID_RESPONSE Can Ship Without bid_response. The Agent Has Nothing to Shade.

Aleksander Sekowski — Fri, 28 Aug 2026 23:21:15 +0000

A DSP-side ARTF host sets lifecycle to LIFECYCLE_DSP_BID_RESPONSE, keeps the publisher bid_request on the envelope, and omits bid_response. The gRPC call completes. The agent returns BID_SHADE on /seatbid/dsp-1/bid/bid-abc. The orchestrator has no bid with that id in the payload it actually received.

That is not a shading bug in the agent. It is an envelope that names a stage without attaching the document that stage requires.

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, the OpenRTB object under mutation, and applicable_intents: the vocabulary the orchestrator is willing to evaluate. The agent answers with Mutation messages. Each mutation has an intent, an operation, a semantic path, and a typed payload.

BID_SHADE is a response-stage intent. It adjusts bid.price on a specific seat and bid id. The path grammar is explicit: /seatbid/{seat}/bid/{bid id}. There is no impression index to fall back on. If bid_response is missing, every shading path is a guess.

lifecycle is a label on the call, not proof of contents

ARTF defines lifecycle stages such as LIFECYCLE_PUBLISHER_BID_REQUEST and LIFECYCLE_DSP_BID_RESPONSE. The name tells the agent which intents are meaningful on this hop. It does not inject the matching OpenRTB member.

A response-stage call still has to carry bid_response when the agent is expected to read prices and ids from it. RTBlint reports the mismatch as artf.lifecycle.payload_mismatch:

{
  "id": "ep-1",
  "tmax": 120,
  "lifecycle": "LIFECYCLE_DSP_BID_RESPONSE",
  "bid_request": { "id": "a-1" }
}

The envelope declares the DSP bid response stage and carries no bid_response member. Intents that belong to that stage, BID_SHADE above all, address a bid by seat and bid id. The agent is being asked to reason about an answer it was never shown.

The symmetric failure at the publisher stage is sending BID_SHADE when only bid_request is present and no bid exists yet. That combination triggers artf.mutation.intent_not_applicable together with a missing target payload. Shading before any bid is made is not a floor tweak; it is the wrong lifecycle for the intent.

applicable_intents is the other half of the contract

The orchestrator also publishes applicable_intents: which mutation types it will even consider on this extension point.

Without that list, the agent invents work the host may reject. RTBlint flags artf.intents.missing when the field is absent entirely.

When the field is present but not a JSON array, protojson refuses it. A single intent written as a bare string looks natural in hand-authored JSON and fails on the wire:

{
  "applicable_intents": "ACTIVATE_DEALS"
}

Protobuf repeated fields serialize as arrays. The fix is ["ACTIVATE_DEALS"], even for one intent. That encoding error is artf.intents.not_array.

If the agent returns an intent outside the declared list, the mutation is dead on arrival: artf.mutation.intent_not_applicable. That is expensive inside a 120 ms tmax window.

When bid_response is present but the path still misses

Hosts that do attach bid_response can still lose shading if the path names a seat or bid id that is not in that document. BID_SHADE does not address bids by array offset. A typo in the seat name is not recoverable by scanning nearby objects.

RTBlint reports that as artf.mutation.bid_unknown. The mutation looks structurally fine. The price never changes because the target bid was never there.

How you catch it before the auction forwards nonsense

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

$ rtblint validate --type artf-request rtb-request.json
FAILED (OpenRTB 2.6-202606 ARTF request envelope): 1 error(s), 0 warning(s).
- [error] lifecycle: envelope declares LIFECYCLE_DSP_BID_RESPONSE
  but carries no bid_response. (artf.lifecycle.payload_mismatch)

$ rtblint validate --type artf-response --request rtb-request.json rtb-response.json

Pass two pairs each mutation against the request's applicable_intents and against semantic paths in the payloads actually carried. Pass three applies accepted mutations and revalidates OpenRTB so you see field-level damage (wrong metric type, deal id the exchange does not list) rather than blaming the original emit.

The same rules run in the ARTF simulator, the browser tester, MCP tools, and gRPC on openadtech.rtblint.v1. ARTF already mandates gRPC for the extension point; validating on that channel beats shelling out after the fact.

Where to read the rest of the surface

The eight intents and what each one touches on OpenRTB are laid out in ARTF mutations and bid request validation. That post is the map for checkpoint validation after every mutating stage, not only at the SSP edge.

For field-by-field context on the envelope itself, ARTF explained walks the request and response members without assuming you have read the PDF first.

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, intents, and paths are contracts you can violate while the RPC still returns OK.

AAMP Can Finish a Video Buy With a Wrapper. It Cannot Prove the InLine Exists.

Aleksander Sekowski — Thu, 27 Aug 2026 23:20:11 +0000

An AAMP buyer agent completes a programmatic video buy and returns a VAST tag URL. The task status is success. The deal is in the Deals Library. Nobody has followed the URL.

Two weeks later fill is at forty percent and the report says "no ad response." The tag the agent negotiated is a <Wrapper> pointing at another host. That second hop is another wrapper. The third hop times out on CTV. Google IMA stops at four hops. The slot goes empty. Nothing in the agent transcript says anything failed, because nothing in the agent layer required anyone to resolve the chain.

IAB Tech Lab's Agentic Advertising Management Protocols (AAMP) is explicit about keeping VAST as the video envelope. OpenRTB stays the auction rail. AdCOM stays the object model. The agent negotiates above or beside those layers, and what ships to the player is still XML. That design is coherent. It also means the last mile is identical to the last mile you already had: a URL that may be a redirect graph, not a creative.

What "delivery" means in an agentic buy

AAMP 2.0 brought programmatic into scope with buyer and seller agent SDKs that can transact over MCP. AAMP 2.3 added operational gates: diligence checks, server-side trust verification on price-moving paths, deployment targets on Bedrock and Databricks. Those are real controls on money and authorization.

None of them fetch VAST.

Read the IAB agentic advertising standards guide next to the agentic buying and OpenRTB primer and the split is obvious. ARTF agents may rewrite bid requests mid-auction. AdCP-style negotiation may produce a deal ID that shows up in imp.pmp.deals. Either way, when the format is video, execution still collapses to a tag endpoint.

That endpoint can legally be hop one of a wrapper chain. VAST 2.0 through 4.x all allow a <Wrapper> with a <VASTAdTagURI> instead of an <InLine>. SSPs, DSPs, and measurement vendors stack wrappers because each hop carries its own impression and error beacons. The pattern is normal. Treating the first URL as proof of delivery is not.

A wrapper-only response validates against schema. It can return HTTP 200 with well-formed XML and still never reach media. The player needs an <InLine> with a <MediaFile> somewhere downstream, within a depth budget that varies by platform (four hops on IMA and most CTV stacks). An agent that stops at the negotiated URI has verified negotiation, not playback.

The failure modes wrappers hide

These are the ones I see after an agent handoff, not the ones a JSON Schema catches.

Depth exceeded. Four wrappers before the inline is common in open market paths. A fifth hop fails silently on CTV. The outer wrapper often has no <Error> URL, so reporting shows underdelivery with no VAST error code.

Circular or dead URIs. A misconfigured ad server points <VASTAdTagURI> back to itself or to a 404 that returns HTML with a 200 status. The agent never requested the body. The wrapper chains guide lists platform limits and the checklist; circular chains are almost always configuration, and they are invisible until something walks the graph.

followAdditionalWrappers="false" mid-chain. A wrapper that sets this attribute tells the player to stop even if the next response is another wrapper. The chain aborts at that hop. Schema-valid, unplayable.

Wrong host on the inline. The wrapper you tested is not the creative that plays. The InLine lives on a different CDN with a different duration and a different tracking set. That is a separate bug, but wrapper-first QA makes it worse because you never saw the terminal document.

Version drift across hops. Hop one declares VAST 4.2. Hop three uses 3.0 elements. Players pick rules per document. An agent that recorded "4.2" in a deal artifact did not open either file.

AdCP's creative protocol has the same blind spot at the asset layer: a manifest can declare a VAST URL and optional metadata without parsing the tag. AdCP can declare a VAST tag; it cannot check one. AAMP and AdCP disagree about where agents sit, but they agree that VAST stays the envelope. Neither specification resolves wrappers for you.

How to catch it before the flight

Split the job the way players split it.

Step one: the live tag URL in the VAST tag tester. Paste the URI the agent returned, not a saved XML snippet from an earlier debug session. The tester fetches what the endpoint serves now, previews the creative when it can, and surfaces tracking and click URLs on the response it actually got. If hop one is a wrapper, you see wrapper structure immediately.

Step two: the same URL in the VAST inspector. The inspector resolves hop by hop. It reports chain depth, where each <VASTAdTagURI> points, and whether the chain terminates in an <InLine>. That is the check the agent task skipped. If depth is four and your target platform is Roku or Fire TV, you already know you are at the limit before the first impression.

Step three: validate the terminal XML. Once the inspector shows the inline, run structural rules on that document: Duration in HH:MM:SS, required Impression, HTTPS media files, declared version against elements used. CLI or MCP if the agent pipeline needs automation; the tester and inspector are the human and agent-facing entry points.

Wire this into the agent loop the same way you would wire OpenRTB validation after an ARTF mutation. The version negotiation gap on OpenRTB is a parallel problem: the handshake succeeds while the payload downstream is wrong for the receiver. Here the receiver is the player, and the payload is three redirects away.

Where the check belongs

If you host a buyer agent, treat "tag URI received" as an intermediate state, not COMPLETE. Resolve the chain (or call a tool that does) before writing the deal to your system of record.

If you sit on the sell side, reject or flag creatives whose entry URL does not terminate in an inline within your platform's depth budget. The cost of a retry in the agent protocol is lower than the cost of a week of silent no-fill.

If you are comparing stacks, the AAMP, AdCP, and OpenRTB landscape write-up is useful context, but the invariant is stack-agnostic: agents changed who negotiates; VAST still defines what renders.

AAMP's trust work on price-moving paths is worth having. It does not replace proving the creative exists. The tag URL is an address, not an ad. Follow it.

One CAPI JSON cannot serve every vendor

Aleksander Sekowski — Wed, 26 Aug 2026 04:56:26 +0000

The first CAPI integration is usually Meta. The second is a copy with the host changed. That is how LinkedIn returns 422, TikTok stamps arrival time, and Pinterest drops the event for a missing event_id.

The clock is the tell

Meta CAPI event_time is Unix seconds, 10 digits. LinkedIn conversionHappenedAt is milliseconds, 13 digits. A seconds value on LinkedIn reads as 1970 and falls outside the 90-day window. TikTok Events API timestamp is ISO 8601. An epoch number there is treated as arrival time. Pinterest CAPI event_time is seconds again.

Date.now() is right for LinkedIn and wrong for Meta. Math.floor(Date.now()/1000) is right for Meta and wrong for LinkedIn. toISOString() is right for TikTok and a type error on Meta.

Required fields do not translate

LinkedIn requires user.userIds even when you match on userInfo or lead. The field is often an empty array. Omit it and the API returns 422. Meta does not have that field.

Pinterest CAPI requires event_id. Meta treats event_id as how you dedup against the pixel; people ship Meta without it and still see purchases. The same omission on Pinterest is invalid.

{
  "event_name": "Purchase",
  "event_time": 1770000000,
  "user_data": { "em": ["64ec88ca..."] }
}

HTTP 200 is still not the contract

Validate the outbound body, not the warehouse row:

pixellint validate json @meta.json --rulepack vendor/meta-conversions-api
pixellint validate json @li.json --rulepack vendor/linkedin-conversions-api
pixellint validate json @tt.json --rulepack vendor/tiktok-events-api

A shared CAPI JSON is a bug, not a shortcut. Pixellint is not affiliated with Meta, LinkedIn, TikTok, or Pinterest. Playground.

Original: One CAPI JSON cannot serve every vendor