docs(measurement): add three-layer taxonomy doc#3843
Merged
Conversation
… attribution) Frame for measurement-related RFC debates. Names the three layers, their sources of truth, their protocol homes, and their rates of change. Worked examples: SSAI, identity loss, AI-content provenance, outcome-based optimization. Linked from Reference nav alongside media-channel-taxonomy. Origin: #3759 (comment) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…nt-agent open question Adds two sections to docs/measurement/taxonomy.mdx: - Boundaries with Signals and Governance — names the lifecycle/question separation (pre-decision/predictive vs delivery/factual vs constraint/ normative), where lines are crisp, where they blur (one vendor, multiple roles), and why those overlaps reflect industry structure rather than protocol design errors. - Open question: where do measurement agents live? — frames the choice between status-quo distributed measurement, a first-class Measurement Protocol peer to Signals and Governance, and unification of all three under a shared third-party-agent meta-pattern. Lays out the cases for and against each rather than picking one. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
… not distributed
The first draft underdescribed the verification surface AdCP already
ships. Corrections:
- Section 2 (Verification) now documents the four-stage existing
lifecycle: Discovery (required_performance_standards, vendor_metrics,
committed_metrics_supported), Commitment (performance-standard.json
binding metric/threshold/standard/vendor with the tracker-asset MUST,
plus committed_metrics/committed_vendor_metrics frozen on the package),
Execution (manifest trackers, seller's choice of path), Reporting
(vendor_metric_values in delivery-metrics with measurable_impressions
coverage, missing_metrics for accountability).
- Removes the false claim that "the verification result lives outside
AdCP" — vendor-attested values flow back through vendor_metric_values.
The vendor's full dashboard is out-of-band; the attested numbers are
in-protocol.
- Removes the false claim that "no first-class measurement agent
concept" exists — brand.json agents[type='measurement'] is exactly
that. Measurement agents are discoverable BrandRef identities consumed
by performance-standard.vendor, vendor_metrics, vendor_metric_value,
and committed_vendor_metrics.
- Adds a worked end-to-end example: a buyer needing DV viewability at
MRC threshold on a CTV campaign with SSAI in scope. Walks through
discovery → commitment → execution → reporting and shows that the
buyer never asks "is this SSAI?" — the question they actually have
("can my chosen vendor measure here?") is answered structurally by
whether the product passes the filter. SSAI, CSAI, in-app, web, DOOH
all flow through the same surface.
- Replaces the open-question framing. Old version asked whether
measurement should become first-class; new version acknowledges it
already is and asks the narrower question: does the distributed
consumption pattern (cross-protocol BrandRef → brand.json measurement
agent) need to be promoted into a peer protocol surface, or is the
current shape right? Adds a second open question on pre-bid
measurement signals living in Signals while post-delivery measurement
lives in verification.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6 tasks
…rinal additions Three categories of changes from a corpus audit and the design conversation that produced #3848: Audit fixes (false claims in the original doc): - brand.json doesn't carry the metric catalog. brand.json is the BrandRef discovery anchor; the metric catalog (metric_id, standard_reference, accreditations[], unit, methodology_url, methodology_version) is served by the agent's get_adcp_capabilities response under the measurement block. Both the Verification section and the Open questions section reflect this now. - vendor_metric_values is not the universal vendor-attested path. Graduated standard metrics (viewability) flow through their dedicated delivery scalars in delivery-metrics.json; non-graduated vendor metrics flow through vendor_metric_values. Vendor attribution is anchored at the contract layer. - Stale references to committed_vendor_metrics removed (#3576 unified the surface; vendor entries now live in committed_metrics with scope: "vendor"). - missing_metrics fallback caveat added: when committed_metrics is absent, reconciliation falls back to the product's live available_metrics with no commitment-timestamp filter and under- reports gaps. Buyers SHOULD treat absence as 'no audit-grade contract' rather than 'clean delivery'. Doctrinal additions: - Graduated verification metrics — names a maturity gradient (Tier 1 graduated; Tier 2 vendor-extended; Tier 3 asserted) and identifies viewability as the canonical Tier 1 metric today. Articulates that the patterns supporting Tier 1 (qualifier slot, dedicated delivery scalar, performance-standard binding) are reusable templates, not viewability-specific bespoke shapes. - The atomic unit (metric_id, qualifier) — names the row-level symmetry across committed_metrics / missing_metrics (#3576, shipped) and metric_aggregates (#3848, proposed). Reconciliation collapses to a join on (metric_id, qualifier). Contract qualifier is closed; delivery qualifier is a deliberate superset for path-level transparency disclosures (e.g., tracker_firing). - Attribution-derived hybrid in available-metric.json — ROAS, CPA, conversions, conversion_value, units_sold are seller-reported but attribution-derived. Read as 'attribution surfaced through delivery,' not as pure delivery facts. Surfaces audit finding 3.1 without changing schema. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Reflects the audit fixes + graduated-metrics + atomic-unit doctrinal additions from the prior commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 2, 2026
Reconcile metric-type.json enum — collapses metrics / verification / attribution into one list
#3858
Closed
bokelley
added a commit
that referenced
this pull request
May 2, 2026
… rows (#3866) * feat(schemas): add vendor: BrandRef to viewability and performance-feedback rows Closes #3862 (delivery-metrics.viewability) and #3859 (performance-feedback). Both rows previously lacked structured vendor identity, breaking the BrandRef pattern used everywhere else in the verification surface (vendor_metric_values, performance-standard.vendor, committed_metrics vendor-scope entries). delivery-metrics.json viewability: - Optional vendor: BrandRef (RECOMMENDED). Makes the viewability row self-describing so buyer agents reading delivery in isolation can attribute the numbers without joining back to package.committed_metrics. Same shape as vendor_metric_value.vendor. performance-feedback.json: - Optional vendor: BrandRef. Required when feedback_source is third_party_measurement or verification_partner; described in the field rather than enforced via JSON Schema if/then, matching the precedent set by performance-standard.standard's "required when metric is viewability" pattern. Without it, third-party feedback rows are unattributed and consumers can't verify authorization, resolve metric definitions, or route disputes. Both fields additive and backwards-compatible. Origin: schema audit findings §3.4 and §3.9 (run during PR #3843 review). Aligns with the measurement taxonomy doctrinal framing that vendor-attested measurement is anchored on BrandRef → brand.json agents[type='measurement'] discoverable identities. Doc updates: provide_performance_feedback.mdx (vendor field row, example payload), optimization-reporting.mdx (viewability field list). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(schemas): soften performance-feedback.vendor requirement for blended outputs Per product review on PR #3866: the original "required when feedback_source is third_party_measurement or verification_partner" framing was too strict. MMM mixes (Nielsen MMM, Analytic Partners, in-house mix models combining multiple vendor inputs), multi-touch attribution that joins across vendors, and clean-room outputs (LiveRamp, Habu, AWS Clean Rooms where the clean room is not the measurement source) are exactly the highest-value third_party_measurement signals — and they don't have a single attesting vendor. A strict "required" reading forces junk values or blocks the feedback entirely. Softened to: SHOULD populate when feedback_source is third_party_measurement or verification_partner AND a single attesting vendor exists; OMIT for blended outputs and use the response's narrative payload to describe provenance. Updates schema description, doc table row (Conditional → No, with prose), and changeset language to reflect. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This was referenced May 2, 2026
feat(schemas): metric_aggregates partition — row-symmetric delivery aggregation (closes #3848)
#3876
Merged
Open
This was referenced May 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds docs/measurement/taxonomy — a three-layer model (metrics / verification / attribution) that names the layer for any measurement-related design discussion. Origin: framing posted on #3759, then expanded into meta-documentation usable across measurement RFCs.
What it argues
Measurement is three things, often conflated:
The doc:
required_performance_standardsandvendor_metrics, commitment viaperformance-standard.jsonwith vendor BrandRef + tracker-asset MUST + frozencommitted_metrics, execution via creative-manifest trackers, reporting viavendor_metric_values+missing_metrics)brand.jsonagents[type='measurement']Why now
The framing was useful enough on #3759 — partner-PM @coppertop18 used it to refine her SSAI proposal — that it earned a durable home. The doc is also what convinced me #3576 was confirmatory enough to merge (the conversation tested the contract surface against an experienced measurement-vendor PM's mental model, which is the validation that matters for protocol shape).
Files
docs/measurement/taxonomy.mdx(new)docs.json— adds the page to the Reference nav alongsidemedia-channel-taxonomy(both 3.0 and latest versions).changeset/measurement-taxonomy-doc.md— empty changeset (docs-only)Test plan
get_media_buy_delivery,provide_performance_feedback,optimization-reporting,creative-manifests,get_products,create_media_buy,get_adcp_capabilities,sync_event_sources,log_event,conversion-tracking,trusted-match,provenance-verification,signals/overview,governance/overview)Related
🤖 Generated with Claude Code