一、  背景概覽 1、  背景

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

 2、  目標

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

用戶訪問難量化 - 客戶端埋點并未有用戶訪問的標識，只有設備ID單天訪問頁面的時間線，難以準確量化

用戶路徑難跟蹤 - 客戶端spmid埋點體系下，設備ID粒度比較散，串聯用戶訪問頁面成本很高，需要耗費大量BI數分人力

用戶承接也缺乏分析抓手 - 用戶承接數據分析缺乏具體的有效抓手，僅限于有限場景下具體分析

這些問題會阻礙我們對用戶行為的清晰認知，也讓用戶承接只能通過一些后向統計數據進行。

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

故結合以上兩點我們目標總體來說是

• 數據精細化基建：清晰提供生命周期會話級別的用戶訪問全鏈路精細數據和用戶訪問路徑數據
• 提人效 : 運營同學用戶承接找到分析的抓手，提給給運營同學直接的分析平臺，能直觀地檢索到用戶行為數據
• 提產效 : 對外喚用戶提供常見的可配置化用戶承接策略能力，幫助策略產品和運營快速驗證和實現自己的產運策略

二、  方案設計

 1、  流程概覽

圖片

流程簡述

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

所以整個流程可以分為四個主要環節：數據產生、數據收集、外喚OLTP處理、OLAP處理

1.1 數據產生

• 每次APK冷/熱啟動時，服務端下發用戶session_id，并且將投放計劃與session_id綁定，通過下游服務端接口全鏈路埋點上報，完成接口粒度訪問數據采集

1.2 數據收集

• 服務接口攔截層將用戶session_id上報到各個ODS表中，并且客戶端會將session_id打入埋點上報播放行為數據，完成用戶播放行為串起采集

1.3 外喚OLTP處理

• 服務端承接處理層會根據YST外喚和主啟，執行運營、策略向的各種承接需求，會在用戶整個冷/熱生命周期中，執行相應的用戶承接動作

1.4 OLAP處理

• 客戶端埋點可做日常數據挖掘工作
• 對HTTP的ODS表進行聚合處理，將用戶數據查詢和分析工具化
• 利用HTTP的ODS表中接口時序訪問數據，嘗試算法動態滑動窗口和AC機森林進行場景還原，做BI的視覺化工作，比如完成用戶訪問的桑基圖

2、  實現細節

2.1 數據產生

在客戶端的外喚和主啟時，會用一個ID標識當前整個用戶的生命周期，包括冷/熱啟動，而該ID是由服務端根據設備請求公參，生成的MD5值，作為整個云視聽小電視的會話ID，將會作為整個用戶全鏈路追蹤的唯一標識，這里接口的調用時機完全由客戶端來控制，服務端主要負責生成和下發

圖片

投放ID主要由渠道投放平臺產生，包含該次投放中的所有重要信息，與會話ID關聯后可將用戶外喚與會話信息串起，本文暫不詳細展開說明

2.2 數據收集

在客戶端請求下游的業務網關時，會在HTTP頭中帶入會話ID，并且能夠帶入端外投放的ID，整個鏈路上，會使用BM的攔截器去收集每一次業務接口請求中的session_id，并將相關的請求私參與session_id上報，同事傳遞到下游的RPC的頭，GRPC框架的攔截器也會收集session_id并和rpc的入參并上報。這樣每個用戶每次的業務請求都進行服務端埋點上報。

圖片

2.3 外喚OLTP處理

在外喚用戶進入后，客戶端接口調用鏈路中，跳轉外鏈干預會優先調用，獲取到策略化干預之后的外鏈才執行后續業務動作，在這里用戶承接可以實現在配置后臺中靈活配置，并進行外鏈跳轉干預，對不同的用戶群體就能執行不同的承接策略，常見的是用不同的落地頁承接用戶且展現細節可以有不同區分。如下圖是策略承接層的一個典型的干預模塊

圖片

2.4 OLAP處理

數據挖掘

客戶端埋點的日常數據挖掘工作本文暫不展開說明

場景還原

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

圖片

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

圖片

圖片

圖片

算法實現采用滑動窗口+AC機森林，解析出離線接口序列對應的場景序列，具體過程就是用spark的腳本按每個session_id聚合出單時序數據，在單條時序數據中用滑動窗口去識別，每個滑動窗口內用若干個場景識別的AC機去多子字符串匹配，最終輸出場景的時序

示意如下圖

圖片

BI系統視覺化

洗出用戶承接step中前5的數據到hive表，并同步到BI系統

圖片

用戶數據分析平臺化

我們將用戶按會話的粒度進行聚合后，結合用戶畫像的數據，加入一些產運常見的查詢維度，可將數據分析工具化，如下圖所示用戶路徑分析平臺（紅色部分屬于敏感信息）

圖片

同時該平臺可按會話ID下鉆數據，結合之前的場景還原數據，可按單會話場景路徑Track用戶的訪問路徑（按場景訪問時間戳正序）

圖片

3、用戶承接優化案例

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

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

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

圖片

案例2：渠道進入承接優化

有了session_id的基建，就能將承接細粒度到單詞用戶會話級別。基于標識用戶生成的session_id，對運營指定的人群的落地頁進行承接優化，讓用戶進入運營向或指標向的落地頁，并運營能干預一些具體的落地頁細節

圖片

三、  總結與展望

 總結

• 本文闡述了云視聽小電視關于用戶承接方面存在的問題及解決方案
• 指出目前云視聽小電視客戶端埋點存在難量化、用戶行為串聯用戶承接缺乏抓手
• 提出冷/熱啟下用戶會話周期ID的數據基建+投放ID標記端外投放的數據基建
• 提出服務端構建的策略承接層，做可配置化的能力建設
• 本文描述了整體解決方案下session從產生到消費的流程中，部分技術實現細節
• 文本列舉了在整體解決方案下，用戶承接實際落地場景中一些具體的Case實現細節
• 會話生命周期中用戶進入時間點的用戶承接案例
• 會話生命周期中用戶退出時間點的用戶承接案例

展望

人群粒度的簡報與分析方案

使用人群包+的思路，目前視覺化的BI是全量，并沒有按人群包進行切片，而產運如果要分析人群向精細化的用戶承接，需要將現有數據進行人群切片，前期可以考慮在數據分析平臺上做，后期可以考慮出一些天級的人群訪問簡報推送功能。

圖片

服務端生命周期運營 X 運營畫布的設想

在數據層面加策略ID，將策略ID在策略承接層干預模塊下發給客戶端，在客戶端調用業務接口時，將整個策略ID帶上，就能將一些策略在會話級別的生命周期鉤子中執行出來。整個產品層面能做到真正的千人千面。而且這些策略是根據端內的策略平臺生成的，業務接口在查詢時，會實時查詢策略平臺。

圖片

本期作者

何化鈞 嗶哩嗶哩資深開發工程師