Interface ReportingCapabilities

Supported reporting frequency options

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

Timezone for this product's reporting periods. Use 'UTC' or an IANA timezone (e.g., 'America/New_York'). This explicit reporting clock may equal Account.timezone or differ when the upstream platform reports on a separate boundary, so buyers MUST NOT infer it from Account.timezone. It is the reporting timezone for this product's delivery reporting: get_media_buy_delivery start_date, end_date, and daily_breakdown dates are calendar dates in it, and reporting_period boundaries and daily, weekly, or monthly windows fall on its calendar boundaries. Buyers MUST use this value for daily/monthly report alignment.

Whether this product supports webhook-based reporting notifications

Product-scoped subset of get_adcp_capabilities.media_buy.reporting_delivery.offerings[].offering_id that packages using this product can satisfy. This binds seller-wide managed-delivery offerings to product/package eligibility. An empty array explicitly declares no managed offering; absence means product-level applicability is unknown and MUST NOT be inferred from the seller-wide list. Account, seat, credential, or provider constraints may narrow support further during sync_accounts validation.

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. The vendor MAY resolve to the selling party's own brand.json — a seller MAY be its own measurement vendor (DOOH sensor networks, retail-media closed loops, walled gardens) provided it publishes the metric in an agents[type='measurement'] catalog like any other vendor and declares the relationship via vendor_relationship; the catalog contract is not relaxed for first-party measurement.

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

Whether this product supports canonical creative-format breakdowns in GET delivery reporting (by_format within by_package, keyed by format_kind). This is independent from supports_creative_breakdown because a seller may expose aggregate format-grain reporting without exposing individual creative performance.

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 this product supports property breakdowns in delivery reporting (by_property within by_package).

Whether this product supports collection breakdowns in delivery reporting (by_collection within by_package).

Whether this product supports installment breakdowns in delivery reporting (by_installment within by_package).

Whether this product supports collection × property intersection reporting (by_collection_property within by_package).

Whether this product supports installment × property intersection reporting (by_installment_property within by_package).

Whether this product supports placement × property intersection reporting (by_placement_property 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.