背景#
組內負責的產品頁面主要的流量途徑來自集團各 App 端內，其中業務重點關注的一個指標是到達率
到達率計算：資源位點擊到頁面展現 / 資源位點擊
- 資源位點擊為 Native 側埋點，BI 會根據物料名稱判斷對應業務
- 頁面展現為 Web H5 側埋點，一般設置在
mounted声明周期内
最近一直收到到達率降低的問題反饋，在投入不少人力成本進行一些 case 分析後發現原因主要在以下幾個方面：
- 人群意向 / 疲勞度問題
- BI 統計問題，分子 / 分母計算有誤
- 頁面訪問慢
為了後續遇到類似問題時能有現成的統計數據直觀地查看用戶折損點，更有效地進行問題分析與定位，需要對現有用戶鏈路做分析，進行了一番調研，特此記錄一下。
調研#
現有用戶鏈路的查看途徑是在內部監控統計平台的個人診斷鏈路上：
- 首先選擇不同的端，對應會去查不同的埋點上報數據表（Native 和 H5 區分）
- 其次輸入用戶 ID + 時間，可以選擇對應的頁面以及過濾事件精簡查詢結果
- 最終依據上報時間把該用戶對應時間內所有相關的操作埋點直接展示出來
可以看到個人診斷鏈路的核心邏輯是 基於單個用戶標識去檢索以時間為序的全量操作埋點
而行為路徑的統計展示需要 基於固定的操作埋點去計算以邏輯約定為序的階段漏斗數據，即需要有 存在明確順序 並且 具有合理統計維度 的關鍵埋點，因此個人診斷鏈路工具不能滿足統計的需要。
從 用戶點擊資源位 到 頁面展現 結束，對應的技術行為路徑為：端內打開 webview 加載 H5 至展現。
基於這個行為路徑諮詢對應埋點 SDK 同學後有以下結論：
- Native SDK 與 H5 SDK 鏈路 加載無明確順序（類比組件生命周期與頁面生命周期），只能基於一端數據進行監測
- Native SDK
- 標準埋點有 打開 H5 頁面 - 開始加載 H5 頁面 - H5 頁面加載完成，但目前暫不支持（依賴後續發版）
- 已有埋點有 進入某頁面 - 某頁面退出，觸發時機較寬泛（包含 打開 / 關閉 App、App 內切換頁面、前後台切換等），無合理的統計維度
- 關鍵埋點如 左上角點擊返回：端上無直接埋點；SDK 的自動採集上報統一埋點：需要以 控件類型名稱 + 控制器名稱 + 觸發方法名 作為條件篩選，查詢成本偏高且不穩定，並且也無合理的統計維度
- 總結：Native 現有鏈路無可行監測點
- H5 SDK
- 標準埋點有 H5 頁面初始化 - H5 頁面曝光（onLoad 後），具體業務相關信息有 訪問頁面完整鏈接 和 頁面路由，可以依據 inrouter 和渠道號等信息進行模糊匹配
- 借助現有漏斗分析功能可以簡單計算到達率
- 總結：H5 現有鏈路存在監測點，但效果有限
結論#
短期方案：H5 初始化 - 曝光 漏斗轉化率技術側可監測，做輔助觀察
長期方案：Native 發版後進行 Native 側鏈路監測，同時推動端加上點擊返回埋點監測跳失率等更具業務意義的指標