Skip to content

[spec] ctx_token transport and redirect-chain propagation for click-out #23

Description

@pedroamaralsantos

Specification section

7.1 (Delivery formats / ctx_token resolution), optionally 7.2 (Content-Telemetry-ID redirect chains as precedent)

What you observed

The specification defines ctx_token semantics and click-manifest resolution (§7.1), and the commerce profile requires propagation across the click-out boundary — but neither document defines how the token is carried on outbound click URLs or how it survives redirect and deeplink chains.

Section 7.2 provides explicit redirect guidance for Content-Telemetry-ID on content retrieval. Click-out has no equivalent guidance for ctx_token.

In practice, outbound links often pass through multiple hops before the final landing page, for example:

Agent → intermediary → tracker → advertiser landing

We observed no guidance at all on:

  1. How to carry or locate ctx_token on click-out URLs — neither a reserved query parameter name nor a format/pattern that lets any party find the token.
  2. Redirect-chain rules so every hop can capture — or at least forward — the token until the final destination.

Why it matters

Click-out attribution depends on ctx_token being available at conversion — via cookie, server-side store, etc — after being captured by the relevant party.

Without shared guidance, implementers have no common way to put the token on the link the agent shares, find it mid-chain, or know it must still be present when the user arrives at the destination.

If the token is not normatively carried and forwarded through redirect and deeplink chains, token loss will mirror ordinary tracking-parameter loss: intermediate hops drop or rewrite the URL, and the destination never receives the join key.

Without a reserved query parameter, a discoverable pattern, and propagation expectations:

  • Parties cannot reliably capture ctx_token — different agents will implement carriage differently — making attribution unreliable
  • Destination-side tags may never receive or/and find the token
  • Implementers will diverge on naming, placement, and whether to forward the token at all

This breaks the core click-out attribution model regardless of whether telemetry events are also delivered separately.

Proposed direction (optional)

Mirror §7.2 redirect-chain guidance for click-out transport:

  1. Carrying the token — define a conventional query parameter name (e.g. ctx_token) and a documented value format/pattern (e.g. values MUST start with ctx_token_).
  2. Propagation through the chain — when the URL shared by the agent is not the final destination and traffic goes through redirects, every participant in the chain SHOULD preserve ctx_token unchanged until the final destination, so all parties that need it can capture it. This cannot be fully enforced — some hops may not know about Open Attribution — but the expectation should still be defined in the specification so compliant parties know what to do and non-compliant drops are clearly out of spec.

Your perspective

None

Activity

  1. jalexspringer commented on Aug 12, 2026

    @jalexspringer
    Contributor

    Disposition: accepted narrowly for v1. A reserved query parameter, value pattern and SHOULD-level redirect-chain propagation, mirroring §7.2 — a transport and correlation convention that does not claim every intermediary preserved the value or enforce downstream behaviour. This lands in one click-context design change together with #28 and #30, including redirect, repeated-link and earlier-turn click fixtures. Open until that change merges.

  2. added
    v1-coreAccepted for the Content Telemetry v1 core specification
    and removed
    needs-discussionNeeds maintainer or working-group discussion before action
    on Aug 12, 2026
  3. jalexspringer commented on Aug 12, 2026

    @jalexspringer
    Contributor

    The click-context change is up as PR #38: one change covering token pattern and per-presentation binding, the reserved ctx_token/ctx_iss query parameters with redirect propagation, manifest-declared resolution (telemetry.ctx_resolution), and the resolution response specified as the engagement plus the clicked content's lineage by content identity across turns, with an optional count-based session summary. Review welcome there before the 21 August freeze.

  4. jalexspringer commented on Sep 2, 2026

    @jalexspringer
    Contributor

    Landed via PR #38 and published in v1.0 (sections 7.4.1 and 7.4.2). Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    v1-coreAccepted for the Content Telemetry v1 core specification

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions