Skip to main content
Retrieve comprehensive delivery metrics and performance data for media buy reporting. Response Time: ~60 seconds (reporting query)

Scope

get_media_buy_delivery works on any media_buy_id returned by get_media_buys, regardless of how the underlying campaign was created. Sales agents MUST NOT refuse delivery reporting — or narrow its coverage — on the basis that the buy originated outside AdCP. If delivery data for a buy is genuinely unavailable (e.g., the ad server has not yet reported a flight), the seller returns the buy in media_buy_deliveries with zero or partial metrics; the seller does not omit it and does not return MEDIA_BUY_NOT_FOUND for an account-owned buy. Request Schema: /schemas/3.0.19/media-buy/get-media-buy-delivery-request.json Response Schema: /schemas/3.0.19/media-buy/get-media-buy-delivery-response.json

Request Parameters

Date Range Behavior: The date range is start-inclusive, end-exclusive. For example, start_date: "2026-01-01" and end_date: "2026-01-02" returns delivery data for January 1st only (from 2026-01-01 00:00:00 up to, but not including, 2026-01-02 00:00:00). To get a full week of data (Jan 1-7), use end_date: "2026-01-08".
Date Range Examples: *media_buy_ids filters results to specific media buys. If neither provided, returns all media buys in current session context.

Response

Returns delivery report with aggregated totals and per-media-buy breakdowns:

Media Buy Delivery Object

See schema for complete field list.

Billing-grade vs best-effort numbers

Unless the seller explicitly declares otherwise, get_media_buy_delivery returns best-effort numbers: real-time or near-real-time telemetry, subject to revision as counts settle, not an invoicing source of truth. Callers that use these numbers for client reporting or pacing decisions are safe; callers that use them for reconciliation, accruals, or finance close are not. Sellers MAY declare a finalization window in their capabilities (e.g., delivery_reporting.finalization_window_hours) and, once that window has elapsed for a reporting period, treat the numbers returned for that period as authoritative for billing — stable across subsequent calls, suitable for invoice reconciliation, and liable as the source of truth in a dispute. Callers MUST NOT assume finalization in the absence of such a declaration. When a buyer’s independent measurement disagrees with these numbers, reconciliation happens out-of-band through the commercial relationship between counterparties, backed by the audit trail on both sides. AdCP 3.0 does not specify a structured dispute task.

Common Scenarios

Single Media Buy

Multiple Media Buys

Date Range Reporting

Multi-Status Query

Buyer Reference Query

Account-Scoped Query

Metrics Definitions

Query Behavior

Context-Based Queries

  • If no media_buy_ids provided, returns all media buys from current session context
  • Context established by previous operations (e.g., create_media_buy)

Status Filtering

  • Defaults to ["active"] if not specified
  • Can be single string ("active") or array (["active", "paused"])
  • Valid filter values are media-buy lifecycle statuses: pending_creatives, pending_start, active, paused, completed
  • reporting_delayed and failed are delivery/reporting statuses returned in webhook contexts, not request filter values
  • Some legacy integrations may emit pending; treat it as equivalent to pending_start

Date Ranges

  • If dates not specified, returns campaign lifetime delivery data
  • Both start_date and end_date must be provided together — partial date ranges are invalid
  • Date format: YYYY-MM-DD
  • Start-inclusive, end-exclusive: start_date is included, end_date is excluded. For example, start_date: "2026-01-01" and end_date: "2026-01-02" returns data for January 1st only.
  • Products declare date range support in reporting_capabilities.date_range_support
  • Products with date_range_support: "lifetime_only" reject requests that include start_date/end_date with a DATE_RANGE_NOT_SUPPORTED error
  • Products with date_range_support: "date_range" accept date parameters and filter delivery data accordingly
  • Daily breakdown may be truncated for long date ranges to reduce response size

Metric Availability

  • Universal: Impressions, spend (available on all platforms)
  • Format-dependent: Clicks, completed_views, completion_rate (depends on inventory type and platform capabilities)
  • Audience: Reach, frequency (available on platforms with deduplicated measurement)
  • Commerce attribution: Conversions, conversion_value, roas, new_to_brand_rate (available on commerce media and streaming platforms)
  • Engagement: Follows, saves, engagements, profile_visits (available on social and streaming platforms)
  • Attribution window: attribution_window describes the lookback windows and model used for conversion attribution (e.g., 14-day click, 1-day view, last_touch)
  • Package-level: All metrics broken down by package with pacing_index

Data Freshness

  • Reporting data typically has 2-4 hour delay
  • Real-time impression counts not available
  • Use for periodic reporting and optimization decisions, not live monitoring
Phased-maturation channels: Data freshness differs for channels where billing-grade data is produced in phases rather than arriving final on day one — broadcast TV (Live → C3 → C7 DVR accumulation, final C7 ~15–22 days after broadcast), DOOH (tentative plays → post-IVT/fraud-check final), digital with IVT filtering (raw → post-GIVT → post-SIVT), and podcast (7-day → 30-day downloads). Products with reporting_capabilities.measurement_windows declare these timelines. Buyers reconcile against the measurement_window specified in billing_measurement on the agreed terms. See Accountability for measurement terms and Optimization and reporting for the full lifecycle.

Error Handling

Package-Level Metrics

The by_package array provides per-package delivery details with these key fields: Buyer Control:
  • paused: Whether the package is currently paused by the buyer (true/false)
System State:
  • delivery_status: System-reported operational state:
    • delivering - Package is actively delivering impressions
    • completed - Package finished successfully
    • budget_exhausted - Package ran out of budget
    • flight_ended - Package reached its end date
    • goal_met - Package achieved its impression/conversion goal
Performance:
  • pacing_index: Delivery pace (1.0 = on track, below 1.0 = behind, above 1.0 = ahead)
  • rate: Effective pricing rate (e.g., CPM)
  • pricing_model: How the package is billed (cpm, cpcv, cpp, etc.)
Key Distinction: paused reflects buyer control, while delivery_status reflects system reality. A package can be not paused but have delivery_status: "budget_exhausted".

Creative-Level Metrics

When the seller supports creative-level reporting (supports_creative_breakdown in reporting capabilities), each package includes a by_creative array with per-creative delivery metrics. Each creative entry includes:
  • creative_id: Creative identifier matching the creative assignment
  • weight: Delivery weight for this creative during the reporting period (0-100)
  • All standard delivery metrics (impressions, spend, clicks, ctr, etc.)
For deeper creative analytics including variant-level delivery data (asset combination optimization, generative creative), use get_creative_delivery. This is a Creative Protocol task — call it on any agent that implements the Creative Protocol, which may be the same sales agent if it declares "creative" in supported_protocols. See Creative capabilities on sales agents.

Catalog-item reporting

For catalog-driven packages (packages with a catalog field), the seller can return per-catalog-item delivery in the by_catalog_item array within each package. Each entry identifies the catalog item and includes standard delivery metrics: This is optional. Sellers that support item-level reporting populate by_catalog_item; sellers that do not simply omit it.

Dimension Breakdowns

When you include reporting_dimensions in the request, the response includes dimensional breakdown arrays within each by_package entry. Each breakdown entry inherits all fields from delivery-metrics plus dimension-specific identifiers.

Requesting breakdowns

test=false
Each dimension accepts optional limit (max rows; defaults to 25 for geo, audience, and placement) and sort_by (any value from the sort-metric enum, e.g., spend, impressions, clicks, roas — defaults to spend descending; falls back to spend if the seller does not report the requested metric). Geo requires geo_level (country, region, metro, postal_area) and system for metro/postal levels. Each request uses a single geo_level — for multiple granularities (e.g., country and region), make separate requests. Unsupported dimensions are silently omitted from the response, but malformed requests (e.g., geo without geo_level) return a validation error. Breakdowns are per-dimension only — cross-dimensional intersections (e.g., device_type × geo) are not supported.

Available dimensions

Check reporting_capabilities on the product to discover which dimensions are available. Product-level capabilities are authoritative since different products from the same seller may support different breakdowns.

Truncation

Each breakdown array has a sibling boolean flag (e.g., by_geo_truncated). When true, additional rows exist beyond the returned set. When false, the list is complete. Sellers MUST return the truncated flag whenever the corresponding breakdown array is present. Rows are sorted by the requested sort_by metric descending.

Audience sources

The audience_source field indicates where the audience segment originated:

Best Practices

1. Check Date Range Support Before requesting date-filtered delivery, check reporting_capabilities.date_range_support on the product. Products with lifetime_only support reject date range requests — omit start_date and end_date to get campaign lifetime data instead. 2. Use Date Ranges for Analysis For products that support date ranges, specify dates for period-over-period comparisons and trend analysis. 3. Monitor Pacing Index Aim for 0.95-1.05 pacing index. Values outside this range indicate delivery issues. 4. Check Daily Breakdown Identify delivery patterns and weekend/weekday performance differences. 5. Compare Package Performance Use by_package breakdowns to identify best-performing inventory. Check both paused state and delivery_status to understand why packages aren’t delivering. 6. Track Status Changes Use multi-status queries to understand why campaigns were paused or completed.

Post-Delivery Governance Validation

Delivery reporting is not the final step. When campaign governance is active, delivery data feeds into governance validation to detect unauthorized supply paths, geo drift, and pacing violations. The governance feedback loop:
  1. Pull delivery data via get_media_buy_delivery
  2. Report outcomes to the governance agent via report_plan_outcome
  3. The governance agent compares actual delivery against planned parameters (drift detection)
  4. Validate property delivery via validate_property_delivery to catch unauthorized supply paths
Without this feedback loop, delivery data is reported but never validated. Budget overruns, pacing divergence, geo drift, and unauthorized supply paths go undetected.

Next Steps

After retrieving delivery data:
  1. Optimize Campaigns: Use update_media_buy to adjust budgets, pacing, or targeting
  2. Provide Feedback: Use provide_performance_feedback to share results with seller
  3. Update Creatives: Use sync_creatives to refresh underperforming assets
  4. Create Follow-Up Campaigns: Use create_media_buy based on insights

Learn More