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:
- 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.
- 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:
- 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_).
- 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
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_tokensemantics 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-IDon content retrieval. Click-out has no equivalent guidance forctx_token.In practice, outbound links often pass through multiple hops before the final landing page, for example:
We observed no guidance at all on:
ctx_tokenon click-out URLs — neither a reserved query parameter name nor a format/pattern that lets any party find the token.Why it matters
Click-out attribution depends on
ctx_tokenbeing 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:
ctx_token— different agents will implement carriage differently — making attribution unreliableThis 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:
ctx_token) and a documented value format/pattern (e.g. values MUST start withctx_token_).ctx_tokenunchanged 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