联盟广告市场的变革——Header Bidding能力详解！
发布时间：2023-01-13 11:29:11
Header Bidding，中文叫头部竞价。不算是什么新的技术能力，国外桌面PC端2016年开始，已经成为了PC联盟广告的标准。始于PC端，但在海外移动互联网场景，去年Google Admob Open Bidding 和Facebook Audience network In-App Bidding已经支持这样的竞价方式。
广告行业有一个趋势，凡是在海外比较流行的广告模式和技术，总有一天在国内也会蓬勃发展起来，比如说oCPM广告模式以及激励视频广告，当然也包括现在的Header Bidding或者说开放 Bidding。
第一次接触到Header Bidding，大概在2016年左右，恰同学少年，风华正茂，书生意气，挥斥方遒。那时我还在百度搞国际化商业化广告变现，所以对这个新的技术解决方案有一定的研究和了解。没想到一晃5年，Header Bidding 在国内终于有点动静了。
要想了解一个技术方案，首先要了解这个技术方案所面对的核心痛点或者问题。把问题清楚的写下来，问题就解决了一半。
Header Bidding的存在的痛点及其产生的由来
1. 海外Header Bidding 的由来
海外HeaderBidding起源于桌面广告领域——这项技术方案发起的初衷是为了对抗Google的Ad Exchange dynamitc bidding。Google靠自己的DFP（Doubleclick For Publisher）几乎垄断了桌面广告领域，DFP要求广告主必须要接入其RTB的广告交易平台，而不允许广告主和流量直接对接。同时垄断者在分配流量的时候主要做两件事，一是出价不透明，容易偏袒自己内部的广告主；二是分成比例较高。在这等情况下，媒体和广告主都不太满意。
只要有利可图，就一定会有人去做。于是，就有了Header Bidding的广告模式。
桌面广告领域率先推出了Header Bidding，头部竞价。最早的发起者是 appNexus。AppNexus希望联手其它的SSP/ADX，一起通过开放的方式，撼动DFP的垄断地位。因此该技术方案，获得了很多程序化购买SSP/ADX的支持。
Header Bidding 新建一套广告主与媒体流量方的对接协议，让每次的广告的请求优先请求支持Header Bidding的广告主或者DSP。媒体流量方获取广告返回之后，又用Header Bidding返回的广告的价格作为底价去请求DFP等其他广告联盟平台。若其他广告网络无高于此价格的广告返回，则曝光Header Bidding 的广告，若有返回高于此价格的广告，则曝光DFP等广告联盟的广告。
Header 是“标头”和“首标”的意思，意味着支持Header Bidding的广告主有优先选择流量优先出价的权利，从实际的链路逻辑上来看也是这样，具体逻辑如下图：
在这里必须要补充一个知识点，就是联盟的广告模式，每次广告展示的价值是多少钱，无论是桌面广告联盟还是移动广告联盟，在2019年之前都是没有返回给媒体流量方的，但他们支持以某个底价的方式去请求广告，若有广告返回，则表明这个广告的底价是高于某个值，但实际具体多少，并没有清楚的告诉媒体流量方。
2. 国内的Header Bidding要解决的痛点：
国内联盟广告的核心痛点就是每次广告联盟返回给媒体流量方的广告信息是不能直接知道当次曝光的广告价值。
国内移动互联网发达程度远超英美，PC流量已经增长停滞，联盟的广告模式主要也是以移动端流量为主。国内主要的联盟广告平台主要有百度联盟，字节的穿山甲以及腾讯的优量汇，当然，也有其他规模小一定的联盟，比如快手联盟，手机厂商流量联盟等。
有做过移动广告变现联盟的同学都知道，国内联盟主要以接入SDK为主，流量变现核心痛点是不知道每次请求获取的广告的价值。媒体方要查看其流量的变现价值通常是T+1的离线报表方式。
联盟SDK在每次返回广告的时候都没有明示价值，这使得媒体流量方无法根据实时的广告价值来对不同的联盟SDK进行选择。很多聚合SDK主要的策略是通过瀑布流方式（Waterfall——下文会详细说明）的进行变现。或者通过配置不同联盟SDK流量比例和优先级进行变现。
通过Waterfall 的方式或者配置不同联盟SDK比例的方式都需要投入大量的人力进行用户的分层和运营策略的配置。而且，联盟的历史变现效率不是一成不变的，导致配置的策略还不一定是最优的。
国内联盟的Heeder Bidding 就是为了解决这个痛点，目前已有多家主流的联盟广告平台在测试这块的能力。
它驱使每个联盟SDK在每次广告返回的时候不仅将广告曝光所需的素材信息返回，还必须带上当次广告请求的广告价值！媒体流量方可以聚合多个联盟，通过各个联盟返回的广告和价值进行实时竞价，挑选价值最高的广告进行曝光，从而使得流量价值最大化。
国内的Header Bidding 准确的来说是In-APP Bidding 或者Open Bidding。这个Bidding 的逻辑，会使得广告媒体的变现效率有所提升，同时也加剧了国内多家联盟广告平台的竞争，真正到了拼刺刀的环节。
聚合SDK Waterfall 与 Header Bidding的不同点
不同用户量级的公司变现策略有很大的不同。我们先来了解下大部分变现媒体公司的做法。
一般的流量媒体方进行变现都会聚合接入多个广告SDK的逻辑来变现。百度2015年的时候在海外变现就搞了一个聚合广告SDK—DAP。运营策略和思路都很时髦，放在现在的国内也是一骑绝尘的。只可惜成了前浪和先驱。
流量媒体会使用聚合SDK进行变现，常用的广告策略是Waterfall，即瀑布流。瀑布流存在的基础是广告SDK只提供基于某个价格为底价获取广告的接口能力（媒体以底价请求广告联盟，联盟后台返回的广告必须高于底价）。
由于广告联盟SDK在返回广告的时候是没有返回当次曝光的广告的预估价值（即eCPM），但联盟支持以某个底价去请求广告的，所以，为了追求流量价值的最大化，衍生出一种叫瀑布流（Waterfall）的变现策略逻辑。
流量媒体方根据不同广告联盟最近的变现效率表现设置Waterfall排序。
Waterfall的广告策略方案，主要解决两个问题：
1）不断的分价格段位去试探不同广告联盟SDK的广告填充率。
不同的联盟SDK广告价值的分布是不同的，媒体流量方根据历史的经验设置请求优先级（请求顺序），对广告联盟进行分层请求。
分层请求的优点是，能够根据当前媒体场景流量的情况获取价值更高的广告。有同学会问题，能不能同时以某个底价去请求广告呢？结论如下图，当然是不可以。若以15元的底价来请求联盟A和联盟B，这时候两个联盟都有返回，你无法更有效的判断哪个广告价值更高。
举例个例子，比如有多家广告平台，P1的ecpm为20，P2的eCPM为18，Waterfall顺序就是：P1 > P2。通常集成5-8家广告平台，通过广告分层的方式尽可能保证填充率和提升收益。如上图，多个SDK只是顺序和请求策略配置不同，基本的逻辑是一样的。
Waterfall 能相对较好的解决不同联盟平台变现效率差异以及提升填充率的问题。但这里又带来了2个新的比较重要的问题：
1) 历史的变现效率不代表当次真实的广告价值，所以你设置的优先级不一定对。
由于广告主投放都是实时生效的，很难排除某些广告主为了在某个广告平台上获取更多流量而提升出价。比如联盟A优先级第一，当次请求20块，有广告返回，当次曝光机会给了联盟A。但是实际上联盟B由于广告队列的变动，广告价值当次实际上有25，但是由于历史优先级比联盟A低而无法获取当次广告的曝光机会。
2) 广告请求耗时过长
为了更好的精细化运营同时使得获取的广告价格分布更加“准确”，Waterfall的广告请求通常是串行来请求的，这个使得广告请求到返回的耗时非常长，无法满足某些场景下及时广告曝光的诉求。
应用闪屏的广告曝光是500毫秒-1s必须返回，信息流场景的返回时长限制则是毫秒级别的。Waterfall的广告策略模式会让广告请求到曝光的时长增加很多，在很多场景下都无法满足快速填充广告的诉求。（短时间内的预加载可以稍微缓冲一下这个问题）
Header Bidding 或者说实时Bidding 解决了以上的流量媒体变现的这个两个问题。
Bidding的协议，要求联盟广告平台在SDK 或者 API 后台上返回每次广告请求的曝光价值，这样就在联盟变现场景上产生了类似实时竞价RTB的逻辑。
媒体流量方可以根据自己的需求选择需要接入的广告联盟SDK，从而更好的提升广告的变现价值和填充率。
同时，Header Bidding 使得联盟聚合平台有更多操作的空间，无论从变现效率的能力、策略和数据，都有很多优化的点。
不过，由于HeadeBidding 在国内才刚刚开始，预计在较长的时间段内，应该是Bidding 与 Waterfall 并存的情况。
开放Bidding的变现方式对于联盟平台也不一定是坏事，比如像Google Admob Open Bidding，可以通过Open Bidding 获取到其他联盟的广告变现效率和素材情况，从而进行针对性的优化，再结合其丰富的广告主资源，就可以做到强者恒强。
对于媒体流量方而言，可以知晓每次广告请求的最大价值，同时可以对用户价值更好的识别，那么在增长LTV这个点上就有一个更好的预估，能更好更精细化的做用户增长策略。
下面主要讲述的是Header Bidding或Open Bidding 带来的广告竞价和对接方式的变化。
联盟广告的初衷是，中小流量方由于流量规模不大，缺少商务团队以及广告系统技术能力，无法很好的搭建自有的广告系统，需利用大型的广告平台比如Google、Facebook、腾讯、字节等强大的广告系统能力和商务能力进行流量的变现。
在联盟广告市场中，中小流量方无需自己搭建广告平台，无需对接各种不同的广告主而进行流量的商业变现，相当于将技术和商务对接能力交给了一个可长期服务的合作伙伴。而联盟平台则通过对外提供广告变现的能力获取到更多的流量更好的服务不同的广告主，同时收取一定的服务费。可以说，联盟广告是一个双赢的商业模式。
实际上，国内Open Bidding 方案发展最终会变成怎样，取决于头部各家联盟的开放程度以及技术支持能力。OpenBidding 会引起流量媒体方在竞价逻辑以及广告链路上的变化。
不同用户规模的媒体流量方，对于广告联盟的诉求是不同的。
衡量一款推荐产品的能力的重要指标是其对用户的推荐颗粒度的精细运营能力，近几年很火的概念叫“千人千面”其实就是对用户颗粒度的不断细分。同样，衡量一个联盟的经营能力的重要指标除了变现效率，就是其对合作伙伴经营的颗粒度。
用户规模较大的媒体流量方，一方面会自建广告平台，建立自己的广告客户和广告系统，搭建属于自有的广告链路能力，同时通过接入广告联盟补充广告源提升广告填充率。
用户规模中小的媒体流量方，则会直接接入广告联盟SDK，通过聚合多个联盟SDK和调整策略的方式力求流量价值的最大化。中小规模流量方通常主要在广告策略上进行相对简单的调整，整个广告链路都会托管给SDK进行处理。这样可以将人力更加集中在产品的优化上。
不同的分层客户，需要不同的联盟对接方式。
整体来说，广告流程都是：广告从客户端进行请求，从联盟广告平台上获取到广告，进行竞价，继而进行广告的曝光和转化链路。
媒体流量方与联盟广告平台进行对接的路径中主要有两个核心的变化因素，如下图：
1）广告竞价在服务端还是在客户端；
2）广告的曝光和广告转化链路是直接调用SDK还是进行自建广告样式（类似纯原生广告样式）并搭建广告链路。
广告竞价能力在服务端会更有优势，但并不是所有联盟都支持。
竞价的逻辑在服务端，从逻辑上看优势更多，使得在广告的竞价逻辑上更轻。同时更好的进行广告策略的调整和运营，灵活性要更好，更新速度快。若在客户端，则每次的竞价逻辑的改动都需要更新应用版本，更新速度慢，版本覆盖不全，维护成本很高。所以，理论上，如果条件允许，一般竞价逻辑最好还是放在服务后台。
那么在客户端竞价的逻辑，主要出现的场景是，联盟广告平台只对某些中大型媒体开放服务端Bidding的能力。中大型媒体体量大，研发能力较强，服务较为稳定，所以针对部分客户是可开放服务端bidding的能力的。
小型的媒体流量方，都是通过聚合多个SDK的方式提升广告的填充率和变现效率，那么这个时候，就只能在客户端进行比价的操作逻辑了。客户端使用的是联盟SDK统一的广告能力，对于联盟广告平台来说也会更加的可控。
比如Google admob Open Bidding 聚合了多个SDK，并没有通过服务端进行对接，因此这个竞价的逻辑只能在客户端进行。
在客户端进行竞价，整个广告策略逻辑在客户端代码上就非常重，调整不灵活，数据问题的排查依赖于大量的数据上报。
广告曝光和转化链路直接调用SDK更加可控，而自建广告链路则相对灵活
广告的转化链路主要包括广告曝光，点击，落地页加载，广告转化等步骤的能力以及数据上报。这一系列的功能需要保证广告能力的稳定和数据上报的准确性，使用统一的SDK封装的链路能力和数据上报能力的是最好的方式。
联盟广告SDK在广告链路上实际要处理很多重要的能力，广告归因ID上报，广告核心行为数据上报统计，广告落地页加载速度优化，广告下载能力优化以及广告反作弊能力的相关数据识别和上报。
中小流量方，一般不太建议单独自建广告链路，直接使用SDK封装好的能力是最简单快速的变现方式。
自建广告链路，流量媒体方从广告联盟平台上获取的仅仅是广告的价值（ECPM）以及广告素材、文案、落地页等相关的原材料，媒体方需要实现广告整套的转化链路和数据上报，同时通过原材料组装广告的样式。对于中大型媒体来说能更好的补充广告源，同时广告样式可以更灵活的调整和配置。
问题则在于，广告联盟平台对于这块的链路可控性太差，链路能力优化依赖于媒体方平台的配合。由于广告曝光也依赖于媒体方进行上报，一些在联盟广告SDK上可做的反作弊能力都无法有效的实施，因此对于一般的客户，联盟广告平台是不会开放API方式的能力给到媒体方的。
海外的移动广告中，有一种叫网盟的商业形式，代表公司有Appia，Mobopatner，glispa，Avazu，IronSource，YeahMobi等。主要适用场景在CPA的广告，通过S2S对接媒体的服务端，返回广告的基本素材和CPA价格，剩下的就全部由媒体方实现，通过点击上报数据与应用的激活LastClick 归因,最终按CPA计费。这个方式广告联盟对于广告链路完全不可控，作弊流量就非常多。但这个方式又很灵活，所以有不少的小公司靠着这个活得也不错。如下图。这种网盟广告的模式也催生出了一批广告offer的分发商，业内称“广告的二道贩子”，这个我们有机会再说说。
|
联盟广告市场的变革——Header Bidding能力详解！
发布时间：2023-01-13 11:29:11
Header Bidding，中文叫头部竞价。不算是什么新的技术能力，国外桌面PC端2016年开始，已经成为了PC联盟广告的标准。始于PC端，但在海外移动互联网场景，去年Google Admob Open Bidding 和Facebook Audience network In-App Bidding已经支持这样的竞价方式。
广告行业有一个趋势，凡是在海外比较流行的广告模式和技术，总有一天在国内也会蓬勃发展起来，比如说oCPM广告模式以及激励视频广告，当然也包括现在的Header Bidding或者说开放 Bidding。 第一次接触到Header Bidding，大概在2016年左右，恰同学少年，风华正茂，书生意气，挥斥方遒。那时我还在百度搞国际化商业化广告变现，所以对这个新的技术解决方案有一定的研究和了解。没想到一晃5年，Header Bidding 在国内终于有点动静了。 要想了解一个技术方案，首先要了解这个技术方案所面对的核心痛点或者问题。把问题清楚的写下来，问题就解决了一半。 Header Bidding的存在的痛点及其产生的由来 1. 海外Header Bidding 的由来 海外HeaderBidding起源于桌面广告领域——这项技术方案发起的初衷是为了对抗Google的Ad Exchange dynamitc bidding。Google靠自己的DFP（Doubleclick For Publisher）几乎垄断了桌面广告领域，DFP要求广告主必须要接入其RTB的广告交易平台，而不允许广告主和流量直接对接。同时垄断者在分配流量的时候主要做两件事，一是出价不透明，容易偏袒自己内部的广告主；二是分成比例较高。在这等情况下，媒体和广告主都不太满意。 只要有利可图，就一定会有人去做。于是，就有了Header Bidding的广告模式。 桌面广告领域率先推出了Header Bidding，头部竞价。最早的发起者是 appNexus。AppNexus希望联手其它的SSP/ADX，一起通过开放的方式，撼动DFP的垄断地位。因此该技术方案，获得了很多程序化购买SSP/ADX的支持。 Header Bidding 新建一套广告主与媒体流量方的对接协议，让每次的广告的请求优先请求支持Header Bidding的广告主或者DSP。媒体流量方获取广告返回之后，又用Header Bidding返回的广告的价格作为底价去请求DFP等其他广告联盟平台。若其他广告网络无高于此价格的广告返回，则曝光Header Bidding 的广告，若有返回高于此价格的广告，则曝光DFP等广告联盟的广告。 Header 是“标头”和“首标”的意思，意味着支持Header Bidding的广告主有优先选择流量优先出价的权利，从实际的链路逻辑上来看也是这样，具体逻辑如下图：
在这里必须要补充一个知识点，就是联盟的广告模式，每次广告展示的价值是多少钱，无论是桌面广告联盟还是移动广告联盟，在2019年之前都是没有返回给媒体流量方的，但他们支持以某个底价的方式去请求广告，若有广告返回，则表明这个广告的底价是高于某个值，但实际具体多少，并没有清楚的告诉媒体流量方。 2. 国内的Header Bidding要解决的痛点： 国内联盟广告的核心痛点就是每次广告联盟返回给媒体流量方的广告信息是不能直接知道当次曝光的广告价值。 国内移动互联网发达程度远超英美，PC流量已经增长停滞，联盟的广告模式主要也是以移动端流量为主。国内主要的联盟广告平台主要有百度联盟，字节的穿山甲以及腾讯的优量汇，当然，也有其他规模小一定的联盟，比如快手联盟，手机厂商流量联盟等。 有做过移动广告变现联盟的同学都知道，国内联盟主要以接入SDK为主，流量变现核心痛点是不知道每次请求获取的广告的价值。媒体方要查看其流量的变现价值通常是T+1的离线报表方式。 联盟SDK在每次返回广告的时候都没有明示价值，这使得媒体流量方无法根据实时的广告价值来对不同的联盟SDK进行选择。很多聚合SDK主要的策略是通过瀑布流方式（Waterfall——下文会详细说明）的进行变现。或者通过配置不同联盟SDK流量比例和优先级进行变现。 通过Waterfall 的方式或者配置不同联盟SDK比例的方式都需要投入大量的人力进行用户的分层和运营策略的配置。而且，联盟的历史变现效率不是一成不变的，导致配置的策略还不一定是最优的。 国内联盟的Heeder Bidding 就是为了解决这个痛点，目前已有多家主流的联盟广告平台在测试这块的能力。 它驱使每个联盟SDK在每次广告返回的时候不仅将广告曝光所需的素材信息返回，还必须带上当次广告请求的广告价值！媒体流量方可以聚合多个联盟，通过各个联盟返回的广告和价值进行实时竞价，挑选价值最高的广告进行曝光，从而使得流量价值最大化。 国内的Header Bidding 准确的来说是In-APP Bidding 或者Open Bidding。这个Bidding 的逻辑，会使得广告媒体的变现效率有所提升，同时也加剧了国内多家联盟广告平台的竞争，真正到了拼刺刀的环节。
聚合SDK Waterfall 与 Header Bidding的不同点 不同用户量级的公司变现策略有很大的不同。我们先来了解下大部分变现媒体公司的做法。 一般的流量媒体方进行变现都会聚合接入多个广告SDK的逻辑来变现。百度2015年的时候在海外变现就搞了一个聚合广告SDK—DAP。运营策略和思路都很时髦，放在现在的国内也是一骑绝尘的。只可惜成了前浪和先驱。 流量媒体会使用聚合SDK进行变现，常用的广告策略是Waterfall，即瀑布流。瀑布流存在的基础是广告SDK只提供基于某个价格为底价获取广告的接口能力（媒体以底价请求广告联盟，联盟后台返回的广告必须高于底价）。 由于广告联盟SDK在返回广告的时候是没有返回当次曝光的广告的预估价值（即eCPM），但联盟支持以某个底价去请求广告的，所以，为了追求流量价值的最大化，衍生出一种叫瀑布流（Waterfall）的变现策略逻辑。 流量媒体方根据不同广告联盟最近的变现效率表现设置Waterfall排序。 Waterfall的广告策略方案，主要解决两个问题： 1）不断的分价格段位去试探不同广告联盟SDK的广告填充率。 不同的联盟SDK广告价值的分布是不同的，媒体流量方根据历史的经验设置请求优先级（请求顺序），对广告联盟进行分层请求。 分层请求的优点是，能够根据当前媒体场景流量的情况获取价值更高的广告。有同学会问题，能不能同时以某个底价去请求广告呢？结论如下图，当然是不可以。若以15元的底价来请求联盟A和联盟B，这时候两个联盟都有返回，你无法更有效的判断哪个广告价值更高。
举例个例子，比如有多家广告平台，P1的ecpm为20，P2的eCPM为18，Waterfall顺序就是：P1 > P2。通常集成5-8家广告平台，通过广告分层的方式尽可能保证填充率和提升收益。如上图，多个SDK只是顺序和请求策略配置不同，基本的逻辑是一样的。 Waterfall 能相对较好的解决不同联盟平台变现效率差异以及提升填充率的问题。但这里又带来了2个新的比较重要的问题： 1) 历史的变现效率不代表当次真实的广告价值，所以你设置的优先级不一定对。 由于广告主投放都是实时生效的，很难排除某些广告主为了在某个广告平台上获取更多流量而提升出价。比如联盟A优先级第一，当次请求20块，有广告返回，当次曝光机会给了联盟A。但是实际上联盟B由于广告队列的变动，广告价值当次实际上有25，但是由于历史优先级比联盟A低而无法获取当次广告的曝光机会。 2) 广告请求耗时过长 为了更好的精细化运营同时使得获取的广告价格分布更加“准确”，Waterfall的广告请求通常是串行来请求的，这个使得广告请求到返回的耗时非常长，无法满足某些场景下及时广告曝光的诉求。 应用闪屏的广告曝光是500毫秒-1s必须返回，信息流场景的返回时长限制则是毫秒级别的。Waterfall的广告策略模式会让广告请求到曝光的时长增加很多，在很多场景下都无法满足快速填充广告的诉求。（短时间内的预加载可以稍微缓冲一下这个问题） Header Bidding 或者说实时Bidding 解决了以上的流量媒体变现的这个两个问题。 Bidding的协议，要求联盟广告平台在SDK 或者 API 后台上返回每次广告请求的曝光价值，这样就在联盟变现场景上产生了类似实时竞价RTB的逻辑。 媒体流量方可以根据自己的需求选择需要接入的广告联盟SDK，从而更好的提升广告的变现价值和填充率。 同时，Header Bidding 使得联盟聚合平台有更多操作的空间，无论从变现效率的能力、策略和数据，都有很多优化的点。 不过，由于HeadeBidding 在国内才刚刚开始，预计在较长的时间段内，应该是Bidding 与 Waterfall 并存的情况。 开放Bidding的变现方式对于联盟平台也不一定是坏事，比如像Google Admob Open Bidding，可以通过Open Bidding 获取到其他联盟的广告变现效率和素材情况，从而进行针对性的优化，再结合其丰富的广告主资源，就可以做到强者恒强。 对于媒体流量方而言，可以知晓每次广告请求的最大价值，同时可以对用户价值更好的识别，那么在增长LTV这个点上就有一个更好的预估，能更好更精细化的做用户增长策略。 下面主要讲述的是Header Bidding或Open Bidding 带来的广告竞价和对接方式的变化。 联盟广告的初衷是，中小流量方由于流量规模不大，缺少商务团队以及广告系统技术能力，无法很好的搭建自有的广告系统，需利用大型的广告平台比如Google、Facebook、腾讯、字节等强大的广告系统能力和商务能力进行流量的变现。 在联盟广告市场中，中小流量方无需自己搭建广告平台，无需对接各种不同的广告主而进行流量的商业变现，相当于将技术和商务对接能力交给了一个可长期服务的合作伙伴。而联盟平台则通过对外提供广告变现的能力获取到更多的流量更好的服务不同的广告主，同时收取一定的服务费。可以说，联盟广告是一个双赢的商业模式。 实际上，国内Open Bidding 方案发展最终会变成怎样，取决于头部各家联盟的开放程度以及技术支持能力。OpenBidding 会引起流量媒体方在竞价逻辑以及广告链路上的变化。 不同用户规模的媒体流量方，对于广告联盟的诉求是不同的。 衡量一款推荐产品的能力的重要指标是其对用户的推荐颗粒度的精细运营能力，近几年很火的概念叫“千人千面”其实就是对用户颗粒度的不断细分。同样，衡量一个联盟的经营能力的重要指标除了变现效率，就是其对合作伙伴经营的颗粒度。 用户规模较大的媒体流量方，一方面会自建广告平台，建立自己的广告客户和广告系统，搭建属于自有的广告链路能力，同时通过接入广告联盟补充广告源提升广告填充率。 用户规模中小的媒体流量方，则会直接接入广告联盟SDK，通过聚合多个联盟SDK和调整策略的方式力求流量价值的最大化。中小规模流量方通常主要在广告策略上进行相对简单的调整，整个广告链路都会托管给SDK进行处理。这样可以将人力更加集中在产品的优化上。 不同的分层客户，需要不同的联盟对接方式。 整体来说，广告流程都是：广告从客户端进行请求，从联盟广告平台上获取到广告，进行竞价，继而进行广告的曝光和转化链路。 媒体流量方与联盟广告平台进行对接的路径中主要有两个核心的变化因素，如下图： 1）广告竞价在服务端还是在客户端； 2）广告的曝光和广告转化链路是直接调用SDK还是进行自建广告样式（类似纯原生广告样式）并搭建广告链路。
广告竞价能力在服务端会更有优势，但并不是所有联盟都支持。 竞价的逻辑在服务端，从逻辑上看优势更多，使得在广告的竞价逻辑上更轻。同时更好的进行广告策略的调整和运营，灵活性要更好，更新速度快。若在客户端，则每次的竞价逻辑的改动都需要更新应用版本，更新速度慢，版本覆盖不全，维护成本很高。所以，理论上，如果条件允许，一般竞价逻辑最好还是放在服务后台。 那么在客户端竞价的逻辑，主要出现的场景是，联盟广告平台只对某些中大型媒体开放服务端Bidding的能力。中大型媒体体量大，研发能力较强，服务较为稳定，所以针对部分客户是可开放服务端bidding的能力的。 小型的媒体流量方，都是通过聚合多个SDK的方式提升广告的填充率和变现效率，那么这个时候，就只能在客户端进行比价的操作逻辑了。客户端使用的是联盟SDK统一的广告能力，对于联盟广告平台来说也会更加的可控。 比如Google admob Open Bidding 聚合了多个SDK，并没有通过服务端进行对接，因此这个竞价的逻辑只能在客户端进行。 在客户端进行竞价，整个广告策略逻辑在客户端代码上就非常重，调整不灵活，数据问题的排查依赖于大量的数据上报。 广告曝光和转化链路直接调用SDK更加可控，而自建广告链路则相对灵活 广告的转化链路主要包括广告曝光，点击，落地页加载，广告转化等步骤的能力以及数据上报。这一系列的功能需要保证广告能力的稳定和数据上报的准确性，使用统一的SDK封装的链路能力和数据上报能力的是最好的方式。 联盟广告SDK在广告链路上实际要处理很多重要的能力，广告归因ID上报，广告核心行为数据上报统计，广告落地页加载速度优化，广告下载能力优化以及广告反作弊能力的相关数据识别和上报。 中小流量方，一般不太建议单独自建广告链路，直接使用SDK封装好的能力是最简单快速的变现方式。 自建广告链路，流量媒体方从广告联盟平台上获取的仅仅是广告的价值（ECPM）以及广告素材、文案、落地页等相关的原材料，媒体方需要实现广告整套的转化链路和数据上报，同时通过原材料组装广告的样式。对于中大型媒体来说能更好的补充广告源，同时广告样式可以更灵活的调整和配置。 问题则在于，广告联盟平台对于这块的链路可控性太差，链路能力优化依赖于媒体方平台的配合。由于广告曝光也依赖于媒体方进行上报，一些在联盟广告SDK上可做的反作弊能力都无法有效的实施，因此对于一般的客户，联盟广告平台是不会开放API方式的能力给到媒体方的。 海外的移动广告中，有一种叫网盟的商业形式，代表公司有Appia，Mobopatner，glispa，Avazu，IronSource，YeahMobi等。主要适用场景在CPA的广告，通过S2S对接媒体的服务端，返回广告的基本素材和CPA价格，剩下的就全部由媒体方实现，通过点击上报数据与应用的激活LastClick 归因,最终按CPA计费。这个方式广告联盟对于广告链路完全不可控，作弊流量就非常多。但这个方式又很灵活，所以有不少的小公司靠着这个活得也不错。如下图。这种网盟广告的模式也催生出了一批广告offer的分发商，业内称“广告的二道贩子”，这个我们有机会再说说。
|
|
