看到朋友提到RTB的一些討論，分享點我個人設計的經驗

看到朋友提到RTB的一些討論，分享點我個人設計的經驗。因為腦袋現在不是很清楚，寫的不是邏輯通暢的話還請見諒。
.
DSP系統設計會包含RTB(Real Time Bidding)這運算單元，存在理由之其一是為了要解決「多人在同個時段彼此競爭，並鎖定相同之對象，以同樣預算、同樣走期下，依照出價狀態做出適當化的廣告播送排序」。
.
私心一點講，這麼做的目的也就是讓平台方可讓廣告預算於執行上，可以進入「最佳極大化的執行運算」。也就是令每一分廣告預算不僅都能被妥善用掉，還能在同質競爭激烈的受眾中，區分出哪些受眾價格高、哪些受眾價格低。而高低範圍在預算與出價之間找出平均值，將此平均值作為衡量廣告播放權重的參考依據。
.
這麼說，也就是競爭激烈的受眾，會刺激出價者出更多錢，然後誘導預算相對較低的廣告主可把預算放在次要、次次要受眾身上。藉此做到第一階層的平衡。RTB整體來講，對我而言只不過是個手段與方法，欲達成之任務目的有很多層不同意義，所以我本身不怎麼會去主動談RTB，反倒是用「規劃較為符合客戶廣告預算之媒體操作策略」，作為溝通說明的主軸。
.
其實，核心都是為了解決遞送廣告時，面對「同時」多方不同的需求，怎麼去平衡而生的一種技術應用與設計。細節日後有機會再分享，光是為了要設計RTB這機制，我們就得規劃無數種不同的情境與版本，用來讓廣告的分配還有排程可以盡量符合媒體平台經營者的「需求」。
.
最後補充，有出當然就會有進。一個廣告被播送出去，在系統上呈現什麼樣貌，數字回饋得到什麼，然後再將其資訊「比較與運算」過後，依照原先設定好的幾種不同模式，置入到系統中再運算。從中回去看採用RTB時的出價會不會因為邏輯設計上的矛盾產生衝突造成非必要的浪費(包含播送次數不足)或是令成效不佳的廣告被過度消耗(預算執行不彰)等。
.
設計DSP的雜談，真正內部作業在開發這種系統時，設計出來的複雜度也不是怎麼幾個字就能說完。所以我不大傾向將RTB作為一種行銷Fancy的說詞，反倒是更為深入的去看這運算本質的存在應該在系統中扮演什麼角色，又這角色帶來到何種程度的平衡。
.
補充說明。不只是RTB本身會有競爭賽的狀況，幾乎相同的條件在廣告遞送時，也有很多競賽的情況要被解決。如果就人性來講，DSP的本質就是為DSP的擁有者獲得最大利益(廣告預算被執行)，但事實上光是這樣不夠，廣告主的期待也得同樣去滿足，那就是廣告成效在什麼樣的狀況下可以被最佳化的展現。而這又是另外一個層面的競賽，與RTB沒有直接關連，可卻是影響廣告在不同的時間點、不同的地點、不同的設定上，會發生各種不同的結果。只是這些結果到底能不能滿足初始設計時的要求，那就得不斷在各種情境下去假設，並實際投入運算，再找出有沒有違背現況的問題。