目錄
- 1,什么是超播?
- 2,超播發生的原理
- 2.1 廣告上下線
- 2.2 從不同視角看超播
- 2.2.1 按照計費型別
- 2.2.2 按照站內和站外角度來看
- 2.2.3 從成本來看
- 3,什么場景下會發生超播
- 3.1 從商家作弊的角度上看
- 3.2 從平臺的角度上看
- 4,如何防止超播?
- 4.1 提高實時性
- 4.2 流量控制
- 4.2.1 PID
- 4.2.2 Budget pacing
- 4.2.3 概率控制
- 4.3 廣告預下線
- 4.3.1 方式一:設定閾值buffer
- 4.3.2 方式二:廣告消耗預估
- 5,業界對于超播的常規做法
- 5.1 廣告主投放后臺的角度
- 5.2 從廣告工程及演算法側的角度
1,什么是超播?
另一種中文說法是超投,在英文里面叫做Over delivery,
Over delivery: The dollar amount we delivered to a campaign beyond its daily budget as a percentage of total revenue.
與之相對的是under delivery,表示的是沒達量,
兩種場景理解含義:
(1)從曝光量上講,在GD(合約式保量廣告中),一般廣告主要求一筆預算需要達到多少的曝光量,那么over delivery表示的是平臺最終投出去的廣告曝光量大于廣告主合約中規定的曝光量,那么超出的部分怎么辦呢?只能平臺自己消化,別人只讓你曝光量這么多,你現在投多了那是你自己的問題,
(2)從預算角度上講,平臺投放出去的廣告過多,實際消耗超出了廣告主設定的預算(假設以點擊來算,那么就是廣告投多了,導致點擊偏多,如果按照真實點擊量計算,那么平臺實際應該收取的費用超出了廣告主設定的預算)
2,超播發生的原理
2.1 廣告上下線
在了解超播發生的原理之前,我們先從系統整體角度看看廣告系統是怎么投廣告,怎么算錢的,
圖片
上圖參考自網上(文末有說明來源),如有侵權,聯系筆者洗掉
系統設計的關鍵點:
(1)實時反饋(Real-Time FeedBack),分為幾個部分:廣告召回的實時性、計費打點的實時性,
(2)預下線,需要做的就是消耗的預測,可以參考pinterest做的一個消耗實時預估的系統,
2.2 從不同視角看超播
2.2.1 按照計費型別
CPC和CPM容易發生超播,但是CPT是不存在超播的情況的,因為它是按照時間計費的,時間一到就下線,
重要的一個點:點擊計費和曝光計費兩種不同方式的計費方式,產生的超播嚴重程度也是不一致的,從用戶行為的操作路徑來看,點擊操作是比曝光操作滯后的,帶來的一個問題就是,前一秒還有可用預算,廣告投出去了,但是用戶不點擊,過了一段時間,用戶再回去點擊,但是這個時候可能廣告主預算可能已經花完了,那么這種因為用戶行為的滯后性導致的超播是一種不可避免的正常超播,所以無論怎樣降低超播程度,都不可能把超播降為0,
2.2.2 按照站內和站外角度來看
站外超播高于站內超播,因為站外因素不可控,超播程度不僅取決于我們平臺自身,也取決于所對接的外部平臺的防超播的能力,
2.2.3 從成本來看
超播分為兩種型別的超播:
(1)有成本超播,就是平臺超播的這部分的廣告需要花費一定成本,這種主要存在于聯盟廣告中,平臺要向外部媒體花錢采買流量,如果平臺超播了,那么超播的部分就需要花費額外的成本了,
(2)無成本超播,無成本超播就是不用買單的那部分超播,這部分超播會由外部平臺獨自承擔掉,
3,什么場景下會發生超播
3.1 從商家作弊的角度上看
(1)商家可以反復調低然后調高預算,
(2)商家反復在賬戶剛沒錢的時候,往賬戶充一點錢,賬戶可以反復將廣告先下線再上線,
(3)賬號轉退款的時候也可能出現超播的情況,因為賬號側需要將資金變動的訊息發送給計費側,資料同步造成的延遲導致投放不能及時下線,因而產生超播,
3.2 從平臺的角度上看
(1)廣告上下線的實時性,這部分就涉及多個系統間的互動了,每個涉及到廣告投放的狀態及時更新的地方都有可能導致超播的發生,一般主要發生在引擎和計費側,以及c端打點的回傳的及時性,
(2)預算平滑分配的能力,比如如果廣告投放速度過快,在該停止投放的時候,沒有及時踩剎車,可能導致超播嚴重,
4,如何防止超播?
4.1 提高實時性
(1)降低延時,廣告預算消耗、賬戶余額、廣告投放狀態等實時感知,力求達到實時反饋,
(2)廣告提前下線,主要依賴消耗預測準確度,具體可以參考pinterest的消耗預測做法,
4.2 流量控制
目的是:減少下線指令發出前廣告被檢索的數量,這樣廣告投出去的量變少,相當于水管變小,精細化控流,從而達到廣告超投的影響變小,
4.2.1 PID
Pid演算法,是比例Proportion、積分Integral、導數微分Derivative首字母的簡稱,pid演算法是一種非常經典的且應用廣泛的控制演算法,最早被應用在自動化控制領用,從對一個小元件的溫度控制,到對一架無人機的飛行路徑、飛行速度的設計,pid演算法都可以發揮作用,
Pid演算法的原理,主要是依據實時的投放反饋資料,來動態運用比例、積分、微分手段及勝率的預測,控制投放速度的均勻穩定,PID控制的基礎是比例控制;積分控制可消除穩態誤差,但可能會增加超調;微分控制可加快大慣性系統回應速度及減弱超調趨勢,運用“傅立葉變換”將流量波動波形及投放進度波形進行數學擬合的基礎上來做預測,
優點:引入Pid演算法后,對廣告消耗速度的控制更加的細膩,不會出現到臨界點突然展示機會瞬間大幅度變化的情況,對廣告超投有非常大的幫助,可以拉長廣告的投放時間,幫助廣告預算在投放時間內,根據需求均勻的消耗掉預算,減少流量過大廣告預算極端時間內就被消耗殆盡的情況,
缺點:需要比較強大的演算法團隊和大資料團隊,無法根據流量的變化動態調整投放速度,有可能使高價的廣告主過早的退出競價市場,不利于平臺整體收入的最大化
4.2.2 Budget pacing
Pacing演算法簡單的說,是根據歷史流量占比預估預算分配,使廣告覆寫的有效用戶盡可能的多,具體做法是在演算法中引進廣告排序引數,參與傳遞率PTR,通過rt 智能步調調整消耗速度,使消耗根據流量的變化同比消耗,目標是使消耗分布曲線無限接近流量分布,
演算法的主要思想是:根據整體的流量及交易情況分配展示,旨在一天時間內平均分配每個廣告投放的展示次數,
①對于每個廣告系列,我們都可以獲得白天可見的曝光流量模式的預測,根據預測,我們可以確定一個預算分配計劃,此分配計劃是根據投放的預算與預測的可靠流量根據比例確定的,

②在運行時,我們會密切監控每個廣告系列的廣告投放量,如果這個投放的消耗比分配快,我們將調低他們的展示概率,不允許他們參與某些競價,
Budget Pacing的兩種策略:
(1)Bid modification(調整出價)
(2)probabilistic throttling(調整競價的概率)

4.2.3 概率控制
概率演算法是一種比較簡單的演算法,由廣告策略產品經理制定,根據實際消耗占目標消耗(限額)的比例,確定廣告被檢索的概率,當實際消耗快逐漸接近目標消耗時,廣告被檢索的概率逐步降低,以此減少下線指令發出前廣告被檢索的數量,
優點:對演算法的要求相對簡單,人員成本較低,小公司也可以實作,并且有相當有效的作用,可以在很大程度上減少超投現象
缺點:控制程序粒度較大,容易造成廣告預算不夠平滑,前期消耗很快,后期消耗很慢,只能解決超投的問題,但是無法幫助廣告主優化投放效果,
4.3 廣告預下線
4.3.1 方式一:設定閾值buffer
預估廣告的消耗,然后設定一個預算余量的buffer,如果快要達到下線的閾值,就需要做提前下線,比如:如果設定了到達預算的80%為要下線的buffer,那么當消耗到達了這個值的時候就把廣告下線,這個時候盡管發出了下線的通知,但是其實可能還在繼續投,
4.3.2 方式二:廣告消耗預估
這種方式就依賴于消耗計算的實時性以及消耗預估的準確程度,在預計某些計劃快要達到預算上限的時候,應降低它們的投放速度,從而使計劃平滑地到達預算上限,
需要注意的是:因為已經投放出去的廣告會停留在用戶界面上,用戶依然可以對它進行操作,這種行為的滯后性會讓短時間內的廣告消耗難以準確地衡量,而這種自然延遲是不可避免的,我們唯一能確信的只有廣告投放事件,
5,業界對于超播的常規做法
5.1 廣告主投放后臺的角度
最小預算不能低于一個數值,比如50,因為預算越小,演算法可以發揮的調節作用就越小;
那么有個問題就是,就是這里的防止商戶作弊的最小預算和預算門檻之間的關系是什么?各個行業也肯定不同,所以如果要建立這么一個標準在的話,應該如何劃分這個標準?
建議廣告主不要頻繁修改出價和預算,不僅會破壞演算法的訓練程序,而且在出價和預算的程序中會造成演算法調整的一段盲區,導致超投,
當廣告主調小預算時,設定一個限制,比如,如果即時生效,則調整的預算下限需要大于消耗金額的某個值,或者直接調小金額第二天生效,
5.2 從廣告工程及演算法側的角度
該圖參考自LinkedIn的論文(見文末的參考文獻說明)
Reference:
1,《Smart Pacing for Effective Online Ad Campaign Optimization》
2,《Budget Pacing for Targeted Online Advertisements at LinkedIn》
3,http://www.woshipm.com/pd/2095328.html

轉載請註明出處,本文鏈接:https://www.uj5u.com/qukuanlian/305514.html
標籤:區塊鏈
上一篇:Autoshark遭黑客攻擊打響Defi十月安全警鐘
下一篇:橙子錢包app是誰做的?
