Skip to main content
A guaranteed buy promises an amount of delivery, such as a number of impressions. Your ad server forecasts how much of that it can deliver for the buy’s inventory, flight and targeting. When a buy asks for more than the forecast, someone has to decide whether to sell more than the ad server expects to have. Your over-forecast policy makes that decision. This page applies to guaranteed packages on Google Ad Manager connected through Apostra. A package is guaranteed when the pricing option the buyer selected is guaranteed, as your ad server reports it; a product can offer both kinds. Non-guaranteed packages, other ad servers and other sources are not checked.

​
Overbook or hold for review

  • Overbook (the default). Apostra sends the buy as it arrives, and the ad server books it anyway. Nothing waits on you, and the buy may under-deliver if the forecast is right.
  • Hold for review. Before sending a guaranteed buy, Apostra asks your ad server for its availability. A buy that fits the forecast is sent as usual. A buy that asks for more than the forecast for any package waits in your Approvals, and nothing is booked until you decide.
To hold such buys for your review, choose Hold for my review under Guaranteed buys over the ad server’s forecast in the approval gates on the AI Business Rules page, ask Apostra, or save it on V3 with save_business_rules:
Save "overbook" to go back. Neither direction asks you to confirm anything, because holding adds review rather than removing it. The setting applies to your whole storefront and to buys created after you change it; read it with get and kind: "business_rules". It stays in Apostra: your ad server is only asked for its forecast, and never holds or decides a buy itself. When you hold for review, a buy whose availability the ad server cannot confirm is held too, with the reason, so you are never overbooked on an answer the ad server could not give. That happens when:
  • the ad server returns no forecast for a package;
  • the ad server does not forecast a package’s goal, for example a share-of-voice goal;
  • some of the buyer’s targeting values do not exist in the ad server yet, so the forecast leaves them out and may overstate availability;
  • the ad server does not answer in time (about 35 seconds), cannot be reached, or fails;
  • the ad server refuses the request, for example because it cannot book the buyer’s targeting (the ad server’s reason code is shown);
  • the buy has no flight or budget to forecast.
The check adds a short wait, up to that time limit, before the buyer gets an answer for a guaranteed buy. Your storefront’s own operator booking its own supply is not checked, because that booking is already your decision.

​
Decide a held buy

A held buy is an ordinary media-buy approval in your Approvals queue: it uses the same routing, notifications and decision as any other buy. Open the Page with open_approvals, or ask Apostra to open your approvals. The row is marked Over forecast or Availability unconfirmed, and opening it shows, for each guaranteed package:
  • the goal unit (impressions, viewable impressions or clicks);
  • what the buy requested;
  • what the ad server forecasts is available;
  • the shortfall.
Then choose one:
  • Approve. Apostra sends the buy as submitted, and the ad server books the full order, even though it may not deliver all of it.
  • Reject. Nothing is sent to the ad server, and the buyer sees the buy as rejected.
If your storefront already reviews every media buy, a guaranteed buy is reviewed once: the same review shows its availability, including “Within the ad server forecast” when it fits. If the buyer changes a held buy before you decide, the review says its figures describe the earlier version.

​
Decide through V3

An agent can run the same review without the Approvals Page. A held buy is a media_buy_approval work item:
  • search with kind: "work_item" lists it, and its text names each buy the policy held with its outcome (shortfall or unverified).
  • get with kind: "work_item", workItemKind: "media_buy_approval" and the buy’s id returns availabilityReview: the outcome, when it was checked, whether the buyer has changed the buy since, and for each package the goal unit, requested, available and shortfall, the ad server’s reason when it had no forecast, and any buyer targeting the forecast left out. Failed checks list the ad server’s error code and the packages left unchecked.
  • save_work_item with kind: "media_buy_approval" and status: "approved" sends the buy as submitted; status: "rejected" sends nothing.
An approved buy then appears with the rest of your buys on the Media Buys Page.