廣告科技 - 當waterfall遇上header bidding
好久好久以前，我開始著手寫著中文版的廣告科技文章，大概也不超過十篇，放在這也放在那，大概是我寫得太差沒人要看。幾年前終於有人回覆我，謝謝我寫的這些文章並期待我的下一次廣告系列的更新(也可能是意思意思說說而已?)，但當時我已經不在廣告業也被covid打亂我的生活。之後在跌跌撞撞的工作生涯中，又回到了廣告科技業。想來也是時候再一次繼續我的廣告科技更新?
在這一篇header bidding的文章中，我曾經提到header bidding在逐漸取代waterfall，經過了這麼多年，可能你以為waterfall已經是上一個時代的產物。但其實不然，他還是在某處繼續光發熱。
在這我要更正一個在header bidding篇的敘述，即hedaer bidding速度快利潤也高，更精確的說法是，在有限的時間內，拿到最大的利潤。假設給予足夠的時間，waterfall的利潤可能不比header bidding差。總結來說，header bidding 和 waterfall的區別在於對時間和效能之間的有不同的權衡。
時間
相較於網頁廣告需要在第一時間將廣告顯示給使用者，手機廣告則有很充裕的時間來決定廣告。比如說你玩手機遊戲，玩了20分鐘後需要看一支廣告來拿精力讓你繼續玩，在這個例子裡，app只要在20分鐘內決定好廣告即可。
效能
效能可以分兩部分討論，上游(DSP, Exchange, etc)及下游(Publisher, App, etc)。
下游(Publisher, App, etc)
Publisher的目標就是最高利潤。如果用header bidding來說的話，就是針對當前user impression舉辦“一次”競標讓所有上游廠商帶著自己內部競標結果來參與，以此來爭取短時間內的利潤最大化。而waterfall則有一個header bidding所沒有的優勢，即讓上游廠商重複舉行內部競標，並針對每一次的內部競標設下達標限制，以此達到比較穩定的高報酬的可能性。舉例來說，publisher可以設定以下的waterfall
1: floor $10 DSP1
2: floor $9.99 DSP1
3: floor $9.98 DSP1
4: floor $9.97 DSP1
5: floor $9.96 DSP1
對於每次的floor，DSP1 都會重新舉行一次內部競標，並可能有不同的結果。白話一點來說，就是上下游廠商不停的討價還價，上面的設定可以成翻譯下面的場景。
app: 你去問問有沒有廣告商要用$10來買這個impression
DSP1: 好，我來問問。....最高$9.5
app: 不行，不然你去試試$9.99
DSP1: 好啦，我來問問。....最高$9.5
app: 不行啦，反正我時間多可以耗，不然你再去問問$9.98
DSP1: 好...我來問問。....有了，這次有$9.98!
app: 成交！
相較於header bidding是直接拿最價錢最高的結果(可能低於waterfall floor)，waterfall則是可以用重複的競標來確保拿到最佳結果。這時聰明的publisher也發現，是否可以兩種方法合在一起，做成撒尿牛丸(暴露年齡)。事實上是可以的，也確實有人這樣做。舉例來說，publisher可以設定以下Hybrid waterfall
1: floor $10 DSP1 DSP2 DSP3
2: floor $9.99 DSP1 DSP2 DSP3
3: floor $9.98 DSP1 DSP2 DSP3
4: floor $9.97 DSP1 DSP2 DSP3
5: floor $9.96 DSP1 DSP2 DSP3
也就是每一個floor都是一個header bidding，白話來說，就是上面小劇場裡，app每次的對話對象從一個DSP改成多的DSP，也更容易達到最大利潤。
上游(DSP, Exchange, etc)
對於上游廠商來說，通常採分潤制，理論上下游賺越多，上游也賺越多，但實際上每一次的內部競標都需需要成本，從上面的例子來說，三次內部競標也許可以多帶來一點利潤，但扣掉競標成本之後可能賺的更少了。
因此有的廠商可能會嘗試偵測針對同一個user impression的重複競摽並做出處理。然而這非常困難，因為對於廠商來說，每一個floor發出的ad request都是沒有關連的。除非這個waterfall SDK屬於某一間廠商，從而知道是否app有設定重複的競標。
結論
雖然waterfall和header bidding都有一個清晰的架構定義，但在現實中，都會針對自己的需求來改造出客製化的架構，例如如果覺得waterfall一層跑完才跑下一層太慢，其實你可以一次發出五層的reqeust，然後再依序往下走。如果覺得header bidding一次不夠，那你可以多跑幾次。所以很難說某一個架構比另一個好，只是有沒有用對地方而已。