建站
咨詢
售后
建站咨詢
新聞中心
一、 背景概覽 1、 背景
云視聽小電視作為一個發(fā)展迅猛的APP，是多屏部門主要產(chǎn)品線，會安裝于各電視廠商的智能系統(tǒng)上。用戶通過點擊端外的資源位進(jìn)入小電視APK（外喚）或者直接打開小電視APK（主啟），這兩種方式進(jìn)入端內(nèi)，來消費(fèi)各種視頻資源和信息。在此商業(yè)邏輯鏈條中，涉及端外投放拉新拉活獲客，進(jìn)入APK后端內(nèi)承接，瀏覽消息過程中用戶體驗，以及退出時用戶的整體觀感，對活躍過的用戶預(yù)期召回等很多要做的事情。本文中我們主要關(guān)注渠道用戶通過外喚或主啟的方式進(jìn)入小電視后，在用戶全鏈路的生命周期過程中，在各個節(jié)點上，對用戶進(jìn)行更好的承接，讓廣大用戶更加喜歡我們的產(chǎn)品。
2、 目標(biāo)
云視聽小電視歷經(jīng)多個產(chǎn)研走轉(zhuǎn)，本身就存在歷史技術(shù)債較重，數(shù)據(jù)埋點缺失較為完整工業(yè)化體系的問題，而做好渠道用戶承接首先就需要做好用戶數(shù)據(jù)的全鏈路跟蹤，看清用戶的行為。之前的客戶端埋點數(shù)據(jù)存在以下問題：
用戶訪問難量化 - 客戶端埋點并未有用戶訪問的標(biāo)識，只有設(shè)備ID單天訪問頁面的時間線，難以準(zhǔn)確量化
用戶路徑難跟蹤 - 客戶端spmid埋點體系下，設(shè)備ID粒度比較散，串聯(lián)用戶訪問頁面成本很高，需要耗費(fèi)大量BI數(shù)分人力
用戶承接也缺乏分析抓手 - 用戶承接數(shù)據(jù)分析缺乏具體的有效抓手，僅限于有限場景下具體分析
這些問題會阻礙我們對用戶行為的清晰認(rèn)知，也讓用戶承接只能通過一些后向統(tǒng)計數(shù)據(jù)進(jìn)行。
另外一個問題是之前外喚用戶缺乏靈活的承接策略執(zhí)行，每次執(zhí)行用戶的外喚承接策略都需要走跟版發(fā)布
故結(jié)合以上兩點我們目標(biāo)總體來說是
- 數(shù)據(jù)精細(xì)化基建：清晰提供生命周期會話級別的用戶訪問全鏈路精細(xì)數(shù)據(jù)和用戶訪問路徑數(shù)據(jù)
- 提人效 : 運(yùn)營同學(xué)用戶承接找到分析的抓手，提給給運(yùn)營同學(xué)直接的分析平臺，能直觀地檢索到用戶行為數(shù)據(jù)
- 提產(chǎn)效 : 對外喚用戶提供常見的可配置化用戶承接策略能力，幫助策略產(chǎn)品和運(yùn)營快速驗證和實現(xiàn)自己的產(chǎn)運(yùn)策略
二、 方案設(shè)計
1、 流程概覽
圖片
流程簡述
為實現(xiàn)以上的目標(biāo)，我們參考業(yè)界常見埋點實踐方案，設(shè)計一套以session_id和投放ID為核心串通數(shù)據(jù)的埋點與分析處理流程。其中投放ID是由我們內(nèi)部渠道投放平臺生成的某一次端外投放ID，作為產(chǎn)運(yùn)回收投放效果標(biāo)識的唯一ID，在本文中暫不詳細(xì)展開說明；而本文主要關(guān)注的session_id來自于每次APK冷/熱啟動時，服務(wù)端下發(fā)的一串?dāng)?shù)值，作為用戶該次生命周期的會話ID。從數(shù)據(jù)流程視角看，如上圖所示，session_id的生命周期控制由端上控制，會在APK啟動后在各個業(yè)務(wù)接口的HTTP頭中帶上，準(zhǔn)備服務(wù)端的各個接口的前置攔截層會將該ID進(jìn)行收集上報，當(dāng)然如果是外喚情況，會將投放ID一起關(guān)聯(lián)上報。之后，session_id進(jìn)入服務(wù)端的承接策略層，該層承擔(dān)著外喚OLTP處理的功能，根據(jù)用戶請求的參數(shù)和運(yùn)營配置的承接策略，以內(nèi)置的外鏈干預(yù)模塊為抓手，執(zhí)行相應(yīng)的承接動作。session_id上報進(jìn)入數(shù)倉后，服務(wù)端和客戶端的ODS層用戶會話粒度的數(shù)據(jù)就緒，會持續(xù)進(jìn)行OLAP處理，在客戶端測埋點，會有BI同學(xué)進(jìn)行日常的數(shù)據(jù)挖掘工作。在服務(wù)端埋點測，我們會根據(jù)會話數(shù)據(jù)，做相應(yīng)的分析聚合固化，可將分析數(shù)據(jù)平臺化工具化；另一方面，會根據(jù)數(shù)據(jù)進(jìn)行算法處理，將用戶訪問場景還原，做對應(yīng)的BI視覺化；最后session_id隨著下游的rpc服務(wù)，進(jìn)入rpc鏈路的上報，以便根據(jù)訪問時長等信息做一些技術(shù)向優(yōu)化，不過本文主要關(guān)注用戶承接方面工作，這里并不詳細(xì)說明。
所以整個流程可以分為四個主要環(huán)節(jié)：數(shù)據(jù)產(chǎn)生、數(shù)據(jù)收集、外喚OLTP處理、OLAP處理
1.1 數(shù)據(jù)產(chǎn)生
- 每次APK冷/熱啟動時，服務(wù)端下發(fā)用戶session_id，并且將投放計劃與session_id綁定，通過下游服務(wù)端接口全鏈路埋點上報，完成接口粒度訪問數(shù)據(jù)采集
1.2 數(shù)據(jù)收集
- 服務(wù)接口攔截層將用戶session_id上報到各個ODS表中，并且客戶端會將session_id打入埋點上報播放行為數(shù)據(jù)，完成用戶播放行為串起采集
1.3 外喚OLTP處理
- 服務(wù)端承接處理層會根據(jù)YST外喚和主啟，執(zhí)行運(yùn)營、策略向的各種承接需求，會在用戶整個冷/熱生命周期中，執(zhí)行相應(yīng)的用戶承接動作
1.4 OLAP處理
- 客戶端埋點可做日常數(shù)據(jù)挖掘工作
- 對HTTP的ODS表進(jìn)行聚合處理，將用戶數(shù)據(jù)查詢和分析工具化
- 利用HTTP的ODS表中接口時序訪問數(shù)據(jù)，嘗試算法動態(tài)滑動窗口和AC機(jī)森林進(jìn)行場景還原，做BI的視覺化工作，比如完成用戶訪問的?；鶊D
2、 實現(xiàn)細(xì)節(jié)
2.1 數(shù)據(jù)產(chǎn)生
在客戶端的外喚和主啟時，會用一個ID標(biāo)識當(dāng)前整個用戶的生命周期，包括冷/熱啟動，而該ID是由服務(wù)端根據(jù)設(shè)備請求公參，生成的MD5值，作為整個云視聽小電視的會話ID，將會作為整個用戶全鏈路追蹤的唯一標(biāo)識，這里接口的調(diào)用時機(jī)完全由客戶端來控制，服務(wù)端主要負(fù)責(zé)生成和下發(fā)
圖片
投放ID主要由渠道投放平臺產(chǎn)生，包含該次投放中的所有重要信息，與會話ID關(guān)聯(lián)后可將用戶外喚與會話信息串起，本文暫不詳細(xì)展開說明
2.2 數(shù)據(jù)收集
在客戶端請求下游的業(yè)務(wù)網(wǎng)關(guān)時，會在HTTP頭中帶入會話ID，并且能夠帶入端外投放的ID，整個鏈路上，會使用BM的攔截器去收集每一次業(yè)務(wù)接口請求中的session_id，并將相關(guān)的請求私參與session_id上報，同事傳遞到下游的RPC的頭，GRPC框架的攔截器也會收集session_id并和rpc的入?yún)⒉⑸蠄蟆＿@樣每個用戶每次的業(yè)務(wù)請求都進(jìn)行服務(wù)端埋點上報。
圖片
2.3 外喚OLTP處理
在外喚用戶進(jìn)入后，客戶端接口調(diào)用鏈路中，跳轉(zhuǎn)外鏈干預(yù)會優(yōu)先調(diào)用，獲取到策略化干預(yù)之后的外鏈才執(zhí)行后續(xù)業(yè)務(wù)動作，在這里用戶承接可以實現(xiàn)在配置后臺中靈活配置，并進(jìn)行外鏈跳轉(zhuǎn)干預(yù)，對不同的用戶群體就能執(zhí)行不同的承接策略，常見的是用不同的落地頁承接用戶且展現(xiàn)細(xì)節(jié)可以有不同區(qū)分。如下圖是策略承接層的一個典型的干預(yù)模塊
圖片
2.4 OLAP處理
數(shù)據(jù)挖掘
客戶端埋點的日常數(shù)據(jù)挖掘工作本文暫不展開說明
場景還原
場景是指用戶在一個會話生命周期里，從開始到結(jié)束期間在小電視內(nèi)不同分區(qū)模塊之間進(jìn)行切換，播放等訪問場景。在數(shù)據(jù)收集到數(shù)倉后，由于是服務(wù)端收集到的接口層面的細(xì)粒度數(shù)據(jù)，新老版本多樣，客戶端很難為單獨接口打上場景標(biāo)簽的情況下，并沒有帶入用戶頁面場景跳轉(zhuǎn)信息。而運(yùn)營在直觀分析時，是以需要參考當(dāng)前用戶訪問場景的。比如用戶這次跳轉(zhuǎn)什么地方，請求了什么接口，故我們需要根據(jù)接口訪問時序，將單session的訪問場景進(jìn)行還原。這里本質(zhì)上是一個離線數(shù)據(jù)模式串匹配的算法問題，故我們將每個接口進(jìn)行序號化（比如a），幾個序號組合定義為一種模式串（比如bdc）定義清楚模式映射的場景（比如ac→詳情頁起播）。故就能通過滑動窗口+AC機(jī)森林，能識別出對應(yīng)的跳轉(zhuǎn)場景，這里我們使用Spark的批處理腳本，進(jìn)行模式識別。以上流程輸出基本的場景還原數(shù)據(jù)后，其中一部分?jǐn)?shù)據(jù)簡單聚合，結(jié)合用戶畫像的維表信息，就能為產(chǎn)運(yùn)提供有價值的用戶訪問日志信息；如下圖，是OLAP處理其中BI視覺化的前置工作，在同步到BI平臺前進(jìn)行場景還原的調(diào)度任務(wù)圖
圖片
如下圖所示，我們根據(jù)某些客戶端版本，定義接口組合到場景的映射
圖片
圖片
圖片
算法實現(xiàn)采用滑動窗口+AC機(jī)森林，解析出離線接口序列對應(yīng)的場景序列，具體過程就是用spark的腳本按每個session_id聚合出單時序數(shù)據(jù)，在單條時序數(shù)據(jù)中用滑動窗口去識別，每個滑動窗口內(nèi)用若干個場景識別的AC機(jī)去多子字符串匹配，最終輸出場景的時序
示意如下圖
圖片
BI系統(tǒng)視覺化
洗出用戶承接step中前5的數(shù)據(jù)到hive表，并同步到BI系統(tǒng)
圖片
用戶數(shù)據(jù)分析平臺化
我們將用戶按會話的粒度進(jìn)行聚合后，結(jié)合用戶畫像的數(shù)據(jù)，加入一些產(chǎn)運(yùn)常見的查詢維度，可將數(shù)據(jù)分析工具化，如下圖所示用戶路徑分析平臺（紅色部分屬于敏感信息）
圖片
同時該平臺可按會話ID下鉆數(shù)據(jù)，結(jié)合之前的場景還原數(shù)據(jù)，可按單會話場景路徑Track用戶的訪問路徑（按場景訪問時間戳正序）
圖片
3、用戶承接優(yōu)化案例
在以上的數(shù)據(jù)基建下和用戶承接層設(shè)計下，可以衍生出一系列的承接方案和執(zhí)行策略，本文挑選其中兩個作為case來簡單闡述
案例1：渠道退出挽留彈窗
產(chǎn)品根據(jù)承接流失的情況，提出的一個策略需求，具體來說，根據(jù)BI系統(tǒng)視覺化中的示例圖，發(fā)現(xiàn)在所有渠道上，外喚用戶每一步都有一定比例的流失，尤其是在step1，剛剛進(jìn)入端內(nèi)后，haixin渠道大約有1/5就退出了。故產(chǎn)品在step前置的路徑上，在用戶做出退出APP動作時，通過挽留彈窗策略來降低某些人群的流失率，給對應(yīng)的人群配置感興趣的彈窗內(nèi)容（比如用算法多卡計算出人群的喜好OGV）就能提高用戶留存。下圖是運(yùn)營配置的平臺界面，其中干預(yù)項中是包括人群在內(nèi)的細(xì)節(jié)配置。
圖片
案例2：渠道進(jìn)入承接優(yōu)化
有了session_id的基建，就能將承接細(xì)粒度到單詞用戶會話級別。基于標(biāo)識用戶生成的session_id，對運(yùn)營指定的人群的落地頁進(jìn)行承接優(yōu)化，讓用戶進(jìn)入運(yùn)營向或指標(biāo)向的落地頁，并運(yùn)營能干預(yù)一些具體的落地頁細(xì)節(jié)
圖片
三、 總結(jié)與展望
總結(jié)
- 本文闡述了云視聽小電視關(guān)于用戶承接方面存在的問題及解決方案
- 指出目前云視聽小電視客戶端埋點存在難量化、用戶行為串聯(lián)用戶承接缺乏抓手
- 提出冷/熱啟下用戶會話周期ID的數(shù)據(jù)基建+投放ID標(biāo)記端外投放的數(shù)據(jù)基建
- 提出服務(wù)端構(gòu)建的策略承接層，做可配置化的能力建設(shè)
- 本文描述了整體解決方案下session從產(chǎn)生到消費(fèi)的流程中，部分技術(shù)實現(xiàn)細(xì)節(jié)
- 文本列舉了在整體解決方案下，用戶承接實際落地場景中一些具體的Case實現(xiàn)細(xì)節(jié)
- 會話生命周期中用戶進(jìn)入時間點的用戶承接案例
- 會話生命周期中用戶退出時間點的用戶承接案例
展望
人群粒度的簡報與分析方案
使用人群包+的思路，目前視覺化的BI是全量，并沒有按人群包進(jìn)行切片，而產(chǎn)運(yùn)如果要分析人群向精細(xì)化的用戶承接，需要將現(xiàn)有數(shù)據(jù)進(jìn)行人群切片，前期可以考慮在數(shù)據(jù)分析平臺上做，后期可以考慮出一些天級的人群訪問簡報推送功能。
圖片
服務(wù)端生命周期運(yùn)營 X 運(yùn)營畫布的設(shè)想
在數(shù)據(jù)層面加策略ID，將策略ID在策略承接層干預(yù)模塊下發(fā)給客戶端，在客戶端調(diào)用業(yè)務(wù)接口時，將整個策略ID帶上，就能將一些策略在會話級別的生命周期鉤子中執(zhí)行出來。整個產(chǎn)品層面能做到真正的千人千面。而且這些策略是根據(jù)端內(nèi)的策略平臺生成的，業(yè)務(wù)接口在查詢時，會實時查詢策略平臺。
圖片
本期作者
何化鈞 嗶哩嗶哩資深開發(fā)工程師
網(wǎng)頁名稱：多屏云視聽小電視渠道用戶承接思考與實踐
分享地址：http://fisionsoft.com.cn/article/dhipdcp.html
