RTB撕開黑盒子 Part 0：Pacing: is everyone doing it wrong?

標籤：

 

曾嘗試為我們的RTB客戶解決過Pacing問題，Pacing問題要解決的問題是：如果一個客戶給你一筆預算，讓你去運營一個廣告推廣計劃，在一定的時間內投放廣告，將這筆預算在指內的時間內，比較均勻地將預算消耗完。如果把預算消耗超出了，那就要自己貼錢了。如果沒消耗完，這對於下次和客戶合作的時候會有點丟臉。並且如果你不是均勻地進行消耗，你會發現自己面對著一堆憤怒的客戶。比如幾分鐘就燒完客戶50美元的預算。聽起來很顯然，是吧？但這問題比聽起來要困難的多。

Doing it wrong

當Datacratic第一次將頭伸進RTB時，控制預算消耗的主要工具就是一個日限額。我們用了48個小時才發現下面的方法是不可行的：我們設定了幾種類型的過濾來決定何時對所有請求進行競價。但結果是或是我們沒有消耗完日預算，或是很快就燒完了預算，通常是後者。在實踐中，我們是從0點開始購買展示，並在早晨晚些時候消耗完。

 

 

在日限額達到後就不再競價

如果客戶要求投放的時間是30-60天，採用上述的投放方式，看起來似乎還不算太糟：因為是按要求的時間將預算消耗完，並且每天消耗相同的金額。但我們有一點很不開心的是，每天有一大段時間我們是沒有進行任何競價的。於是我們加了一個小特性，對X%的流量進行競價，當這個特性發布後，我們發現結果中有個非常有意思的現象：我們以前所購買的流量，實際上是一天之中最貴的流量！是一個流量較多的推方計劃的平均勝出價格，它有一個很明顯的規律：如果是從中午開始購買流量，CPM的價格是逐漸下降的，一直到午夜突然陡升近40%，CPM隨後有些波動，然後在早晨下降後又上升，到中午達到峰值。然後又是一天新的迴圈開始。

 

 

 

可以看到每天午夜都會有價格的陡升

那麼為什麼會有午夜的這種價格陡升呢？按理說這應該是個充分競爭的市場，但午夜後的1分鐘的流量真比2分鐘前的流量多值40%嗎？我們也沒徹底搞清這個問題！我們當前的猜測是：競爭環境中一定有很多的DSP和我們剛開始一樣：每天設定一個日限額，並在午夜重設日限額。這就意味著在午夜時對流量有很大的需求，因為如此，價格一下被抬高（也可能是其中一個DSP重設日限額後，它的出價比之前出價最高的DSP還高，使得這個小的流量價格陡升）。並且因為DSPs有著不同的日限額和流量控制策略，所以它們是在一天中不同的時間點消耗完的，這樣就使得需求下降，進一步引起價格下降。從有一個規律不明顯，但將多天的效果疊加，就得到了，可以看出在3點鐘還有一個類似的陡升，3點鐘是西海岸的午夜。

 

 

 

八月彙總平均後的每分鐘的勝出價格

現在對於這種陡升也有一些其它的可能解釋。可能是我們處在東北方這個位置，所以我們這個地區的請求流的組成有變化，所以這或許僅僅是一個地區的規律？儘管3點鐘的陡升的現象讓這種解釋聽不來不太可靠。午夜也恰好是我們開始競價的時候，但我們的量是逐量的，並且我們的量不足以說明這種陡升。也可能是一些大的網站在午夜有一些最低出價的限制。或是其它DSPs很聰明地發現了午夜之後的點擊率比午夜前幾分鐘高很多。我對這些解釋充滿了懷疑，讀到我這篇文章的任何人有什麼想法，我非常歡迎來與我討論。但不管是什麼原因，下面的結論都可能是成立的：如果你只想在一天中的幾小時內投放廣告，不要選擇淩晨開始投放，10AM結束。

 

譯註：不知道國內的DSP開發有沒有做這個資料分析，我分析出來的結果和Datacratic的不太一樣，但我現在還在爆流量的階段，可能統計的量上不太夠，但還是有些規律的。有機會大家一些討論一下。

 

Closed-Loop Control to Rescue

我們先假設這一篇文章，在RTB圈子裡引起了極大的關注，而這種淩晨的價格陡升現象消失了，或是你也許只想將預算均勻地在每天消耗，如何去做呢？上面提到過，我們可以每天對X%比例的流量進行競價。最簡單的辦法就是，將日限額除以不加限制的每日消耗，得到競價比例，這原則上能在淩晨消耗完日限額。但在實踐中，只對固定比例的流量競價，每天的曝光量會差異非常大，有時候會超出預算消耗（如果你沒設定日限額）有時候會消耗不完預算。也許某些天你會得到一個變化量非常大的請求量，也許是因為你上流的SSP在做修改。（譯註：如果你的請求量在在9點後是一條直線，這是因為google的QPS限制，這個可以讓google的support team的人支援一下，這個曾經搞的我很困惑為什麼請求量這麼均勻）。也許SSP出了故障。而且競價流量會有很大的變化，比如，突然間有大量增加（或大量減少）來自你定向地區的請求。（譯註：這個現象很明顯，我現在考慮了廣告位的影響，請求的流量有時候會有大量的某個廣告位的垃圾請求過來，導致我的出價曝光產生劇烈的變化）。也許是你的競價邏輯本身會使消耗速度不一致。所有的這些因素都會造成你的消耗額是隨時間變化而參差不齊的：

 

 

 

儘管設定的出價機率是個常數，消耗速度還是可能不均勻

那麼解決方案是什麼呢？對我們來講這個問題是一個控制論的問題，並且我們從無反饋控制換成了反饋控制。如果你是想用機率來控制競價，那麼如果你設定完請求機率，然後競價一周后分析結果後，這基本是無反饋控制。如果每天早晨你看一下前一天消耗是多少，然後相應地調整當天的競價機率，那麼這就是反饋控制的做法，反饋控制即是將輸出的資訊反饋到輸入中去。這種方案很容易自動化，並且很自然地可以將反饋周期變短，將周期從天調整到幾分鐘。我們的RTB系統按這個方案重新設計了出價速度的實現，我們可以將與目標出價速度的差異控制到1-2%，我們只使用了簡單的反饋機制：每2分鐘，參考前2分鐘的出價速度，設定下2分鐘的‘正確出價速度’。所以，無論什麼原因，我們假設少了20%的請求，比如在晚間，那麼競價機率會上升，使用消耗速度保持近似相等。還有一些更複雜的反饋控制方案，但這種基本的方案已經不錯了。

 

 

 

是我們反饋控制的結果。注意，無反饋控制的輸出看起來像Mordor的山（魔戒），而反饋控制的輸出像是Shire的平原。

 

 

 

為真實的資料，進行了一點平滑以揭示深層的變化，Pace(藍色，機率 * 1000)會在晚間流量下降時上升，消耗速度(綠色)會與目標消耗速度(紅色)幾乎保持一致。

和任何好的最佳化演算法一樣，它要做的就是完全按你的要求來做：它努力將消耗速度和目標消耗速度的差距降到最小。但是如果系統出現了一個嚴重的故障，導致一段時間不能競價，當故障恢複後，這種方案將不會調整目標消耗速度來補償前一段不能競價造成的影響：

 

 

故障後，消耗速度沒有進行補償（斜率和以前的目標消耗速度斜率是一樣的）

 

為了處理故障造成的影響，還有一些因為系統不完美，使得錯誤積累造成的超出預算，未到預算的問題，我們需要動態地調整消耗速度目標。我們重新定義一下我們反饋控制的最佳化目標：消耗速度始終儲存與剩餘消耗在剩餘時間同一水平。這就意味著如果有一天或是一小時出了故障，無需人工幹預，就可以在故障後調消耗速度目標進行補償。這個系統還有一個很好的性質，它會在剩餘消耗為0時，準確地自動停止。

 

 

很明顯，你不會想在任何時間總是採用相同的消耗速度，事實上我認為你是肯定不會的。一個反饋控制系統可以支援幾乎任何你想要的消耗速度的曲線。你可以採用競價機率外的變數去控制(比如：真實的競價價格，或是定向條件，或是任何你能想出來的方式)。最後，思維敏捷的讀者可能發現一個問題，上面描述的方法只有當請求流量大於你的限額可以買的量的時候才有效，如果你的競價機率設定到了100%也得不到你的日限額，甚至當你贏得所有的流量也不可能達預算，甚至對所有流量你都勝出也到不到預算。那上面的方法是無效的。

RTB撕開黑盒子 Part 0：Pacing: is everyone doing it wrong?