如果您在应用变现领域工作过一段时间，您一定听过"open bidding"和"header bidding"这两个术语被几乎互换使用。它们的目标相同——在各需求源之间创造实时竞争以推高eCPM——但底层工作方式不同。理解这些差异是为您的应用选择正确方法的关键。
什么是header bidding？
header bidding起源于网页广告，发行商在网页的"header"中添加JavaScript代码，以在向主广告服务器发出广告调用之前同时向多个需求合作伙伴请求出价。最高出价者胜出，由此创造出真正的竞争，并消除了需求源被逐一调用的顺序waterfall问题。
在移动应用场景中，header bidding通过客户端SDK工作。每个参与的需求合作伙伴都有一个SDK集成到您的应用中。当广告机会出现时，所有SDK被同时调用，各自返回一个出价，最高出价胜出。AppLovin MAX和Unity LevelPlay都通过其in-app bidding功能支持这种模式。
什么是open bidding？
open bidding（前称Exchange Bidding）是Google的服务器端替代方案。它不通过多个SDK在用户设备上运行拍卖，而是在Google的服务器上运行拍卖。需求合作伙伴连接到Google的基础设施并以服务器对服务器的方式提交出价，从而消除了在客户端进行单独SDK集成的需要。
open bidding通过Google Ad Manager提供，可让您接入Google庞大的需求生态系统以及已加入该计划的第三方交易平台。
关键差异
延迟
这是最显著的实际差异。客户端header bidding要求每个SDK发起网络调用、处理拍卖并返回出价——所有这些都在用户设备上完成。SDK越多意味着处理时间越长。open bidding以服务器对服务器方式运行，通常更快，并且不消耗设备资源。对于广告加载速度直接影响用户体验的应用来说，这一点至关重要。
SDK复杂性
每个header bidding合作伙伴都需要在您的应用中集成一个SDK。更多的SDK意味着更大的应用二进制包、更多潜在的SDK冲突，以及在SDK需要更新时更大的维护开销。open bidding只需要Google Mobile Ads SDK，需求合作伙伴在服务器端连接。这大大降低了技术复杂性。
需求多样性
通过AppLovin MAX等平台进行的header bidding让您能接入广泛的广告网络，每个网络都有自己的广告主关系和需求。open bidding让您接入Google的需求以及参与的交易平台，但参与合作伙伴的范围小于通过客户端bidding可获得的范围。最优方法通常是两者并用。
透明度
客户端header bidding让您完全实时地看到每个合作伙伴的出价。您可以准确地看到每个网络的出价、谁胜出以及原因。open bidding通过GAM提供报告，但拍卖发生在Google的服务器上，这让您对bidding过程的实时细粒度可见性略低。
您应该选择哪一个？
坦率的答案是：大多数成功的发行商两者都用。以下是一个实用框架：
使用通过GAM的open bidding作为您的主要拍卖机制。它以最小的SDK开销和快速的广告加载提供强劲的需求。然后通过您的mediation平台（AppLovin MAX或Unity LevelPlay）补充两到三个表现最佳网络的客户端bidding，以确保最大的需求多样性。
产生最高广告收入的发行商并不是在open bidding和header bidding之间做选择——他们是将两者结合在混合方法中，以最大化竞争，同时将技术复杂性控制在可管理范围内。
混合方法的实践
在典型的混合设置中，您的waterfall是这样的：通过GAM的open bidding与两到三个in-app bidding网络并肩竞争。在此之下，您有面向不支持实时bidding的网络的传统waterfall条目。托管需求合作伙伴可以位于该堆栈的任何层级，提供额外的竞争，无论正在使用哪种拍卖机制，都能让您的整体收益受益。
关键是不要把它搞得过于复杂。从通过GAM的open bidding开始，加入您的mediation平台上表现最佳的bidding合作伙伴，并与托管合作伙伴合作来填补空缺。然后根据数据告诉您的情况进行优化。