编辑导语：SSP是媒体广告商业化的核心系统，在SSP平台上，媒体可对自己的广告位资源、流量资源进行管理，并进行相关的策略运营，以达到最大的流量变现效果。那么怎样构建媒体广告商业化体系呢？本篇文章作者分享了构建媒体广告商业化体系的具体方法和逻辑，一起来学习一下吧，希望对你有帮助。
本系列文章主要介绍媒体端广告商业化体系，包括产品和运营的相关工作，本文将围绕目前常规SSP平台的产品结构和运行逻辑展开讲解。
SSP是媒体广告商业化的核心系统，因此想要构建媒体广告商业化体系，一个可靠的SSP是必不可少的。
SSP全称为供应方平台（Supply Side Platform），顾名思义，是流量供应方管理和售卖流量的系统。
媒体通过SSP平台管理流量并且进行流量售卖。SSP平台核心的功能是流量管理和流量售卖，SSP所有的模块都是围绕这两个功能去服务的。
相比于投放端复杂的计费方式，媒体端几乎都是以CPM作为计费方式，因此SSP中涉及价格的部分一般都是以CPM/eCPM去计算。
有关其他的计费方式，例如CPC/CPA/CPD/CPS等，会在后续的文章涉及时详细说明。
流量管理功能，主要是针对上游、媒体端各媒体、广告位和用户信息进行管理，包括广告主管理、媒体管理、广告位管理、代码位管理、用户分群、屏蔽等模块。
）广告主管理：广告主管理主要用于管理和配置上游的相关信息，包括广告主信息，结算信息，返点控制等等。
）媒体管理：媒体管理主要用于管理和配置媒体自身的相关信息以及媒体在上游的信息。媒体自身的信息主要包括媒体的名称和包名，建议在初始化时服务端与本地进行验证。媒体在上游的信息与上游（ADX/DSP）规定的字段有关，一般包括id和密钥。媒体在上游的信息建议通过服务端配置和下发，以应对上游信息的调整以及应用信息写入错误的问题。
）广告位管理：广告位配置主要用于配置广告位相关的信息，包括广告位名称，广告位所属媒体，广告位的类型、尺寸和样式， 广告位与广告代码位映射，广告位与屏蔽规则映射等。
）广告代码位管理：广告代码位配置主要用于配置广告代码位相关信息，包括广告代码位id，广告代码位所属上游，广告代码位属性，例如是否支持bidding，是否支持缓存等。代码位的配置主要用于收益自动化分配，以及后期算法调节策略。
）用户分群：在采集到用户信息后，系统需要将用户信息存储处理打标签。用户信息一般分为两类，用户属性和用户行为。
用户属性主要包括手机品牌、手机型号、用户地域、手机网络、手机系统、IP、运营商等。
用户行为包括三类：
一类是基于归因的用户行为，例如用户来源渠道、用户来源投放计划等；
一类是基于用户在媒体内的行为，例如全新用户、是否注册登录、停留时长、召回用户、次日用户、首日用户、点击广告次数等；
第三类基于联盟对于用户的评价，例如平均ecpm、最高ecpm等。
需要根据以上的分类将用户信息打标签，并且归整为系统可用的用户分群。媒体规模越大，对于用户分群的需求越高。
）屏蔽：屏蔽功能需要基于用户分群功能来打造。由于广告本身会影响用户体验，因此屏蔽功能也是必不可少的。
一般在用户分群的基础上，增加广告位控制和时间控制，来以此屏蔽广告请求（屏蔽和定向是一体两面，因此也有SSP通过反向定向来实现屏蔽功能）。
流量售卖功能，是SSP核心功能，所有需要通过广告变现的媒体，都需要通过SSP系统中的流量售卖功能来配置售卖策略，以期获得收益的最大化。
在年之前，媒体端主要以瀑布流（waterfall）的形式配置流量分发策略。从年下半年开始，各大网盟开始力推头部竞价（header bidding）模式，目前主流SSP流量售卖均支持waterfall，header bidding以及waterfall+header bidding模式。
早年程序化广告交易市场不透明的年代，媒体端对于上游预算情况几乎是一无所知，如何售卖流量让收益最大化成为了难题。
传统的做法是根据昨天和历史的收益情况，调整售卖流量顺序，优先售卖给历史价格高的上游。
但是这里存在两个问题，第一个问题是这里需要大量的人力进行数据分析和策略调整，第二个问题是当广告市场预算出现波动时，没有办法快速跟进调整售卖策略。
后来各大联盟支持保价功能，即PD交易，媒体可以在联盟后台设置每个广告代码位的底价，广告联盟以不低于这个底价的价格返回广告素材和结算（虽然实际结算会有波动），这为媒体侧的waterfall提供了极大地便利，媒体可以根据在联盟后台设置的代码位底价按照从高到低的价格售卖流量，并且以此形成了很长一段时间基于waterfall的变现模型。
那么为什么媒体端是从高到低降价拍卖，而不是从价格从低到高售卖？
这两种拍卖在历史上都是源远流长的，从高到低降价拍卖被称为“荷兰式拍卖”，从低到高升价拍卖被称为“英式拍卖”。
我们在影视剧中常见的拍卖，都是以英式拍卖为主。荷兰式拍卖最大的优点在于成交迅速，缺点在于交易效率偏低，为了提升交易效率，对拍卖师（运营）策略设置的要求较高。
英式拍卖的优点在于更容易拍出更高的价格，缺点在于成交时间较长，且对于竞买方来说，风险更高。
媒体售卖流量最终的目的是获得最大的收益，英式拍卖更容易对媒体带来更高的价格，但是对于上游来说，采用英式拍卖，意味着更高的风险和更大的服务器成本，因为上游需要对同一流量进行多次出价。
所以采取荷兰式拍卖，实际上是上游和媒体博弈妥协的产物。
但是对于媒体来说，waterfall也不是最完美的解决方案。
waterfall存在的最大的问题就是多层的串行请求会将广告请求时间拖得非常的长，即使是开启了缓存和预加载，在一些时效性要求很高的广告位上，依然会存在有比较严重的超时情况，例如开屏广告。
但是如果不做多阶保价，不将价格层级分细，对于媒体来说不能平滑的售卖自己的流量，收益依然是有损失的，因此如何设置waterfall层级和价格也是一门学问。
除此以外，waterfall依然需要大量人力不断的根据市场情况调整售卖策略，这对于媒体来说也是不低的成本。
因此只有媒体规模到达一定的高度，才能够有效的去做精细化运营，否则精细化运营带来的收益提升无法覆盖人力资源成本。
面对waterfall存在的一系列问题，Header Bidding模式出现了。
Header Bidding兴起于桌面广告领域，最初是媒体和小型广告联盟为了对抗谷歌而推出的一项技术。
通过在网页<head>添加代码，迫使谷歌在竞价中出更高的价格才可以购买到流量，这也是header bidding中header的来源。
随着移动端的兴起，与谷歌的对抗从桌面端转移到了移动端，header bidding也从桌面端转移到了移动端。
虽然呼声很高，但是国内的header bidding直到年初，才开始由穿山甲进行小规模测试，到年底，大部分联盟都对媒体开放了bidding能力。
相比于传统的waterfall，bidding有明显的优势。
bidding允许所有联盟同时竞价，一次性获得多个报价，对于联盟来说虽然密封拍卖对出价的要求更高，但减少了waterfall重复请求的带宽和服务器成本，对于媒体来说，减少了广告策略配置的人力成本，同时减少了waterfall造成的广告超时问题，还有机会获得更高的价格，所以上下游都有动力去推动bidding模式。
但是目前各联盟的bidding能力还不完善，大多还是沿用原有的模型，只是在出价上更加平滑。
同时系统的鲁棒性也需要继续加强。因此在短时间内，媒体不会完全的转向bidding，而是采用bidding+waterfall混合的模式进行流量售卖。
混合模式应该如何分发流量，这里提供一个我认为相对来说比较好的形式。
SDK同步进行bidding和waterfall的流程。
当bidding获取到各网盟报价并且获得胜出价时，判断waterfall状态，如果waterfall已经获得广告，则进行二次比价判断bidding胜出价和waterfall价格，如果waterfall价格胜出则展现对应广告，如果bidding价格胜出则将价格返回给胜出方并且展现对应广告。
如果bidding获取到各网盟报价并且获得胜出价时，waterfall未获得广告，则waterfall流程继续进行直到获得广告或者到某层价格低于bidding胜出价格时截断waterfall流程，并进行二次比价。
这种形式相对来说效率更高，不需要waterfall走完全部的层级即可以获得更高的价格，目前市面上已经有一些SSP采用这样的形式。
数据系统也是SSP系统中必不可少的一环，后续会有专门的文章来详细的介绍，在这里简单的介绍一下数据系统的结构。
从系统结构上来说，数据系统主要包括数据采集，数据处理，数据存储和数据展示，从功能上来说，数据系统主要分为三大块：收入系统，数据报表，数据监控。
一般的大型网盟都会在次日上午返回昨日的收益数据，并且提供API给媒体自动化获取数据，媒体需要将收益数据入库。
收益数据一般做以下的用途：
作为与上游结算的依据；
与媒体自身的数据相匹配，判断数据gap并从中找寻问题；
用于运营分析广告策略调整的效果，如果媒体通过算法来调整广告策略，那么更需要收入数据作为算法自动化调整的依据。
收入系统会面临以下几个问题，在设计之初就需要考虑到：
部分上游不会提供API获取数据，需要手动录入；
不同的上游字段不一样，需要定义一个统一的字段并且与各上游对应；
上游数据会延迟甚至错误，需要能够重新录入，并且在录入后同步所有使用该数据的系统。
数据报表是数据系统的核心功能，主要分为详细报表和可视化简报。可视化简报主要用于在宏观层面展示媒体的情况，详细报表主要用于运营对具体数据的分析。
数据监控是算法调整策略的前提，也是极大解放人力的工具。数据监控的原理并不复杂， 主要针对字段设置条件，在指定的时间段内。同比/环比波动到达一定阈值即触发报警，具体的规则会在后续文章中交流。
