Commerce-facing requirements for the Content Telemetry standard.
Version: 0.1 Status: Draft Last updated: 2026-06-11 Constrains: Content Telemetry specification, version 0.1
- Scope
- Normative references
- Terms and definitions
- Relationship to the Content Telemetry standard
- Requirements
- Conformance assessment
- The OpenAttribution Commerce conformance mark
- Versioning
The Content Telemetry standard defines a wire format for reporting how AI agents use content. The format is permissive: an emitter producing well-formed events at any conformance level is conforming to the standard.
This profile is the commerce-facing layer. It applies to participants in agentic commerce: affiliate networks, marketplaces, brands, and destination sites that receive AI-driven traffic and want to attribute it to the content that produced it. It names a single accreditation tier, Compliant, and the requirements an implementer must meet to be assessed at it.
When an AI agent recommends a product, that recommendation was shaped by content the agent read: reviews, comparison guides, editorial recommendations. The agent retrieves that content, grounds it, cites some of it, displays some of it, and the user clicks through to a destination - or directs the agent to take them there. A single click is the end of a chain of sources, not a single referrer. This profile exists to keep that chain intact across the boundary between the agent and the landing page, so a destination can credit every source that informed the response, not only the one URL the user happened to click.
The mechanism is the standard's ctx_token (standard, section 7.1): an opaque click-token the agent issues, which crosses to the landing page in place of the session identifier, and which a telemetry consumer resolves to the originating session. This profile requires that propagation and the consumer-side resolution that makes it useful.
The standard and this profile are maintained separately. The standard defines the format; this profile defines the commerce-facing requirements layered on it. This profile adds requirements; it never modifies the wire format.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
This document specifies:
- the requirements an implementer must meet to be assessed as OpenAttribution Commerce Compliant
- how an implementer is assessed against those requirements
- the conditions for displaying the OpenAttribution Commerce conformance mark
This document does not specify:
- the telemetry wire format - event types, schema, conformance levels, transport (see the Content Telemetry specification, the normative reference in section 2)
- attribution algorithms, counting models, or commission logic
- content access, licensing, or pricing terms
- privacy policies or data protection requirements
- any operator's account model, API endpoints, or hosted infrastructure
| Reference | Description |
|---|---|
| Content Telemetry specification, version 0.1 | The telemetry wire format this profile constrains. https://github.com/SPUR-Coalition/telemetry |
| RFC 2119 | Key words for use in RFCs to indicate requirement levels |
| RFC 8174 | Ambiguity of uppercase vs lowercase in RFC 2119 key words |
This profile constrains a fixed version of the Content Telemetry specification. Where this document refers to "the standard", it means version 0.1 as cited above. Adoption of a later standard version is a deliberate revision of this profile (section 8).
The terms defined in the Content Telemetry specification section 3 apply. In addition, for the purposes of this document:
profile
document that layers community-specific requirements on a standard
Compliant
named tier of accreditation under this profile - meeting every requirement in section 5
accredited implementer
emitter or telemetry consumer assessed as meeting this profile's requirements
conformance mark
visual mark an OpenAttribution Commerce-accredited implementer may display to indicate Compliant status (section 7)
click-out
a user reaching a destination site, marketplace, or brand from an AI agent's response: following an outbound link (engagement_type: link_click) or directing the agent to open the destination on their behalf (engagement_type: agent_navigate)
ctx_token
opaque click-token issued by the originating agent and carried on a content_engaged event in place of session_id when the engagement crosses to a landing page (standard, section 7.1)
click manifest
the set of content_grounded, content_cited, and content_displayed events for the session resolved from a ctx_token - the citation chain behind a click (standard, section 7.1, ctx_token resolution)
multi-citation attribution
crediting every source in the click manifest for a click-out, rather than only the single clicked URL (section 5.6)
The standard defines the wire format. This profile selects from it and adds requirements specific to commerce.
This profile uses the standard's three economic actors (standard, section 4.1 Roles): the content owner (the editorial source whose reviews, guides, and recommendations shape the response), the intermediary (the marketplace, affiliate or ad network, or telemetry vendor that observes flows and resolves attribution), and the agent (the AI shopping assistant). A destination or brand in this profile is a content owner of its own landing content; where it also operates a network or marketplace it is additionally an intermediary, and the requirements that attach to each role apply to it in each capacity. As in the standard, emitter and telemetry consumer are functions, not actors: an affiliate network is an intermediary that is typically both.
The standard defines three conformance levels - Retrieval, Grounding, and Citation (standard, section 5.7) - a privacy mechanism with four levels (standard, section 5.5), the ctx_token click-out mechanism and its resolution (standard, section 7.1). The standard makes none of these mandatory for any relationship.
This profile builds on the standard's mechanisms without changing them. An implementer that meets this profile's requirements is, by construction, conforming to the standard. An implementer can conform to the standard without engaging with this profile at all.
The dependency runs one way - profile to standard, never the reverse. The standard can therefore be transferred to another steward without disturbing this profile: the profile updates its section 2 reference to the standard's new location and version. This profile names no operator, no hosted endpoint, and no operator-specific API. Every requirement is expressed against the standard's mechanisms, so a competing operator can implement and be assessed against this profile with no dependency on any single operator's infrastructure.
An implementer assessed as OpenAttribution Commerce Compliant MUST meet every requirement below that applies to its role: an emitter against sections 5.1 to 5.5; a party that performs attribution on click-outs against section 5.6; a telemetry consumer against section 5.7. Multi-citation attribution (section 5.6) is the requirement that distinguishes this profile.
The implementer MUST emit Content Telemetry documents that are valid under the standard. Where an implementer advertises a standard conformance level - Retrieval, Grounding, or Citation - it MUST satisfy that level's requirements. Conformance is verified against the standard's reference test suite where the advertised level is document-checkable (standard, section 5.7).
A destination site reporting click-out engagement events is a schema-valid engagement emitter, but does not qualify at Retrieval level unless it also emits the content_retrieved events Retrieval requires. An agent reporting retrieval, grounding, and citation qualifies at the Citation level; display and engagement events are optional lifecycle signals under the standard. Both can be Compliant under this profile where they meet the commerce requirements below.
Telemetry MUST be delivered at event granularity. Each fetched, grounded, cited, displayed, or engaged content piece is reported as a discrete event, with the fields the standard requires at the implementer's conformance level.
Aggregated reporting - summaries, counts, or rollups that collapse multiple events into a single record - does not satisfy this requirement. Aggregation, where useful, is performed by the receiving party on event-level input.
Within the scope of the relationship it reports under, the implementer MUST report every qualifying event it observes. Selective reporting - emitting events for some sessions or content while omitting others in the same scope - does not satisfy this requirement. A party MAY accept sampling in a specific agreement, as with delivery cadence in section 5.3. Completeness is assessed as an operational requirement (section 6).
The implementer MUST be capable of delivering telemetry in real time. Real-time means events are dispatched to the receiving endpoint as they occur, subject only to ordinary network and processing latency.
A commerce relationship MAY negotiate an alternative delivery cadence in a specific agreement. The standard supports both modes; this profile sets real time as the default and lets bilateral agreements vary it.
An implementer that observes a click-out from an AI agent's response to a landing page - typically an affiliate network, marketplace, or destination site - MUST report it as a content_engaged event carrying the event-level content_url of the destination (standard, section 6.7): engagement_type: link_click where the user followed a link, engagement_type: agent_navigate where the agent opened the destination at the user's direction. The two forms are the same boundary crossing and meet the same requirements in this profile.
This is the event that anchors commerce attribution: it records that a user acted on the agent's response. Reporting it is unconditional. Whether the citation chain behind it can be read is a separate, consent-gated matter (section 5.7.2).
On a content_engaged event with engagement_type: link_click or agent_navigate that crosses to a landing page after a click-out, the implementer MUST propagate the session linkage using the ctx_token mechanism (standard, section 7.1): the event carries a ctx_token issued by the originating agent in place of session_id.
The implementer MUST NOT carry the raw session_id across the agent-to-landing-page boundary. The ctx_token is opaque and resolvable only by a telemetry consumer, so the session identifier is not exposed to the destination or to any party observing the outbound link. An implementer that emits a cross-boundary click-out engagement with neither ctx_token nor a resolvable session linkage does not meet this requirement.
The point of this profile is that a click-out credits the whole citation chain, not only the clicked URL.
An implementer performing attribution on a click-out MUST be capable of crediting every source in the click manifest (section 3.7): the content_grounded, content_cited, and content_displayed events of the session resolved from the ctx_token. It MUST NOT restrict attribution to the single content_url carried on the click-out engagement event when the click manifest is available.
The click manifest is the set of those events for the resolved session; the implementer weights them under its own counting model. This profile does not mandate the algorithm - last-touch, linear, position-based, or any other model in the standard's section 10 is permitted - only that every source in the manifest is eligible for credit. A destination that resolves a ctx_token and credits only the clicked URL, discarding the other grounded and cited sources, is not Compliant.
Because this profile does not mandate weights, eligibility alone could be satisfied with a token share. The implementer MUST therefore disclose the weighting model it applies to click-manifest sources to the parties whose content is eligible for credit.
The manifest reflects only what privacy and consent permit (section 5.7.2). Sources withheld by privacy_level gating or by a missing consent opt-in are not in the manifest and cannot be credited; this is a property of the data the implementer receives, not a relaxation of this requirement.
Sections 5.1 to 5.5 govern emitters; section 5.6 governs any party that performs attribution on received events. A telemetry consumer - a party that receives telemetry and resolves ctx_tokens to click manifests (standard, section 7.3 and section 7.1) - is assessed against the requirements below. The multi-citation requirement in section 5.6 relies on them.
The consumer MUST meet the telemetry-consumer conformance rules of the Content Telemetry specification (standard, section 5.7.4): accept any session with a compatible schema version, tolerate unknown fields and events from any conformance level, and accept the session-document, standalone-event, and event-batch delivery formats, reconstructing sessions from standalone events and event batches where needed. The standard recommends that a consumer strip privacy-violating fields rather than reject the document carrying them (standard, section 5.7.5); this profile makes that stripping a requirement.
The consumer MUST support resolving a ctx_token to the click manifest of the originating session: the set of content_grounded, content_cited, and content_displayed events for that session (standard, section 7.1, ctx_token resolution).
The manifest the consumer returns:
- MUST be gated by the resolved session's
privacy_level(standard, section 5.5). Fields and sources not available at that level MUST NOT appear in the manifest. - MUST be gated by two-sided consent. The consumer MUST return the manifest only when the agent that issued the token has opted in to sharing sessions via click tokens; when the agent opt-in is absent, the consumer MUST NOT disclose the manifest. Within a returned manifest, a source MUST appear only when its content owner has opted in to being visible in click-token lookups; the consumer MUST withhold the events of any content owner whose opt-in is absent while returning the remainder of the manifest. The mechanism by which an agent and a content owner record these opt-ins is operator-defined; the consent gate itself is required.
A consumer that returns a clicked URL but cannot return the rest of the citation chain does not satisfy this requirement and cannot support the multi-citation attribution that section 5.6 requires of the parties it serves.
The consumer MUST resolve the owning content owner for each event and expose to a given party only the events that party is entitled to. A content owner's identifiable telemetry MUST NOT be disclosed to another party without that content owner's authorisation. This is the same isolation the standard relies on for multi-content-owner sessions (standard, section 7.3); resolving a ctx_token does not override it - the click manifest is itself gated by section 5.7.2.
Aggregate or anonymised reporting across a catalogue - benchmarks that do not reveal an individual content owner's content usage - is not restricted by this requirement.
An implementer is assessed as OpenAttribution Commerce Compliant when it meets every requirement in section 5 that applies to its role: an emitter against sections 5.1 to 5.5, a party that performs attribution on click-outs against section 5.6, a telemetry consumer against section 5.7. Assessment has two parts:
- Technical conformance - verified against the standard's reference test suite, for the conformance level an emitter advertises (5.1) or against the standard's telemetry-consumer rules for a consumer (5.7.1), plus the commerce-specific document checks in the
accreditation/suite: a cross-boundary click-out engagement (link_clickoragent_navigate) carries actx_tokenand not a rawsession_id(5.5), and a conforming commerce flow records the grounded, cited, and displayed sources that make a click manifest possible (5.6). An objective, repeatable check. - Operational requirements - event-level granularity, completeness, and real-time delivery (5.2, 5.3),
ctx_tokenresolution to a privacy- and consent-gated click manifest (5.7.2), multi-citation crediting of the manifest and disclosure of the weighting model (5.6), and content-owner resolution and isolation (5.7.3), verified by inspection of the implementer's pipeline and by attestation.
The accreditation/ directory holds example fixtures: telemetry documents that do and do not satisfy the document-checkable component of this profile. Operational requirements - cadence, completeness, the consent gate, the weighting model and its disclosure, and content-owner isolation - cannot be fixture-tested and are assessed separately.
Assessment is self-attested in this draft version. An independent audit programme is anticipated; the profile will be revised to require opt-in to it once available.
An OpenAttribution Commerce-accredited implementer may display the OpenAttribution Commerce conformance mark.
- The mark indicates the implementer is assessed as OpenAttribution Commerce Compliant.
- The mark refers to a specific version of this profile. An implementer reassessed against a later profile version updates the mark accordingly.
- OpenAttribution may withdraw the right to display the mark from an implementer that no longer meets the requirements.
The conformance mark is a trademark of OpenAttribution. Permission to display it is granted through accreditation and is separate from the Creative Commons Attribution-ShareAlike 4.0 International licence that covers this document. Consistent with section 2(b)(2) of that licence, the licence grants no right to use the OpenAttribution Commerce conformance mark or other OpenAttribution trademarks; that right is conveyed only through accreditation.
Mark artwork and detailed display rules are published separately by OpenAttribution.
This profile is versioned independently of the standard it constrains.
Draft and preview versions (0.x) may change the requirements as the accreditation programme develops. From 1.0 onward, a change that adds, removes, or materially alters a requirement is a major version change.
This profile constrains a fixed version of the standard (section 2). When the Content Telemetry standard publishes a new version, OpenAttribution decides whether this profile adopts it. Adoption is a deliberate revision: the section 2 reference changes, and the change is published as a new profile version. The standard advancing does not change this profile until the profile is revised to follow it.
If stewardship of the standard transfers to another body, this profile updates its section 2 reference to the standard's new name and location. The requirements are unaffected - they reference conformance levels, event semantics, and the ctx_token mechanism, which are properties of the format, not of its steward.