廣告機制流程
[TOC]
目前使用的廣告機制
- 瀑布流
- 競價
使用的版位
瀑布流
由於瀑布流廣告不會挑CPM(千次曝光價格),為了讓每一次的廣告請求及展示的收益最大化,這裡將價格分三個區塊。每個價格區間需要對應一個廣告版位。
插頁
- 高CPM版位
- 中CPM版位
- 無地板價版位
橫幅
- 高CPM版位
- 中CPM版位
- 無地板價版位
以上版位存在於一個廣告平台,如果有多個平台則需創建相同數量的版位,並於APP內自行處理切換呼叫不同平台廣告的機制。
競價
競價模式的廣告與傳統瀑布流不同,系統會自動將出價高的廣告優先提供給手機端呼叫,因此這邊只需要創立對應的廣告版位即可。
插頁
- 插頁版位
橫幅
- 橫幅版位
實作項目
- 瀑布流插頁廣告manager (輪流呼叫瀑布流插頁版位、處理廣告response)
- 瀑布流橫幅廣告manager (輪流呼叫瀑布流橫幅版位、處理廣告response)
- 競價插頁廣吿manager (處理競價插頁廣告response)
- 競價橫幅廣吿manager (處理競價橫幅廣告response)
- 插頁廣告adapter (請manager呼叫廣告,並接收manager輸出的廣告,傳遞給controller)
- 橫幅廣告adapter (請manager呼叫廣告,並接收manager輸出的廣告,傳遞給controller)
在切換不同版位以及不同平台需使用責任鏈模式處理,以確保不會呼叫過多的廣告。過多無用的請求會妨礙人員對後台數的判斷,當廣告顯示出現問題時,會難以判斷其核心原因。
職責說明
Manager(管理器)
- 請求第三方廣告
- 自動接續請求各價位廣告(瀑布流適用)
- 回傳請求的廣告
Adapter(轉接器)
- 判斷是否需要請求廣告(ex:是否達到預定的請求廣告時間)
- 要求Manager取得廣告
- 透過代理模式取得Manager的廣告
- 統一將接收的廣告轉成UIView類別並輸出給controller
Controller(顯示器)
流程圖
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
| graph TB
adapterRequestAd(Adapter下達請求廣告指令)-->checkBiddingManager{檢查是否有競價Manager} checkBiddingManager--是-->biddingAdRequest[競價廣告請求] checkBiddingManager--否-->initBiddingManager[初始化競價manager] initBiddingManager-->biddingAdRequest -->isBiddingAdResponse{是否有競價廣告回應}
isBiddingAdResponse--是-->adapterReceiveAd[將廣告傳給Adapter] adapterReceiveAd-->toController[提供指定Controller廣告] toController-->displayAdvertise(顯示廣告) isBiddingAdResponse--否-->leadToWaterfall[Adapter導向瀑布流廣告] leadToWaterfall-->checkWaterfallManager{檢查是否有瀑布流Manager} checkWaterfallManager--是-->highPriceAdRequest[請求高價位廣告] checkWaterfallManager--否-->initWaterfallManager[初始化瀑布流manager] initWaterfallManager-->highPriceAdRequest highPriceAdRequest-->highIsResponse{高價位廣告是否有回應} highIsResponse--是-->adapterReceiveAd highIsResponse--否-->midPriceAdRequest[請求中價位廣告] midPriceAdRequest-->midIsResponse{中價位廣告是否有回應} midIsResponse--是-->adapterReceiveAd midIsResponse--否-->lowPriceAdRequest[請求低價位廣告] lowPriceAdRequest-->lowIsResponse{低價位廣告是否有回應} lowIsResponse--是-->adapterReceiveAd lowIsResponse--否-->endLoop(結束)
|