DEV Community: Aleksander Sekowski

RMT Explained: How IAB Redefining Media Types Classifies OpenRTB Impressions

Aleksander Sekowski — Sun, 11 Oct 2026 00:35:07 +0000

On September 16, 2026, IAB Tech Lab opened Programmatic Standard Practices v1 for public comment through October 16. The council's pitch is familiar and worth taking seriously: stop inventing new pipes and align on how existing standards are supposed to behave in live transactions. That same week, much of the industry was still digesting a different IAB Tech Lab thread, Redefining Media Types (RMT), which plans to encode impression-level viewing facts directly into OpenRTB bid requests. RMT is not a reporting PDF off to the side. It is a classification layer that reads the video object you already send.

If your job is video buying, selling, or SSP integration, RMT matters because it re-labels inventory using fields that validate as JSON today and still disagree downstream. The stake is not "did we parse the request." The stake is whether planning, curation, and finance tools will treat a lean-back CTV impression and a muted in-feed clip as comparable products because a derived bit said they were.

What RMT adds on top of OpenRTB

RMT classifies video advertising on two layers.

The macro layer sorts environments by how someone is actually watching: Lean Back Viewing, Personal Screen Viewing, and Passive and Communal Viewing. Those buckets exist because legacy labels like "CTV" or "online video" describe delivery pipes, not experience. A lean-back living room session and a vertical social feed are not the same product at the same price, even when both are "video."

The operational layer is eight binary attributes on a single impression: sound state, skip-enabled versus completion-required, full-screen presentation, addressability, signal availability, measurability, device class, and ad format. The RMT field mapping on RTBlint is explicit: seven of the eight already have homes in OpenRTB 2.6 and AdCOM. The standard's plan is to derive the eighth from combinations of those homes, not to introduce a parallel schema.

Scope is broad on purpose: connected TV, browser video, social video, FAST, video podcasting, retail video. Anything that shows up as imp.video in a bid request is in scope.

How classification is supposed to work on the wire

Think of RMT as a reducer over the bid request. You start with the same JSON your exchange already accepts. A classifier walks a fixed table and emits eight yes/no answers plus a macro bucket.

Sound state is the clearest example, and it is not the only one. OpenRTB lists video.playbackmethod as playback methods that may apply to the placement. Values 1 and 5 imply sound on at start; 2 and 6 imply sound off by default. RMT's sound attribute treats that field as a single factual claim about this impression. The OpenRTB video object guide separates playbackmethod from plcmt, linearity, and pod fields because RMT's format attribute reads those too.

Skip versus completion-required reduces video.skip, skipmin, and skipafter. OpenRTB only defines the offsets when skip is 1. Traffic that ships skipafter without declaring skippability is valid JSON with an undefined contract. Any skip bit RMT derives from that trio is guesswork dressed as measurement.

Ad format leans on video.plcmt, video.linearity, and mtype, plus the CTV Ad Portfolio extensions documented in the CTV signaling notes. Pause, overlay, and squeezeback formats only make sense when plcmt and related AdCOM enums match what the player can render.

Device uses device.devicetype and the app, site, or DOOH context to separate connected TV from phone from set-top box.

Addressability today is inferred from device.ifa, device.lmt, and user.eids. Measurability is proxied by video.api containing OMID (7) and by metric objects on the imp. RMT wants several of these inferences to become declared booleans. That moves failures from "we could not tell" to "you told us wrong," which is progress only if the underlying fields are populated honestly.

None of this requires a new endpoint. It requires agreement that playbackmethod: [1, 2] cannot mean both sound on and sound off for one impression, that plcmt is not a copy of deprecated placement, and that skip offsets without skip: 1 are not a skip contract.

Where the mapping breaks in production

We have run this movie before. In 2022 the IAB deprecated video.placement and introduced video.plcmt with tighter definitions. Three years later, as the plcmt migration retrospective documents, plenty of traffic still carries contradictory values in both fields, or neither field at all. OpenRTB does not reject wrong enums inside the allowed range. There is no error code for a semantic mismatch between the version string and the fields you populated.

RMT inherits that enforcement gap. If playbackmethod is empty on thirty percent of your video imps, a sound-state attribute built on it is empty on thirty percent the day RMT ships, and downstream reporting will still bucket those rows as if the taxonomy were complete.

Four attributes are especially fragile because the protocol only offers weak proxies today. Full-screen presentation leans on video.pos and width and height comparisons that CTV sellers often leave unset. Signal availability is inferred from regs.gpp, source.schain, and extensions rather than a dedicated bit. Measurability conflates player capability (video.api) with whether the impression was actually measured. RMT's design is thoughtful; the inputs are messy.

The placement versus plcmt guide is the practical cheat sheet for one column in the RMT table. Fix enum drift there before a second taxonomy lands on top.

How you catch it before the classifier does

An LLM or agent that "implements" RMT can emit labels from a bid request JSON and still be wrong on the wire. The RPC or batch job returns OK. The OpenRTB object underneath did not change. You need a deterministic check on the payload RMT reads, not on the narrative about it.

rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) validates the OpenRTB bid request: AdCOM enum ranges, skip dependencies such as openrtb.field.requires_skippable_video, dated-snapshot fields, and dialect mismatches between spec JSON and protobuf JSON. It is independent of IAB Tech Lab and of AAO; the spec does not require it, but it is the package that owns this object when you are wiring AdCP, ARTF, or AAMP agents that still close the hop as OpenRTB.

Paste a production request into the bid request tester for a one-off read. Gate the same rules in CI using the OpenRTB validation guide. After the bid clears, the win still renders as VAST: run the live tag through the VAST tag tester and trace wrapper hops with the VAST inspector. When plcmt signals CTV portfolio pause or overlay formats, validate the returned creative shape in the IAB-style VAST tester (independent fork, not an IAB Tech Lab product). Measure fill rate on the seven mapped fields (playbackmethod, skip trio, plcmt, devicetype, api, pos, ifa) before you trust an eighth derived attribute.

Where to go next

Start with the full mapping table in Redefining Media Types: eight claims and the bidstream fields they land on. Audit your video traffic against the OpenRTB enums reference so pause and CTV portfolio values match AdCOM 1.0-202607. If you operate supply-side video at scale, read the CTV capacity gap post for how another classification layer behaves when comment windows close and adapters have not caught up.

RMT is good work on a real problem: classify by viewing experience, not by pipe name. The risk is the ordinary one for programmatic: a precise taxonomy on imprecise inputs produces confident, precise, wrong reports. Validate the fields you already have while Programmatic Standard Practices asks the industry to use those standards consistently. The comment window on governance is open until October 16; the fix on your bid stream can start today.

adagents.json vs ads.txt and schain: Four Files, Two Supply-Chain Questions

Aleksander Sekowski — Sat, 10 Oct 2026 00:30:25 +0000

In early October 2026, IAB Tech Lab's programmatic supply-chain leadership pushed back on the idea that adagents.json should replace ads.txt, sellers.json, and the OpenRTB SupplyChain object. The argument, echoed in trade coverage of Hillary Slattery's rebuttal, is that the IAB files already answer who may sell inventory and how a bid request moved. AgenticAdvertising.org's answer is different: it names which sales agents a publisher authorized for agentic negotiation. Those are not the same question, and the auction payload still only embeds one of them.

If you are wiring AdCP, a Prebid Sales Agent, or a buyer-side agent that reads well-known JSON, you need both mental models on the desk. Picking one file and calling supply path "done" is how authorized agents and authorized sellers diverge without anyone getting an error.

adagents.json: who may represent the publisher to an agent

adagents.json lives at /.well-known/adagents.json. It is an AAO artifact tied to the Ad Context Protocol family. The document lists authorized_agents: agent URLs, property or placement scope, delegation type, optional exclusivity, and time bounds. The buyer agent is supposed to fetch this file before it treats an agent as allowed to sell a slice of inventory.

The unit of trust is the agent relationship, not the advertising system id on a schain node. A row can authorize https://sales-agent.example/ for one property id while saying nothing about the SSP seller account that will eventually emit OpenRTB. AdCP discovery tools can validate the JSON shape and pinned schema version; they do not, by themselves, prove that the live bid request was produced inside the scoped authorization.

Example inside the grammar: exclusive: true on an authorized agent row is meaningful in adagents.json. It does not delete a RESELLER line in ads.txt. Publishers can publish both files, get HTTP 200 on each, and still disagree about whether resale is allowed depending on which file the buyer's SPO product read last.

ads.txt, sellers.json, and schain: who may sell and who touched this impression

The IAB programmatic supply-chain stack predates agentic buying and still carries most programmatic traffic.

ads.txt (and app-ads.txt) is a publisher-hosted flat file. Each line binds a seller account id to an advertising system domain with DIRECT or RESELLER. OWNERDOMAIN and subdomain delegation extend that to property ownership. The question is authorization to sell inventory under that publisher id.

sellers.json sits on the SSP or exchange. It maps seller ids to company names, domains, and seller types so buyers can interpret ads.txt lines in context.

source.schain rides on the OpenRTB bid request. It is a per-impression chain of nodes (asi, sid, hp, and related fields) describing which systems took custody of this request. SupplyChain 1.1, in public comment through 2026, adds hp=0 nodes for entities that take technical custody without being payment-flow sellers. That is still schain semantics; it is not an adagents.json agent URL.

The three IAB artifacts cross-check in mature buyer workflows: crawl ads.txt, map ids through sellers.json, reconcile nodes on the wire against authorized sellers. A structural schain defect still fails even when authorization files look fine. For instance, complete: 1 with a chain that omits an expected hop triggers checks documented under openrtb.schain.incomplete. Under 1.1 expectations, an unexpected hp value on a node is a different class of bug, as in openrtb.schain.node.hp_unexpected.

Two stacks on one impression

Put the sides next to each other:

Question	adagents.json	ads.txt + sellers.json + schain
What is being authorized?	Agent URL and scope for agentic sales	Seller account and resell relationship
Where does it live?	Publisher well-known JSON	Publisher ads.txt, exchange sellers.json, bid request schain
What rides on OpenRTB?	Nothing normative today	`source.schain` (and related supply extensions)
Typical failure	Agent negotiated a buy outside publisher scope	Seller id or hop not authorized for this domain

Neither column substitutes for the other. An agent listed in adagents.json can be absent from schain while schain stays syntactically valid. A schain node can match ads.txt while the agent that closed the AdCP package never appeared in the publisher's authorized_agents list. OpenRTB 2.6 has no first-class field that says "this impression was produced by agent X under authorization Y."

That gap is why industry debate this fall (IAB defending the existing trio versus AAO's agent file) matters for implementation, not press releases alone. Buyers evaluating "98% of bid streams validate directness" are measuring the IAB stack. Agentic paths add a parallel authorization fetch the bid stream does not automatically enforce.

Network and channel supply paths that attach eids under schain have their own OpenRTB 2.6 rules; see openrtb-2-6-network_channel_supplychain_eids when your inventory is not a plain publisher domain story. The agent file still does not replace that object.

How you catch it

Manual reconciliation remains the honest first step: for each registrable domain you buy, fetch adagents.json and ads.txt, resolve agent URLs and seller ids, and compare them to source.schain on a live or logged bid request. Policy belongs in your stack; the wire objects will not merge the files for you.

For the OpenRTB payload, paste the request into the OpenRTB tester or run rtblint validate against the dated snapshot you pinned. An LLM implementing AdCP, ARTF, or agent tools can emit plausible schain and still miss incomplete chains, wrong ver, or dialect mismatches that only show up on the exchange's parser. rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) is the deterministic check on that object: mutations, discovery helpers, and supply-chain rules. It does not crawl adagents.json and certify agents against ads.txt; nothing in the spec requires that merge today. The package is independent of IAB Tech Lab and of AgenticAdvertising.org.

Where to go next

Start with the OpenRTB supply chain trust stack guide for how the IAB files fit together and where adagents.json sits beside them. The ads.txt vs sellers.json vs schain walkthrough is the side-by-side for the classic trio. For the agent versus schain split in agentic workflows, read adagents.json does not audit schain. If your integration speaks gRPC protobuf JSON, pair supply-chain checks with OpenRTB's two JSON dialects so a green schema pass on one transport does not mask an unparseable hop on the next.

Until your emit boundary re-applies adagents scope on the impression and your buyer policy cross-fetches both stacks, four files can all return 200 while the auction answers only the question schain was built for.

VASTAdTagURI in a DAAST Wrapper Validates as XML. Audio Players Read DAASTAdTagURI.

Aleksander Sekowski — Fri, 09 Oct 2026 00:07:28 +0000

The podcast stitcher logs a VAST-style no-fill. Finance sees the deal as delivered in the ad server. The XML attachment in the ticket is a <DAAST> root with a <Wrapper>, an <Impression>, and a redirect URL that opens fine in a browser.

The failure is the element name around that URL, not the hostname.

<DAAST version="1.0">
  <Ad id="audio-wrap-1">
    <Wrapper>
      <AdSystem>Video Ad Server</AdSystem>
      <Impression><![CDATA[https://ssp.example.com/imp?id=44]]></Impression>
      <VASTAdTagURI><![CDATA[https://buy-side.example/daast-inline.xml]]></VASTAdTagURI>
    </Wrapper>
  </Ad>
</DAAST>

Every string inside the CDATA can be HTTPS and reachable. A generic XML validator still returns OK. An audio player built for DAAST 1.0 never treats <VASTAdTagURI> as the next hop. It looks for <DAASTAdTagURI>. Hop one ends with no inline audio and no second request.

Two envelopes, two redirect tags

VAST and DAAST share the InLine versus Wrapper shape, but they are not interchangeable documents. VAST <Wrapper> must carry <VASTAdTagURI>. DAAST <Wrapper> must carry <DAASTAdTagURI>. The IAB DAAST specification mirrors VAST section structure on purpose, then renames the wrapper redirect so parsers know which grammar applies to the response body.

OpenRTB makes the same split on the bid request side. AdCOM lists separate creative subtypes for DAAST 1.0 inline versus DAAST 1.0 Wrapper, alongside the VAST protocol values. A buyer can declare audio wrapper support while the adm or the VAST URL still returns a document typed for the wrong envelope.

This is the audio version of copying video leftovers into a new channel. Trafficking tools that started on CTV export <VideoClicks> and <VASTAdTagURI> habits. Podcast and streaming audio paths need <AdInteractions> and <DAASTAdTagURI> on the wrapper. The mistake survives copy-paste and template reuse because the outer <Wrapper> label looks familiar.

Agentic workflows make that reuse easier, not harder. Teams are wiring MCP and API buying across CTV, display, and audio from one dashboard (AdExchanger on agentic CTV buying). The buy can close in the agent UI while the asset generator still emits video element names on a DAAST root. HTTP 200 on upload is not proof the player will follow the chain.

What the linter flags

On the sample above, three independent problems show up at once:

Missing required <DAASTAdTagURI> on the wrapper (rule reference).
A VAST-only child under DAAST (DAAST-1.0-wrapper-vast-adtaguri).
Often a missing wrapper <Impression> when the copy came from a minimal video wrapper (same structural gap as wrapper with no <VASTAdTagURI> on the video side).

Each <Ad> under either envelope still has to contain exactly one <InLine> or <Wrapper>. An empty <Ad> or a wrapper with no redirect target fails for the same reason on VAST and DAAST (VAST-2.0-ad-has-inline-or-wrapper applies to the shared ad shape).

For video wrappers the parallel requirement is explicit: VAST-2.0-wrapper-vastadtaguri errors when <VASTAdTagURI> is absent. DAAST players surface the same class of failure as a wrapper resolution error even though QA only checked that the XML was well formed.

How you catch it before serve

Start from the live tag URL when the ticket gives you one. The VAST tag tester fetches the document, shows tracking URLs, and lets you confirm whether the response is typed as VAST or DAAST before you trust a preview player.

When the tag wraps, use the VAST inspector hop by hop. You want to see whether each wrapper exposes the redirect element the spec for that document type names, not whether hop one returned 200.

CLI checks belong on the attachment the ad server will actually serve:

$ vastlint check audio-wrapper.xml
rulepack: DAAST 1.0
  error   DAAST-1.0-wrapper-daastadtaguri
          DAAST <Wrapper> must contain <DAASTAdTagURI>
  warning DAAST-1.0-wrapper-vast-adtaguri
          <VASTAdTagURI> is a VAST element; DAAST wrappers redirect via <DAASTAdTagURI>

An implementation that lets a model or agent emit DAAST XML still has to validate the envelope. vastlint (cargo install vastlint, npm install vastlint) is that check for VAST, VMAP, and DAAST creatives. It is independent of IAB Tech Lab and of AAO. The spec does not require it; I use it because RPC success and schema-well-formed are not the same as servable audio.

Where to read the contract

The DAAST overview walks through document typing, wrapper versus inline, and how DAAST tracking events differ from linear video quartiles. For a cross-envelope QA checklist, the IAB VAST validator guide explains what a spec pass covers and what still requires fetching the live chain.

If you are standardizing one engine for VMAP breaks and audio pods, keep document type in the test name. Validating a DAAST wrapper with VAST-only rules, or skipping wrapper redirect element names because the URL string looks correct, is how audio fill dies quietly while video templates keep shipping.

ADJUST_DEAL_FLOOR on /imp/imp-1 Parses. ARTF Still Needs /imp/{id}/pmp/deals/{deal id}.

Aleksander Sekowski — Thu, 08 Oct 2026 00:05:57 +0000

IAB Tech Lab's milestone on ARTF v1.0 says the Agentic Real Time Framework is final and running on live bidstreams. Hosts are wiring GPU agents beside the auction, container health checks pass, and gRPC returns OK. That is the week to stop treating "parsed" as "applied."

A publisher agent can return a mutation that looks like every sample in the repo, complete with enum names and a rooted path, and still aim at the wrong entity. The orchestrator receives a legal protobuf JSON document and has nothing on the wire to patch.

Intent and path are a matched pair

ARTF v1.0 does not use JSON Pointer. Each Mutation carries a semantic path: a rooted string that names a business entity inside the carried OpenRTB object, not a field walk.

The v1.0 reference documents four shapes:

/user/data/segment for segment and identity intents
/imp/{imp id} for impression-scoped deal activation, suppression, and metrics
/imp/{imp id}/pmp/deals/{deal id} for per-deal floor and margin proposals
/seatbid/{seat}/bid/{bid id} for bid shading on a concrete bid

Each Intent enum value is tied to one of those shapes. ACTIVATE_DEALS, SUPPRESS_DEALS, and ADD_METRICS stop at the impression. ADJUST_DEAL_FLOOR and ADJUST_DEAL_MARGIN must name both the impression and the deal id, because OpenRTB stores bidfloor on the Deal object under imp[].pmp.deals[], not on Imp itself.

Copy a path template from an ADD_METRICS example and swap the intent to ADJUST_DEAL_FLOOR without extending the path:

{
  "intent": "ADJUST_DEAL_FLOOR",
  "op": "OPERATION_REPLACE",
  "path": "/imp/imp-1",
  "adjust_deal": { "bidfloor": 12.5 }
}

Protobuf JSON parsing succeeds. The path resolves to impression imp-1, which exists in the bid request. The payload oneof is populated. Transport is green.

The coherence check is where ARTF stops being syntax. Impression paths accept ACTIVATE_DEALS, SUPPRESS_DEALS, and ADD_METRICS. They do not accept ADJUST_DEAL_FLOOR. RTBlint reports artf.mutation.path_intent_mismatch: the intent targets an impression, but deal-floor intents belong on /imp/{imp id}/pmp/deals/{deal id}.

The symmetric mistake is pointing an impression intent at a deal path. ACTIVATE_DEALS on /imp/imp-1/pmp/deals/deal-premium parses the deal segment correctly, then fails the same rule because activation is an impression-level operation, not a single row in deals[].

Why agents copy the wrong path

Model-generated mutations often reuse the last path that validated in context. Metrics enrichment at /imp/imp-1 is a common template. Floor changes feel like "another number on the same imp," so the path stays short.

applicable_intents does not fix this. The host may declare ADJUST_DEAL_FLOOR in the envelope and still receive a mutation whose path never names a deal. artf.mutation.intent_not_applicable is a different failure: the intent string was never offered. Here the intent is allowed; the path is wrong.

Relative paths fail earlier with artf.mutation.path_not_absolute. Unknown intent strings in the envelope's applicable_intents fail with artf.intent.unknown before the agent runs. Path-intent mismatch is the class of bug that survives those checks.

Margin is legal ARTF with no OpenRTB field

Even when the path is correct, one intent has no column to write. ADJUST_DEAL_MARGIN is valid ARTF, but OpenRTB 2.6 Deal has no margin field. The orchestrator applies margin out of band. RTBlint flags artf.mutation.no_openrtb_target as a warning so you do not expect pass-three OpenRTB validation to prove margin landed.

How you catch it

I run three passes on every ARTF hop: envelope and carried OpenRTB as protobuf JSON, the mutation set against applicable_intents and semantic paths, then apply accepted mutations and revalidate OpenRTB on the object the exchange will see.

The ARTF simulator runs the same engine in a browser: paste an RTBRequest, paste mutations, watch apply-then-revalidate. The primer on lifecycle, paths, and permissioning is ARTF explained. The longer walkthrough of independent acceptability is ARTF mutations and bid request validation.

CLI:

$ rtblint validate --type artf-response --request rtb-request.json rtb-response.json
FAILED (OpenRTB 2.6-202606 ARTF mutation set): …
  mutations[1].path: Intent ADJUST_DEAL_FLOOR targets "/imp/imp-1", which names an impression.
    Paths that carry ADJUST_DEAL_FLOOR look like /imp/{imp id}/pmp/deals/{deal id}.
  (artf.mutation.path_intent_mismatch)

MCP tools validate_artf_request and validate_artf_response (with apply when you need post-patch OpenRTB) exist so an agent implementing AdCP, ARTF, or AAMP-style patches can call the check on its own output. The RPC can still return OK; the wire contract for OpenRTB inside the envelope does not move. rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) is the deterministic check on that object and mutation set. It is independent of IAB Tech Lab and of AAO; the spec does not require it, and nothing in v1.0 replaces pass two before you forward.

Where to go next

Treat path templates as intent-specific types, not shared strings. When you add deal-floor agents, unit-test the full path including pmp/deals/{deal id} against the deals the sample bid request actually carries.

For rule-level detail, see path intent mismatch, intent not applicable, and no OpenRTB target for margin.

Production ARTF means production path bugs. gRPC success is transport; semantic paths are still the contract that decides whether a floor change ever touches a deal row.

firstQuartile Under NonLinearAds Validates. CTV Portfolio Players Never Schedule It.

Aleksander Sekowski — Wed, 07 Oct 2026 00:04:30 +0000

On October 5, IAB Europe published its final Connected TV Measurement Framework. Video completion rate and view-through rate are first-class metrics again, with explicit disclosure rules. Those numbers only move if the tag fires the events the player actually schedules. For pause, overlay, squeezeback, and the rest of the CTV Ad Portfolio (finalized July 22, 2026), that schedule is not the linear quartile ladder.

A squeezeback flight I debugged last month looked healthy in the ad server. Impressions counted. The creative rendered in the shrunken frame. The buyer's dashboard showed zero completion and zero time-on-screen. The XML still had <Tracking event="firstQuartile"> sitting under <NonLinearAds>, copied from a :30 instream template.

What the spec assigns to each container

VAST does not forbid arbitrary event names inside <TrackingEvents>. It maintains a vocabulary, and on 4.x both linear and non-linear events live in the same list. firstQuartile, midpoint, and complete are valid strings whether they appear under <Linear> or <NonLinearAds>.

Runtime behavior is container-specific. A linear creative owns a playhead tied to <Duration>. The player advances that clock and fires quartiles against it. A NonLinear creative has no guaranteed playhead. The IAB CTV signaling guidance tells buyers to measure portfolio units with creativeView and overlayViewDuration, plus interaction events such as close when the viewer dismisses the unit.

The Format-to-Signal table in Signaling Implementation Guidelines pairs each portfolio format with NonLinear VAST delivery. Squeezeback uses plcmt = 8 and layout-specific pos values (11 through 17). Overlay uses plcmt = 7. Pause uses plcmt = 5 with playbackmethod 8 or 9. None of those rows describe a linear InLine spot with quartile beacons.

Trafficking systems that reuse mid-roll exports therefore ship structurally legal XML with the wrong measurement contract. The ad can paint pixels. The verification pixel for "75% watched" never fires, because nothing in the NonLinear path subscribed to quartiles.

The copy-paste failure mode

The failure is boring. A creative ops team duplicates a working instream tag, drops AdCOM extensions for plcmt, pos, and playbackmethod, and changes the <Creative> subtree to <NonLinearAds>. Impression URLs stay. Quartile URLs stay. Nobody rewrites tracking because the validator green-lit every event name.

Worse, some teams leave start under NonLinear. Players that do fire start only do so for linear timelines. A NonLinear unit that never receives creativeView looks unviewed in MRC-style counting even when the overlay was on screen for twenty seconds.

Video squeezeback and motion overlay add a second gap. Quartiles and overlayViewDuration need a timeline. A video <MediaFile> under <NonLinear> without <Duration> validates in many pipelines, but VAST-4.4-nonlinear-video-no-duration exists because progress events have nothing to anchor. Static pause images can omit duration when dwell is unknown at response time; full-motion portfolio assets cannot.

Signal mismatches show up separately. Paste squeezeback pos onto a pause plcmt and you get VAST-4.4-adcom-pos-format-mismatch even when tracking looks fine. I walked pause versus squeezeback signal pairs in Netflix pause ads go programmatic. This post is the measurement half: right container, wrong events.

How you catch it before the flight

Schema validation and an LLM rewriting VAST will both accept firstQuartile under NonLinearAds. The wire contract for portfolio inventory is container plus signals plus the NonLinear event set. You still need a deterministic check on the payload the buy claimed.

Start with the live tag, not a pasted fragment. The VAST tag tester fetches the ad server URL, previews the creative, and lists tracking URLs as declared. If every URL says quartile but the creative tree is NonLinear, you found the bug before spend moves.

Wrapper chains hide the same mistake on hop three. The VAST inspector walks each hop and shows where InLine finally appears. Portfolio campaigns that stitch server-side often wrap twice; the broken <TrackingEvents> block may not be in the file your designer exported.

For SIMID or interactive overlay assets, the IAB-style VAST tester (an independent fork, not an IAB Tech Lab product) exercises the handshake and protocol log alongside the media fallback. Interactive portfolio units still owe creativeView when the fallback image renders without SIMID.

CLI checks come after URL-level review:

$ vastlint check squeezeback-brand.xml
  warning  AdCOM pos is not a position the declared plcmt format supports  VAST-4.4-adcom-pos-format-mismatch
  warning  <NonLinear> delivers a video <MediaFile> but declares no <Duration>  VAST-4.4-nonlinear-video-no-duration
0 errors, 2 warnings

vastlint (cargo install vastlint, npm install vastlint) encodes the July 2026 CTV portfolio rules: AdCOM extension shapes, format-to-signal tables, NonLinear media requirements. It does not yet emit a dedicated rule for quartiles under NonLinearAds, because the defect is semantic, not syntactic. CI should assert NonLinear portfolio directories include creativeView and, for timed video, overlayViewDuration, and reject firstQuartile there the same way you reject HTTP media on HTTPS inventory.

An implementation that lets a model emit VAST still has to verify the payload against that contract. vastlint is that check for the creative side. It is independent of IAB Tech Lab and of AAO.

Where to go next

The CTV Ad Portfolio reference maps each format to plcmt, pos, and expected NonLinear delivery. The tracking events index table lists which events belong under <Linear> versus <NonLinearAds>; keep that table open while auditing exports.

When video portfolio tags miss <Duration>, read the rule doc for nonlinear video without duration before you trust quartile or overlay progress URLs. When signals disagree with the asset, fix pos and playbackmethod before you re-traffic tracking.

Programmatic pause and squeezeback inventory is expanding as platforms adopt the six-format signal set. Measurement frameworks now ask for disclosed completion methodology. The cheapest way to fail that disclosure is a valid XML document that bills impressions while reporting an empty quartile column on a unit that never had a linear playhead.

data:text/javascript in InteractiveCreativeFile Passes VAST 4.3. SIMID Still Loads HTML.

Aleksander Sekowski — Tue, 06 Oct 2026 00:02:36 +0000

IAB Europe published its final CTV Measurement Framework on October 1, 2026. Buyers are now expected to ask how viewability, completion, and interactive engagement were measured, not just what number appeared on the IO. The video can play while the SIMID layer never mounts, and nothing in the campaign report explains that gap.

One XML mistake I keep seeing on migrated tags: the interactive URL is inlined as a data: URI left over from a VPAID script, not an HTML page.

<InteractiveCreativeFile apiFramework="SIMID" type="text/html">
  <![CDATA[data:text/javascript;base64,Y29uc29sZS5sb2coJ2hlbGxvJyk=]]>
</InteractiveCreativeFile>

Trafficking tools that only XSD-check the document treat this as legal VAST 4.3. The linear <MediaFile> still points at an MP4, so preview looks fine. The player never enters SIMID mode on the iframe because the payload is not an HTML document.

What VAST 4.3 changed, and what SIMID did not

VAST 4.3 explicitly allows data: URIs where a creative URL would otherwise be HTTPS. That is useful for tiny test tags and for environments that block outbound fetches during QA.

SIMID 1.0 §3.1 is narrower: the creative loaded in the sandbox is an HTML document that implements the SIMID postMessage API. The MIME in the URI matters. data:text/html (or application/xhtml+xml) is in scope. data:text/javascript, data:application/javascript, or a base64 blob that decodes to a script is the same class of mistake as putting type="application/javascript" on the element while calling it SIMID.

The type="text/html" attribute on <InteractiveCreativeFile> does not rewrite the URI. If the CDATA declares text/javascript, you have a spec conflict even when the attribute looks correct.

What you see in production

The failure is quiet. SSAI and many CTV players play the progressive or stitched media and skip interactivity when the SIMID URL cannot load as HTML. Quartile and completion beacons on the linear asset still fire, so delivery dashboards look healthy. Product and engagement metrics tied to the interactive unit flatline.

That pattern matches other SIMID URL bugs (empty CDATA, http://, placeholder macros). The SIMID rule index groups them by rule id so you can grep CI output instead of re-learning each migration artefact.

For this specific case, vastlint reports SIMID-1.0-simid-url-data-html as an error when a SIMID URL uses a data: scheme without an HTML media type.

$ vastlint check simid-data.xml
simid-data.xml  VAST 4.3
  error    SIMID creative URL uses data: URI without text/html MIME
           SIMID-1.0-simid-url-data-html

Whitespace-only URLs and missing CDATA bodies are a different rule (SIMID-1.0-simid-url-empty). Fix the MIME before you chase handshake bugs inside the creative.

How you catch it before the buy goes live

Start with the live tag, not a pasted fragment from the ad server UI.

The VAST tag tester fetches the tag URL, previews the media, and surfaces tracking URLs so you can confirm the MP4 or HLS path is real. If interactivity is part of the sale, paste the same URL into the VAST inspector and walk wrapper hops until you reach the <InteractiveCreativeFile> that carries SIMID.

For the handshake itself, the IAB-style VAST tester loads sample creatives and logs host transport messages. It is an independent fork, not an IAB Tech Lab product, but it exercises the same postMessage path a spec-compliant player uses. If the workbench never enters SIMID mode while the video preview plays, fix the URL and apiFramework before you open a ticket against the HTML asset.

CLI or CI after that:

$ vastlint check --severity error tag.xml

The SIMID validation overview maps which rules apply to linear versus nonlinear 1.1 overlays. The SIMID overview restates the envelope: HTTPS or valid data:text/html, sibling <MediaFile>, and apiFramework="SIMID" exactly.

An implementation that lets a model or agent emit VAST still has to check the payload on the wire. vastlint (cargo install vastlint, npm install vastlint) is that check for the creative the buy claimed. It is independent of IAB Tech Lab and of AAO. It does not replace OMID verification in <AdVerifications>; SIMID and OMID solve different layers. When both are on the tag, validate each contract separately.

Where to go next

If you are migrating off VPAID, read how type="text/html" differs from legacy JavaScript media files, and keep a real <MediaFile> next to SIMID so players without iframe support still have video.

If your trafficking template still emits inline scripts, host a minimal HTML wrapper that loads the SIMID API and point the tag at https:// before you consider data: at all. CTV measurement frameworks assume the interactive layer can actually run; a data:text/javascript URI validates as VAST and fails as SIMID.

OpenProposal Ranks Briefs. The OpenRTB Bid Request Has No Proposal Handle.

Aleksander Sekowski — Mon, 05 Oct 2026 01:01:17 +0000

On September 22, 2026 IAB Tech Lab shipped AAMP 3.0 with OpenProposal, a draft spec for how seller agents describe ad products and how buyer agents compare those representations to a campaign brief. Public comment runs through October 22. IAB Australia opened a seller sandbox the same week to exercise discovery and proposal flows on synthetic data, with live spend out of scope.

That is the right problem to automate. A human media team can read three RFP responses. Software cannot compare thousands unless every seller encodes what they are selling the same way. OpenProposal is that encoding layer, wired to the transaction rails Tech Lab already publishes: AdCOM, OpenDirect, and the Deals API.

The failure mode shows up one hop later, when the accepted line item is not a signed insertion order sitting in a folder but an auction call.

Two stages, one wire format

OpenProposal lives in the planning stage. The buyer agent holds a brief: channel, geography, budget band, format constraints, maybe a content taxonomy slice. Seller agents return structured products. The buyer agent scores fit.

AAMP 2.x already supports programmatic guaranteed, preferred deals, PMP lines, and the open marketplace through the same buyer and seller SDKs. When the winning path is programmatic, execution is still an OpenRTB bid request and response pair on the exchange you already operate. Nothing in OpenRTB names which OpenProposal response won. There is no proposal_id, no back-pointer to the brief version, and no guarantee that the imp.video object still carries the duration or placement semantics the comparison used.

AdCP negotiates version on every message and returns a typed error when buyer and seller disagree. AAMP 2.3 added trust verification on price-moving paths. OpenRTB still agrees its dated snapshot in onboarding docs, not in the JSON. We wrote about that asymmetry in the agentic version negotiation gap. OpenProposal adds a third layer: a structured comparison that never has to survive into the auction object.

Duration is the easy miss

Live CTV breaks on imprecise creative length. OpenRTB 2.6 added rqddurs, an array of exact acceptable durations in seconds. It is mutually exclusive with minduration and maxduration. Sports and news pods use it because a 29 second ad in a 30 second slot is dead air.

Suppose the brief asks for 15 and 30 second pods. OpenProposal matching scores a seller product that advertises those exact lengths under AdCOM placement semantics. The buyer agent accepts the proposal, then builds the programmatic hop from a template that still sets a range:

"video": {
  "mimes": ["video/mp4"],
  "protocols": [7, 8],
  "minduration": 5,
  "maxduration": 60,
  "plcmt": 1
}

The JSON is well formed. A DSP can bid 6, 12, or 45 second VAST tags that satisfy the range. Every tag violates what the brief and the proposal comparison already agreed. Quartile and podding logic downstream assumes the tighter contract.

The fix on the wire is not a comment in the SDK README. It is replacing the range with the exact set the proposal scored:

"rqddurs": [15, 30]

and dropping minduration and maxduration entirely. RTBlint flags the mutual exclusivity and the 2.6 field set in the rqddurs rule doc. The CTV OpenRTB guide is the field map for pod bidding (podid, slotinpod, rqddurs, duration floors).

validate_bid_request is not a brief checker

An implementation that lets a model emit the auction JSON still has to check that JSON against the OpenRTB snapshot the exchange runs. rtblint (cargo install rtblint, npm install rtblint-core, MCP rtblint-mcp) is that check on the bid request and bid response. It is independent of IAB Tech Lab and of AAO. The spec does not require it.

The hosted MCP server exposes validate_bid_request with an optional version argument. Omit version and validation defaults to the latest tracked 2.6 dated release in the build, not necessarily the snapshot your SSP pinned in a PDF three years ago. Pass the wrong id and you get a structured finding rather than a silent pass against the wrong rule set. See openrtb-version-unsupported for what that looks like on the wire.

$ rtblint validate --dialect spec-json bid.json
ok: true

# same bytes, exchange on 2.6-202303 with rqddurs sent alongside minduration:
$ rtblint validate --version 2.6-202303 bid.json
rule: openrtb-2.6-imp-video_audio-rqddurs
severity: error
message: rqddurs is mutually exclusive with minduration and maxduration

The tool validates the auction object, not the RFP story. If your pipeline only checks JSON Schema on the OpenProposal response and then forwards a hand-written imp, you can ship a buy that never existed in the comparison step.

Pin version to the exchange contract on every forward. Cross-check imp.video.plcmt and related AdCOM placement fields against what OpenProposal scored. AdCOM moved placement to plcmt with a different enum; echoing 2.5 integers without cattax and subtype discipline mislabels inventory. The plcmt migration write-up is still the readable map for teams that lived through the rename.

For video lines that clear to VAST, the auction check is only half the hop. Run the live ad tag through the VAST tag tester for fetch, preview, and tracking URLs, then the VAST inspector for wrapper hops. vastlint owns that XML payload. OpenProposal JSON does not substitute.

Where to read next

MCP tools and AdCP discovery for wiring validate_bid_request into a buyer agent loop.
Video object fields including rqddurs versus duration ranges.
Agentic version negotiation on OpenRTB for why the auction layer still lacks an on-wire snapshot id even while AAMP and AdCP argue about versions above it.

OpenProposal public comment is open until October 22, 2026. Whether or not the draft gains a formal bridge field in a later revision, production paths already split planning from execution. Treat the forwarded bid request as a separate contract and validate it like one.

One purchase can create four different conversion numbers.

Aleksander Sekowski — Sun, 04 Oct 2026 06:39:50 +0000

A customer completes order order-123 for $79. The backend has one paid order. Meta reports a Purchase. GA4 reports a purchase key event. Google Ads shows a conversion on a different day, or none at all.

It is tempting to add another tag until the dashboards agree. That can turn one order into two conversion signals. I use the order ID to trace the measurement path before changing any tags or bidding settings.

Start with the confirmed order.

The backend order is the control record. For a test purchase, keep the order ID, completion time, value, currency, and refund status together. Then ask which systems observed that specific order.

For order-123, the expected event is one confirmed Purchase for $79 USD. A page view on the thank-you page is weaker evidence. That page can reload, fail to load, or appear before payment is final.

Check the request and the identifier separately.

A tracking pixel is an HTTP request that reports an event. A cookie is a stored value the browser may attach to a later eligible request. The purchase request can arrive without a cookie. A cookie can also remain in storage when the purchase request never fires.

That distinction changes the debug path. If the request is absent, inspect the trigger, consent state, browser blocking, and network errors. If the request arrived but attribution is weak, inspect the landing click ID, cookie scope, and checkout redirects. The tracking pixel vs cookie guide walks through both sides in DevTools.

Send each ad platform its own purchase event.

The same confirmed order can feed Meta Pixel and a Google Ads website conversion action. They use separate destinations and field names. For example:

fbq('track', 'Purchase',
  { value: 79.00, currency: 'USD' },
  { eventID: 'order-123' });

gtag('event', 'conversion', {
  send_to: 'AW-123456789/ExampleLabel',
  value: 79.00,
  currency: 'USD',
  transaction_id: 'order-123'
});

Those are illustrative IDs. In production, inspect the fired requests and confirm the real Meta Pixel ID, Google Ads conversion ID and label, value, currency, and order ID. A tag manager preview saying both tags fired is the start of the check. The Meta Pixel vs Google Ads conversion tracking guide covers the two contracts and their duplicate protection.

Decide which Google Ads action should drive bidding.

GA4 can record purchase and mark it as a key event. Google Ads can then create a conversion action from that Analytics event. A direct Google Ads conversion tag is another way to measure the purchase.

Check the source of every Purchase action in Google Ads. If you have both a direct Ads action and a GA4-sourced action, verify which one is Primary in the campaign goal. Primary actions normally feed the Conversions column and bidding; Secondary actions are usually for observation. Importing an Analytics event does not make your goal choice for you.

The GA4 key events vs Google Ads conversions guide gives a reconciliation path for these settings and the resulting counts.

Separate event receipt from attribution.

Suppose a shopper clicks an ad on Monday and buys on Tuesday. The purchase event can be recorded correctly while an ad report credits it to Monday, applies a lookback window, or leaves it unattributed. Meta and Google Ads can also credit the same order under their own rules. Their attributed totals should not be added together as unique sales.

I debug in this order:

Confirm the paid order in the backend ledger.
Capture one event per intended destination, with the right order ID and value.
Check that relevant click identifiers survived the landing and checkout path.
Inspect each conversion action's source, counting method, goal, and attribution window.
Compare reports over the same date range and account time zones. In Google Ads, check the by-conversion-time view when daily dates appear to disagree.

The conversion tracking vs attribution guide expands that sequence with examples. I maintain Pixellint to validate captured pixel URLs and conversion payloads. It can check the request contract; the backend ledger and ad platform settings complete the investigation.

The URL in the tag manager is not the URL the browser fired.

Aleksander Sekowski — Sun, 04 Oct 2026 04:31:24 +0000

The string in Campaign Manager and the string in Chrome Network are not the same artifact. One of them is allowed to contain [CACHEBUSTER]. The other is not. A pixel checker that does not know which one you pasted will fail every legal macro, or it will pass a token that never expanded.

That is the whole job of the tester: say what you pasted, then check it against the contract for that state.

Template versus fired URLs is the state model. The playground at pixellint.org is the same engine as pixellint validate, running in the browser. cargo install pixellint and npm install pixellint are the same rule ids again. A finding in the box is the finding CI will print. Pixel not firing is how you get a URL worth pasting. The GTM snippet is not that URL.

Three states, and unknown is not a third product

unknown is the default when you did not say. Macro rules stay conservative. They will not assume the token was supposed to expand, and they will not assume it was supposed to remain. You get core URL checks and vendor parameter checks, with less certainty on macros. A first paste in the playground without a state is fine. Leaving production CI on unknown because it feels safer is not. It is vaguer. Teams that leave unknown everywhere either ignore macro findings or argue about them every sprint.

template means this is what the ad server, the MMP, or the tag manager stores. [NAME], ${NAME}, and {{NAME}} are expected in legal slots. Empty consent fields are unfilled slots. Copying from the Google Ad Manager UI is a template even when it looks like a URL. A Slack message from trafficking with ord=[timestamp] is a template. A Jira attachment of the Floodlight tag as sold is a template. A GTM custom pixel field that still has {{dlv-order-id}} is a template.

fired means this is what left the device or the server. Chrome Network, Charles, a HAR, an access log, MMP raw data, server-side GTM preview of the outbound request. If you see ord=1724284800123, it has fired. If you see [TIMESTAMP], it has not. If you see both in one URL, one macro family expanded and another did not. That is a fired miss.

$ pixellint validate url 'https://example.com/pixel?cb=[CACHEBUSTER]' --state template
$ pixellint validate url 'https://example.com/pixel?cb=1724284800123' --state fired

Validating the first line as fired fails a macro that is supposed to be there. Validating the second line as a template passes a shape you would never store, and it will also pass a dead token you should have caught. State only changes macro and empty-template behavior. A fired Meta Purchase URL without a numeric id is still vendor.meta.param.id.missing. Saying template will not invent an id. Core still applies in all three states: absolute URL, host present, http or https, no userinfo, fragments ignored, http flagged for upgrade. Vendor packs still apply when the host matches.

What to paste, and what not to paste

Paste the collector request. For a browser pixel that is facebook.com/tr, google-analytics.com/g/collect, ad.doubleclick.net/ddm/activity/..., ct.pinterest.com, analytics.tiktok.com. For a conversion API, set the format to JSON and paste the body the worker posts. Deep-link the box with ?kind=url or ?kind=json. Redact access tokens, raw emails, and cookies before the paste. A 64-character hex digest can stay. Artifacts you test on the site may be stored. The privacy note is the scope. The local CLI and pixellint-mcp do not send the artifact.

Do not paste the GTM loader and call it the conversion. Do not paste a Pixel Helper screenshot. Do not paste the base code snippet. The loader returning 200 only proves a container script was fetched. The conversion is the collector, or the JSON POST Pixel Helper cannot see.

Video ads add a third paste. A VAST document declares Impression and Tracking URLs. Those URLs are pixels: load beacons for impression and quartiles, a redirect chain for the click. The XML can be well formed and the fired start URL can still contain [CACHEBUSTER], or it can be http on an HTTPS player, or it can be the click URL reused as Impression. VAST tracking events are pixels is that split. Fetch the live tag in the VAST tester when the document still has to unwrap. Walk hops in the inspector when the player printed a wrapper error. Then paste the fired start URL into the pixel checker with --state fired. Two contracts, two pastes. Pixellint does not parse the VAST parent. vastlint does not decide whether the expanded URL is a legal Floodlight activity.

CI wants two fixtures, not a weekly HAR

One job, two states, two files. Run the template with --state template and the HAR-extracted URL with --state fired. For server bodies, pixellint validate json on a redacted production-shaped payload. Exit code 1 is an error-severity finding. Exit 0 still allows warnings. Exit 2 is a usage or input problem. A weekly archaeology session on a HAR does not catch the merge that shipped Date.now() as event_time. The fired JSON fixture does. A template fixture does not catch it, because that bug is not in the template. If you only store templates, you only test trafficking. If you only store HARs, you only test one serve, and you fail every legal macro in Ad Manager. Store both.

- uses: aleksUIX/pixellint@v0.31.10
  with:
    path: fixtures/conversion-pixel.txt
    kind: url

The action downloads a prebuilt binary. It does not compile the rules on the runner. The same binary is what cargo install pixellint runs, which is what the playground runs. Pin the rulepack when the body has no host. A Meta JSON blob and a Snap JSON blob are both objects. action_source: website is Meta. action_source: web is Pinterest. WEB is Snap. Omit the field and more than one pack will speak.

Set the state on the command, not in a comment inside the URL. An agent that emits a pixel, a verification beacon, or a conversion body can still get HTTP 200 from the vendor. I maintain Pixellint. It is independent of Google, Meta, and IAB Tech Lab. It is the check on the artifact after the model or the trafficking sheet emits it, and before you treat a GIF or a 200 as proof the activity counted.

Hash the email. Do not hash the IP. Both mistakes still return 200.

Aleksander Sekowski — Sun, 04 Oct 2026 04:30:45 +0000

A Purchase reaches the Meta Conversions API with a 64-character hex string in every user_data field. Test Events shows the event. Match quality on the live dataset stays poor, and nobody can see which field missed.

The helper hashed the email, which Meta requires. It also hashed the IP address and the click cookie, which Meta requires you to leave alone. Both mistakes return HTTP 200.

Vendors match SHA-256 of a specific normalization. Not bcrypt. Not MD5. Not a digest of the display string as the CRM stored it. The 64-character hex is the payload. The algorithm is not a choice. Hashing PII is the split. The field list for Meta lives on the Conversions API pack.

Two allowlists, not one function

On Meta CAPI, user_data.em, ph, fn, ln, ge, db, ct, st, zp, country, and external_id are SHA-256 hex. Lists are the same contract, one digest per value. TikTok Events API hashes context.user.email, phone_number, and external_id. Snap uses the Meta-shaped em and ph fields. Pinterest CAPI hashes em, ph, external_id, and hashed_maids.

A raw email in those slots is a matching miss and a log leak. A digest of the wrong input is a 64-character string that never joins a person. The collector still returns 200. Pixellint flags a raw address as vendor.meta-conversions-api.body.unhashed_email, and the TikTok, Snap, and Pinterest twins. A value that is not 64 hex characters on a hashed slot fails as user_data.em.invalid and the matching field ids.

What must stay plaintext: client_ip_address and client_user_agent on Meta, Snap, and Pinterest. context.ip and context.user_agent on TikTok. Those are request metadata, not customer information parameters. Hashing them makes the event unmatchable. A helper that maps every string in user_data through SHA-256 will hash them by accident.

Click ids and cookies are plaintext too. fbc, fbp, fbclid, ttclid, gclid, msclkid, li_fat_id, and twclid are not SHA-256 inputs. If a privacy pass hashed every string, you deleted the strongest identifiers you had. The cookie values are already opaque tokens. Digesting them a second time is not anonymization. It is a join key you threw away. Send the _fbc cookie value as stored, or rebuild it in the documented fb.1.creationTime.fbclid shape. Do not put the raw fbclid in user_data.fbc and do not hash either one.

A 64-character hex string in an IP or user-agent slot is vendor.meta-conversions-api.body.hashed_plaintext_field, plus the TikTok, Snap, and Pinterest codes. The check is the pattern ^[A-Fa-f0-9]{64}$, scoped to the plaintext fields. It does not invent extra plaintext fields.

// identifiers hashed, request metadata left as seen
user_data.em = sha256hex(email.trim().toLowerCase());
user_data.ph = sha256hex(e164Phone);
user_data.client_ip_address = ip;
user_data.client_user_agent = ua;
user_data.fbc = fbcCookie;

// the production bug: one walk of user_data
for (const key of Object.keys(user_data)) {
  user_data[key] = sha256hex(String(user_data[key]));
}

The second loop produces a legal-looking digest in client_ip_address. Meta cannot reproduce the IP it saw on the request. The email may be fine. The event still 200s.

Normalize, then hash, then send

Send the 64-character hex digest. Upper-case hex still matches. Meta documents lower-casing the input, not the digest, so rejecting an upper-case digest would invent a requirement. Do not Base64 the hash. Do not prefix sha256:. Do not HMAC with a secret the vendor does not have. HMAC-SHA256 with your API secret produces a digest the graph cannot reproduce.

Hashing first and then lower-casing the digest does not undo a mixed-case email that went into the hasher. Trim and lower-case the email, hash that, send the hex. Test with a known address and the vendor's own example digest before you ship the helper. If your digest disagrees with the documented example, stop. Do not A/B the algorithm in production.

MD5, SHA-1, and bcrypt show up in CRM exports. None of those are the ads contract. A bcrypt string is not 64 hex characters and fails the SHA-256 slot. An MD5 hex is 32 characters and fails the same check. The HTTP 200 does not mention any of that.

Google Ads enhanced conversions hash email after a stricter Gmail normalize: dots and plus-tags. One hasher shared between Meta and Google Ads will miss one of them on Gmail-heavy lists. Build the normalize next to the vendor, not in a shared hashEmail() that both pipes call.

Reddit is the exception people copy backwards

Reddit CAPI v3 accepts email and phone unhashed or SHA-256 hashed. That pack does not require a digest on those fields. Copying the Meta hasher onto Reddit is allowed. Requiring a digest because Meta required one is a rule Reddit did not write. The inverse is worse: seeing that Reddit accepts a raw email, and then sending a raw email on Meta. unhashed_email is the Meta finding. Do not take Reddit's optional digest as a Meta policy.

Double hashing looks legal

The other production bug is hashing on the pixel and hashing again on the server. The browser sends a digest. The server runs SHA-256 on that digest. The result is still 64 hex characters. It matches nobody. If the pixel already hashed advanced matching, the server must hash the raw value it has, not the digest the browser sent. Two pipes, one normalization, one hash, same hex. Dedup is event_id, not a second hash.

Events Manager match quality will not tell you which field missed. A Purchase with hashed email, hashed phone, hashed IP, and a real fbc can look fine in Test Events and score badly in production because the IP never joined. Paste the JSON into pixellint validate json. hashed_plaintext_field is the IP bug. unhashed_email is the other direction.

Keep one fixture with one email, one E.164 phone, one IP, one user-agent, one fbp, one fbc. Assert the email and phone are 64 hex. Assert the IP still looks like an address. Assert fbp still starts with fb.. That fixture is cheaper than a week of ROAS archaeology.

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

The conversion API validator is the rest of the same body: clock, action_source, value, currency. Hashing is the part a generic privacy helper gets backwards while the status code stays green. Paste the redacted JSON into pixellint.org with the format set to JSON. I maintain Pixellint. It is independent of Meta, TikTok, Snap, Pinterest, and Reddit. The rule ids cite their customer-information docs because that is where the allowlists live, not because this is an official hasher. A model that "hashes PII before send" will hash the IP unless something checks the field list. The package is that check.

Floodlight still needs src, type, and cat. A leftover ord=1 counts once.

Aleksander Sekowski — Sun, 04 Oct 2026 04:30:42 +0000

People still search for DART Floodlight tags. DART was DoubleClick's ad server. Campaign Manager 360 still serves the same activity on doubleclick.net. The request returns a GIF. The conversion still lands on the wrong activity, or it lands once.

Floodlight is not a query string, and it is not a Conversions API with the host changed.

The shape is semicolon pairs on the path:

https://ad.doubleclick.net/ddm/activity/src=1234567;type=conv;cat=purch;ord=987654321;qty=1;cost=19.99

src is the numeric Floodlight configuration id, the advertiser. type is the activity group tag. cat is the activity tag. Trafficking the wrong cat is a silent wrong conversion, not a 404. The activity you meant never increments. A different activity does. DART Floodlight tags is that identity. The path table is the Floodlight pack.

$ pixellint validate url @floodlight.txt --rulepack vendor/floodlight

Missing, empty, or illegal values show up as vendor.floodlight.param.src.missing, .type.missing, .cat.missing, and the empty and invalid twins. Staging has to use a staging cat. A QA purchase on the production activity is real revenue in Campaign Manager and a lie in the test plan. Server-to-server Floodlight is a different Campaign Manager feature. If you use it, src, type, and cat still have to name the activity you think they name. There is no second pipe with a different clock. Do not invent an event_id query because a Meta playbook said both sides need one. Dedup for this tag is the counting method on the activity, not a shared UUID with a browser pixel.

ord=1 is a cache, not a counter

ord is required cache busting. A browser or a CDN that sees the same URL will collapse a thousand impressions into one response. A standard counter tag needs a unique ord on every fire. Unique counting is the other method: you send ord=1 together with a random num. vendor.floodlight.counting.unique_requires_ord fires when num is present and ord is not. A leftover ord=1 on a standard counter, copied from a screenshot or a sample tag, collapses fires into one cached GET. The GIF still returns 200. The activity count does not move.

Do not put an email or a phone in ord. Cache busting is the same job on display impression pixels: a unique query value, expanded before the request, with no personal data in the slot. An unexpanded [CACHEBUSTER] or [timestamp] on a URL that already served is an undercount. Macros from Google Ad Manager have to expand. If you still see square brackets, you copied the template from the trafficking UI, or the player never substituted. That is a template versus a fired URL. Validate the tag as stored with --state template. Validate the HAR row with --state fired. One fixture cannot be both. A literal 1 that survived into production is the classic miss.

cost and qty on purchase activities are numbers you defined in Campaign Manager. A currency symbol in cost is not a number. Floodlight has no event_time digit count and no SHA-256 em field on the standard activity tag. Do not hash the path. Hashing a Floodlight URL because a Conversions API helper hashed every string does not make the activity match better. It makes the path nonsense.

Consent on the path is still a TC String

gdpr, gdpr_consent, gpp, gpp_sid, and us_privacy ride as the same semicolon fields. Core privacy rules read the query string and Floodlight-style path parameters, which is why those checks are not a Google-only pack. gdpr is 0 or 1. gdpr=1 needs a TC String whose header decodes as version 2. gdpr_consent=1 and gdpr_consent=true pass an alphabet check and fail a decode. They are valid base64. They are not a TC String. They do not carry consent.

Empty values and unexpanded macros are template slots. A fired tag that still contains an unexpanded GDPR token never carried consent. Duplicate gdpr_consent parameters are core.privacy.duplicate_signal. Floodlight on the same page as Google Consent Mode still wants the TC String on the tag. Consent Mode is not TCF. A US Privacy string such as 1YNN is not a GPP header, and gpp without gpp_sid fails on its own.

https://ad.doubleclick.net/ddm/activity/src=1234567;type=conv;cat=purch;ord=1;num=9988;gdpr=1;gdpr_consent=CPXXXXXXXX

That ord=1 is legal only because num is present and you meant unique counting. The same ord=1 without num on a standard counter is the cache bug. Mixed macro families in one URL, [NAME] next to ${NAME} next to {{NAME}}, is a mixed-syntax finding in core. A pixel URL uses one syntax.

Preview is not the published tag

GTM preview can show a Floodlight tag with macros filled in the panel while the published container still sends the token. Confirm Network after publish, on a clean profile. Copy the activity URL. A filter on the word pixel misses doubleclick.net. Lint it twice:

$ pixellint validate url @floodlight.txt --rulepack vendor/floodlight
$ pixellint validate url @floodlight.txt --rulepack core

The vendor pack checks src, type, cat, and the counting pair. Core checks scheme, macros, and the consent strings. Unknown hosts get attribution, not a pile of invented rules. A click URL must not be trafficked as this impression activity. An impression activity should return the GIF or a 204. A 302 to a landing page is a click tracker wearing an activity path.

Paste the fired URL into the playground at pixellint.org. If the string still has brackets, set the state to template or you will fail every legal macro in the creative. I maintain Pixellint. It is not affiliated with Google or Campaign Manager. The rules cite Campaign Manager's activity URL because that is the contract, not because this is an official tag checker. A model or a trafficking sheet can emit src, type, and cat that look filled in. The package is the check that those three name an activity, that ord matches the counting method, and that gdpr_consent decodes.

Pixel Helper cannot see a Conversions API POST. A 200 is not the contract.

Aleksander Sekowski — Sun, 04 Oct 2026 04:30:12 +0000

A checkout worker posts a Purchase to the Meta Conversions API. The response is HTTP 200. Test Events stays empty. The next move is usually a new access token.

The token is rarely the bug. Pixel Helper cannot see the POST at all. The 200 is liveness. The body is the contract.

Meta Pixel Helper, TikTok Pixel Helper, and GTM preview watch the browser. Conversion API events are POSTs from your backend, from server-side GTM, or from a queue worker. They do not appear in Chrome Network unless you proxied them through the page. Debugging a server event inside Pixel Helper is how you conclude the server is down when event_time had thirteen digits. A CAPI tester is the check on the JSON you are about to ship. HTTP 200 is not validation is why the status code is the wrong assert. Conversions API not working is the ticket this produces.

What the tester checks, and what it refuses to pretend

A conversion API validator checks required fields, types, timestamp units, hashed versus raw identifiers, action_source enums, event_source_url when the source is the web, and value plus currency on money events. Each finding has a stable id, a severity, a fix, and a link to the page the vendor published.

It does not prove the event attributed. It does not log into Events Manager. It does not mint a click id you never stored. It does not call the Graph API. A pass means the artifact matches the published envelope. Attribution is a later, slower UI. Use Pixel Helper for the browser pipe: event name, eventID, value, whether two base codes fired PageView. Use the validator on the JSON. Use Test Events only after the body already passed, and strip test_event_code before production. That field diverts the event into the test panel. Leaving it on a live POST is how a green QA panel hides a pipe that never trains.

The usual first body looks like this. It 200s. It should not ship.

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1770000000000,
    "action_source": "website",
    "user_data": { "em": "buyer@example.com" }
  }]
}

event_time is thirteen digits. Meta documents Unix seconds, ten digits, and a window of about seven days. A millisecond value lands far in the future. em is a raw address. Meta wants SHA-256 of a normalized email, and wants client_ip_address and client_user_agent in the clear. action_source is website with no event_source_url. Purchase has no custom_data.value and no custom_data.currency. The Meta Conversions API pack prints those as separate findings. A legal Purchase is event_name Purchase, a ten-digit event_time, the same event_id the pixel sent as eventID, event_source_url of the thank-you page, hashed email, plaintext IP and user-agent, and a numeric value with an ISO 4217 currency.

The clock and the enum are why one JSON cannot travel

Store one UTC instant. Convert at the edge. The field name is not a hint you can trust across companies.

Meta event_time and Pinterest event_time are Unix seconds, ten digits. Reddit CAPI v3 event_at is milliseconds, thirteen digits. LinkedIn conversionHappenedAt is milliseconds, inside about ninety days. A ten-digit clock on LinkedIn reads as 1970. GA4 timestamp_micros is about sixteen digits. TikTok's current Events API path wants seconds on event_time; the older pixel path still wants ISO 8601, and an epoch there is treated as arrival time. OpenAI Ads timestamp_ms is milliseconds. Date.now() is right for one of these and wrong for the others.

action_source is an enum per vendor, and there is no default you can omit and hope. Meta: website, app, phone_call, and the rest of that list. website requires event_source_url. Pinterest is web, not website. Snap is WEB. Reddit v3 is WEBSITE. Bare JSON has no host, so the Meta, Snap, and Pinterest packs tell each other apart by that field. A missing or misspelled action_source matches more than one pack, and each reports it. That is why a typo looks like three vendors yelling at once. Pin --rulepack so a Meta body does not collect Snap findings because the enum was omitted.

$ pixellint validate json @capi.json --rulepack vendor/meta-conversions-api
$ pixellint validate json @tiktok.json --rulepack vendor/tiktok-events-api
$ pixellint validate json @reddit.json --rulepack vendor/reddit-conversions-api

What to keep next to the worker

A legal Meta Purchase. A legal Meta Lead without a fake value. A Purchase that must fail because event_time has thirteen digits. A Purchase that must fail because em is raw. A production fixture that must not contain test_event_code. A staging fixture that must contain it. A TikTok CompletePayment with the clock that path documents. A Reddit v3 event with a thirteen-digit event_at and WEBSITE. A LinkedIn conversion with the URN and conversionHappenedAt in milliseconds.

Dashboards lag, and they graph the wrong name. Purchse still charts. It charts as a custom event. Absence in the UI is not a 404. Presence in the UI is not proof the payload matched the contract you intended. CI on the JSON is the fast signal. Events Manager is the slow one. When someone files "CAPI not working," the first reply is the redacted JSON and the linter output, not a token rotation.

In the playground, set the format to JSON and paste the body the worker posts. Deep-link with ?kind=json. Redact access tokens and raw emails first. A 64-character hex digest is fine to keep. Artifacts you test on pixellint.org may be stored. Local cargo install pixellint, npm install pixellint, and cargo install pixellint-mcp do not send the payload. Same rule ids in all three, so a finding in QA is the same ticket in CI.

I maintain Pixellint. It is independent of Meta, TikTok, Reddit, Segment, and PostHog. A worker or a model can emit a body that the vendor accepts. The package is the check on that body before you call the endpoint. Hashing is the other half of the same payload: which fields are digests, and which must stay plaintext.

DEV Community: Aleksander Sekowski

RMT Explained: How IAB Redefining Media Types Classifies OpenRTB Impressions

What RMT adds on top of OpenRTB

How classification is supposed to work on the wire

Where the mapping breaks in production

How you catch it before the classifier does

Where to go next

adagents.json vs ads.txt and schain: Four Files, Two Supply-Chain Questions

adagents.json: who may represent the publisher to an agent

ads.txt, sellers.json, and schain: who may sell and who touched this impression

Two stacks on one impression

How you catch it

Where to go next

VASTAdTagURI in a DAAST Wrapper Validates as XML. Audio Players Read DAASTAdTagURI.

Two envelopes, two redirect tags

What the linter flags

How you catch it before serve

Where to read the contract

ADJUST_DEAL_FLOOR on /imp/imp-1 Parses. ARTF Still Needs /imp/{id}/pmp/deals/{deal id}.

Intent and path are a matched pair

Why agents copy the wrong path

Margin is legal ARTF with no OpenRTB field

How you catch it

Where to go next

firstQuartile Under NonLinearAds Validates. CTV Portfolio Players Never Schedule It.

What the spec assigns to each container

The copy-paste failure mode

How you catch it before the flight

Where to go next

data:text/javascript in InteractiveCreativeFile Passes VAST 4.3. SIMID Still Loads HTML.

What VAST 4.3 changed, and what SIMID did not

What you see in production

How you catch it before the buy goes live

Where to go next

OpenProposal Ranks Briefs. The OpenRTB Bid Request Has No Proposal Handle.

Two stages, one wire format

Duration is the easy miss

validate_bid_request is not a brief checker

Where to read next

One purchase can create four different conversion numbers.

Start with the confirmed order.

Check the request and the identifier separately.

Send each ad platform its own purchase event.

Decide which Google Ads action should drive bidding.

Separate event receipt from attribution.

The URL in the tag manager is not the URL the browser fired.

Three states, and unknown is not a third product

What to paste, and what not to paste

CI wants two fixtures, not a weekly HAR

Hash the email. Do not hash the IP. Both mistakes still return 200.

Two allowlists, not one function

Normalize, then hash, then send

Reddit is the exception people copy backwards

Double hashing looks legal

Floodlight still needs src, type, and cat. A leftover ord=1 counts once.

ord=1 is a cache, not a counter

Consent on the path is still a TC String

Preview is not the published tag

Pixel Helper cannot see a Conversions API POST. A 200 is not the contract.

What the tester checks, and what it refuses to pretend

Other vendors document the same quiet drop

The clock and the enum are why one JSON cannot travel

What to keep next to the worker