漫谈广告流量分发策略:Waterfall & Header Bidding

流量,作为广告变现的基础,如何合理利用流量,充分发挥其最大价值,是每个广告从业者都会面临的问题。本文从ADX的角度,探讨流量流转中的分发机制,合理的分发机制可最大化流量利益,希望读者能从本文获取一些启发。

一、流量流转机制 

ADX(AD Exchange),广告交易市场,在流量流转流程中起承上启下作用,向上对接DSP,向下对SSP/媒体负责,借助其工作流程来了解广告流量流转机制,有助于我们更好的去理解流量过分发过程中可能存在的优化点。广告流量流转机制如下:

当前端App触发广告流量机会时,会将本次流量下发给其对接的ADX,流量属性中通常会带有广告位和用户信息等相关属性;

ADX在接收到流量请求时,首先会校验流量的合法性,最简单的就是参数校验,然后校验订单/DSP的预设值,最终将该流量下发给哪些DSP;

DSP接收到本次流量时,根据流量中携带的相关属性决定是否参与竞价,如果流量合适,则返回参竞价格(或者dealId)及广告元素给ADX;

ADX接收各家DSP竞价信息,在经过一系列的有效性判断之后根据价格竞价排序,价高者得之,将获胜的广告信息下发给媒体,同时通知DSP其广告获胜了(这一步非必需,但建议有);

媒体在收到广告信息后,对广告进行渲染展示。

当产生用户行为时,需通过监测链接回传ADX和DSP相关行为数据,主要的行为曝光曝光、点击、下载、唤醒等。

针对通过监测链接回传行为数据,有C2S(Client to Server)和S2S(Serverto Server)两种模式,目前大多数客户都投放时都要求C2S的上报方式。

其中关于ADX涉及的各关键指标在上篇《商化广告角色大盘点》中的ADX部分有所提及,本文旨在探讨流量分发机制,对指标不做过多的解释,感兴趣的读者可移步阅读。

通过上述流量流转流程可以发现,广告流量主要在ADX侧进行转发,如果ADX对接了多家DSP,合理的流量分发机制可以提升填充率及ecpm,使得流量收益最大化。

二、Waterfall 

当ADX对接了多个DSP时,在请求不同的DSP时,是该串行请求还是该并行请求呢?这里面就涉及不同的策略。

首先来说说串行请求,即Waterfall。Waterfall,中文翻译为“瀑布流”,字面意思理解就是“从上往下流”,但“从上到下”这四个字该如何理解?

在广告行业中,Waterfall指的是“在无法实时评估每次流量的价值时,基于历史eCPM数据,从上到下请求DSP,分发流量”。这就是所说的广告串行请求。

通过一个实际例子来看Waterfall的使用场景。假设ADX对接了三个平台,三个平台的eCPM和填充料分别如下:

假如有1000个广告请求,则有以下广告请求方案:

方案1:全部请求DSP1

收益 = 1000 * 20 / 1000 * 30% = 6

方案2:全部请求DSP2广告源

收益 = 1000 * 15 / 1000 * 50% = 7.5

方案3:全部请求DSP3

收益 = 1000 * 25 / 1000 *20% = 5

从上述的三个方案来看,虽然方案的eCPM最低,但其填充率最高,最终的总收益最高。那是否说方案2是最佳方案,答案肯定是不是的,因为其只利用了50%的流量,剩下50%的流量被浪费了,于是引申出了方案4。

方案4:先把1000个广告请求全部请求 DSP3 ,把未填充的部分请求 DSP1,最后未填充的部分请求DSP2,具体流量分发流程图如下。

收益 = 1000 * 25 / 1000 * 20% + 800 * 20 / 1000 * 30%+560 *15/ 1000 *50% = 14

方案4最终的收益14元,填充率为72%,相对于前三种方案,既提升了收益,又提升了填充率。

那既然看着收益和填充率都上去了,是不是采用Waterfall就可以解决流量分发问题了呢,现实总会让你啪啪打脸。Waterfall的方案主要存在以下几个问题点:

Waterfall的核心点在于“历史eCPM的数据”,那么如何去衡量一个dsp的历史eCPM数据,这个历史是多久?

串行请求会增大广告展示耗时,平均请求一次至少在100ms以上,多次请求会造成前端展示延迟,用户体验感较差。由于不同广告位的环境不同,用户可接受程度也不一样,需要分广告位设置整体请求次数/超时时间。

由于Waterfall 的请求优先级是根据历史eCPM数据来决定优先级的,针对某次具体请求时,可能排在前面的DSP出价没有后面的出价高。这样一来就会错过排在后面的出价更高的DSP广告,流量利益没有获得最大化。

各个DSP的eCPM数据维护,由于季节性问题,eCPM的数值会发生变化,需要运营同学手动维护,成本较高。

这里关于“历史数据的eCPM”,咱们展开讲一下:

这个历史是多久?这个问题是没有标准答案的!因为每个DSP的效果不一样。

我们唯一能够做的就是尽去预测每家的eCPM以及填充率,这可以通过历史数据去验证,也可以通过商务关系去了解,只有得到了正确稳定的数值,对我们来说才是真实可靠的。3天、7天、10天或者更久都是ok的,只要你认为这个数字是合理的,经得起推敲就可以。

对于新对接的DSP,由于其无历史数据积累,需要如何评估其eCPM值呢?

可以通过商务运营渠道了解其eCPM和填充率情况;

可以针对新对接的DSP进行流量扶持,积累一定的数据后回归入正常的DSP进行排序。这个流量扶持的周期和样本数据,各家算法团队的要求不太一样,能满足自身业务即可。

如果对于两个DSP,他们的eCPM和填充率都一样的情况下,如何排序呢?此时可以从其它纬度来评估,例如接口响应时长,素材质量等方面去考量。

三、Header Bidding 

既然Waterfall有诸多问题,那有木有其它替代方案?

读者肯定在想,如果每次竞价的时候,DSP都能实时返回本次出价,那么这样就不需要计算和维护“历史eCPM数据”了,在流量分发时,就可以并行的分发流量,在得到所有DSP的出价后,根据出价决定竞价成功者,这就是“Header Bidding”。

“Header Bidding”,中文翻译为“头部竞价”,字面意思理解就是“流量发给头部买家,头部媒体进行竞价,然后将获胜的底价作为底价去请求其它不支持实时竞价的DSP”。要想实现这个,首先得有如下几个前提:

头部买家在返回广告素材时,需要同时返回出价,这样媒体/ADX才可以完成竞价;

非头部买家虽然不支持实时返回出价,但需要支持传入广告位底价,这样如果有广告返回,那么价格一定高于底价,对ADX和媒体来说收益最高。

Header Bidding起源于国外,最初应用在PC上面。

DFP(Google Doubleclick For Publisher),国外PC网站集成最多的广告平台,由于其垄断了PC广告,加上Google的Ad Exchange dynamitc bidding(感兴趣的朋友百度了解),对Publisher和其它DSP很不友好,因此AppNexus希望联手其它的ADX/DSP一起通过Header Bidding技术来撼动DFP的垄断地位。

从上述的描述中可以发现,header bidding相对于Waterfall具备如下几处优点:

公平竞价:所有DSP同时竞价,各自评估流量价值进行出价;

收益最大化:原先排在Waterfall底部的DSP可以通过提高出价来赢得广告展示机会。

在国内,PC的发展已相对比较停滞不前,更大的潜力在移动端。因此更准确的说,国内的header bidding应该叫In-App bidding。

由于国内的In-App bidding起步较晚,目前只有几家头部媒体支持实时返回出价,因此在很长的一段时间内都会是headering bidding和Waterfall并存的方式,对于支持实时出价的媒体优先通过header bidding,然后将获胜的出价作为该广告位的底价去请求其它DSP,最终根据价格竞价。

四、总结 

其实无论是串行or并行,都只是解决问题的策略,核心目标只有一个“流量收益最大化”。

站在媒体方的角度,当然是希望越多的媒体同时竞价;

站在DSP的维度,必然是希望流量先发给自家,自家挑选完之后再发给其他家,甚至可能是流量独占。

当然现实中的环境错综复杂,不同的对接方式,也都会都会影响不同的策略,只有紧紧抓住“流量收益最大化”这个重点,兼顾多家利益,才能以不变应万变。

电商节各大电商争夺市场的时候,流量预算充足,为了多拿预算,流量优先分发给电商DSP;

某些DSP的eCPM和填充率都还可以,但是就是素材比较low,偶尔还可能涉及到黑五类广告,或者说技术上存在小坑(比如网络延迟高),此时针对这些DSP需要做流量限制;

某些DSP虽然eCPM不高,但是填充率还行,比较适合做保底填充,需要给予一定比例的流量养着;

……

PS:https://business.sohu.com/a/477343554_114819

你可能感兴趣的:(漫谈广告流量分发策略:Waterfall & Header Bidding)