起點課堂會員權益
職業(yè)體系課特權
線下行業(yè)大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識怎樣構建媒體廣告商業(yè)化體系（一）
編輯導語：SSP是媒體廣告商業(yè)化的核心系統(tǒng)，在SSP平臺上，媒體可對自己的廣告位資源、流量資源進行管理，并進行相關的策略運營，以達到最大的流量變現(xiàn)效果。那么怎樣構建媒體廣告商業(yè)化體系呢？本篇文章作者分享了構建媒體廣告商業(yè)化體系的具體方法和邏輯，一起來學習一下吧，希望對你有幫助。
本系列文章主要介紹媒體端廣告商業(yè)化體系，包括產(chǎn)品和運營的相關工作，本文將圍繞目前常規(guī)SSP平臺的產(chǎn)品結構和運行邏輯展開講解。
一、SSP
SSP是媒體廣告商業(yè)化的核心系統(tǒng)，因此想要構建媒體廣告商業(yè)化體系，一個可靠的SSP是必不可少的。
SSP全稱為供應方平臺（Supply Side Platform），顧名思義，是流量供應方管理和售賣流量的系統(tǒng)。
媒體通過SSP平臺管理流量并且進行流量售賣。SSP平臺核心的功能是流量管理和流量售賣，SSP所有的模塊都是圍繞這兩個功能去服務的。
相比于投放端復雜的計費方式，媒體端幾乎都是以CPM作為計費方式，因此SSP中涉及價格的部分一般都是以CPM/eCPM去計算。
有關其他的計費方式，例如CPC/CPA/CPD/CPS等，會在后續(xù)的文章涉及時詳細說明。
1. 流量管理
流量管理功能，主要是針對上游、媒體端各媒體、廣告位和用戶信息進行管理，包括廣告主管理、媒體管理、廣告位管理、代碼位管理、用戶分群、屏蔽等模塊。
1）廣告主管理：廣告主管理主要用于管理和配置上游的相關信息，包括廣告主信息，結算信息，返點控制等等。
2）媒體管理：媒體管理主要用于管理和配置媒體自身的相關信息以及媒體在上游的信息。媒體自身的信息主要包括媒體的名稱和包名，建議在初始化時服務端與本地進行驗證。媒體在上游的信息與上游（ADX/DSP）規(guī)定的字段有關，一般包括id和密鑰。媒體在上游的信息建議通過服務端配置和下發(fā)，以應對上游信息的調(diào)整以及應用信息寫入錯誤的問題。
3）廣告位管理：廣告位配置主要用于配置廣告位相關的信息，包括廣告位名稱，廣告位所屬媒體，廣告位的類型、尺寸和樣式， 廣告位與廣告代碼位映射，廣告位與屏蔽規(guī)則映射等。
4）廣告代碼位管理：廣告代碼位配置主要用于配置廣告代碼位相關信息，包括廣告代碼位id，廣告代碼位所屬上游，廣告代碼位屬性，例如是否支持bidding，是否支持緩存等。代碼位的配置主要用于收益自動化分配，以及后期算法調(diào)節(jié)策略。
5）用戶分群：在采集到用戶信息后，系統(tǒng)需要將用戶信息存儲處理打標簽。用戶信息一般分為兩類，用戶屬性和用戶行為。
用戶屬性主要包括手機品牌、手機型號、用戶地域、手機網(wǎng)絡、手機系統(tǒng)、IP、運營商等。
用戶行為包括三類：
- 一類是基于歸因的用戶行為，例如用戶來源渠道、用戶來源投放計劃等；
- 一類是基于用戶在媒體內(nèi)的行為，例如全新用戶、是否注冊登錄、停留時長、召回用戶、次日用戶、首日用戶、點擊廣告次數(shù)等；
- 第三類基于聯(lián)盟對于用戶的評價，例如平均ecpm、最高ecpm等。
需要根據(jù)以上的分類將用戶信息打標簽，并且歸整為系統(tǒng)可用的用戶分群。媒體規(guī)模越大，對于用戶分群的需求越高。
6）屏蔽：屏蔽功能需要基于用戶分群功能來打造。由于廣告本身會影響用戶體驗，因此屏蔽功能也是必不可少的。
一般在用戶分群的基礎上，增加廣告位控制和時間控制，來以此屏蔽廣告請求（屏蔽和定向是一體兩面，因此也有SSP通過反向定向來實現(xiàn)屏蔽功能）。
2. 流量售賣
流量售賣功能，是SSP核心功能，所有需要通過廣告變現(xiàn)的媒體，都需要通過SSP系統(tǒng)中的流量售賣功能來配置售賣策略，以期獲得收益的最大化。
在2021年之前，媒體端主要以瀑布流（waterfall）的形式配置流量分發(fā)策略。從2021年下半年開始，各大網(wǎng)盟開始力推頭部競價（header bidding）模式，目前主流SSP流量售賣均支持waterfall，header bidding以及waterfall+header bidding模式。
3. Waterfall（瀑布流）模型
早年程序化廣告交易市場不透明的年代，媒體端對于上游預算情況幾乎是一無所知，如何售賣流量讓收益最大化成為了難題。
傳統(tǒng)的做法是根據(jù)昨天和歷史的收益情況，調(diào)整售賣流量順序，優(yōu)先售賣給歷史價格高的上游。
但是這里存在兩個問題，第一個問題是這里需要大量的人力進行數(shù)據(jù)分析和策略調(diào)整，第二個問題是當廣告市場預算出現(xiàn)波動時，沒有辦法快速跟進調(diào)整售賣策略。
后來各大聯(lián)盟支持保價功能，即PD交易，媒體可以在聯(lián)盟后臺設置每個廣告代碼位的底價，廣告聯(lián)盟以不低于這個底價的價格返回廣告素材和結算（雖然實際結算會有波動），這為媒體側的waterfall提供了極大地便利，媒體可以根據(jù)在聯(lián)盟后臺設置的代碼位底價按照從高到低的價格售賣流量，并且以此形成了很長一段時間基于waterfall的變現(xiàn)模型。
那么為什么媒體端是從高到低降價拍賣，而不是從價格從低到高售賣？
這兩種拍賣在歷史上都是源遠流長的，從高到低降價拍賣被稱為“荷蘭式拍賣”，從低到高升價拍賣被稱為“英式拍賣”。
我們在影視劇中常見的拍賣，都是以英式拍賣為主。荷蘭式拍賣最大的優(yōu)點在于成交迅速，缺點在于交易效率偏低，為了提升交易效率，對拍賣師（運營）策略設置的要求較高。
英式拍賣的優(yōu)點在于更容易拍出更高的價格，缺點在于成交時間較長，且對于競買方來說，風險更高。
媒體售賣流量最終的目的是獲得最大的收益，英式拍賣更容易對媒體帶來更高的價格，但是對于上游來說，采用英式拍賣，意味著更高的風險和更大的服務器成本，因為上游需要對同一流量進行多次出價。
所以采取荷蘭式拍賣，實際上是上游和媒體博弈妥協(xié)的產(chǎn)物。
但是對于媒體來說，waterfall也不是最完美的解決方案。
waterfall存在的最大的問題就是多層的串行請求會將廣告請求時間拖得非常的長，即使是開啟了緩存和預加載，在一些時效性要求很高的廣告位上，依然會存在有比較嚴重的超時情況，例如開屏廣告。
但是如果不做多階保價，不將價格層級分細，對于媒體來說不能平滑的售賣自己的流量，收益依然是有損失的，因此如何設置waterfall層級和價格也是一門學問。
除此以外，waterfall依然需要大量人力不斷的根據(jù)市場情況調(diào)整售賣策略，這對于媒體來說也是不低的成本。
因此只有媒體規(guī)模到達一定的高度，才能夠有效的去做精細化運營，否則精細化運營帶來的收益提升無法覆蓋人力資源成本。
4. Header Bidding（頭部競價）模型
面對waterfall存在的一系列問題，Header Bidding模式出現(xiàn)了。
Header Bidding興起于桌面廣告領域，最初是媒體和小型廣告聯(lián)盟為了對抗谷歌而推出的一項技術。
通過在網(wǎng)頁<head>添加代碼，迫使谷歌在競價中出更高的價格才可以購買到流量，這也是header bidding中header的來源。
隨著移動端的興起，與谷歌的對抗從桌面端轉移到了移動端，header bidding也從桌面端轉移到了移動端。
雖然呼聲很高，但是國內(nèi)的header bidding直到2021年初，才開始由穿山甲進行小規(guī)模測試，到2021年底，大部分聯(lián)盟都對媒體開放了bidding能力。
相比于傳統(tǒng)的waterfall，bidding有明顯的優(yōu)勢。
bidding允許所有聯(lián)盟同時競價，一次性獲得多個報價，對于聯(lián)盟來說雖然密封拍賣對出價的要求更高，但減少了waterfall重復請求的帶寬和服務器成本，對于媒體來說，減少了廣告策略配置的人力成本，同時減少了waterfall造成的廣告超時問題，還有機會獲得更高的價格，所以上下游都有動力去推動bidding模式。
但是目前各聯(lián)盟的bidding能力還不完善，大多還是沿用原有的模型，只是在出價上更加平滑。
同時系統(tǒng)的魯棒性也需要繼續(xù)加強。因此在短時間內(nèi)，媒體不會完全的轉向bidding，而是采用bidding+waterfall混合的模式進行流量售賣。
5. 混合競價模式
混合模式應該如何分發(fā)流量，這里提供一個我認為相對來說比較好的形式。
SDK同步進行bidding和waterfall的流程。
當bidding獲取到各網(wǎng)盟報價并且獲得勝出價時，判斷waterfall狀態(tài)，如果waterfall已經(jīng)獲得廣告，則進行二次比價判斷bidding勝出價和waterfall價格，如果waterfall價格勝出則展現(xiàn)對應廣告，如果bidding價格勝出則將價格返回給勝出方并且展現(xiàn)對應廣告。
如果bidding獲取到各網(wǎng)盟報價并且獲得勝出價時，waterfall未獲得廣告，則waterfall流程繼續(xù)進行直到獲得廣告或者到某層價格低于bidding勝出價格時截斷waterfall流程，并進行二次比價。
這種形式相對來說效率更高，不需要waterfall走完全部的層級即可以獲得更高的價格，目前市面上已經(jīng)有一些SSP采用這樣的形式。
二、數(shù)據(jù)系統(tǒng)
數(shù)據(jù)系統(tǒng)也是SSP系統(tǒng)中必不可少的一環(huán)，后續(xù)會有專門的文章來詳細的介紹，在這里簡單的介紹一下數(shù)據(jù)系統(tǒng)的結構。
從系統(tǒng)結構上來說，數(shù)據(jù)系統(tǒng)主要包括數(shù)據(jù)采集，數(shù)據(jù)處理，數(shù)據(jù)存儲和數(shù)據(jù)展示，從功能上來說，數(shù)據(jù)系統(tǒng)主要分為三大塊：收入系統(tǒng)，數(shù)據(jù)報表，數(shù)據(jù)監(jiān)控。
1. 收入系統(tǒng)
一般的大型網(wǎng)盟都會在次日上午返回昨日的收益數(shù)據(jù)，并且提供API給媒體自動化獲取數(shù)據(jù)，媒體需要將收益數(shù)據(jù)入庫。
收益數(shù)據(jù)一般做以下的用途：
- 作為與上游結算的依據(jù)；
- 與媒體自身的數(shù)據(jù)相匹配，判斷數(shù)據(jù)gap并從中找尋問題；
- 用于運營分析廣告策略調(diào)整的效果，如果媒體通過算法來調(diào)整廣告策略，那么更需要收入數(shù)據(jù)作為算法自動化調(diào)整的依據(jù)。
收入系統(tǒng)會面臨以下幾個問題，在設計之初就需要考慮到：
- 部分上游不會提供API獲取數(shù)據(jù)，需要手動錄入；
- 不同的上游字段不一樣，需要定義一個統(tǒng)一的字段并且與各上游對應；
- 上游數(shù)據(jù)會延遲甚至錯誤，需要能夠重新錄入，并且在錄入后同步所有使用該數(shù)據(jù)的系統(tǒng)。
2. 數(shù)據(jù)報表
數(shù)據(jù)報表是數(shù)據(jù)系統(tǒng)的核心功能，主要分為詳細報表和可視化簡報?？梢暬唸笾饕糜谠诤暧^層面展示媒體的情況，詳細報表主要用于運營對具體數(shù)據(jù)的分析。
3. 數(shù)據(jù)監(jiān)控
數(shù)據(jù)監(jiān)控是算法調(diào)整策略的前提，也是極大解放人力的工具。數(shù)據(jù)監(jiān)控的原理并不復雜， 主要針對字段設置條件，在指定的時間段內(nèi)。同比/環(huán)比波動到達一定閾值即觸發(fā)報警，具體的規(guī)則會在后續(xù)文章中交流。
作者：rorain；公眾號：rorain的思考筆記；
本文由 @ rorain 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協(xié)議。
- 目前還沒評論，等你發(fā)揮！
