spec(creative): model inline display tags and paired internal redirects

[bokelley]

Problem

The AdCP 3.2 display_tag canonical says it covers JavaScript, iframe, and
1x1-redirect delivery, but its default contract has only one required
tag_url URL asset. That is not enough to represent common advertiser-ad-server
exports faithfully:

• CM360 iframe/JavaScript and JavaScript placement tags are inline markup, not a
  single tag URL.
• A CM360 Internal Redirect is an atomic pair: an image/ad-request URL and a
  click-through URL, entered separately in Google Ad Manager. Treating the
  image URL as HTML or separating the pair loses the trafficking contract.
• url-asset-type.json has clickthrough, tracker_pixel, and tracker_script, but
  no invocation mechanism for a display ad request. Meanwhile the canonical
  text asks for a tag URL with an "appropriate url_type" that does not exist.

This makes a conformant implementation choose among incorrect representations:
label inline third-party markup as hosted html5, squeeze a paired redirect
into one URL, or use an undefined extension.

References:

• display_tag.json
• url-asset.json
• CM360 placement tags: iframe/JavaScript and Internal Redirect

Proposed direction

Keep the portable canonical format_kind: "display_tag". Do not add a
Google-specific canonical kind. Extend the display-tag contract with explicit,
discriminated delivery variants:

1. tag_url — the existing single-URL contract.
2. inline_markup — inline iframe/JavaScript/standard tag markup, represented
   by an appropriate typed asset rather than pretending it is a hosted HTML5
   bundle.
3. paired_redirect — an atomic ad_request_url + clickthrough_url contract.

A GAM seller can then publish a publisher-scoped format option such as
format_option_id: "gam_internal_redirect" under format_kind: "display_tag", with the paired variant required. Other sellers can expose only
the variants they actually traffic.

The WG should decide whether ad_request_url is:

• a new generic URL invocation type; or
• a dedicated display-redirect asset that owns the pair atomically.

The latter is safer if separate URL slots could be mixed across rows or
creative revisions.

Required semantics

• A paired redirect is one creative representation; its URLs cannot be matched
  independently.
• The format option declares which delivery variants it accepts.
• Dimensions remain format/placement constraints and can be declared for every
  variant.
• Macro tokens remain byte-preserved until the declared resolver owns
  substitution; this issue does not define the macro vocabulary.
• html5 remains reserved for seller-hosted HTML5 bundles, not arbitrary
  third-party tag snippets.

Acceptance criteria

• display_tag can represent URL, inline-markup, and paired-redirect
  delivery without vendor-specific canonical kinds.
• The paired form requires both ad-request and click-through URLs and keeps
  them atomic.
• supported_tag_types (or its replacement) distinguishes all supported
  variants and includes Internal Redirect semantics.
• Positive examples cover CM360 iframe/JavaScript and GAM Internal
  Redirect.
• Negative vectors reject half-present pairs and HTML5 misclassification.
• SDK types, generated schemas, docs, and conformance fixtures agree.

Compatibility

Additive if the existing tag_url representation remains valid. Sellers that
do not advertise the new variants continue unchanged.

[bokelley]

Triage

Classification: Feature request — normative spec extension (RFC)
Bucket(s): spec / protocol, creative
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: Problem confirmed — url-asset-type.json has no ad-invocation type; display_tag.json's "appropriate url_type" reference is a dangling pointer. Option B (dedicated paired asset schema) required to enforce atomicity at the schema layer. supported_tag_types needs scope annotation and a supported_delivery_variants sibling field.
• adtech-product-expert: CM360 inline markup is a genuine daily-traffic gap; GAM Internal Redirect is real but narrower and risks enshrining a GAM UI idiom in the spec. Recommends shipping inline_markup in 3.2, deferring paired_redirect to 3.3 pending a production AdCP implementation. Flags maxLength needed on inline_markup to prevent misuse as an html5 substitute.
• ad-tech-protocol-expert-deep (RFC advisor): Option B confirmed by VAST/DAAST precedent — co-required URLs in those standards are structurally nested, not sibling fields with prose-enforced co-presence rules. A dedicated display_redirect compound asset schema enforces atomicity; Option A (ad_request_url as a new url_type enum value) cannot. card-asset in core/assets/ establishes the AdCP precedent for this pattern.

My take: The problem is unambiguous — the current schema cannot represent CM360 inline markup or GAM Internal Redirect without misclassifying or losing the trafficking contract. All experts agree Option B is the right call for the paired case; two WG decisions remain open before this lands.

---

Decision 1 — paired_redirect timing: 3.2 or 3.3?

Product expert recommends deferring: no production AdCP implementation of GAM Internal Redirect exists yet; naming tied to a GAM UI concept rather than the delivery mechanism. Protocol experts confirm the change is additive non-breaking on main but do not weigh in on timing.

Option A — ship inline_markup + paired_redirect together in 3.2:

// Creative manifest — GAM Internal Redirect (paired_redirect slot)
{
  "paired_redirect": {
    "asset_type": "display_redirect",
    "ad_request_url": "https://ad.pinnacle-media.example/gampad/ads?iu=/1234/nova",
    "clickthrough_url": "https://nova-brand.example/landing"
  }
}

Full trafficking fidelity for GAM Internal Redirect publishers in 3.2. Risk: no production validation before ratification; may want to rename (invocation_redirect) before locking the field.

Option B — ship inline_markup alone in 3.2, defer paired_redirect to 3.3:

+ "supported_delivery_variants": ["tag_url", "inline_markup"],
+ // normative note: supported_tag_types constrains the tag_url slot only
  "supported_tag_types": ["iframe", "javascript"]

Unblocks CM360 inline-tag adopters immediately; paired_redirect waits for a production reference implementation and a naming decision (paired_redirect vs invocation_redirect).

@bokelley — your call on timing. The schema design (Option B asset shape) is settled.

---

Decision 2 — supported_tag_types coupling (must resolve before merge, non-blocking on the above)

All experts agree: add supported_delivery_variants at the format-declaration level as the delivery-variant discriminator; add a normative note scoping supported_tag_types to the tag_url slot only; treat supported_tag_types soft-deprecation as a separate RFC decision so this change stays additive.

---

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

---

Generated by Claude Code