用戶行為分析模型實踐（三）——H5通用分析模型
一、背景
針對用戶行為數據進行采集有個專業術語叫埋點，在h5頁面上做的埋點統稱為H5埋點。H5頁面因其靈活性，便捷的交互和豐富的功能，以及在移動設備上支持多媒體等特點目前被廣泛應用于網頁app開發。
現階段H5埋點的自由度較高，行業數據產品在同類高頻的業務場景上設計的時間花費較多，埋點開發、埋點測試等事項耗時，且需重復勞動；同樣的埋點數據分析層面-基礎分析指標，留存指標，頁面分析等需求需多次開發模型，浪費寶貴的人力資源。
H5通用分析模型旨在通過規范化埋點設計方案，開發設計一套通用度高，擴展方便，需求響應迅速的模型，減少行業數據產品和開發在類似需求上的人力投入，提升數據分析效率。
二、分析模型概述
2.1 術語解釋
2.2 模型概述
針對業務發展的不同階段，會有相應的數據分析需求。如圖（1），在業務初期，用戶的訪問，留存情況等是階段性分析重點，業務產品運營可以根據分析數據適時的調整頁面布局，運營策略等；應用發展中后期可能會更多的關注訂單、轉化、路徑等相關分析指標。如果能在應用上線之初，快速的拿到核心分析指標數據，對產品的推廣，迭代無疑是收益良多。所以，本次模型構建從應用初期分析最廣泛的核心指標出發，落地應用概況、頁面訪問、用戶留存等維度全方位核心分析指標體系。
圖（1）應用生命周期內指標分析情況
2.2.1 分析模型主題
本次通用分析模型圍繞以下分析主題構建。
- 【基礎分析】：從用戶瀏覽次數，人均訪問頁面數，人均使用時長，新老用戶等基礎指標展示用戶訪問大盤數據。
- 【頁面分析】：面向具體頁面，分析用戶訪問pv,uv,訪問時長等核心指標，有針對性的發現頁面訪量薄弱環節，為合理化頁面管理提供數據支撐，協助產品經理通過信息重組，提升頁面訪問量。
- 【留存分析】：通過用戶的留存，了解目前的產品現狀（用戶的哪些行為導致留存率的不同）; 判斷產品的改進有無效果（用戶行為是否發生了改變導致留存率的提升）；留存分析反映了用戶由初期的不穩定用戶轉化為活躍用戶，穩定用戶，忠誠用戶的過程。
2.2.2 分析指標定義
（以下示例中數據均為參考數據，非真實數據）
1、基礎分析：訪問pv，uv等指標（全維度）
2、頁面分析：頁面訪問相關pv，uv，時長等指標
注：用戶對訪問頁面進行命名，分析平臺提供配置入口，方便用戶對頁面進行命名。
3、留存分析：新用戶留存，活躍用戶留存 包括：N日內留存 和 第N日留存。
通常意義上的留存分析指的是：用戶在APP產生行為后，在固定的第N日繼續訪問或使用APP的用戶；包括活躍用戶留存和新用戶留存
為滿足不同業務的分析需求。此次留存模型包含 n日內留存分析，即用戶在APP產生行為后，在固定的第N日內繼續訪問或使用APP的用戶（日期范圍留存）。
三、埋點方案
3.1 業務目標
- 采集用戶的pv，uv數據，幫助產品同學了解目前的產品現狀，并不斷改進產品；
- 自動采集，對pv，uv等這類埋點，業務無需再開發，打開開關即可采集這類數據。
3.2 自動采集
3.2.1 什么是自動采集
自動采集是相對于前端開發者而言，目的是為了幫助前端開發者提升數據采集效率。通過自動采集開關配置，無需在手動實現上報邏輯。使用時前端開發者通過引入h5sdk.js(也稱jssdk.js)，打開自動采集開關，我們就會在適當的時機，以適當的規則采集數據，并進行上報。開發者無需在關注采集代碼內部邏輯，以此來減輕同類數據采集的開發工作量。
3.2.2 如何自動采集
按照給定的規則進行頁面事件EventListener，當用戶活動觸發對應的事件時，我們會組裝好數據，然后將組裝好的數據通過https傳入到后臺。
3.2.3 自動采集的三大規則場景
我們的網站是一個SPA應用。SPA應用通過改變前端路由的變化，實現頁面內組件的切換。組件的切換，對于一個非前端開發者來說，可以泛指頁面的切換。所以我們第一場景是要覆蓋url變化的這類事件。在實踐中，我們發現，當我們需要采集頁面的用戶停留時長時，往往會不準確。為什么不準確？用戶可以縮小化瀏覽器，也可以切換tab到其他網站，這個時候計算的用戶時長是不準確的。因為用戶雖然打開了我們網頁，但是并沒有聚焦到我們的網頁。這種不應該算作用戶停留時長，因此對于這些行為，我們又加上了失去焦點，得到焦點，以及切換瀏覽器tab事件的EventListener，這兩種場景。
綜上三大場景總結如下：
- 頁面切換時，進行采集，即url變化時觸發的事件；
- 頁面失去焦點，得到焦點時，進行采集。即focus，blur事件；
- 頁面通過瀏覽器tab切換離開，切換回來時，進行采集，即visibilitychange事件；
3.2.3.1 三大規則場景的界定
上文我們已經在實踐中總結出了自動采集的三大場景，在實際應用針對三大場景的使用我們也總結出了一套界定方案。
（1）規則一界定——怎么判斷頁面切換？
a、現在的網站要么是MPA，要么是SPA模式，或者兩種模式混合，MPA主要是后臺路由，SPA主要是前端路由（hash模式和history模式）。但無論是SPA還是MPA，當頁面需要切換時，url一定會變化，基于此點，我們判斷當url變化時，用戶一定切換了頁面。此時觸發規則一的事件，產生數據上報。
這里需要注意2個問題：
- 第1個問題：url變化 = window.location.origin + window.location.pathname + window.location.hash 這三部分的任一部分變化，即為url變化，并不包括window.location.search這部分的變化；
- 第2個問題：在SPA中，如果一個頁面內有多個tab，當切換tab時，開發者也改變他的url的window.location.pathname，此時也會認為是頁面切換，也會產生上報數據，如下這種情況。
圖（2）
b、完整頁面切換上報流程，由頁面A切換到頁面B時，一共上報4個埋點；
圖（3）
c、關于路由的EventListener
現在的大多網站，大多是SPA應用，SPA的前端路由有hash模式和history模式這兩種模式，當通過前端路由來頁面切換時，肯定會觸發hash模式或history相關的api。
因此，我們只需要把所有觸發事件的場景給全部進行EventListener即可。有如下2種路由的EventListener：window.hashchange事件——觸發hash模式時、window.popstate事件、pushstate,replacestate自定義事件——觸發history模式時。
這里有2個問題需要關注：一是當某個SPA應用的路由事件，觸發了history模式時，我們應該移除hash模式的EventListener。二是pushstate,replacestate自定義事件，因為BOM并沒有提供相關的api支持EventListener，需要自行封裝使用，如下code。
引入JSSDK
（2）規則二界定——怎么判斷頁面失去焦點，得到焦點？
失去焦點，得到焦點。我們主要進行如下這兩個事件的EventListener：
引入JSSDK
（3）規則三界定——怎么判斷瀏覽器tab切換離開，切換回來？
tab切換離開，切換回來。我們主要進行如下這一個事件的EventListener：
引入JSSDK
注意：如果一個行為同時滿足2個及2個以上的規則時，只會取一個規則上報數據。避免不重復上報數據。
3.3 埋點設計
3.3.1 埋點個數
為了得到pv和uv的相關數據，我們設計了2個埋點，1個為頁面進入時上報的埋點，另外1個為頁面離開時的埋點，上報的數據都是一對的，離開-進入頁面為一對，失去焦點-得到焦點為一對，切換tab離開當前頁面-返回當前頁面也為一對；
為什么要設計2個埋點？設計2個埋點，能覆蓋全面上述我們所說的3種規則場景；其次，方面計算頁面停留時長；最后就是方便邏輯判斷，避免重復上報；
3.3.2 參數的設計
按照不同的需求，參數的設計分為如下4類：
- pv，uv需要參數，開發者傳入參數：unique_id——標識用戶唯一標識、topic_id——當前網站唯一標識、current_env——當前網站環境，默認為prod，可用戶傳入；
- pv，uv需要參數，sdk內部獲取參數：duration——頁面停留時長、last_page_url——上個頁面url、page_url——當前頁面url；
- SDK需要的參數，幫助判斷事件觸發類型，SDK內部獲取參數：eventType
- 用戶其他需要補充的參數：自定義參數
3.4 數據上報
數據上報方式是XMLHttpRequest、window.navigator.sendBeacon，基于h5sdk上報邏輯架構。
圖（4）
3.5 兼容性和容錯性
關于兼容性，依賴于window對象、不兼容IE6、IE7，IE8;
關于容錯性，對通用化內部邏輯做了try catch的容錯兼容，保證出錯時不影響業務主邏輯運行，同時上報一個出錯的事件類型，知道出錯的原因，以便提前做好對應的優化方案。
3.6 個人數據保護合規
為了保護好用戶的個人數據及其隱私并滿足法律法規要求，在埋點的設計、采集、使用等環節需要進行充分的隱私保護設計。例如，在埋點設計階段，需要確定標識符的選擇、埋點參數的最小必要、采集頻率的最小必要等；在埋點的采集、使用階段，需要確保相關處理行為的透明、可控，包括對用戶進行告知，獲取用戶的有效同意，提供撤回同意的渠道等等。
四、數倉方案
埋點方案已經具備，接下來的工作就是設計一套接入高效，拓展便捷的數倉分析模型；為實現以上既定的分析目標，模型設計過程中需要解決以下核心問題。
4.1 核心問題列表
4.2 模型分層標準
介紹模型設計前，先說下vivo 數倉模型分層基本原則，及本次模型分層思路，各層模型設計原則參照《vivo中臺數倉建設方法論》，層級設計摘要如下：
4.3 模型層級架構
通過核心問題拆解發現，為實現通用分析模型方案，需要從數據接入層收口，在數據接入時統一參數解析，統一字段命名，并設置相應的應用id字段，區分各個業務數據源；接著需要生成活躍數據明細表，可統計相應的基礎分析，頁面分析指標；同時為滿足留存分析的需要，我們需要構建相應的活躍全量表，留存分析主題表基于活躍增量表和活躍全量表生成，用戶活躍信息通過打標簽的方式標記。至此涉及三個主題分析的模型規劃完畢。層級劃分原則及規劃邏輯模型明細，如：圖（5）
圖（5）
從分層架構圖可看出H5通用分析模型分為明細層(dw)、輕度匯總層(dma)、分析主題表 (dmt) 和指標層(da); 其中輕度匯總層可作為中間數據提供行業分析師及數據開發、業務產品等查詢分析使用；匯總層作為分析平臺通用分析模型報表數據源，導入mysql存儲，前端基于mysql表實現數據展示,各個模型設計細則如下：
數據模型規劃及設計的核心在于三點：確定appid和用戶id映射關系，留存方案實現及留存記錄入庫bitmap方式讀寫。
1、確定appid和用戶id映射關系-unique_id 關聯設計
多業務id統一
2、留存方案實現及留存記錄入庫bitmap方式讀寫
留存方案
4.4 模型數據流圖
至此，模型的設計落地全部完成，模型包含埋點數據表2張，dw明細層模型1張，維表1張，dma輕度匯總主題層2張，dmt主題表2張，任務層深4層，模型層2層，模型數據接入0.5人日可完成。
數據流圖如下：
圖（6）
五、數據展示
模型數據展示可基于用戶行為分析平臺，數據指標存儲使用 MySQL 數據庫，數據展示邏輯實現如下：
圖（7）
5.1 報表展示
報表配置完成后，各個分析模塊的前臺展示示例如下：
圖（8）應用概況報表
圖（9）用戶留存報表
圖（10）頁面分析報表
六、未來展望
至此，H5通用分模型落地流程已介紹完畢。本文主要是基于業務初期訴求，快速落地通用的、統一的數據解決方案，滿足業務分析人員在產品初期最迫切的分析需求。隨著業務的不斷發展迭代，運營產品的分析方向也會不斷的擴展和深入，同時不同的業務關注點不同，針對分析模型的訴求也不盡相同。例如在業務中后期，簡單的訪問留存分析已經支撐不了更進一步的決策制定，此時針對頁面訪問的路徑分析模型；針對營銷分析的訂單轉化模型、歸因分析模型；針對頁面跳轉分析的用戶漏斗模型等需求會相應變多。
所以，為更好的支撐業務目標達成，H5通用分析模型系列在后期會根據業務訴求落地相應的分析模型，持續為產品運營提供高效穩定的數據解決方案。
