Interface ReportingCapabilities

Supported reporting frequency options

Expected delay in minutes before reporting data becomes available (e.g., 240 for 4-hour delay)

Timezone for reporting periods. Use 'UTC' or IANA timezone (e.g., 'America/New_York'). Critical for daily/monthly frequency alignment.

Whether this product supports webhook-based reporting notifications

Metrics available in reporting. Impressions and spend are always implicitly included. When a creative format declares reported_metrics, buyers receive the intersection of these product-level metrics and the format's reported_metrics.

Vendor-defined metrics this product can report, beyond the closed available_metrics enum. Each entry is a pointer ({ vendor, metric_id }) into the vendor's metric catalog — the canonical definition (standard alignment, accreditations, methodology, unit, human-readable description) lives at the vendor's get_adcp_capabilities.measurement.metrics[], queried once per vendor when needed. Use this for proprietary metrics like attention scores, emissions, panel-based demographics, or platform-native social metrics not yet in the standard enum. Sellers populate values in delivery via delivery-metrics.json#/properties/vendor_metric_values. The metric is identified by the tuple (vendor, metric_id); identifiers are namespaced by the vendor, so the same metric_id may mean different things in different vendors' vocabularies. Semantic uniqueness key is (vendor.domain, vendor.brand_id, metric_id); sellers MUST de-duplicate before emission and MUST NOT declare the same vendor metric twice. Buyers MAY treat duplicate (vendor, metric_id) rows as a seller-side conformance bug. (JSON Schema uniqueItems is not used here because BrandRef carries optional fields whose absence/presence would defeat deep-equal — uniqueness is on the semantic key, enforced at build/validation time on the seller side.) Promotion path: when the industry converges on a metric via a published standard, the spec adds it to the closed available_metrics enum and the vendor extensions become historical aliases.

Whether this product supports creative-level metric breakdowns in delivery reporting (by_creative within by_package)

Whether this product supports keyword-level metric breakdowns in delivery reporting (by_keyword within by_package)

Whether this product supports device type breakdowns in delivery reporting (by_device_type within by_package)

Whether this product supports device platform breakdowns in delivery reporting (by_device_platform within by_package)

Whether this product supports audience segment breakdowns in delivery reporting (by_audience within by_package)

Whether this product supports placement breakdowns in delivery reporting (by_placement within by_package)

Whether delivery data can be filtered to arbitrary date ranges. 'date_range' means the platform supports start_date/end_date parameters. 'lifetime_only' means the platform returns campaign lifetime totals and date range parameters are not accepted.

Granularities at which this product honors per-window pulls on get_media_buy_delivery (via request time_granularity + include_window_breakdown: true). Closes the GET-side half of the snapshot/log two-paths-parity contract for data-bearing events: a buyer who missed a webhook fire at any granularity listed here can reconstruct an identical payload by polling. Capability-scoped MUST — sellers MUST honor pulls at any granularity declared here, and MUST return UNSUPPORTED_GRANULARITY for pulls outside the set. Sellers MAY emit higher-frequency webhooks than they expose for pull (common where the webhook is a Kafka tap and historical reads go through a warehouse with coarser granularity); buyers see the gap up front via this capability and treat the webhook as primary for those frequencies. Absent or empty means the product only supports cumulative date-range pulls and full per-window recovery via GET is unavailable — see snapshot-and-log Rule 4.

Measurement maturation stages available for this product. Used by any channel where billing-grade data is produced in phases rather than arriving final on day one. Examples: broadcast/linear TV (Live → C3 → C7 DVR accumulation), DOOH (tentative plays → post-IVT/fraud-check final), digital with IVT filtering (raw → GIVT filtered → SIVT filtered), podcast (7-day downloads → 30-day downloads). Each window defines an accumulation period and expected data availability. When present, delivery reports reference a specific window_id. Sellers whose data is final on first delivery typically omit this.