云視聽小電視作為一個(gè)發(fā)展迅猛的APP，是多屏部門主要產(chǎn)品線，會(huì)安裝于各電視廠商的智能系統(tǒng)上。用戶通過點(diǎn)擊端外的資源位進(jìn)入小電視APK（外喚）或者直接打開小電視APK（主啟），這兩種方式進(jìn)入端內(nèi)，來消費(fèi)各種視頻資源和信息。在此商業(yè)邏輯鏈條中，涉及端外投放拉新拉活獲客，進(jìn)入APK后端內(nèi)承接，瀏覽消息過程中用戶體驗(yàn)，以及退出時(shí)用戶的整體觀感，對(duì)活躍過的用戶預(yù)期召回等很多要做的事情。本文中我們主要關(guān)注渠道用戶通過外喚或主啟的方式進(jìn)入小電視后，在用戶全鏈路的生命周期過程中，在各個(gè)節(jié)點(diǎn)上，對(duì)用戶進(jìn)行更好的承接，讓廣大用戶更加喜歡我們的產(chǎn)品。

云視聽小電視歷經(jīng)多個(gè)產(chǎn)研走轉(zhuǎn)，本身就存在歷史技術(shù)債較重，數(shù)據(jù)埋點(diǎn)缺失較為完整工業(yè)化體系的問題，而做好渠道用戶承接首先就需要做好用戶數(shù)據(jù)的全鏈路跟蹤，看清用戶的行為。之前的客戶端埋點(diǎn)數(shù)據(jù)存在以下問題：

用戶訪問難量化 - 客戶端埋點(diǎn)并未有用戶訪問的標(biāo)識(shí)，只有設(shè)備ID單天訪問頁面的時(shí)間線，難以準(zhǔn)確量化

用戶路徑難跟蹤 - 客戶端spmid埋點(diǎn)體系下，設(shè)備ID粒度比較散，串聯(lián)用戶訪問頁面成本很高，需要耗費(fèi)大量BI數(shù)分人力

用戶承接也缺乏分析抓手 - 用戶承接數(shù)據(jù)分析缺乏具體的有效抓手，僅限于有限場(chǎng)景下具體分析

這些問題會(huì)阻礙我們對(duì)用戶行為的清晰認(rèn)知，也讓用戶承接只能通過一些后向統(tǒng)計(jì)數(shù)據(jù)進(jìn)行。

另外一個(gè)問題是之前外喚用戶缺乏靈活的承接策略執(zhí)行，每次執(zhí)行用戶的外喚承接策略都需要走跟版發(fā)布

故結(jié)合以上兩點(diǎn)我們目標(biāo)總體來說是

• 數(shù)據(jù)精細(xì)化基建：清晰提供生命周期會(huì)話級(jí)別的用戶訪問全鏈路精細(xì)數(shù)據(jù)和用戶訪問路徑數(shù)據(jù)
• 提人效 : 運(yùn)營同學(xué)用戶承接找到分析的抓手，提給給運(yùn)營同學(xué)直接的分析平臺(tái)，能直觀地檢索到用戶行為數(shù)據(jù)
• 提產(chǎn)效 : 對(duì)外喚用戶提供常見的可配置化用戶承接策略能力，幫助策略產(chǎn)品和運(yùn)營快速驗(yàn)證和實(shí)現(xiàn)自己的產(chǎn)運(yùn)策略

二、  方案設(shè)計(jì)

 1、  流程概覽

圖片

流程簡述

為實(shí)現(xiàn)以上的目標(biāo)，我們參考業(yè)界常見埋點(diǎn)實(shí)踐方案，設(shè)計(jì)一套以session_id和投放ID為核心串通數(shù)據(jù)的埋點(diǎn)與分析處理流程。其中投放ID是由我們內(nèi)部渠道投放平臺(tái)生成的某一次端外投放ID，作為產(chǎn)運(yùn)回收投放效果標(biāo)識(shí)的唯一ID，在本文中暫不詳細(xì)展開說明；而本文主要關(guān)注的session_id來自于每次APK冷/熱啟動(dòng)時(shí)，服務(wù)端下發(fā)的一串?dāng)?shù)值，作為用戶該次生命周期的會(huì)話ID。從數(shù)據(jù)流程視角看，如上圖所示，session_id的生命周期控制由端上控制，會(huì)在APK啟動(dòng)后在各個(gè)業(yè)務(wù)接口的HTTP頭中帶上，準(zhǔn)備服務(wù)端的各個(gè)接口的前置攔截層會(huì)將該ID進(jìn)行收集上報(bào)，當(dāng)然如果是外喚情況，會(huì)將投放ID一起關(guān)聯(lián)上報(bào)。之后，session_id進(jìn)入服務(wù)端的承接策略層，該層承擔(dān)著外喚OLTP處理的功能，根據(jù)用戶請(qǐng)求的參數(shù)和運(yùn)營配置的承接策略，以內(nèi)置的外鏈干預(yù)模塊為抓手，執(zhí)行相應(yīng)的承接動(dòng)作。session_id上報(bào)進(jìn)入數(shù)倉后，服務(wù)端和客戶端的ODS層用戶會(huì)話粒度的數(shù)據(jù)就緒，會(huì)持續(xù)進(jìn)行OLAP處理，在客戶端測(cè)埋點(diǎn)，會(huì)有BI同學(xué)進(jìn)行日常的數(shù)據(jù)挖掘工作。在服務(wù)端埋點(diǎn)測(cè)，我們會(huì)根據(jù)會(huì)話數(shù)據(jù)，做相應(yīng)的分析聚合固化，可將分析數(shù)據(jù)平臺(tái)化工具化；另一方面，會(huì)根據(jù)數(shù)據(jù)進(jìn)行算法處理，將用戶訪問場(chǎng)景還原，做對(duì)應(yīng)的BI視覺化；最后session_id隨著下游的rpc服務(wù)，進(jìn)入rpc鏈路的上報(bào)，以便根據(jù)訪問時(shí)長等信息做一些技術(shù)向優(yōu)化，不過本文主要關(guān)注用戶承接方面工作，這里并不詳細(xì)說明。

所以整個(gè)流程可以分為四個(gè)主要環(huán)節(jié)：數(shù)據(jù)產(chǎn)生、數(shù)據(jù)收集、外喚OLTP處理、OLAP處理

1.1 數(shù)據(jù)產(chǎn)生

• 每次APK冷/熱啟動(dòng)時(shí)，服務(wù)端下發(fā)用戶session_id，并且將投放計(jì)劃與session_id綁定，通過下游服務(wù)端接口全鏈路埋點(diǎn)上報(bào)，完成接口粒度訪問數(shù)據(jù)采集

1.2 數(shù)據(jù)收集

• 服務(wù)接口攔截層將用戶session_id上報(bào)到各個(gè)ODS表中，并且客戶端會(huì)將session_id打入埋點(diǎn)上報(bào)播放行為數(shù)據(jù)，完成用戶播放行為串起采集

1.3 外喚OLTP處理

• 服務(wù)端承接處理層會(huì)根據(jù)YST外喚和主啟，執(zhí)行運(yùn)營、策略向的各種承接需求，會(huì)在用戶整個(gè)冷/熱生命周期中，執(zhí)行相應(yīng)的用戶承接動(dòng)作

1.4 OLAP處理

• 客戶端埋點(diǎn)可做日常數(shù)據(jù)挖掘工作
• 對(duì)HTTP的ODS表進(jìn)行聚合處理，將用戶數(shù)據(jù)查詢和分析工具化
• 利用HTTP的ODS表中接口時(shí)序訪問數(shù)據(jù)，嘗試算法動(dòng)態(tài)滑動(dòng)窗口和AC機(jī)森林進(jìn)行場(chǎng)景還原，做BI的視覺化工作，比如完成用戶訪問的?；鶊D

2、  實(shí)現(xiàn)細(xì)節(jié)

2.1 數(shù)據(jù)產(chǎn)生

在客戶端的外喚和主啟時(shí)，會(huì)用一個(gè)ID標(biāo)識(shí)當(dāng)前整個(gè)用戶的生命周期，包括冷/熱啟動(dòng)，而該ID是由服務(wù)端根據(jù)設(shè)備請(qǐng)求公參，生成的MD5值，作為整個(gè)云視聽小電視的會(huì)話ID，將會(huì)作為整個(gè)用戶全鏈路追蹤的唯一標(biāo)識(shí)，這里接口的調(diào)用時(shí)機(jī)完全由客戶端來控制，服務(wù)端主要負(fù)責(zé)生成和下發(fā)

圖片

投放ID主要由渠道投放平臺(tái)產(chǎn)生，包含該次投放中的所有重要信息，與會(huì)話ID關(guān)聯(lián)后可將用戶外喚與會(huì)話信息串起，本文暫不詳細(xì)展開說明

2.2 數(shù)據(jù)收集

在客戶端請(qǐng)求下游的業(yè)務(wù)網(wǎng)關(guān)時(shí)，會(huì)在HTTP頭中帶入會(huì)話ID，并且能夠帶入端外投放的ID，整個(gè)鏈路上，會(huì)使用BM的攔截器去收集每一次業(yè)務(wù)接口請(qǐng)求中的session_id，并將相關(guān)的請(qǐng)求私參與session_id上報(bào)，同事傳遞到下游的RPC的頭，GRPC框架的攔截器也會(huì)收集session_id并和rpc的入?yún)⒉⑸蠄?bào)。這樣每個(gè)用戶每次的業(yè)務(wù)請(qǐng)求都進(jìn)行服務(wù)端埋點(diǎn)上報(bào)。

圖片

2.3 外喚OLTP處理

在外喚用戶進(jìn)入后，客戶端接口調(diào)用鏈路中，跳轉(zhuǎn)外鏈干預(yù)會(huì)優(yōu)先調(diào)用，獲取到策略化干預(yù)之后的外鏈才執(zhí)行后續(xù)業(yè)務(wù)動(dòng)作，在這里用戶承接可以實(shí)現(xiàn)在配置后臺(tái)中靈活配置，并進(jìn)行外鏈跳轉(zhuǎn)干預(yù)，對(duì)不同的用戶群體就能執(zhí)行不同的承接策略，常見的是用不同的落地頁承接用戶且展現(xiàn)細(xì)節(jié)可以有不同區(qū)分。如下圖是策略承接層的一個(gè)典型的干預(yù)模塊

圖片

2.4 OLAP處理

數(shù)據(jù)挖掘

客戶端埋點(diǎn)的日常數(shù)據(jù)挖掘工作本文暫不展開說明

場(chǎng)景還原

場(chǎng)景是指用戶在一個(gè)會(huì)話生命周期里，從開始到結(jié)束期間在小電視內(nèi)不同分區(qū)模塊之間進(jìn)行切換，播放等訪問場(chǎng)景。在數(shù)據(jù)收集到數(shù)倉后，由于是服務(wù)端收集到的接口層面的細(xì)粒度數(shù)據(jù)，新老版本多樣，客戶端很難為單獨(dú)接口打上場(chǎng)景標(biāo)簽的情況下，并沒有帶入用戶頁面場(chǎng)景跳轉(zhuǎn)信息。而運(yùn)營在直觀分析時(shí)，是以需要參考當(dāng)前用戶訪問場(chǎng)景的。比如用戶這次跳轉(zhuǎn)什么地方，請(qǐng)求了什么接口，故我們需要根據(jù)接口訪問時(shí)序，將單session的訪問場(chǎng)景進(jìn)行還原。這里本質(zhì)上是一個(gè)離線數(shù)據(jù)模式串匹配的算法問題，故我們將每個(gè)接口進(jìn)行序號(hào)化（比如a），幾個(gè)序號(hào)組合定義為一種模式串（比如bdc）定義清楚模式映射的場(chǎng)景（比如ac→詳情頁起播）。故就能通過滑動(dòng)窗口+AC機(jī)森林，能識(shí)別出對(duì)應(yīng)的跳轉(zhuǎn)場(chǎng)景，這里我們使用Spark的批處理腳本，進(jìn)行模式識(shí)別。以上流程輸出基本的場(chǎng)景還原數(shù)據(jù)后，其中一部分?jǐn)?shù)據(jù)簡單聚合，結(jié)合用戶畫像的維表信息，就能為產(chǎn)運(yùn)提供有價(jià)值的用戶訪問日志信息；如下圖，是OLAP處理其中BI視覺化的前置工作，在同步到BI平臺(tái)前進(jìn)行場(chǎng)景還原的調(diào)度任務(wù)圖

圖片

如下圖所示，我們根據(jù)某些客戶端版本，定義接口組合到場(chǎng)景的映射

圖片

圖片

圖片

算法實(shí)現(xiàn)采用滑動(dòng)窗口+AC機(jī)森林，解析出離線接口序列對(duì)應(yīng)的場(chǎng)景序列，具體過程就是用spark的腳本按每個(gè)session_id聚合出單時(shí)序數(shù)據(jù)，在單條時(shí)序數(shù)據(jù)中用滑動(dòng)窗口去識(shí)別，每個(gè)滑動(dòng)窗口內(nèi)用若干個(gè)場(chǎng)景識(shí)別的AC機(jī)去多子字符串匹配，最終輸出場(chǎng)景的時(shí)序

示意如下圖

圖片

BI系統(tǒng)視覺化

洗出用戶承接step中前5的數(shù)據(jù)到hive表，并同步到BI系統(tǒng)

圖片

用戶數(shù)據(jù)分析平臺(tái)化

我們將用戶按會(huì)話的粒度進(jìn)行聚合后，結(jié)合用戶畫像的數(shù)據(jù)，加入一些產(chǎn)運(yùn)常見的查詢維度，可將數(shù)據(jù)分析工具化，如下圖所示用戶路徑分析平臺(tái)（紅色部分屬于敏感信息）

圖片

同時(shí)該平臺(tái)可按會(huì)話ID下鉆數(shù)據(jù)，結(jié)合之前的場(chǎng)景還原數(shù)據(jù)，可按單會(huì)話場(chǎng)景路徑Track用戶的訪問路徑（按場(chǎng)景訪問時(shí)間戳正序）

圖片

3、用戶承接優(yōu)化案例

在以上的數(shù)據(jù)基建下和用戶承接層設(shè)計(jì)下，可以衍生出一系列的承接方案和執(zhí)行策略，本文挑選其中兩個(gè)作為case來簡單闡述

案例1：渠道退出挽留彈窗

產(chǎn)品根據(jù)承接流失的情況，提出的一個(gè)策略需求，具體來說，根據(jù)BI系統(tǒng)視覺化中的示例圖，發(fā)現(xiàn)在所有渠道上，外喚用戶每一步都有一定比例的流失，尤其是在step1，剛剛進(jìn)入端內(nèi)后，haixin渠道大約有1/5就退出了。故產(chǎn)品在step前置的路徑上，在用戶做出退出APP動(dòng)作時(shí)，通過挽留彈窗策略來降低某些人群的流失率，給對(duì)應(yīng)的人群配置感興趣的彈窗內(nèi)容（比如用算法多卡計(jì)算出人群的喜好OGV）就能提高用戶留存。下圖是運(yùn)營配置的平臺(tái)界面，其中干預(yù)項(xiàng)中是包括人群在內(nèi)的細(xì)節(jié)配置。

圖片

案例2：渠道進(jìn)入承接優(yōu)化

有了session_id的基建，就能將承接細(xì)粒度到單詞用戶會(huì)話級(jí)別。基于標(biāo)識(shí)用戶生成的session_id，對(duì)運(yùn)營指定的人群的落地頁進(jìn)行承接優(yōu)化，讓用戶進(jìn)入運(yùn)營向或指標(biāo)向的落地頁，并運(yùn)營能干預(yù)一些具體的落地頁細(xì)節(jié)

圖片

三、  總結(jié)與展望

 總結(jié)

• 本文闡述了云視聽小電視關(guān)于用戶承接方面存在的問題及解決方案
• 指出目前云視聽小電視客戶端埋點(diǎn)存在難量化、用戶行為串聯(lián)用戶承接缺乏抓手
• 提出冷/熱啟下用戶會(huì)話周期ID的數(shù)據(jù)基建+投放ID標(biāo)記端外投放的數(shù)據(jù)基建
• 提出服務(wù)端構(gòu)建的策略承接層，做可配置化的能力建設(shè)
• 本文描述了整體解決方案下session從產(chǎn)生到消費(fèi)的流程中，部分技術(shù)實(shí)現(xiàn)細(xì)節(jié)
• 文本列舉了在整體解決方案下，用戶承接實(shí)際落地場(chǎng)景中一些具體的Case實(shí)現(xiàn)細(xì)節(jié)
• 會(huì)話生命周期中用戶進(jìn)入時(shí)間點(diǎn)的用戶承接案例
• 會(huì)話生命周期中用戶退出時(shí)間點(diǎn)的用戶承接案例

展望

人群粒度的簡報(bào)與分析方案

使用人群包+的思路，目前視覺化的BI是全量，并沒有按人群包進(jìn)行切片，而產(chǎn)運(yùn)如果要分析人群向精細(xì)化的用戶承接，需要將現(xiàn)有數(shù)據(jù)進(jìn)行人群切片，前期可以考慮在數(shù)據(jù)分析平臺(tái)上做，后期可以考慮出一些天級(jí)的人群訪問簡報(bào)推送功能。

圖片

服務(wù)端生命周期運(yùn)營 X 運(yùn)營畫布的設(shè)想

在數(shù)據(jù)層面加策略ID，將策略ID在策略承接層干預(yù)模塊下發(fā)給客戶端，在客戶端調(diào)用業(yè)務(wù)接口時(shí)，將整個(gè)策略ID帶上，就能將一些策略在會(huì)話級(jí)別的生命周期鉤子中執(zhí)行出來。整個(gè)產(chǎn)品層面能做到真正的千人千面。而且這些策略是根據(jù)端內(nèi)的策略平臺(tái)生成的，業(yè)務(wù)接口在查詢時(shí)，會(huì)實(shí)時(shí)查詢策略平臺(tái)。

圖片

何化鈞 嗶哩嗶哩資深開發(fā)工程師