Google Ad Manager Deal Types:
PMP, Guaranteed & Preferred

Choosing the right type: the decision tree

The three types serve distinct buying needs. Two questions settle it:

• Is the volume guaranteed? If the buyer wants a firm impression reservation, it's a Programmatic Guaranteed. Otherwise, PMP or Preferred Deal.
• Is the price fixed or bid? A fixed negotiated price with no committed volume → Preferred Deal. Multiple buyers competing above a floor → Private Auction (PMP).

The setup workflow

The technical path differs by type — REST for PMP, SOAP (Proposal) for PG and PD.

PMP (Private Auction) path — REST

1. Create the parent PrivateAuction (create_auction) — the named container grouping the deals of one negotiation.
2. Identify the buyer (list_buyers) — get the buyer_account_id of the Authorized Buyers (DSP) seat.
3. Create the deal (create_deal, deal_type = pmp_auction) with the floor_price (minimum CPM) and, optionally, targeting and creative sizes.

PG / PD path — SOAP (Proposal + ProposalLineItem)

1. Create the Proposal (create_proposal) — it requires the advertiser (Company), salesperson, trafficker, and marketplace buyer before any action.
2. Add the ProposalLineItems (create_proposal_line_items) — lineItemType = SPONSORSHIP for a PG, PREFERRED_DEAL for a PD, with the net rate (CPM), goal, and targeting.
3. Advance the state — request_buyer_acceptance to send it to the buyer, or reserve_proposal to reserve inventory (PG). Negotiation runs through edit_proposal_for_negotiation, get_marketplace_comments, and, if needed, terminate_proposal_negotiations.

The validation workflow

This is the step the GAM console doesn't make explicit — and where deals break most often. OrbiAds validates upfront, before any network call:

• Local validation — targeting geo hierarchy, a strictly positive floor_price, and each type's own constraints: PG requires a committed volume units > 0, PD enforces FRONTLOADED + goalType = NONE. The discriminator guarantees exactly one spec (PMP/PG/PD) is set.
• Cost estimation (estimate_deal_cost) — the credit cost is computed and shown before the write, based on the type and the number of line items.
• Dry-run then confirmation — every write is simulated first (dry_run = true) and returns a confirmation_token. Nothing is sent to GAM until the token is confirmed: no deal goes live by accident.
• Status lifecycle — a deal moves from PENDING_ACCEPTANCE to ACTIVE, then possibly PAUSED, CANCELED, or ENDED. Checking that status is part of post-creation validation.

With OrbiAds, in natural language

The deals MCP tool exposes this entire workflow to your AI agent (Claude, ChatGPT, Gemini) — create and update deals, auctions, buyers, proposals, and proposal line items, plus estimate_deal_cost and AdCP integration. Reads are free; only writes consume credits, always after the dry-run and confirmation.