做App或网站广告变现时，很多人都会遇到一个问题：
为什么接了多个广告平台，但高价需求不一定能拿到展示机会？
传统瀑布流（Waterfall）会按预设顺序依次请求广告平台。排在前面的广告源即使实际价格不高，也可能先填充广告位；排在后面的高价需求甚至没有机会参与。
Open Bidding要解决的就是这个问题：让多个需求方在同一次广告请求中提交价格，再由Google Ad Manager统一选择更有价值的广告。
这篇文章，我就用尽量通俗的方式，把Open Bidding是什么、为什么出现、它是怎么工作的一次讲清楚。
什么是Open Bidding？
Open Bidding 是 Google Ad Manager（GAM）中的一种服务端实时竞价机制。
当广告请求进入GAM后，GAM会把请求发送给符合条件的收益合作伙伴，如Ad Network。这些收益合作伙伴各自从其需求方中选出最高报价，并将结果返回 GAM。最后，GAM在统一竞价中决定哪一个广告获得展示资格。
可以把它理解为：发布商把多个外部需求方接入GAM，由GAM在同一次广告请求中统一比较报价和可交付的广告。
这里的“需求方”不一定是单个DSP。通常是GAM先向SSP或广告交易平台发请求，再由对方在自己的买方生态中完成内部竞价。
Open Bidding早期曾被称为Exchange Bidding。
Open Bidding如何工作？
一次广告请求的大致流程如下：
- 用户打开网页：广告位产生广告请求。
- 请求发送到GAM：可通过Google Publisher Tag、Google Mobile Ads SDK或IMA SDK等方式发送。
- GAM同时识别可参与的需求：包括符合条件的直销订单、Ad Exchange、Open Bidding收益合作伙伴，以及可能存在的中介广告源。
- GAM向Open Bidding合作伙伴发出竞价请求：每个SSP或广告交易平台在自己的平台内选择可用的最高报价。
- 合作伙伴返回报价和广告素材：通常每个合作伙伴针对该次曝光返回一个最高的有效报价。
- GAM 进行统一竞价：系统综合比较直销订单的交付需求、Ad Exchange报价、Open Bidding报价、底价、创意资格和其他投放规则。
- 返回获胜广告：最终广告素材返回网页或 App 并展示给用户。
Google官方将其描述为服务端到服务端的实时竞价：GAM会向符合条件的收益合作伙伴发送请求，并在统一竞价中比较外部合作伙伴、Ad Exchange 和直销订单的价值。
这里有一个容易误解的点：Open Bidding不是简单的“价高者得”。 最终结果还会受到保量订单、动态分配、底价、广告规格、创意审核、政策限制和收益分成后的净收入等因素影响。对发布商而言，GAM 的目标是选择符合规则且整体收益更高的结果。
Open Bidding为什么会出现？
在瀑布流模式中，发布商通常会给广告源设置固定顺序，例如：
- 广告网络 A：预估 CPM 20 元
- 广告网络 B：预估 CPM 15 元
- 广告网络 C：预估 CPM 10 元
广告请求会从上到下依次发送。问题是，广告网络A实际可能只愿意为这次曝光支付8元，但广告网络B或C可能愿意支付25元；由于B和C没有被请求，高价需求被错过了。
Open Bidding改变了这个逻辑：
- 不再主要依赖人工设置的顺序；
- 多个外部需求方可同时返回真实报价；
- GAM用统一竞价决定最终展示结果；
- 发布商更容易把第三方需求放进同一个收益决策流程。
因此，它的价值不只是“减少延迟”，更重要的是让广告价格更接近该次曝光的实际市场价值。
Open Bidding、瀑布流与 Header Bidding 的区别
| 对比项 | 瀑布流 | Header Bidding | Open Bidding |
|---|---|---|---|
| 核心逻辑 | 按预设顺序依次请求 | 多个竞价方并行报价 | GAM 向多个收益合作伙伴发起服务端竞价 |
| 是否并行 | 通常否 | 通常是 | 是 |
| 主要控制方 | App / 发布商的中介配置 | 发布商或 Header Bidding 平台 | Google Ad Manager |
| 常见技术方式 | SDK 或广告网络调用 | 浏览器端、服务端或混合模式 | 以服务端到服务端集成为主 |
| 适用环境 | App、网页、视频 | 以网页为主，也可用于 App / CTV 等 | 网页、App、视频等 GAM 支持的环境 |
| 主要代价 | 低价广告可能抢先填充 | 集成、延迟和运营复杂度较高 | 依赖 GAM、AdX 资格及支持的合作伙伴 |
最简单的理解是：
- 瀑布流：先问A，A不要才问B。
- Header Bidding：同时问多个竞价方，由发布商或竞价层汇总结果。
- Open Bidding：由GAM在服务端同时询价，再与GAM内的其他需求一起决定谁胜出。
所以，Open Bidding可以和Header Bidding达到类似目标：减少瀑布流造成的价格信息不对称。但两者的接入位置、控制权和生态不同。
Open Bidding 有什么优势？
- 统一管理外部需求：发布商可以在 GAM 中管理收益合作伙伴、投放条件、报告和部分结算流程，而不必为每个外部需求方单独维护复杂的前端竞价代码。
- 减少瀑布流的价格损失：多个参与者基于同一次曝光返回报价，高价值需求不必因为排在瀑布流后面而失去机会。
- 对页面和App的前端改动相对少：Open Bidding 会利用现有的 GAM 标签或 SDK 发起广告请求，外部竞价主要发生在服务器之间。相较于在网页中加载多个 Header Bidding Adapter，它通常对前端的额外负担更小。
- 可与GAM的直销和AdX需求一起比较：Open Bidding 并不是独立运行的孤岛。它可以进入 GAM 的统一竞价流程，与 Ad Exchange、符合条件的直销订单和其他需求共同参与广告选择。
Open Bidding 有没有限制？
Open Bidding 不是“接入后收入一定上涨”的开关，使用前需要注意几个限制。
- 依赖GAM合作伙伴资格：发布商需要具备相应的GAM/Ad Exchange使用资格，并与可用的Open Bidding收益合作伙伴建立合作关系。并非任何SSP都可以直接接入，也不是所有广告格式、地区和库存环境都一定支持。
- 控制权不如自建竞价体系：GAM负责统一竞价、合作伙伴接入方式和部分规则。对于大型发布商而言，这降低了运营复杂度，但也意味着对竞价逻辑、数据和供应路径的控制较少。
- 它不一定完全取代瀑布流：在实际的 App变现架构中，Open Bidding和中介瀑布流可能同时存在。部分需求方只支持瀑布流调用，部分需求方支持实时竞价。GAM也可能返回一个中介广告源链路，由App SDK再依次调用。
- 服务费用：Google会对Open Bidding的第三方需求方出价收取约5%–10%的服务费，这部分成本最终可能体现在发布商收益中。
Open Bidding适合谁？
它通常适合以下发布商：
- 已使用GAM和 Ad Exchange的网站、App或视频发布商；
- 希望引入多个SSP，但不想维护复杂Header Bidding前端方案的团队；
- 希望让第三方需求与GAM内部需求一起参与收益决策的发布商；
- 希望逐步从纯瀑布流迁移到实时竞价架构的App变现团队。
如果你是大型媒体集团，并且非常重视竞价规则、买方覆盖、供应路径和数据控制，也可以采用混合模式：保留 Open Bidding，同时部署Header Bidding 或其他自建竞价能力。
总结
Open Bidding是GAM内的服务端实时竞价机制，不是“移动端 Open Auction”的同义词，也不等于Header Bidding。
它解决的核心问题是：让多个外部需求方的真实报价进入同一次广告选择，而不是按照瀑布流顺序逐个碰运气。
但它并不天然保证收入增长。真正决定收益的，仍然是需求质量、可参与的合作伙伴、库存价值、底价策略、直销订单、广告体验和供应链管理。
