Google Open Bidding Direct Pay vs. Standard Open Bidding & Prebid: Mechanics, %-Media Fees, and Net Bidding

On November 1, 2026, Google Ad Manager 360 enforces a mandatory transition to net-bidding auction mechanics for all Open Bidding Direct Pay yield groups, fundamentally altering how server-side exchange bids compete against Google Ad Exchange (AdX) and client-side Prebid line items. In a unified first-price auction where microsecond latency thresholds and fractional CPM adjustments dictate win rates, the structural distinction between a bid adjusted dynamically by Google's real-time revenue share and a net bid cleared under an invoice-level percentage-of-media (%-media) fee determines which demand pipe captures high-value impressions. For programmatic architects managing hybrid monetization stacks across web, mobile app, and Connected TV (CTV), treating server-to-server (S2S) auctions as a monolithic channel introduces severe yield leakage and floor misalignment.

When a publisher evaluates server-side header bidding against Google's native S2S framework, the underlying clearing mechanics govern both effective CPM (eCPM) density and working capital velocity. Standard Open Bidding consolidates contracting, credit risk, and monthly disbursements under Google's clearinghouse model in exchange for a fixed auction-time platform deduction. Conversely, Open Bidding Direct Pay decouples auction execution from financial settlement, requiring enterprise publishers to maintain bilateral contracts with participating SSP partners, receive gross-of-Google-fee payouts directly from those exchanges, and pay Google a separate monthly utilization fee.

Engineering an optimal yield topology requires dissecting how these two Open Bidding modes interact with Prebid.js 11.x, Prebid Server, and Prebid Mobile SDK implementations. From SupplyChain (schain) object serialization and IAB Tech Lab sellers.json classification to cookie match tables and Unified Pricing Rules (UPRs), every layer of the stack responds differently depending on whether an SSP bid enters Google Ad Manager (GAM) via a client-side key-value pair, a standard Google-disbursed yield group, or a Direct Pay net-bidding endpoint.

How Open Bidding Evolved: Availability for All AdX Publishers vs. GAM 360 Direct Pay

When Google first introduced Exchange Bidding in Dynamic Allocation (EBDA) as a server-to-server counterweight to client-side header bidding, access was tightly gated behind enterprise GAM 360 contracts and restrictive partner quotas. Over subsequent architecture cycles, Google rebranded the framework and expanded access across its sell-side ecosystem. Today, standard Google Open Bidding is available to all publishers using Ad Exchange in Google Ad Manager, removing the historical GAM 360 prerequisite and allowing mid-market and independent publishers operating through AdX or Multiple Customer Management (MCM) Manage Inventory and Manage Account structures to activate server-side yield partners directly inside the GAM interface.

In the standard Open Bidding workflow, Google functions as both the technical auctioneer and the financial clearinghouse. When an ad request reaches GAM via Google Publisher Tags (GPT), the Google Mobile Ads (GMA) Next-Gen SDK, or the Interactive Media Ads (IMA) SDK, GAM evaluates eligible line items and simultaneously dispatches an encrypted, Google-proprietary or OpenRTB 2.6 bid request to configured yield partners within a single unified auction. Because standard Open Bidding respects Unified Pricing Rules, publishers apply centralized floor prices across AdX, Open Bidding yield partners, and non-guaranteed remnant line items without maintaining separate exchange-specific floor matrices.

The financial architecture of standard Open Bidding prioritizes operational simplicity at the expense of an explicit auction-time tax. Under the standard model, the publisher does not need a direct bilateral payment contract with each SSP to receive funds; instead, the publisher accepts the partner's terms within GAM, and Google handles invoicing, collections, currency conversion, and consolidated monthly payouts on a Net-30 cycle. To underwrite this clearinghouse service and infrastructure load, Google deducts an auction-time revenue share directly from the winning Open Bidding bid: typically 5% for display and mobile app inventory, and 10% for video and CTV inventory.

If an SSP submits a $10.00 CPM bid into standard Open Bidding for a web display impression, GAM reduces that bid by 5% to $9.50 before comparing it against competing AdX bids and Prebid price-priority line items. That 5% haircut immediately degrades the SSP's win rate in high-density auctions where Prebid bidders compete at zero ad-server tax. While publishers scaling their Open Bidding connections benefit from zero client-side thread blocking and consolidated collections in the standard tier, enterprise publishers running high-volume GAM 360 instances frequently require a mechanism to eliminate Google's standard auction-time deduction and negotiate custom commercial terms directly with their supply-side partners. That requirement led to the architecture of Open Bidding Direct Pay.

Inside Open Bidding Direct Pay

Open Bidding Direct Pay re-architects the settlement and bidding pipeline exclusively for enterprise publishers operating on GAM 360. Specifically, Open Bidding Direct Pay allows GAM 360 publishers to receive gross payments directly from participating Open Bidding SSPs under bilateral contracts rather than relying on Google to collect and disburse auction proceeds. By removing Google from the money-movement path, the publisher assumes direct counterparty relationships with each activated SSP, while Google restricts its role to technical callout orchestration, unified auction clearing, and impression verification.

At the protocol layer, the real-time bid request lifecycle in Open Bidding Direct Pay mirrors standard Open Bidding. When an ad unit fires, GAM resolves targeting, applies Unified Pricing Rules, checks user consent strings (such as IAB TCF v2.2 or GPP payloads), and initiates a server-to-server callout to the Direct Pay yield partner with strict latency timeouts (typically 160ms for web and mobile display, and up to 300ms for video and CTV). However, the metadata flagging the contract type, the SupplyChain node representation, and the downstream financial reconciliation diverge completely from the standard model.

Because Google no longer intercepts the clearing funds in Direct Pay, it cannot simply withhold a 5% or 10% cut from a monthly AdX wire transfer. Instead, Google monetizes the technical execution of Direct Pay through a contracted monthly percentage-of-media (%-media) fee billed directly on the publisher's GAM 360 invoice, paired with a structural mandate that all Direct Pay partners transition to net-bidding auction mechanics. Understanding how this contractual and mathematical shift operates is essential for any AdOps team evaluating whether to migrate a demand partner from Prebid or standard Open Bidding into Direct Pay.

Direct SSP Contracts, Seller Classification (PUBLISHER vs. INTERMEDIARY), and Direct Payouts

Migrating a yield partner to Open Bidding Direct Pay transforms both the Supply Path Optimization (SPO) footprint of the impression and the publisher's treasury operations. When DSPs evaluate bid requests, their bidding algorithms inspect the OpenRTB source.ext.schain object alongside the publisher's ads.txt or app-ads.txt file and the SSP's sellers.json ledger to verify the commercial hop count.

In a standard Open Bidding integration, because Google mediates the financial settlement between the SSP and the publisher, SupplyChain serialization and seller classification can reflect an intermediary structure depending on how the SSP maps the Google-hosted seat. Conversely, when a GAM 360 publisher establishes a direct contract with an SSP for Open Bidding Direct Pay, the commercial relationship is strictly bilateral. The publisher lists the SSP's seat ID as DIRECT in its ads.txt or app-ads.txt file, and the SSP classifies the publisher account with "seller_type": "PUBLISHER" (rather than "INTERMEDIARY" or "BOTH") inside its public sellers.json file.

{
  "source": {
    "fd": 1,
    "tid": "7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d",
    "ext": {
      "schain": {
        "ver": "1.0",
        "complete": 1,
        "nodes": [
          {
            "asi": "skyboosts.com",
            "sid": "pub-984102",
            "hp": 1,
            "rid": "req-5541928301",
            "name": "Enterprise Media Corp",
            "domain": "enterprisemedia.example.com"
          }
        ]
      }
    }
  }
}

As demonstrated in the single-hop schain payload above, a clean hp: 1 (payment flows directly to this node) declaration paired with a verified PUBLISHER classification prevents tier-1 DSPs from throttling QPS or applying SPO bid shading penalties against intermediary resellers. For publishers learning what an SSP is in the context of modern supply path curation, this direct contractual link ensures that curated direct and semi-direct demand sources treat the server-side Open Bidding request with the same supply-chain trust as a direct Prebid integration.

However, bypassing Google's clearinghouse transfers accounts-receivable management, sequential liability risk, and payment-term negotiation entirely onto the publisher's finance team. If an SSP pays on Net-90 terms or enforces clawbacks on uncollected buyer invoices, the publisher absorbs that working capital drag directly. At Sky Boosts, we eliminate this friction for our publishing partners by combining 100% Google-friendly, HUMAN and Pixalate IVT-clean inventory standards with reliable Net-30 and Net-60 payment terms, ensuring that direct payouts maintain predictable cash-flow velocity without exposure to restricted ad categories like gambling, alcohol, tobacco, or adult content.

The November 2026 Transition to Net-Bidding Auction Mechanics and Google's %-Media Fee

The most significant engineering milestone in the lifecycle of Open Bidding Direct Pay is the standardization of how bids enter the GAM 360 auction. Under Google's platform rules, Open Bidding Direct Pay runs the auction on net-bidding mechanics, a framework that becomes strictly mandatory across all Direct Pay connections as of November 1, 2026.

To understand why Google mandated net bidding for Direct Pay, consider what happens when an SSP submits a gross bid into an auction where the ad server does not know the SSP's private contractual revenue share with the publisher. If an SSP holds a direct contract with a publisher stipulating a 15% SSP take rate, and the SSP submits a $10.00 gross bid into GAM without adjustment, GAM would evaluate that bid at $10.00 against an AdX net bid of $9.20. The Open Bidding partner would win the auction at $10.00, yet the publisher would only collect $8.50 net from the SSP, causing a $0.70 CPM yield loss per thousand impressions through false auction elevation.

Under the mandatory November 1, 2026 net-bidding architecture, the participating Open Bidding Direct Pay SSP must deduct its own contractual fee prior to transmitting the bid response to GAM. Furthermore, because Google does not collect the clearing funds from the SSP, Google does not apply the standard 5% or 10% auction-time deduction to the bid inside the real-time auction. Instead, Google tracks the total media value cleared through the Open Bidding Direct channel and bills the GAM 360 publisher a monthly %-media fee on their platform invoice.

We can formalize the effective publisher yield ($Y_{pub}$) and auction-time competing value ($V_{auction}$) across all three pathways using the following equations, where $B_{gross}$ is the buyer's gross clearing bid, $r_{ssp}$ is the SSP's contractual revenue share, $f_{ob}$ is Google's standard Open Bidding fee (0.05 for display, 0.10 for video), and $f_{media}$ is Google's contracted monthly %-media invoice fee for Direct Pay:

$$\text{Standard Open Bidding: } V_{auction} = Y_{pub} = B_{gross} \times (1 - r_{ssp}) \times (1 - f_{ob})$$

$$\text{Open Bidding Direct Pay (Net Bidding): } V_{auction} = B_{gross} \times (1 - r_{ssp})$$

$$\text{Open Bidding Direct Pay Net Yield: } Y_{pub} = V_{auction} \times (1 - f_{media})$$

$$\text{Client-Side Prebid.js: } V_{auction} = Y_{pub} = B_{gross} \times (1 - r_{ssp})$$

Notice the critical divergence between $V_{auction}$ (the number GAM uses to pick the winner) and $Y_{pub}$ (the cash the publisher retains after paying Google's invoice) in Open Bidding Direct Pay. Because the Direct Pay net bid ($V_{auction}$) enters the GAM unified auction without an auction-time deduction by Google, it competes on exact mathematical parity with a client-side Prebid net bid. However, because the publisher still owes Google the monthly $f_{media}$ percentage fee on all volume won by that Direct Pay partner, a Direct Pay bid of $8.50 that beats an AdX net bid of $8.45 may actually yield less net cash to the publisher once the monthly %-media invoice fee is subtracted.

Architectural Dimension	Standard Open Bidding	Open Bidding Direct Pay	Client-Side Prebid (Prebid.js 11.x)
GAM Tier Eligibility	All GAM publishers with linked AdX	GAM 360 Enterprise only	All GAM tiers (via price-priority line items)
SSP Contracting & Payout	Consolidated via Google (Net-30)	Direct bilateral SSP contract & payout	Direct bilateral SSP contract & payout
Seller Classification	Google clearinghouse / Intermediary	Direct (PUBLISHER in sellers.json)	Direct (PUBLISHER in sellers.json)
Auction Bid Mechanic	Net of SSP fee, minus 5%/10% Google cut	Net of SSP fee (Mandatory Nov 1, 2026)	Net of SSP fee (via bidCpmAdjustment)
Google Platform Fee	5% Display / 10% Video deducted in-auction	Monthly %-media fee billed on GAM invoice	$0 on winning bids (ad server CPM fees apply only on unfilled/non-AdX impressions if over quota)
GAM Demand Channel	Open Bidding	Open Bidding Direct	Key-values / Header Bidding (Yield Group mapped)

Coexistence with Prebid: Cookie Match Rates, Client-Side Signals, and Unified Flooring

Given that Open Bidding Direct Pay eliminates the 5% to 10% auction-time bid reduction and establishes direct sellers.json parity, engineering leaders often ask whether they can deprecate client-side Prebid.js or Prebid Mobile SDK wrappers entirely in favor of an all-Open-Bidding architecture. In production environments, the answer remains no: highest total yield is consistently achieved by running a hybrid stack where Prebid and Open Bidding coexist and reinforce one another.

Three technical factors explain why client-side Prebid outperforms server-to-server Open Bidding on a per-impression bid value basis on web environments:

1. Cookie Match Synchronization and Alternative IDs: In Open Bidding, user identity resolution relies on Google's hosted cookie-matching tables (google_gid / encrypted hosted match tables) or Google's Publisher Provided Identifiers (PPID) and Secure Signals framework. While efficient, server-to-server match rates between Google and third-party SSPs frequently trail direct client-side cookie syncs executed by Prebid's userSync module, where the browser reads the SSP's domain cookie natively and enriches the ortb2.user.ext.eids array with deterministic first-party and industry IDs.
2. Client-Side Telemetry and Viewability Signals: Prebid.js 11.x executes directly inside the browser DOM, allowing adapters to inspect real-time viewport geometry, scroll velocity, device hardware concurrency, and exact ad slot dimensions prior to bid transmission. Server-to-server Open Bidding requests originate from Google's data centers, stripping out granular client-side execution context that DSP algorithms prize when predicting viewability completion rates.
3. Timeout Curve Flexibility: Google enforces rigid server-side timeout ceilings on Open Bidding yield partners to protect overall ad-serving latency. If a tier-1 DSP connected to an SSP requires 220ms to run a complex machine-learning valuation model on a high-value web impression, an Open Bidding callout capped at 160ms will time out and drop the bid, whereas a Prebid.js wrapper configured with a 600ms-1000ms auction timeout captures the clearing price.

Conversely, Open Bidding excels in inventory environments where client-side execution is constrained or where QPS efficiency is paramount: CTV Server-Side Ad Insertion (SSAI) streams, mobile app environments running GMA Next-Gen SDK mediation, and high-latency cellular connections where firing ten parallel client-side HTTP requests degrades Core Web Vitals (specifically Interaction to Next Paint, or INP).

To run Prebid.js 11.x alongside Open Bidding Direct Pay without creating arbitrage or floor cannibalization, AdOps engineers must normalize all incoming bids to net publisher value and align Prebid's Price Floors Module with GAM's Unified Pricing Rules. Furthermore, if a GAM 360 publisher pays a monthly %-media fee on Open Bidding Direct Pay volume, the publisher should account for that invoice cost when setting target CPMs or evaluating whether a dual-connected SSP should prioritize the Prebid path over the Open Bidding Direct path.

window.pbjs = window.pbjs || {};
window.pbjs.que = window.pbjs.que || [];

// Contractual revenue shares (for SSPs sending gross bids in Prebid)
const SSP_REV_SHARE = {
  skyboosts: 0.00, // Already submits net bids natively
  sspPartnerAlpha: 0.15, // Submits gross bids; requires 15% net adjustment
  sspPartnerBeta: 0.12
};

pbjs.que.push(function() {
  pbjs.setConfig({
    bidderTimeout: 850,
    enableTIDs: true,
    priceGranularity: {
      buckets: [
        { precision: 2, min: 0.01, max: 5.00, increment: 0.01 },
        { precision: 2, min: 5.00, max: 20.00, increment: 0.05 },
        { precision: 2, min: 20.00, max: 100.00, increment: 0.50 }
      ]
    },
    floors: {
      enforcement: {
        floorDeals: false,
        bidAdjustment: true
      },
      data: {
        currency: 'USD',
        schema: {
          fields: ['mediaType', 'size']
        },
        // Aligned directly with GAM Unified Pricing Rules (UPRs)
        values: {
          'banner|300x250': 1.25,
          'banner|728x90': 1.50,
          'video|*': 8.50
        },
        default: 0.80
      }
    },
    ortb2: {
      source: {
        ext: {
          schain: {
            ver: '1.0',
            complete: 1,
            nodes: [{
              asi: 'skyboosts.com',
              sid: 'pub-984102',
              hp: 1
            }]
          }
        }
      }
    }
  });

  // Normalize all Prebid bids to Net CPM to match Nov 2026 OB Direct Pay mechanics
  pbjs.bidderSettings = {
    standard: {
      bidCpmAdjustment: function(bidCpm, bid) {
        const fee = SSP_REV_SHARE[bid.bidderCode] || 0.00;
        const netCpm = bidCpm * (1 - fee);
        return Math.round(netCpm * 100) / 100;
      }
    }
  };
});

By enforcing bidCpmAdjustment on the client side and synchronising floors.data.values with GAM Unified Pricing Rules, the publisher guarantees that Prebid line items, Open Bidding Direct Pay net bids, standard Open Bidding bids, and AdX demand compete on a level playing field. For large-scale media groups architecting custom enterprise publisher solutions, this unified flooring discipline prevents DSPs from discovering a cheaper backdoor into the same impression via an unfloored server-side endpoint.

Reporting Breakdown: Tracking 'Open Bidding Direct' Demand Channel in GAM

Reconciling revenue across a hybrid monetization stack requires isolating standard Google-disbursed Open Bidding traffic from bilateral Direct Pay traffic. In Google Ad Manager Historical Reporting and Data Transfer logs, Google segregates these pipelines at the Demand Channel dimension level: standard connections report under Open Bidding, whereas Direct Pay connections are reported under the Open Bidding Direct demand channel.

AdOps analysts and financial controllers must recognize two operational nuances when querying Open Bidding Direct metrics in GAM 360:

1. GAM Revenue Reflects Cleared Net Bids, Not Final Invoice Cash: Because Direct Pay runs on net-bidding mechanics, the revenue reported under Open Bidding Direct in GAM represents the sum of winning net bids transmitted by the SSP. It does not automatically subtract Google's monthly %-media platform fee (which is billed separately on the GAM 360 monthly invoice), nor does it account for any impression clawbacks or billable-event discrepancies determined by the SSP's own ad-measurement ledger.
2. Billable Event Alignment: In standard Open Bidding, Google governs the billable impression count (typically rendered impressions measured by GPT/SDK viewable_impression or ad_rendered pings). In Open Bidding Direct Pay, while GAM logs the rendered impression under Open Bidding Direct, the publisher's actual payout is governed by the terms of the direct SSP contract. Any discrepancy between GAM's rendered impression beacon and the SSP's win/billing notice tracker directly impacts effective yield.

To monitor true net yield across all demand channels and audit the financial efficiency of Open Bidding Direct Pay against Prebid and AdX, data engineering teams should run automated daily reconciliations over GAM BigQuery Data Transfer tables joined with SSP reporting APIs.

WITH gam_channel_summary AS (
  SELECT
    DATE(impression_timestamp) AS report_date,
    demand_channel,
    yield_partner_name,
    COUNT(1) AS rendered_impressions,
    SUM(net_revenue_micros) / 1000000.0 AS gam_reported_net_rev_usd
  FROM
    `project_id.gam_data_transfer.NetworkImpressions_12345678`
  WHERE
    DATE(impression_timestamp) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) AND CURRENT_DATE()
    AND demand_channel IN ('AD_exchange', 'OPEN_BIDDING', 'OPEN_BIDDING_DIRECT', 'HEADER_BIDDING')
  GROUP BY
    1, 2, 3
)
SELECT
  report_date,
  demand_channel,
  yield_partner_name,
  rendered_impressions,
  ROUND(gam_reported_net_rev_usd, 2) AS gam_net_rev,
  -- Apply contracted Google %-media invoice fee (e.g., 1.5% = 0.015) to Open Bidding Direct
  ROUND(
    CASE
      WHEN demand_channel = 'OPEN_BIDDING_DIRECT' THEN gam_reported_net_rev_usd * (1.0 - 0.015)
      ELSE gam_reported_net_rev_usd
    END, 2
  ) AS post_google_fee_net_rev,
  ROUND(
    (CASE
      WHEN demand_channel = 'OPEN_BIDDING_DIRECT' THEN gam_reported_net_rev_usd * (1.0 - 0.015)
      ELSE gam_reported_net_rev_usd
    END / NULLIF(rendered_impressions, 0)) * 1000, 3
  ) AS effective_net_ecpm
FROM
  gam_channel_summary
ORDER BY
  report_date DESC,
  effective_net_ecpm DESC;

As the November 1, 2026 net-bidding deadline approaches, AdOps and yield engineering teams operating on GAM 360 should execute a three-step audit across every server-side demand partner. First, verify with each Direct Pay SSP whether their endpoint has already migrated to net-bid transmission, and confirm that your ads.txt, app-ads.txt, and sellers.json mappings reflect a direct PUBLISHER relationship. Second, calculate the break-even threshold between standard Open Bidding (5% display / 10% video deduction) and Open Bidding Direct Pay (your contracted GAM 360 %-media fee plus internal finance overhead for direct billing reconciliation). Finally, maintain a balanced hybrid topology that pairs client-side Prebid.js 11.x and Prebid Mobile SDK adapters with server-side Open Bidding connections, ensuring that high-value browser signals and low-latency server-to-server demand work in concert under a single, synchronized Unified Pricing Rule architecture.