开发者俱乐部

标题: Header Bidding：程序化交易的一股泥石流 [打印本页]

作者: xman 时间: 2016-11-11 08:07
标题: Header Bidding：程序化交易的一股泥石流

　　什么是Header Bidding?它的目的和原理如何?发展前景又如何呢?在一个秋风萧瑟的下午，我们与AppNexus负责Header Bidding产品的Paul Yang相对而坐，向他请教这项今年异军突起席卷了程序化广告市场的新技术。我们将从Paul那里捋来的一些皮毛整理成此文，以飨读者。
　　先来看看trends.builtwith的统计数据，感受一下世界范围内媒体网站对Header Bidding的需求。如下图所示，从2016年2月到9月，使用此技术的媒体网站的数量几乎是爆发式增长：仅仅一年时间，就有超过40%的头部网站采用了Header Bidding技术。有趣的是，还有一家著名的SSP公司，因为没有及时拥抱Header Bidding技术而躺枪，导致股价暴跌。(具体是哪家自己查。)说这是程序化交易的一股泥石流，恐怕不为过吧?

　　程序化交易这种透明交易机制的形成和完善，为广告主的效果和媒体的变现都提供了新的想象空间。然而，这个市场中起决定作用的不只是技术，还有商业利益上的博弈。随着Google、Mopub等在Adx市场的地位日趋垄断，它们几乎独揽了实时竞价中流量分配的大权，导致广告主和媒体间的供需出现了不小的问题。在收益最大化的驱使下，市场驱使广告主和媒体联合起来打破垄断，这便催生了Header  Bidding技术。
　　抛开技术细节，Header  Bidding产生的市场原因是什么呢?曾子曰：哪里有压迫，哪里就有反抗。简单来说，程序化交易市场看似公平透明，可是垄断者Google、Mopub等在分发流量时，一来徇私舞弊(都会偏袒自己的内部广告主)，二来捐税太重(Mopub收取高达40%的费用)，广告主和媒体的利益受到了损害。其实别的都不用做，只要绕开Adx，就可以多出不少的利润。
　　在这样的利益驱动下，媒体与DSP一个是干柴，一个是烈火，产下了了他们爱情的结晶Header  Bidding：倘若DSP和媒体能够建立直连，DSP便有机会在实时竞价开始之前向媒体直接报价，媒体网站根据出价高低决定中标DSP，如果没有，再交由Adx进行实时竞价也不迟。这样一来，媒体网站重夺竞价权利，有助于提高CPM;DSP的广告也有处更多自由选择机会，保证了买方市场;最关键的是，如果竞价成功，便可把ADX/SSP那一份中介费也给省了。
　　下面我们回到产品层面，看看Header Bidding的流程究竟有何不同呢。先花一分钟时间回忆一下传统的Real Time Bidding的流程。

　　1.用户接触到媒体网站的广告位时，前端向ADX发起广告请求。(图中2.1)
　　2.ADX向各DSP传送URL(或应用ID)和用户标识，发起询价请求。如果是Web环境，DSP还要根据cookie mapping查出对应的已方用户标识。随后，DSP计算并返回自己的出价。ADX选出出价最高的DSP返回给媒体网站。(图中2.2)
　　3.媒体网站从胜出的DSP拿到广告创意并展示。其中2.2， 2.3两步可以合并为一步，即DSP同时返回出价和广告创意地址，由ADX返回给媒体。(图中2.3)
　　在RTB中，询价和竞价的过程是在服务器端完成的，要绕开ADX，就要在客户端做点儿手脚，下面是Header Bidding的询价和决策过程：

　　1.用户访问媒体页面，向媒体服务器发起HTTP请求。
　　2.媒体服务器将实现Header Bidding功能的脚本hb.js放在HTML的head标签中，该HTML作为HTTP  Response发给用户浏览器。
　　3.用户浏览器在解析HTML时，将媒体网站配置好的hb.js下载到本地。在hb.js的控制下，用户浏览器向媒体网站约定好的Bidders发起本次曝光机会的竞价请求，Bidders将报价返回给用户浏览器。
　　4.在hb.js控制下，用户浏览器将各家Bidder报价信息回传给媒体网站。
　　5.媒体服务器同时向ADX或SSP发送广告请求。
　　6.ADX或SSP发起RTB过程并获得广告候选。
　　7.媒体服务器将Header Bidding出价结果和RTB出价结果放在一起进行排序，出价最高者赢得本次广告展示机会，用户浏览器请求胜出方加载广告。
　　注意，上面的最后一步有一个容易被忽略的小问题：怎么才能将ADX/SSP返回的广告与HB返回的广告竞价呢，要知道Google可不会配合你给出报价。这里有两种办法：第一种方法，是跟ADX谈判，晓之以理动之以情，希望它从民族大义出发配合出价，可这对ADX来说，有点儿被卖了还帮着数钱的意思;第二种方法，是将HB返回的最高价格作为底价，再让ADX以此底价发动RTB。这两种方法各有优劣，我就不具体分析了。
　　简单说吧，媒体先劫道儿，留下了买路财以后，再放给ADX处理。这是一种什么样的精神，这是一种肥水不流外人田的精神!而Header  Bidding的快速发展，核心驱动力就在于在客户端多劫了一道，留下了利润，吃点儿什么不香啊!
　　对比RTB与Header Bidding的流程，可能您会有下面的问题：
　　1.Header Bidding是加强版的RTB吗?
　　形式上可以说是如此。当用户访问媒体网站之后，媒体网站首先进行Header Bidding，然后进行RTB，将两次竞价结果综合到一起，价高者胜。
　　2.Header Bidding和RTB的区别是什么?
　　主要区别在于询价请求是谁发出的。在RTB中，询价请求是由SSP或ADX发出的;而在Header  Bidding中，询价请求是由用户浏览器(客户端)发出的。
　　3.哪里可以体现出媒体和DSP的联手反垄断?
　　答案在hb.js中。在Header  Bidding过程中，hb.js起核心的控制作用。用户浏览器该向哪个Bidder发竞价请求，都是媒体网站同这些Bidders提前商量好后写进hb.js的配置中。
　　4.Header Bidding存在的意义是什么?
　　作为卖方，媒体网站提高了竞价密度，有助于提升CPM;作为买方，Bidders有了新渠道，有助于提升ROI。买卖双方携起手来，打破垄断，降低了渠道费用。
　　这么说来，有了Header Bidding，程序化交易市场的面貌就能焕然一新了吗?这未免过于乐观了。Header  Bidding的产生和快速发展，主要是由于市场博弈的原因，从技术上来看并不见得是完美的模式，具体表现在以下一些问题上：
　　1.客户端竞价的可行性如何
　　HB采用客户端竞价的方式，媒体网站和广告主得利，但与之共存的高延时极大的降低的用户浏览该媒体网站的兴趣，媒体网站曝光减少，Bidders还愿意来投广告吗?
　　2.HB能否真的突破ADX垄断
　　客户端竞价高延时的短板使得HB陷入了一个十分尴尬的境地。不用吧，市场有链接买卖双方的需求，商业潜力巨大;用吧，对用户体验又有伤害。这样看来，HB并不足以戳中G点。如果    也改用服务端竞价，那和RTB还有什么区别?
　　要说大家最关心的问题，莫过于HB在中国市场的发展前景如何。答案倒也简单：发展空间不大。因为HB的出发点，是要打破ADX垄断，通过劫道提高利润，但是在国内，大媒体通常是自己开发SSP，自己对接DSP，媒体打破媒体的垄断，自己革自己的命，这不是大饼卷手指头自个儿吃自个儿么?
　　如果您想试一试HB方案，可以参考AppNexus的开源实现Prebid.js(http://prebid.org)，这是一款开源且免费的JavaScript框架，它帮助媒体网站轻松实现Header  Bidding的部署，并且方便需求方的接入。Prebid.js有以下特性：
　　支持市场中大多数的Bidders，也包括了大多数的ad server。
　　针对大多数媒体网站遇到的问题都有成形的解决方案，例如：高延迟、不公平竞价机制和较长的研发周期等。
　　可以在JSON中配置Bidders，简化prebid.js配置过程。
　　开源，免费
　　从技术上看，Prebid.js由若干功能模块组成，我们也简要介绍下这些模块和他们的主要功能，方便码皇们了解：
　　异步请求模块
　　配置Prebid.js，使其拥有一个或多个Bidders(可以是DSP、SSP或广告网络等任何可以参与竞价的服务)
　　页面加载时，Prebid.js异步向这些Bidders发起竞价请求。
　　页面定时器模块
　　可以设置定时器来避免Bidders占用太多时间。若某个Bidder超时，则忽略该Bidder的响应。
　　键值对模块
　　Bidder返回竞价时，Prebid.js将竞价和创意ID构建成带参字符串传递给广告服务器。
　　Line Items模块
　　在广告服务器内部，Line Items主要用于参数解析和竞价排序。
　　创意组件
　　竞价排序完成后，该组件用于告知Prebid.js去获胜的Bidder处加载广告。
　　拉拉杂杂说了这么多，简单总结一下：Header  Bidding如泥石流般席卷程序化交易市场，颇有点儿无心插柳的意思。这件事再次提醒我们：广告技术本质上是为商业服务的，商业上是否有新的价值产生，远比技术上的进步和合理更加重要，此事望诸君切记。

欢迎光临开发者俱乐部 (http://xodn.com/)