Skip to main content
Goal progress shows whether a campaign is meeting the goals it booked. It is an assessment from the latest seller delivery data and campaign facts Apostra has processed. It does not calculate a new answer while you read it. For a compact delivery snapshot, see Campaign pulse. Ask for the progress include on a campaign or media buy:
On a campaign, goalProgress contains the campaign’s own goals, its media-buy goals, and each package’s delivery goal. On a media buy, it contains that buy’s goals and its packages’ delivery goals. The entries keep the exact scope in scope.

​
Read a goal

Each goalProgress entry describes one stored goal assessment. For an optimization entry, goal is the campaign or media buy’s native AdCP optimization_goal, including its snake_case field names such as event_sources, event_source_id, and metric_id. askedTarget and answeredTarget are the target values the assessment compares; actual and basis are Apostra’s calculated evidence for that comparison. Within a delivery entry, values are null when the seller has not supplied enough compatible data for that measure. For example, Apostra does not combine spend that sellers reported in different currencies. An on-pace result means the projected finish is within 2% of the binding constraint, or within the projection’s measured uncertainty range, whichever is larger. In get_delivery, each campaign and media buy on the page has a deliveryGoal block, even before a stored delivery assessment exists. Its expected and pacingIndex cover the dates you asked for. The projected finish and end state come from the latest stored evaluation, so they match the goal progress returned by campaign and media-buy reads. When the sweep has not yet stored a delivery assessment, deliveryGoal.verdict is null and deliveryGoal.verdictWithheld is awaiting_confirmation. That is a normal pending state, not zero delivery. The goal-progress sweep starts a bounded refresh pass every 15 seconds. A candidate verdict must agree across two consecutive evaluations before Apostra publishes it. Use verdictWithheld to understand what it means and what to do next:
  • no_budget_or_booked_impressions: the delivery goal has neither a spend budget nor booked impressions. Add a spend budget or booked-impression goal.
  • no_flight: the delivery goal has no usable start or end date. Correct the flight dates.
  • data_through_before_flight: available delivery data ends before the flight begins. Wait for in-flight delivery reporting, or correct the reporting dates.
  • delivery_not_reported: no delivery has been reported yet. Retry after delivery is reported and check the seller reporting feed if it remains absent.
  • too_early_to_judge: the available data is too early for a reliable projected finish. Wait for more delivery data.
  • awaiting_confirmation: the sweep has a candidate state that has not yet matched across two consecutive evaluations. This is normal just after a change; a verdict normally follows after the next 15-second pass once the two evaluations agree. Synthetic demo entries always show this value because demos never have a stored assessment.
  • fx_rate_unavailable: a campaign needs a daily currency rate that is unavailable for the requested range. Retry once a rate is available or correct the currency setup.
  • unavailable: a delivery-fact, currency-rate, or stored-assessment read failed. Retry later; this is never a judgement on the campaign.
progress can be null while deliveryGoal is populated. That means there is no optimisation-goal progress to show, but Apostra still has delivery-goal evidence for the campaign or media buy. If a legacy report does not provide both dates for the reporting interval, get_delivery omits goalProgress. Apostra cannot calculate interval expected or pacingIndex without those dates. sellerPacingIndex and sellerDeliveryProjection are seller-published values that Apostra passes through unchanged. The delivery verdict is Apostra’s assessment against the buyer’s goal: it does not edit, score, or certify the seller, and it creates no seller-facing change or notification.

​
Show goal progress in a list

Use the same include with search:
Each row then carries progressSummary: worstVerdict uses this order, from most to least serious:
  1. underdelivery, behind, and other missed goals
  2. early_exhaustion
  3. on_pace and on_track
  4. complete and beat
Goals whose verdict is withheld do not affect the summary. If every goal is withheld, worstVerdict is null. The summary is deliberately small so a page of campaigns or media buys can be read in one request. Use get when you need every goal and its evidence.

​
Keep a view current

Read again at nextCheckAt when it is present. A new seller delivery, conversion event, goal, or budget change can also produce a new assessment. The Apostra web app updates a changed goal assessment within about a minute.