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