Programmatic Guaranteed (PG), Preferred Deals, and the IAB Deals API v1.0: Troubleshooting Deal ID Drop-Offs

Inside an OpenRTB 2.6 bid request, the imp.pmp.deals array carries the entire contractual weight of a direct programmatic reservation, yet a single misconfigured auction-type integer (at), an unadjusted net-versus-gross bidfloor, or an unmapped buyer seat identifier (wseat) will cause a demand-side platform (DSP) to drop 100% of incoming traffic before creative selection even executes. Across institutional Connected TV (CTV), mobile app, and web environments, Private Marketplace (PMP), Preferred Deal (PD), and Programmatic Guaranteed (PG) transactions represent the highest-yielding tiers of publisher monetization. However, AdOps engineering teams routinely encounter a severe operational failure mode: a Deal ID is negotiated, trafficked in the supply-side platform (SSP) and Google Ad Manager 360 (GAM 360), and activated by the agency trader, only to record thousands of outbound bid requests with zero returned bids.

Diagnosing why a deal stalls requires looking past surface-level reporting dashboards and inspecting the actual wire-level mechanics of the programmatic supply path. Unlike open auction transactions, where bid density compensates for individual bidder timeouts or targeting rejections, a direct deal concentrates demand into a single buyer seat or curation pipe. Any schema discrepancy between how the sell-side wrapper constructs the impression object and how the buy-side bidder parses the deal metadata halts revenue generation immediately. Furthermore, in CTV Server-Side Ad Insertion (SSAI) and client-side Prebid.js 11.x or Prebid Server (Go/Java) deployments, deal drop-offs compound across multiple sequential gates, from initial QPS throttling down to ad pod deduplication.

At Sky Boosts, our engineering teams architect direct and semi-direct deal pipes across Web, Mobile App, and CTV inventory that is 100% Google-friendly and pre-verified by HUMAN and Pixalate for invalid traffic (IVT) cleanliness, maintaining strict brand safety with zero alcohol, gambling, adult, or tobacco demand. By pairing deterministic Net-30 and Net-60 publisher payouts with deep protocol compliance across OpenRTB 2.6, VAST 4.3, and GAM 360 Multiple Customer Management (MCM), we isolate and resolve the exact telemetry bottlenecks that cause deal under-delivery.

The Deal Funnel: Where 60% of PMP Bid Requests Get Filtered Out

When a publisher initiates an ad opportunity associated with an active PMP or PG contract, the outbound bid request must survive five distinct technical filtration stages before an impression renders and clears billing. Across industry-wide programmatic pipes, more than 60% of deal-flagged bid requests are discarded between the publisher wrapper and the final ad server arbitration layer. Understanding the exact mechanics of this attrition funnel is the prerequisite for isolating whether a stalled Deal ID is failing due to sell-side configuration, transport-layer stripping, buy-side targeting constraints, or ad server priority conflicts.

The first filtration gate occurs at the sell-side ingestion and QPS throttling layer. Before a request ever reaches a participating SSP partner or Prebid Server endpoint, client-side wrapper depth timeouts, missing user consent strings (TCF v2.2 or GPP), or aggressive supply path optimization (SPO) traffic shaping can terminate the call. If an SSP classifies a request as low-value or lacking required device identifiers (such as ifa on CTV or idfa/gaid on mobile apps), its internal traffic shaper may suppress the outbound call unless the deal is explicitly flagged to bypass QPS throttling rules.

The second and third filtration gates occur inside the DSP edge listener and core bidding engine. Upon receiving the OpenRTB payload, the DSP edge router validates whether the incoming deal.id exists in its active campaign cache and whether the transmitted wseat array matches the agency or advertiser seat configured by the trader. Requests that pass edge authentication enter the third stage: buy-side audience, frequency, and supply validation. Here, traders frequently layer proprietary third-party audience segments, cross-device frequency caps, or strict contextual and viewability thresholds on top of a Deal ID that already had targeting applied on the SSP side. This double-filtering starves the deal of eligible scale.

The fourth filtration gate encompasses financial and creative validation. Even when the DSP intends to bid, the response is aborted if the trader's assigned creative fails protocol matching (for example, attempting to serve a VPAID creative into a CTV VAST 4.3 SSAI stream), violates publisher battr or badv blocks, or fails duration-specific floor checks. Finally, the fifth stage occurs back on the publisher side during ad server arbitration and SSAI stitching. When scaling enterprise programmatic deals, a valid DSP deal response can still lose in GAM 360 if a competing Sponsorship line item preempts it, or get dropped by the CTV SSAI stitcher if the returned VAST XML lacks a pre-transcoded mezzanine asset or violates competitive ad pod separation rules.

OpenRTB 2.6 pmp and Deal Object Anatomy

At the protocol layer, all private marketplace and guaranteed transactions are governed by the pmp object nested inside the OpenRTB imp (impression) container. The pmp object contains two core attributes: private_auction, an integer flag indicating whether the impression is restricted exclusively to the specified deals (1) or eligible to fall back to the open auction (0), and deals, an array of individual Deal objects representing the specific commercial contracts applicable to that impression opportunity.

When troubleshooting deal drop-offs across CTV ad pods or high-value web placements, engineers must verify the exact JSON serialization of the pmp container. The following production-grade OpenRTB 2.6 snippet illustrates a multi-deal CTV video impression request supporting both a Programmatic Guaranteed commitment and a variable-duration Preferred Deal:

{
  "id": "req-ctv-9948102-a",
  "imp": [
    {
      "id": "imp-pod-slot-1",
      "video": {
        "mimes": ["video/mp4", "application/x-mpegURL"],
        "minduration": 15,
        "maxduration": 30,
        "protocols": [7, 8, 11, 12],
        "w": 1920,
        "h": 1080,
        "startdelay": 0,
        "plcmt": 1,
        "podid": "pod-midroll-02",
        "podseq": 1
      },
      "bidfloor": 12.00,
      "bidfloorcur": "USD",
      "pmp": {
        "private_auction": 0,
        "deals": [
          {
            "id": "SKY-PG-CTV-2026-8841",
            "bidfloor": 28.00,
            "bidfloorcur": "USD",
            "at": 3,
            "guaranteed": 1,
            "wseat": ["seat-agency-alpha-01"],
            "wadomain": ["luxuryauto.example.com"]
          },
          {
            "id": "SKY-PD-CTV-2026-4409",
            "bidfloor": 18.00,
            "bidfloorcur": "USD",
            "at": 3,
            "guaranteed": 0,
            "mincpmpersec": 0.75,
            "wseat": ["seat-agency-beta-09", "seat-trader-west-02"],
            "durfloors": [
              {
                "mindur": 15,
                "maxdur": 15,
                "bidfloor": 18.00
              },
              {
                "mindur": 30,
                "maxdur": 30,
                "bidfloor": 24.00
              }
            ]
          }
        ]
      }
    }
  ],
  "tmax": 450,
  "cur": ["USD"]
}

New Deal Attributes (v2.6-202309+): guaranteed, mincpmpersec, and durfloors

Historically, OpenRTB relied solely on the auction type (at) field inside the Deal object to communicate commercial mechanics, where at: 1 signified First Price, at: 2 signified Second Price Plus, and at: 3 indicated that the value passed in bidfloor represented the agreed fixed clearing price. However, this created a major architectural ambiguity: both non-guaranteed Preferred Deals and volume-committed Programmatic Guaranteed contracts operate on fixed pricing (at: 3). Without an explicit protocol flag distinguishing the two, DSPs had to rely on out-of-band manual configuration by traders to know whether a deal required mandatory bidding ("must-bid" PG status) or discretionary bidding (PD status).

To eliminate this ambiguity and support granular CTV video pricing, the IAB Tech Lab OpenRTB v2.6-202309 specification expanded the Deal object with explicit guaranteed (an integer flag for PG deals), mincpmpersec, and durfloors attributes alongside bidfloor and wseat.

Setting guaranteed: 1 inside the Deal object explicitly signals to the receiving DSP that the impression is governed by a Programmatic Guaranteed contract. When a compliant tier-1 DSP ingests guaranteed: 1 alongside at: 3, its bidding logic alters its internal execution path:

• Bypassing Bid Shading: In standard PMP (at: 1) auctions, DSPs apply predictive bid shading algorithms to reduce the submitted bid toward the estimated clearing price. If a PG deal is mistakenly sent with at: 1 and guaranteed: 0, the DSP shades the bid below the contracted rate, failing the SSP floor check. With guaranteed: 1 and at: 3, bid shading is completely disabled.
• Prioritized Pacing and Filter Relaxation: For PG deals, the DSP overrides discretionary user-value scoring and attempts to bid on approaching 100% of requests that pass fundamental brand-safety and technical creative checks.
• Duration-Adjusted Floor Enforcement: In CTV environments, a static deal.bidfloor creates severe yield leakage or false rejections when a deal permits both 15-second and 30-second video creatives. By populating the durfloors array of DurFloors objects (coupled with mincpmpersec for non-standard spot lengths), the SSP communicates exact minimum CPM thresholds per duration bracket directly inside the Deal object. If a trader assigns a 30-second VAST creative to SKY-PD-CTV-2026-4409 but sets their maximum DSP bid at $19.00 based on the base 15-second floor ($18.00), the durfloors specification reveals immediately why the bid is rejected against the $24.00 30-second threshold.

Bid Floor Mismatches and Buyer Seat (wseat) Configuration Errors

Even when at and guaranteed flags are properly formatted, two configuration errors account for the vast majority of zero-bid deal tickets: net-versus-gross floor discrepancies and wseat namespace mismatches.

In programmatic pipes, deal.bidfloor represents the minimum price the SSP requires in the incoming bid.price field of the OpenRTB response. However, commercial deal rates are frequently negotiated between publishers and agencies on a gross basis, while SSPs and DSPs deduct technology or curation fees along the path. Consider a PMP deal negotiated at a $20.00 CPM. If the SSP sets deal.bidfloor: 20.00 expecting a net $20.00 bid, and the agency trader enters a $20.00 maximum bid in their DSP UI, the DSP's internal fee structure (for instance, a 12% platform fee) reduces the outbound wire bid (bid.price) to $17.60. The SSP compares $17.60 against the $20.00 floor and silently discards 100% of the bids with an internal floor-rejection log. Similarly, when multi-currency conversion occurs between USD, EUR, and GBP, floating-point rounding discrepancies of just $0.01 caused by asynchronous foreign exchange rate tables between the SSP and DSP will trigger total deal rejection unless the SSP applies a 1% to 2% floor tolerance buffer on fixed-price deals.

Seat validation errors via the wseat (whitelist of buyer seats) array are equally destructive. Each DSP maintains its own proprietary identifier namespace for DSP partner seats, and global agency holding companies frequently operate dozens of regional or client-specific sub-seats beneath a master parent seat ID. When an SSP trafficker restricts a deal to wseat: ["agency-global-master"], but the local execution trader activates the campaign under a regional child seat ("agency-emea-auto-04"), the DSP edge router drops the request immediately. Furthermore, seat IDs are exchange-specific; passing an AdX buyer network ID inside an OpenRTB wseat array destined for an independent tier-1 DSP guarantees a 100% validation failure.

Automating Deal Metadata Synchronization with the IAB Deals API v1.0 (Finalized Feb 2026)

For over a decade, the operational root cause of wseat, bidfloor, and targeting mismatches was the reliance on manual, out-of-band communication. An AdOps manager would configure a deal in an SSP UI, copy the Deal ID string into a spreadsheet or email, and send it to an agency trader, who would then manually key the Deal ID, floor price, flight dates, and format parameters into the DSP console. Any typo, timezone discrepancy, or uncommunicated mid-flight floor adjustment resulted in immediate deal breakage.

To eradicate this manual synchronization bottleneck, the IAB Tech Lab finalized the Deals API v1.0 specification on February 6, 2026, standardizing the automated exchange of high-level negotiated deal terms, floors, and targeting metadata between SSPs, curation platforms, and DSPs. Rather than waiting for real-time OpenRTB bid requests to discover a configuration mismatch, the Deals API v1.0 establishes an asynchronous RESTful control plane where sell-side and curation platforms programmatically push structured deal definitions directly into the target DSP's deal management inventory prior to flight activation.

Through our unified monetization platform, Sky Boosts leverages automated deal metadata synchronization to ensure that commercial terms, buyer seat mappings, and technical creative constraints are validated by the buy-side platform before a single impression is auctioned. Below is a representative JSON payload conforming to the Deals API v1.0 architecture, illustrating how comprehensive deal terms are synchronized across platforms:

{
  "schema_version": "1.0",
  "deal_metadata": {
    "deal_id": "SKY-PG-CTV-2026-8841",
    "deal_name": "Q3 Luxury Auto CTV Prime Pod Slot 1",
    "seller_network": "skyboosts.com",
    "status": "ACTIVE",
    "commercial_terms": {
      "deal_type": "PROGRAMMATIC_GUARANTEED",
      "auction_type": 3,
      "guaranteed": 1,
      "currency": "USD",
      "base_floor_cpm": 28.00,
      "duration_floors": [
        { "min_duration": 15, "max_duration": 15, "floor_cpm": 28.00 },
        { "min_duration": 30, "max_duration": 30, "floor_cpm": 36.00 }
      ],
      "volume_commitment": {
        "metric": "IMPRESSIONS",
        "contracted_units": 2500000
      }
    },
    "flight_schedule": {
      "start_time_utc": "2026-04-01T00:00:00Z",
      "end_time_utc": "2026-06-30T23:59:59Z"
    },
    "buyer_authorization": {
      "dsp_id": "tier1-dsp-us-east",
      "wseat": ["seat-agency-alpha-01"],
      "wadomain": ["luxuryauto.example.com"]
    },
    "inventory_constraints": {
      "distribution_channel": "CTV_APP",
      "media_types": ["VIDEO"],
      "video_protocols": [7, 8, 11, 12],
      "mimes": ["video/mp4", "application/x-mpegURL"],
      "ssai_required": true
    }
  }
}

By synchronizing this metadata object via the Deals API v1.0, the DSP automatically populates the trader's deal library with the exact wseat, base_floor_cpm, duration_floors, and required video MIME types. If the trader attempts to attach a 30-second video creative with a $30.00 maximum bid, the DSP UI can immediately alert the user before launch that the synchronized deal requires a $36.00 CPM for 30-second spots, preventing silent runtime failures.

Step-by-Step Deal Debugging Protocol for AdOps Teams

When an active PMP, Preferred Deal, or Programmatic Guaranteed line item exhibits severe drop-offs between outbound requests and rendered impressions, AdOps engineers should execute a deterministic, five-step diagnostic protocol spanning the client wrapper, the OpenRTB wire, DSP error telemetry, creative stitchers, and the publisher ad server.

Step 1: Verify Wrapper Injection and First-Party OrtB2 Overrides (Prebid.js 11.x / Prebid Server) In web and mobile environments using Prebid.js 11.x or Prebid Server, verify that the pmp object is not being stripped by bidder adapters or overwritten by module configurations. Use browser developer tools or Prebid Server debug flags ("test": 1) to inspect the exact payload generated for the target SSP adapter:

pbjs.que.push(function() {
  const bidRequests = pbjs.getBidRequests();
  bidRequests.forEach(req => {
    req.bids.forEach(bid => {
      const pmpData = bid.ortb2Imp?.pmp;
      if (pmpData && pmpData.deals?.length > 0) {
        console.table(pmpData.deals.map(d => ({
          bidder: bid.bidder,
          adUnit: bid.adUnitCode,
          dealId: d.id,
          floor: d.bidfloor,
          at: d.at,
          guaranteed: d.guaranteed
        })));
      }
    });
  });
});

Step 2: Audit Outbound Wire Attributes (wseat, at, guaranteed, and Floor Buffers) Capture a raw OpenRTB 2.6 bid request sample from the SSP diagnostic logger. Confirm that the deal.id contains zero leading or trailing whitespace characters. Verify whether wseat is overly restrictive; if the DSP trader cannot confirm their exact child seat ID, temporarily set wseat to an open state (or include all parent and child agency seats) while maintaining private_auction: 1 to test whether seat filtering is the blocker. For fixed-price deals (at: 3), apply a 2% downward floor buffer on the SSP side (for example, setting bidfloor: 19.60 on a $20.00 agreed deal) to absorb minor currency conversion and DSP fee rounding variances.

Step 3: Inspect OpenRTB No-Bid Reason (nbr) Codes and DSP Loss Telemetry Analyze the incoming HTTP 200 or 204 responses from the DSP alongside OpenRTB nbr (No-Bid Reason) integers. While an HTTP 204 indicates a standard no-bid, tier-1 DSPs that return a JSON body with nbr: 5 (Invalid/Unknown Deal ID), nbr: 6 (Blocked Advertiser/Domain), or nbr: 7 (Unmatched User/Device ID) pinpoint the exact buy-side rejection layer. If nbr: 7 dominates on web or mobile inventory, the deal is failing because the trader applied third-party cookie or ID graph targeting that does not overlap with the publisher's traffic; instruct the buyer to remove duplicate audience overlays on the DSP side and rely on first-party publisher curation.

Step 4: Validate VAST 4.3 Creative Compliance and CTV SSAI Readiness If the DSP is submitting valid bids into the SSP (bid.dealid matches the request), yet impression delivery remains near zero, the drop-off is occurring at the creative validation or SSAI stitching stage. In CTV environments, inspect the DSP's bid.adm VAST XML payload. Confirm that the <MediaFile> node includes high-bitrate MP4 mezzanine files alongside adaptive HLS (.m3u8) streams, and verify that bid.adomain and bid.crid are explicitly populated. In SSAI workflows, a new crid often triggers an asynchronous transcoding job; until the stitcher finishes transcoding the mezzanine file into segments matching the publisher's stream profile, the stitcher will drop the deal bid on the initial few requests.

Step 5: Audit GAM 360 Key-Value Targeting and Line Item Priority For deals arbitrated through Google Ad Manager 360 via Prebid, verify that the winning deal bid is not losing inside the ad server. Ensure that the Prebid configuration uses enableSendAllBids: false with explicit bidder-specific or deal-tier key-values (hb_deal, hb_deal_skyboosts, or hb_pb_cat_dur for CTV pods) and that the corresponding GAM 360 line item is trafficked at the proper priority level (such as Sponsorship Priority 4 or Standard Priority 6/8 for PG/Preferred setups, rather than Price Priority 12 where open-exchange dynamic allocation can outbid a strategic commitment). By systematically auditing each of these five layers and adopting the IAB Deals API v1.0 for pre-flight metadata alignment, engineering and AdOps teams can eliminate silent deal drop-offs and convert 100% of contracted reservations into cleared, billable publisher revenue.