上一章： 我在優酷OTT端做自動化制圖 | 《優酷OTT網際網路大屏前端技術實踐》第五章>>> 下一章： OTT端性能優化建設之本地緩存設計 | 《優酷OTT網際網路大屏前端技術實踐》第七章>>> 點選免費下載下傳 《優酷OTT網際網路大屏前端技術實踐》>>>
一、背景
酷喵APP，一方面擁有巨大的DAU量級，一方面受限于種種原因，營銷投放滲透率還有很大提升空間。在技術上如何尋求某些突破口，實作端内投放滲透提升？
經過多方讨論，我們将注意點放在了酷喵APP“播放頁”上。作為視訊服務APP，依托千萬級的強勁日活人群支援，“視訊播放頁”達到PV上億規模，在端内PV量級排名中無可争議的第一。
如何建設OTT播放頁，問題如下：
OTT播放頁将如何承載投放？
互動及互動方式是怎樣？
容錯機制如何處理？
定向投放如何實作？
使用者觀影體驗如何保障？
共建開發如何分工？
……
二、橫向調研
相比較而言，手機APP端、PC端、OTT端在播放頁中，均有相應營銷投放，在“播放器區”均建設有“互動投放”，經情況了解及資料檢測，我們發現播放器區投放滲透效果遠遠優于其它區域坑位。我們判斷，如果OTT端新開辟播放器區投放能力，将在相當大程度上提升投放滲透率。
下面我們對手機APP端、PC端、OTT端播放器區投放，進行簡單介紹。
1、PC端
PC端在播放頁-播放器中，政策投放主要是“付費引導”，如圖所示，PC播放器經過UPS鑒權，擷取該使用者之于該視訊的權益資料，根據資料情況确定是否露出引導文案及連結，點選互動連結拉起“PC彈框收銀台”。
2、手機APP端
手機APP端與PC端類似，也是在不影響使用者觀看體驗情況下，經過鑒權，判斷是否露出付費引導按鈕。不同的是，無論全屏還是小窗播放情況下，手機APP端在使用者點選付費引導按鈕後，都是拉起半屏Native收銀台(右側圖)，此時，仍然不影響使用者觀看視訊。
3、OTT端
與PC端和手機APP端一緻，均為在不影響使用者觀看體驗情況下，經過鑒權，判斷是否露出付費引導按鈕。而使用者遙控器OK鍵，則新打開收銀台頁面，此時視訊觀看被阻斷。
4、總結
我們對比了PC端、手機APP端、OTT端播放器區營運投放能力：
經過調研發現，PC端、手機APP端、OTT端播放頁-播放器區互動投放大緻特點：
1) 播放器區互動投放，基本不影響使用者觀感體驗(OTT端除外)；
2) 播放器區互動投放分兩步，先露出引導内容，經由使用者操作，展示完整投放内容；
3) 使用者可通過操作，将該區域投放關閉，恢複初始狀态(OTT端除外)；
4) 具備特定次元定投能力（圈人設定售賣商品）；
5) 目前三端投放能力主要為付費引導/收單；
縱觀看來，PC端、手機APP端、OTT端的播放頁 “投放”更像是一種“配套能力”，緊緊圍繞視訊付費引導展開，并未涉及活動投放，且形式固化：通過權益判别，實作在站/端内每一個需付費視訊(相對使用者權益)，精準付費引導。而在OTT端我們更希望的是同時具備“付費引導/收單”和“活動投放”兩種能力。是以，在OTT端播放互動建設規劃中，勢必與先行思路有所差別。
三、建設方案
1、方案次元
OTT端最終确定OTT播放頁半屏互動以“裝置硬體/APP版本/賬号權益狀态”綜合次元進行付費引導投放和活動投放，投放内容本身獨立于播放頁/播放器。實作多種次元，批量定投收單以及活動投放。
2、互動方案
經過多方溝通，我們逐漸梳理出一條OTT端播放頁-播放器區營銷投放互動方案。即在OTT播放頁-全屏播放狀态下，通過定向投放，在特定播放時間點位，露出“引導卡片圖”，使用者遙控器OK鍵後，由右側拉出半屏頁面，在該半屏頁面完成既定營銷互動，我們稱之為“OTT半屏互動”。互動圖如下：
3、技術支援方案
目前在OTT端酷喵APP開發過程中中，存在3種技術棧，即原生Native、weex、H5。原生Native作為酷喵APP主要開發項；weex一方面作為坑位投放頁面開發技術棧，一方面作為能力補充，補位Native開發；H5為早期投放頁面開發技術棧，本财年已逐漸被weex取代。
綜合評比，我們得出方案3為最優方案，後續的共建分工及實作邏輯也相應浮出水面。
4、共建分工
互動設計與技術支援方案已經确定，接下來梳理業務開發鍊路，并進行拆解，鍊路邏輯圖如下：
按照上方鍊路邏輯圖，多方共建分工已然明确，本次共建涉及：
1) Native方 - OTT weex容器、播放頁/播放器能力支援；
2) CMS方 - OTT投放CMS能力支援
3) 後端 - 接口支援
4) 前端 - 互動排程/weex開發
四、體驗保障
1、觀感保障
雖然OTT全屏播放，播放畫面尺寸較大，但半屏互動頁由螢幕右側拉出，勢必會遮住部分播放畫面，影響使用者觀看體驗；此外，OTT頁面操作，涉及“焦點切換”(OTT端頁面有且最多隻有一個焦點選中)。這兩點需要尋求突破點解決，經過與播放頁面/播放器同學溝通，得到一個相對完美的解決方案，即：
1) 半屏互動定投，“引導卡片”在特定時間點位露出(本質為weex頁面)，此時由于該卡片尺寸較小，讀使用者觀感體驗營銷較小，不做處理；
2) weex頁面高層級浮在播放器之上，為保證使用者遙控器互動，weex頁面通過Native api，執行搶奪頁面焦點邏輯；
3) 使用者遙控器點選“OK鍵”，半屏頁(開發/設計約定寬600px)由螢幕右側拉出，在該節點，前端weex層調用Native bridge方法，通知播放器，收縮播放器尺寸；
4) 随後使用者遙控器“back鍵”，則weex層立即通知播放器回複全尺寸，之後weex頁面自行執行頁面執行個體銷毀，頁面焦點重新回歸播放器；
2、前端容錯
前端作為最下遊展示業務，直接面向觀影使用者，上遊任意一環節出現故障，都可能導緻前端業務出錯，為保證該環節健壯性，增強前端容錯勢在必行。在weex容器與前端共建過程中，根據架構設計，前端在兩個方面進行了容錯處理：
1）靜默運作-錯誤防控
上文“共建分工”鍊路圖中，在命中定投且到達時間點位後，weex容器被拉起，且為靜默運作，并未展示在界面中。此時前端weex半屏頁被打開，在執行個體化weex頁面過程中，前端邏輯需要通過Native api方法擷取半屏配置資訊、檢視螢幕播放狀态等操作，此階段，一經出現業務錯誤，則前端weex邏輯終止執行個體化，并執行weex執行個體銷毀，将業務錯誤規避于未展示階段：
2）前端緊急開關
考慮到播放頁作為酷喵APP最核心頁面之一，且PV量級巨大，OTT投放平台配置有狀态開關。此外，為保證開關狀态實時性，在前端層面增設緊急開關邏輯，以應對突發故障，雙重保險。
在CMS及前端MT平台，兩道開關保險，確定半屏互動投放，在故障發生時，迅速止血，且實作使用者無感覺，不影響使用者體驗。
五、場景建設
在半屏互動能力支援下，前端線完成兩大場景建設，即：半屏收銀台、半屏活動投放。
1、半屏收銀台
在最初，OTT端僅有Native收銀台，後續借助《OTT 端登入态裝置穿透：掃碼登入與反登入》一文中介紹的同步登入态能力，在前端開發完成weex版“單商品收銀台”，并将該收銀台元件化，實作可視化搭建。
在後續的“OTT半屏收銀台”建設過程中，複用“單商品收銀台”能力，完成與半屏互動能力的結合，“OTT半屏收銀台”就此誕生。
差別于手機APP端半屏收銀台，OTT端半屏收銀台為獨立于播放頁/播放器業務，以“裝置硬體/APP版本/賬号權益狀态”多元度進行付費引導查詢，實作多種次元、批量定投收單，描述為：
特定硬體類型、特定APP版本、特定會員情況、指定會員商品、指定視訊内容播放中曝光。
如上圖，OTT酷喵APP在完成該半屏能力建設後，端内三種收銀台能力形成：Native綜合收銀台、weex單商品收銀台、weex半屏收銀台：
2、半屏活動投放
前文提到，OTT端播放頁半屏互動投放為獨立存在，并非內建式，且具備多元度定投能力，站在營運同學角度來，半屏互動投放無異于一個新的、高曝光量級的“定投坑位”。
與“半屏收銀台”相比，“半屏活動頁”偏向于業務開發，不再拘泥于商品、付費、收單的固定範疇，而是面向于個性化的業務訴求，是以在開發階段也更加多樣化。例如下圖：雙11預約貓晚。
六、總結
借助OTT酷喵APP自身硬體特性及使用者使用習慣，創新完成“半屏互動”建設，該能力既滿足使用者線營運“大量級曝光”的訴求，滿足會員線營運“精準投放、提高滲透”的訴求。根據資料結果，在曝光UV量級上，實作端内投放曝光UV提升200%。
半屏互動能力已經具備，也經受住了實際考驗，作為技術開發人員，除了考慮業務支撐外，還需要考慮開發效能提升。因前端半屏業務相對正常業務而言，開發與調試都更加複雜。在之前的前端半屏業務開發過程中，尤其在拉取配置資料、搶取焦點等環節存在諸多“彎彎繞”，調試/測試過程也不同于正常項目，且新手上手開發成本較高。
在上述痛點之下，尋求突破勢在必行，在經過多輪方案驗證，最終敲定并完成兩種優化建設：
1、半屏可視化搭建
前端開發一套“半屏可視化搭建套件”，內建于阿裡文娛的可視化搭建平台，套件内置播放中調用監聽、搶取焦點、擷取配置、實時監控、緊急開關等邏輯。由營運同學在平台直接可視化搭建釋出，應對正常半屏業務，無需開發介入；
2、半屏投放-能力模闆
主要應對高複雜度/個性化業務，能力模闆完成播放中調用、搶取焦點等邏輯，具體業務實作由業務方<如電淘>自行開發。雙方邏輯解耦，降低開發難度與時間成本，提高半屏業務投放穩定性。
該兩種能力優化，本文不再展開介紹，将在後續文章中詳細解讀。