Tracker firing path (client / server / mixed) — is this a buyer concern AdCP needs to model, and where?

[bokelley]

Summary

A buyer agent may want to mandate client-side or server-side tracker firing on a campaign — e.g., a brand-safety-sensitive CTV buy where the brand standard requires client-side measurement. AdCP today doesn't have a discoverable way to declare this property or filter products on it.

This issue holds two distinct questions and asks WG to weigh in on both:

1. Is this a real, recurring buyer requirement?
2. If yes, where does the declaration live?

Origin

Surfaced in #3759 by @coppertop18, who proposed an execution_context enum on the verification asset spanning capabilities, products, and creative manifest. The measurement taxonomy argues verification is outcome-based — buyer commits vendor + threshold + standard via performance_standard, seller is accountable for delivering, path is plumbing — so per-asset execution_context doesn't earn its protocol surface. But @coppertop18 also surfaced a discovery-filter use case the outcome-based contract doesn't cover:

"Do I wanna mandate client-side measurement only, or server-side measurement only? 'Cause that just means I'm not gonna buy certain properties, most likely." — @coppertop18

That use case is the question this issue asks.

Q1: Is it a real business requirement?

Cases where it would matter:

• Brand mandate. Some brand standards require client-side measurement (regulated verticals, certain ad formats, legal/compliance overlays). Buyer needs to filter products before commit.
• Buyer's own attribution pixels. Server-side firing means the buyer's pixel sees the SSAI service's IP/UA, not the user's device — buyers doing first-party identity ops lose that signal.
• Audit transparency. Knowing the delivered path-mix helps buyers learn — paired with the delivery-time partition follow-up.

Cases where it doesn't:

• Outcome-based verification (most cases). The buyer commits to "70% MRC viewability by DV"; the seller is accountable regardless of path. Vendor confidence varies by path — that's the vendor's job to disclose and the buyer's contract with the vendor to govern.

The discovery-filter case is the strongest. WG sense-check welcome: how often does a real brand standard require client-side-only? Recurring v3.x concern or rare enough to defer?

Q2: If yes, where does it go?

Option A — Product-level delivery property

"delivery": { "tracker_firing": "client" | "server" | "mixed" }

One dimension, channel-neutral, discoverable at get_products, clean filter primitive.

Pros: simple, channel-neutral. Cons: coarse — a single product may have heterogeneous firing per event (VAST impression server-side, click client-side).

Option B — Per-tracker on the creative manifest (extends #3051)

{ "event": "impression", "url": "...", "fires": "server" }

Pros: granular truth, lives where trackers live, natural extension of #3051. Cons: doesn't solve discovery — buyers can't filter at get_products without resolving every manifest.

Option C — Both: product summary + per-tracker truth

Product-level delivery.tracker_firing summary (computed by seller) + per-tracker detail in #3051's tracker schema. Buyers filter on the summary; audit and breakdown use the per-tracker truth.

Pros: matches existing capability-summary → contract → manifest-detail pattern. Cons: two surfaces to keep in sync.

Option D — Capability-level (get_adcp_capabilities)

Cons: too coarse — same seller usually has products with materially different paths.

Strawman

If Q1 = yes, Option C matches existing AdCP patterns best. But the prior question is whether the discovery-filter use case is recurring enough to justify the surface.

Out of scope

• Modeling vendor confidence by path — that lives on the vendor's brand.json agents[type='measurement'] record, not in seller-published declarations.
• Delivery-time breakdown by tracker firing mode — separate follow-up issue building on Add standard-keyed viewability rollup to aggregated_totals on get_media_buy_delivery #3631.

Related

• RFC: SSAI Manifest Shape — In-Document Tracker Placement and Stitcher Boundary #3759 — origin (SSAI verification RFC)
• feat(schemas): unify metric accountability — timestamped contract + symmetric audit #3576 — contract-layer metric accountability
• Add standard-keyed viewability rollup to aggregated_totals on get_media_buy_delivery #3631 — viewability_by_standard partition
• docs/measurement/taxonomy

[coppertop18]

For Q1, unless we have verification vendors, agency, or brands on the WG, I am not sure we can effectively answer how often a real brand standard requires client-side-only validation. At Moat, we saw regulated verticals and certain holdcos where require that verification vendors execute client-side. It wasn't a published industry standard and it only showed up in RFP requirements and insertion order terms. If I were making the call, Q1 answer is yes, AdCP should model this. It's a recurring pre-commit filter for a meaningful segment of buyers, and there's no clean way to handle it out of band without forcing buyers to call sellers and ask. With Q1=Yes, my choice for Q2 is Option C. Here's why:

Option A is essentially what I originally proposed for product schema. Per @bokelley, it's coarse because a single product can have different firing per event type (impression server-side, click client-side).
Option B is granular truth but doesn't solve discovery. You can't filter products before committing.
Option D is too coarse, which is what I said in my original schema proposal when I split seller-level from product-level.

Option C is @bokelley's strawman and it matches my earlier instinct to split across capability discovery and product detail. Product-level summary for the buyer to filter, per-tracker detail for audit and verification. Yes, we will have two surfaces to sync, but the alternative is resolving every manifest before filtering and that doesn't scale. WRT coarseness, the compliance mandate is usually about the verification path, not every tracker. "Can my verification vendor run client-side" and not "does every quartile beacon fire client-side." So the product summary could scope to verification firing path specifically, which reduces the coarseness concern.

[bokelley]

Concrete evidence for Q1 (is this a real, recurring buyer requirement) and a refinement on Q2 (where it goes), surfaced from analysis of ChatGPT's ad-serving and attribution architecture:

ChatGPT's tracker firing is genuinely mixed-mode per event:

• Impressions: server-side. OpenAI's backend injects single_advertiser_ad_unit objects directly into the SSE conversation stream and counts them server-side.
• Click navigation: server-observed. Click opens in OpenAI's in-app webview (open_externally: false), so OpenAI sees the post-click navigation server-side until the user closes the webview.
• Conversion attribution: client-side. The oaiq.min.js SDK runs on the merchant's property and POSTs events to bzr.openai.com/v1/sdk/events.

What this means for this issue:

A binary product-level tracker_firing: "client" | "server" | "mixed" flag (Option A in the original issue) can't express ChatGPT's reality. Even Option C (product summary + per-tracker truth) gets clumsy because the same product fires impressions server-side, clicks server-observed, and conversions client-side. There's no single product-level summary that's honest.

If this issue moves forward, Q2's right answer is per-event firing path, not per-product. Something like:

"delivery": {
  "tracker_firing": {
    "impression": "server",
    "click": "server",
    "conversion": "client"
  }
}

Or it lives on the per-tracker entry in #3051's vast_tracker / daast_tracker work, with the buyer aggregating across events when filtering.

Q1 evidence: ChatGPT is a real, growing channel. The mixed-mode pattern isn't an edge case — it's the pattern for AI-native channels broadly (the seller controls the ad serving and click navigation, but conversion attribution flows through buyer-deployed SDK on merchant property). Walmart Connect's pattern is similar in shape (server-side ad serving on Walmart, server-observed click on Walmart, client-side or back-end conversion at checkout). Brands setting "no server-side measurement" mandates would specifically be ruling out these channels. That's a real buyer-policy lever — not a hypothetical use case.

Recommendation: if/when Q1 resolves yes, the answer to Q2 is per-event mode (not per-product mode). The two examples that justify it (ChatGPT, Walmart Connect closed loop) are also the two channels that demonstrate the seller-as-measurement-agent topology now documented in the taxonomy doc.

Related: #3889 (seller-deployed merchant SDK pattern — the OAIQ-on-merchant case captures the conversion-side firing detail this issue's per-event mode would pair with).

[coppertop18]

I concede that Option C is too coarse given the evidence that "mixed" is going to be the answer for most emerging channels, which makes the field meaningless as a filter. Per-event firing path makes more sense. The buyer's compliance filter is usually about one specific event class as in "can my verification vendor execute client-side for impression measurement" and not "is the whole product client-side." A per-event structure lets the buyer filter on the event they care about without the product-level summary losing all signal. Whether that lives on the product delivery object or on per-tracker entries in #3051 depends on whether it needs to solve discovery (pre-commit filtering) or just audit (post-commit truth). If discovery, it needs to be on the product delivery object. If audit only, per-tracker in #3051 is cleaner.