RFC: SSAI Manifest Shape — In-Document Tracker Placement and Stitcher Boundary

[bokelley]

Summary

Per the deferred follow-up in #3051, this RFC opens the SSAI manifest-shape question. SSAI services (Yospace, AWS Elemental MediaTailor, Google DAI, Harmonic, Akamai, Comcast TVE) rewrite VAST and stitch ad segments into the content manifest before the player ever sees an ad break. This changes which trackers can fire, who fires them, and what the buyer agent can rely on — all of which may (or may not) need expression in the AdCP creative manifest.

Strawman position: most of SSAI is a publisher / sales-agent infrastructure concern, not a creative-manifest concern. The creative agent should keep producing the same vast + vast_tracker + url assets defined in #3051; the sales agent hands its VAST to the SSAI service, which owns firing-side decisions. If that holds, the only manifest-level changes are (a) capability/discovery hints and (b) a SIVA verification asset type.

This RFC tests that strawman. Pushback welcome — particularly from anyone running production SSAI integrations.

Background

CSAI (client-side ad insertion): player fetches VAST, parses <TrackingEvents>, fires trackers itself. The model in #2915 / #3051 assumes this.

SSAI (server-side ad insertion): an intermediate service fetches VAST, downloads ad media, transcodes to match the content manifest's profile, and stitches ad segments into the HLS/DASH manifest. The player sees one continuous stream; ad breaks are signaled out-of-band (HLS EXT-X-DATERANGE, DASH EMSG, or vendor SDK callbacks).

Tracker firing under SSAI varies by vendor:

Vendor	Impression / Quartiles	Clickthrough	Interactivity	Verification
Yospace	Client-side (TrackingClient SDK parses EXT-X-DATERANGE/EMSG, fires from player)	Client-side	Client-side	OMID via SIVA
AWS Elemental MediaTailor	Server-side (default) — Client-Side Reporting API for opt-in override	Client-side	Client-side	SIVA only
Google Ad Manager DAI	Server-side (default) — IMA DAI SDK for client overrides	Client-side (IMA DAI)	Client-side	SIVA / OM SDK DAI
Comcast TVE / Harmonic / Akamai	Mostly server-side	Client-side	Vendor-specific	SIVA

Common thread: the SSAI vendor owns the firing-side decision per tracker, not the buyer or the creative agent. The buyer provides tracker URLs; the vendor picks the path.

Strawman: What AdCP Probably Does NOT Need

The following do not appear to require schema changes, on the strawman view:

• Per-tracker firing-side hint (server | client | either). The SSAI vendor overrides any hint based on its own deployment model; carrying it in AdCP would be informational at best and misleading at worst.
• A separate ssai_tracker asset type. The same vast_tracker event semantics apply; SSAI just changes who fires the URL, not what URL to fire or when.
• Manifest-shape signals for HLS/DASH stitching. That's between the SSAI service and the publisher's origin, not the buyer or creative agent.

What AdCP Probably DOES Need

1. Inventory-level SSAI capability declaration

A buyer agent needs to know whether inventory is SSAI-delivered before it commits, because:

• Interactive overlays (VPAID / OMID interactive) frequently break in SSAI environments.
• Device-graph identifiers (IFA, RIDA) are passed through inconsistently.
• Frequency capping and cross-publisher-cap mechanics differ when an SSAI service handles ad selection vs. proxying to a router.
• Verification options narrow to SIVA (server-side OMID).

Open Q: is this a format capability, a product field, or part of TMP CTV surface guidance? Closed issue #1770 ("TMP CTV: SSAI integration and surface-specific gaps") suggests the latter — but inventory-level discovery probably needs a signal too.

2. SIVA (Server-Side OMID) verification asset type

OMID verification under SSAI uses the SIVA spec. Resources still ship with vendor, resource_url, verification_parameters, api_framework — same shape as the deferred omid_verification asset type from #3051's roadmap — but the verification flow differs. Two options:

• Option A: single omid_verification asset type covers both CSAI and SSAI; the sales agent / SSAI service routes correctly based on inventory delivery mode.
• Option B: separate siva_verification asset type with explicit fields for SIVA-specific resources (e.g., server-side measurement endpoints).

Lean: Option A. The asset content is the same; only the runtime is different.

3. Pod-level vs. ad-level trackers (open question)

Some SSAI vendors emit pod-level beacons (slot impression, pod start, pod complete) that are not per-ad. These don't fit the current per-creative tracker model. Three responses:

• Punt: pod-level signals are publisher infrastructure, not buyer concerns. AdCP stays out.
• Surface them in the response: report-pod-level events back to the buyer via reporting / measurement APIs without touching the creative manifest.
• Carry pod-side trackers in the buy: add a pod-level tracker concept to media buy schema. (Big surface, probably overkill.)

Lean: punt or report, depending on what buyers actually ask for. Need input from buyer agent implementers.

What's Not in Scope For This RFC

• VAST wrapper / ad-tag chaining specifics — covered in feat(schema): add vast_tracker + daast_tracker asset types (#2915) #3051.
• Manifest manipulation (HLS/DASH stitching mechanics) — that's the SSAI service's job, downstream of AdCP.
• TMP CTV surface guidance — see TMP CTV: SSAI integration and surface-specific gaps #1770 (closed; addressed in cross-publisher-cap branch).
• omid_verification decomposition — separate follow-up from feat(schema): add vast_tracker + daast_tracker asset types (#2915) #3051.

Asks

1. Strawman test: is "most of SSAI is publisher infrastructure, AdCP barely changes" the right take, or am I underestimating what buyer agents need to express?
2. Inventory-level SSAI declaration: format capability, product field, or TMP CTV surface guidance — which is the right home?
3. SIVA: Option A (unified omid_verification) or Option B (separate siva_verification)?
4. Pod-level trackers: punt, report, or carry?

CC @coppertop18 (asked in #2915) — please weigh in if you have production SSAI experience.

Spec Files Potentially Affected

• core/format.json or core/product.json — SSAI capability declaration
• core/asset.json — omid_verification asset type (shared with feat(schema): add vast_tracker + daast_tracker asset types (#2915) #3051 follow-up)
• TMP CTV surface guide — SSAI-specific behavior notes
• Creative protocol docs — agent-boundary clarification: SSAI service is a downstream actor, not an AdCP-speaking agent

[bokelley]

Triage

Classification: RFC / proposal
Bucket(s): spec / protocol
Status: deferred

Blocked-on: #3051 — resurfaces on merge

#3051 is the open PR that explicitly deferred SSAI manifest shape to a follow-on RFC. The four design questions here (strawman validity, SSAI capability declaration home, SIVA Option A vs B, pod-level trackers) are well-formed but depend on the vast_tracker/daast_tracker foundation landing first. SSAI scope expansion would also materially delay #3051 review. Re-triage automatically after #3051 merges.

---

Triaged by Claude Code. Session: https://claude.ai/code/session_017GbkKP57Vv6Fr6zsqiu3aj

---

Generated by Claude Code

[coppertop18]

@bokelley My feedback is through the lens of ad verification measurement from my Moat days doing SSAI integrations. I agree with the strawman direction that AdCP should not try to model HLS/DASH stitching mechanics inside the creative manifest. In SSAI, those mechanics are downstream publisher / sales-agent / SSAI-service infrastructure. Where I'd push from a measurement and IVT/viewability integration perspective is that "SSAI barely changes AdCP" may be true for creative assembly, but not for buyer-agent expectations around measurement survivability. For SSAI integrations at Moat, the hard question was not only "can the tracker fire?" The hard question was whether Moat, as the measurement vendor, was receiving sufficient evidence to support viewability, verification, IVT detection, and reporting confidence. SSAI environments especially for CTV open the door to ad server spoofing, and we had to build specific detection for server-side versus client-initiated impressions and flag incongruous serving patterns. Our clients needed to know not just that measurement was running, but whether the SSAI path gave us enough signal to distinguish legitimate delivery from spoofed or degraded environments. SSAI changes who fires the tracker, whether client-side evidence exists, whether identifiers pass through consistently, whether verification code can execute, and whether quartiles/impressions are based on server-side beaconing, SDK callbacks, or player events. So I would keep the creative manifest mostly unchanged, but I do think AdCP needs machine-readable inventory/product-level SSAI measurement capabilities. Happy to go deeper on what those capabilities should look like if measurement is in scope for this RFC.

[bokelley]

100% agree - any help you can provide here would be awesome. I know so little about SSAI - if you want to drive this I would be thrilled!

[coppertop18]

Writing the spec scares me a little (maybe even a lot) not coming from the engineering side, but I am happy to partner with someone who can help translate my recommendations/requirements into the spec :)

[coppertop18]

I'd love to own the measurement capability requirements for this. If someone on the engineering side wants to partner on translating those into spec language, I'm ready to start. @bokelley can you connect me with whoever is closest to the core/product.json or core/asset.json schema work or is that you?

[coppertop18]

I will drive this with Claude by my side.

I've looked at the existing schema patterns — get_adcp_capabilities for seller-level declarations and get_products for product-level attributes. The SSAI measurement capability likely splits across both, which aligns with how AdCP already separates feature discovery from product detail. Here's a directional starting point.

Seller-level: get_adcp_capabilities

This is where a seller declares that SSAI is in play and what verification paths are available. Buyer agents need this before they even look at products.

{
  "media_buy": {
    "ssai": {
      "supported": true,
      "providers": ["aws_mediatailor", "yospace"],
      "verification": {
        "omid_supported": false,
        "siva_supported": true
      },
      "client_side_reporting_available": true
    }
  }
}

Product-level: get_products response

This is where the buyer agent learns what measurement actually survives for a specific product. Different products from the same seller could have different SSAI configurations — a CTV product might be SSAI with server-side firing while a display product from the same seller is CSAI with full client-side measurement.

{
  "product_id": "streamhaus_sports_ctv_q2",
  "name": "StreamHaus Sports Premium",
  "channels": ["ctv"],
  "delivery": {
    "ad_insertion": "ssai",
    "ssai_provider": "aws_mediatailor",
    "tracker_firing": {
      "impression": "server",
      "quartiles": "server",
      "clickthrough": "client",
      "verification": "siva"
    },
    "measurement_capabilities": {
      "viewability_supported": "limited",
      "ivt_detection_supported": true,
      "client_side_signals_available": false,
      "reporting_granularity": "ad_level"
    }
  },
  "pricing_options": [
    {
      "model": "cpm",
      "price": 28.50,
      "currency": "USD"
    }
  ]
}

Why the split matters

Field	Where it lives	Why
ssai.supported	get_adcp_capabilities	Buyer agent needs this before browsing products
ssai.providers	get_adcp_capabilities	Seller-level — vendors don't change per product
omid_supported / siva_supported	get_adcp_capabilities	Verification path is a seller infrastructure decision
client_side_reporting_available	get_adcp_capabilities	Seller-level SDK/reporting capability
ad_insertion	Product delivery	Can differ per product (CTV = SSAI, display = CSAI)
tracker_firing	Product delivery	Firing side can differ per product and event class
viewability_supported	Product measurement_capabilities	Measurement confidence varies by product delivery path
ivt_detection_supported	Product measurement_capabilities	Signal availability varies by product delivery path
client_side_signals_available	Product measurement_capabilities	Device/app context depends on product delivery path
reporting_granularity	Product measurement_capabilities	Some SSAI products report pod-level only, others ad-level

Not the final schema — but directionally, this follows the existing pattern of capabilities for seller-level discovery and product attributes for product-level detail.

I'll follow up with my positions on SIVA (Option A vs. B) and pod-level trackers once we're aligned on whether this shape is directionally right.

[bokelley]

got a sec for a quick slack chat? are you on AAO slack?

[bokelley]

Worth dropping a frame that's useful for SSAI specifically and for AdCP measurement generally. There are three distinct layers that often get conflated, and they have different protocol homes and different trust models:

1. Metrics — "did it happen?"

Delivery facts: impressions, completes, quartiles, clicks, spend, reach, frequency. Seller-attested, governed by industry counting conventions (MRC). Flows through standardized delivery reporting (get_media_buy_delivery). Stable, slow-changing.

2. Verification — "did it count properly?"

Quality attestation: viewability, IVT, brand safety, context fitness. The whole point is that it's not the seller's word — it requires third-party execution (OMID/VPAID historically; SIVA in SSAI). In AdCP this lives in two places:

• Capabilities — which verification paths the seller supports (OMID, SIVA, client-side SDK callbacks, server beacons only) and which signals survive per product. Seller-level via get_adcp_capabilities; product-level via product attributes. This is what @coppertop18's proposal is doing well.
• Creative manifest — the tracker/macro wiring per ad (vast_tracker / daast_tracker from feat(schema): add vast_tracker + daast_tracker asset types (#2915) #3051).

The verification result itself comes from outside AdCP (Moat/IAS/DV).

3. Attribution — "did it cause an outcome?"

Buyer-side join between delivery and outcomes: conversions, lift, MMM, incrementality. The seller doesn't know the conversion event. AdCP's role is enabling the handoff — log-level signals, identity hooks, clean-room and data-collaboration patterns — not running the model.

---

Why this matters for SSAI

SSAI doesn't change metrics — impressions still count and report the same way. It changes which verification paths are valid and whether the surviving signal is rich enough to distinguish legitimate delivery from spoofing. Attribution is mostly orthogonal, though signal degradation flows through.

That's why @coppertop18's split is directionally right: seller-level verification capabilities + product-level surviving-signal attributes, with the creative manifest itself mostly unchanged.

Why the layers evolve at different speeds (and need separate homes)

• Metrics — stable, MRC-governed, decade-scale change
• Verification — medium pace, environment-driven (CTV, SSAI, walled gardens, cookieless, AI-generated content)
• Attribution — fastest-moving (clean rooms, MMM revival, causal AI, commerce media, agentic outcome models)

Treating them as one bucket means every attribution innovation creates schema pressure on the delivery/verification surface. Keeping them separate lets each evolve on its own clock and against its own trust model.

Working rule of thumb

• If the seller is the source of truth → metrics
• If a third party is the source of truth, and the seller's job is to make their job possible → verification
• If the buyer is the source of truth, and the seller's job is to make the join possible → attribution

Worth turning into a docs/measurement/taxonomy.mdx so we have one place to point future RFCs at.