头部竞价的优势

对比瀑布流和头部竞价，最简单的解释当然就是，在瀑布流中，竞价是按顺序进行的，而在头部竞价中，是以单次、统一的方式完成的。

对我来说，主要区别之一在于实时竞价。

在瀑布流设置中，发行商必须在不同的底价设置中，针对多个需求合作伙伴，设置多个标签，采用不同的费率、不同的定向、不同的回传标签。当完成所有设置后，这些合作伙伴就必须管理好这些标签、更新费率和定向、更改回传。工作量很大，需要一支完整的广告运营团队，如果是一人单干，会非常忙。

然后头部竞价来了。头部竞价让发行商可以进行一次性设置，在统一的竞价中，为他们实现多个需求合作伙伴的实时价格竞争。随着头部竞价的到来，真正与瀑布流设置不同的是，您的需求合作伙伴能够提出（并竞争）他们认为库存所值得的价格。

采用瀑布流设置时，广告服务器中的所有价格都是静态的、过时的。随着头部竞价到来，每一分钱加价上都要竞争，这一举改变了市场上的巨头格局，即使是最大需求合作伙伴，也要花更多功夫、更高价钱，才能赢得一次展示。

我认为最大的优势是实时定价，但还有其他优势。瀑布流设置需要大量的时间和实操管理，来检查广告服务器与发行商投放的标签之间的差异。当需求合作伙伴未能填充时，还需要对回传标签进行大量管理。

头部竞价消除了这些问题。虽然也要做一些差异检查，但大多数情况下，头部竞价差异很低，不到5%。

此外，采用瀑布流方法，多个标签会导致网站或应用的延迟增加。 头部竞价的同时叫价可为大多数发行商改善延迟，有助于减少标签来回的时间。

头部竞价的最大优势是发行商能够查看的所有可用库存，而不像在瀑布流中那样，只能看到发送给他们的库存。实施头部竞价系统时，需求合作伙伴可以获得我们所说的“第一优先级”，使他们能够看到其广告主正在寻找的最有价值的用户。所以我认为，主要的好处是，过去他们无法获得的库存，现在开放了。

比方说吧，某些是头部竞价方是由特定的供应方平台（SSP）运行的，而这些头部竞价系统会有点倾向于堆栈中的某些需求合作伙伴。

Prebid是一个开源的解决方案，它不会偏向于某个特定的需求合作伙伴，因此发行商更容易信任实际代码本身。

因此，在实施像Prebid这样的头部竞价系统时，发行商可以获取需求源中数百甚至数千的各种适配器，可以在网页或者应用中实施。

此外，由于Prebid是单一代码源，发行商可以将特定参数传递给所有需求合作伙伴（如底价或供应链）。这对买家是有用的信息，可以帮助他们提交最优惠的价格。

使用头部竞价解决方案时，eCPM也往往更高，因为需求合作伙伴能够根据他们愿意支付的实时价格提交出价，并且出价是同时进行的，而不是按顺序进行，这意味着所有出价中最高者可以中标。

那老实说，我认为主要原因是前期成本。对于应用库存而言，真正实现头部竞价解决方案的唯一方法，是通过服务器实现，而服务器要花钱。为了连接Prebid服务器，您要么需要自己的服务器，并在该服务器内进行竞价，要么付费使用第三方托管服务器。这两种选择都需要投资（尽管自有服务成本更高，因为需要开销、管理成本、维护）。

我们最近看到很多第三方都推出了Prebid托管解决方案，因此，我们开始看到更多的头部竞价采用。

我认为除了成本之外，Prebid服务器并没有得到需求合作伙伴那么多的初步采用，因此没有构建很多适配器。这一点已经改变了。随着需求合作伙伴的采用率提高，发行商的采用率也在增加。我认为我们将在2022年看到更高的Prebid服务器采用率，特别是因为头部竞价解决方案的众多优势，其带来的收入增加，可以超过实施成本。

如同市场上所有的SSP一样，我们拥有自己的适配器，用于客户端和服务端的prebid头部竞价。我们还连接了其他第三方头部竞价解决方案。我不会透露具体的名字，但市场上还有其他与我们有联系的第三方。因此，如果您想尝试实施头部竞价，我们可以帮助您使用Prebid或其他第三方。

我们也有自己的头部竞价解决方案，称为统一竞价，内置在我们的SDK中。我们让发行商可以更简单地从瀑布流切换到头部竞价解决方案，获得更多优质、全球的需求。