開屏廣告的陳年老坑

開屏廣告，顧名思義，是在手機開機的時候閃現3-8秒的廣告。一般可以是圖片、視頻等格式，可點擊可跳內嵌頁。

前段時間受到一活兒，要對開屏廣告做個優化，優化的目標是兩方面：更多的展示量，更精準的控制。

於是便開始研究這個app的開屏廣告實現機理。

然後發現真的是一個相對簡單的實現方式：

這個機制裡面有兩個問題：

1、在啟動——展示過程中，並沒有和伺服器通信。即：無法控制展示量下限（因為伺服器不能告訴客戶端不要再展示了）

2、展示的內容是上次啟動時已緩存。即：無法控制展示量上限（因為不知道有素材的用戶什麼時候再啟動）

於是解決的思路有兩點：

1、讓每天啟動的用戶儘可能地有緩存好的素材。（PS：可以思考下為什麼開屏廣告不能實時地獲取廣告圖片）

2、知道或者預測當天展示了多少。

於是第一版優化方案就出來了。主要的思路是：儘可能地早去讓用戶獲取到素材，比如提前3天。並且對當天的用戶進行切分，通過控制展示幾率來控制展示量。當顆粒足夠小的時候，實際已經可以粗略地控制展示量了。

但這一版並不滿意，原因是，移動端的情況很複雜，比如或者節假日就會偏離。這樣對於廣告售賣來說並不可控。

我們甚至提出了一個預測模型。作用是通過用戶以往登錄行為，來判斷用戶下X次啟動會在什麼時候，並上報給伺服器。這樣伺服器就可以通過每一個移動端上報的預測時間，來預測展示量。

此時，【幾率控制】這條路似乎走到了死胡同，無論怎樣，都會受到異常的節假日影響。並不能精準控制。除非廣告售賣是按CPD來售賣的。

我們又回到剛才的原點：

啟動的時候，沒有和廣告伺服器通信。那麼為什麼不可以在啟動的時候進行通信呢？

原來考慮的是，通信時間太長，會讓用戶先看到一個空白的啟動畫面，然後出現廣告。但是，時間會有多長呢？

於是我們去做了個實驗，實驗發現，通信時間<1s的，佔比80%。完全是可以接受的。

第二版優化方案就出現了。

我們在啟動的時候，向廣告伺服器發起通信，並告知即將展示廣告A，是否批准？廣告伺服器會按照目前的展示量，返回消息，告知是可以展示還是不行。

按照這個方案，需要預先X天投放廣告素材，讓這X天啟動的用戶均下載到廣告素材。那麼在當天有素材的用戶佔比可以去到90%。

然後這些有素材的用戶，展示前先和伺服器通信，詢問是否可以展示。精準控制80%的用戶。剩下的超過1s返回消息的用戶，默認隨機展示，此規則置於本地。

————————————————————————————————

補充個後續：這個廣告位最終被按照CPD來售賣了。一方面，要求廣告客戶提前給素材，在執行過程中不現實。遇到一些國外的的客戶，最後一天才給素材，真是吐槽無力。

業界還有一些奇異的解決方案，比如為了讓開屏廣告兼容多媒體（動畫啊，音樂啊，交互之類）。有些將素材格式做成了一個rar文件，裡面是一個H5框架，置於閃屏文件內，比如著名的企鵝公司。

而我的土辦法是………………做成GIF或mpeg。

整體上，從目前的硬體資源上看，因為啟動時是需要耗損系統的內存資源的，所以不建議做多媒體樣式的廣告。尤其是蘋果，如果你用的組件不太靠譜，隨時會閃退。

再有就是開屏多用於品牌宣傳，按照目前的app啟動機能，你要點擊後跳轉指定的H5甚至原生頁面，那就要犧牲掉一部分低端機。測試過，有些等待超過5s才能跳轉的。

暫時想到以上，有空再把其他坑填上。

另外額外給新人們一個提示：開屏廣告的點擊可跳轉樣式（比如跳H5，跳app原聲界面），一定要先規劃好。在app內跳幾級頁面，能不能返回上一級菜單，都很多坑的。而且安卓和ios都不太一樣。有機會的話，還是和客戶端開發同學們溝通下。坑很多，踩過的包含不限於：

1、不能返回

2、統計不能上報（因為域問題）

3、支付不了（蘋果坑特多，H5支付，還是調用應用內支付）

4、點擊不了（某些H5內嵌再內嵌）

5、聲畫不同步（某些插件遇到性能差的主機會掛）

6、畫面匹配不了（比如2:1）