作者：vivo 互聯(lián)網(wǎng)大數(shù)據(jù)團隊- Zhao Wei、Tian Fengbiao、Li Xiong

本文從提升用戶行為分析效率角度出發(fā)，詳細介紹了H5埋點方案規(guī)劃，埋點數(shù)據(jù)采集流程，提供可借鑒的用戶行為數(shù)據(jù)采集方案；且完整呈現(xiàn)了針對頁面分析，留存分析的數(shù)倉模型規(guī)劃方案，在數(shù)倉模型設計過程中遇見的痛點難點問題也相應的給出了解決思路及案例代碼；在數(shù)據(jù)展示模塊，提供了分析指標數(shù)據(jù)展示的邏輯流程及UI案例，旨在幫助有需要的同學全方位的了解用戶行為數(shù)據(jù)全鏈路分析流程。

一、背景

針對用戶行為數(shù)據(jù)進行采集有個專業(yè)術語叫埋點，在h5頁面上做的埋點統(tǒng)稱為H5埋點。H5頁面因其靈活性，便捷的交互和豐富的功能，以及在移動設備上支持多媒體等特點目前被廣泛應用于網(wǎng)頁app開發(fā)。

現(xiàn)階段H5埋點的自由度較高，行業(yè)數(shù)據(jù)產(chǎn)品在同類高頻的業(yè)務場景上設計的時間花費較多，埋點開發(fā)、埋點測試等事項耗時，且需重復勞動；同樣的埋點數(shù)據(jù)分析層面-基礎分析指標，留存指標，頁面分析等需求需多次開發(fā)模型，浪費寶貴的人力資源。

H5通用分析模型旨在通過規(guī)范化埋點設計方案，開發(fā)設計一套通用度高，擴展方便，需求響應迅速的模型，減少行業(yè)數(shù)據(jù)產(chǎn)品和開發(fā)在類似需求上的人力投入，提升數(shù)據(jù)分析效率。

二、分析模型概述

2.1 術語解釋

2.2 模型概述

針對業(yè)務發(fā)展的不同階段，會有相應的數(shù)據(jù)分析需求。如圖（1），在業(yè)務初期，用戶的訪問，留存情況等是階段性分析重點，業(yè)務產(chǎn)品運營可以根據(jù)分析數(shù)據(jù)適時的調整頁面布局，運營策略等；應用發(fā)展中后期可能會更多的關注訂單、轉化、路徑等相關分析指標。如果能在應用上線之初，快速的拿到核心分析指標數(shù)據(jù)，對產(chǎn)品的推廣，迭代無疑是收益良多。所以，本次模型構建從應用初期分析最廣泛的核心指標出發(fā)，落地應用概況、頁面訪問、用戶留存等維度全方位核心分析指標體系。

圖（1）應用生命周期內指標分析情況

2.2.1 分析模型主題

本次通用分析模型圍繞以下分析主題構建。

• 【基礎分析】：從用戶瀏覽次數(shù)，人均訪問頁面數(shù)，人均使用時長，新老用戶等基礎指標展示用戶訪問大盤數(shù)據(jù)。

• 【頁面分析】：面向具體頁面，分析用戶訪問pv,uv,訪問時長等核心指標，有針對性的發(fā)現(xiàn)頁面訪量薄弱環(huán)節(jié)，為合理化頁面管理提供數(shù)據(jù)支撐，協(xié)助產(chǎn)品經(jīng)理通過信息重組，提升頁面訪問量。

• 【留存分析】：通過用戶的留存，了解目前的產(chǎn)品現(xiàn)狀（用戶的哪些行為導致留存率的不同）;?判斷產(chǎn)品的改進有無效果（用戶行為是否發(fā)生了改變導致留存率的提升）；留存分析反映了用戶由初期的不穩(wěn)定用戶轉化為活躍用戶，穩(wěn)定用戶，忠誠用戶的過程。

2.2.2 分析指標定義

（以下示例中數(shù)據(jù)均為參考數(shù)據(jù)，非真實數(shù)據(jù)）

1、基礎分析：訪問pv，uv等指標（全維度）

2、頁面分析：頁面訪問相關pv，uv，時長等指標

注：用戶對訪問頁面進行命名，分析平臺提供配置入口，方便用戶對頁面進行命名。

3、留存分析：新用戶留存，活躍用戶留存? 包括：N日內留存 和 第N日留存。

通常意義上的留存分析指的是：用戶在APP產(chǎn)生行為后，在固定的第N日繼續(xù)訪問或使用APP的用戶；包括活躍用戶留存和新用戶留存

為滿足不同業(yè)務的分析需求。此次留存模型包含 n日內留存分析，即用戶在APP產(chǎn)生行為后，在固定的第N日內繼續(xù)訪問或使用APP的用戶（日期范圍留存）。

三、埋點方案

3.1 業(yè)務目標

• 采集用戶的pv，uv數(shù)據(jù)，幫助產(chǎn)品同學了解目前的產(chǎn)品現(xiàn)狀，并不斷改進產(chǎn)品；

• 自動采集，對pv，uv等這類埋點，業(yè)務無需再開發(fā)，打開開關即可采集這類數(shù)據(jù)。

3.2 自動采集

3.2.1 什么是自動采集

自動采集是相對于前端開發(fā)者而言，目的是為了幫助前端開發(fā)者提升數(shù)據(jù)采集效率。通過自動采集開關配置，無需在手動實現(xiàn)上報邏輯。使用時前端開發(fā)者通過引入h5sdk.js(也稱jssdk.js)，打開自動采集開關，我們就會在適當?shù)臅r機，以適當?shù)囊?guī)則采集數(shù)據(jù)，并進行上報。開發(fā)者無需在關注采集代碼內部邏輯，以此來減輕同類數(shù)據(jù)采集的開發(fā)工作量。

3.2.2 如何自動采集

按照給定的規(guī)則進行頁面事件EventListener，當用戶活動觸發(fā)對應的事件時，我們會組裝好數(shù)據(jù)，然后將組裝好的數(shù)據(jù)通過https傳入到后臺。

3.2.3 自動采集的三大規(guī)則場景

我們的網(wǎng)站是一個SPA應用。SPA應用通過改變前端路由的變化，實現(xiàn)頁面內組件的切換。組件的切換，對于一個非前端開發(fā)者來說，可以泛指頁面的切換。所以我們第一場景是要覆蓋url變化的這類事件。在實踐中，我們發(fā)現(xiàn)，當我們需要采集頁面的用戶停留時長時，往往會不準確。為什么不準確？用戶可以縮小化瀏覽器，也可以切換tab到其他網(wǎng)站，這個時候計算的用戶時長是不準確的。因為用戶雖然打開了我們網(wǎng)頁，但是并沒有聚焦到我們的網(wǎng)頁。這種不應該算作用戶停留時長，因此對于這些行為，我們又加上了失去焦點，得到焦點，以及切換瀏覽器tab事件的EventListener，這兩種場景。

綜上三大場景總結如下：

頁面切換時，進行采集，即url變化時觸發(fā)的事件；

頁面失去焦點，得到焦點時，進行采集。即focus，blur事件；

頁面通過瀏覽器tab切換離開，切換回來時，進行采集，即visibilitychange事件；

3.2.3.1 三大規(guī)則場景的界定

上文我們已經(jīng)在實踐中總結出了自動采集的三大場景，在實際應用針對三大場景的使用我們也總結出了一套界定方案。

（1）規(guī)則一界定——怎么判斷頁面切換？

a、現(xiàn)在的網(wǎng)站要么是MPA，要么是SPA模式，或者兩種模式混合，MPA主要是后臺路由，SPA主要是前端路由（hash模式和history模式）。但無論是SPA還是MPA，當頁面需要切換時，url一定會變化，基于此點，我們判斷當url變化時，用戶一定切換了頁面。此時觸發(fā)規(guī)則一的事件，產(chǎn)生數(shù)據(jù)上報。

這里需要注意2個問題：

• 第1個問題：url變化 = window.location.origin + window.location.pathname + window.location.hash 這三部分的任一部分變化，即為url變化，并不包括window.location.search這部分的變化；

• 第2個問題：在SPA中，如果一個頁面內有多個tab，當切換tab時，開發(fā)者也改變他的url的window.location.pathname，此時也會認為是頁面切換，也會產(chǎn)生上報數(shù)據(jù)，如下這種情況。

圖（2）

b、完整頁面切換上報流程，由頁面A切換到頁面B時，一共上報4個埋點；

圖（3）

c、關于路由的EventListener

現(xiàn)在的大多網(wǎng)站，大多是SPA應用，SPA的前端路由有hash模式和history模式這兩種模式，當通過前端路由來頁面切換時，肯定會觸發(fā)hash模式或history相關的api。

因此，我們只需要把所有觸發(fā)事件的場景給全部進行EventListener即可。有如下2種路由的EventListener：window.hashchange事件——觸發(fā)hash模式時、window.popstate事件、pushstate,replacestate自定義事件——觸發(fā)history模式時。

這里有2個問題需要關注：一是當某個SPA應用的路由事件，觸發(fā)了history模式時，我們應該移除hash模式的EventListener。二是pushstate,replacestate自定義事件，因為BOM并沒有提供相關的api支持EventListener，需要自行封裝使用，如下code。

引入JSSDK

/*** 拼接通用化上報參數(shù)* @param {string} 重寫路由事件類型*/ function resetHistoryFun(type){// 將原先的方法復制出來let originMethod = window.history[type]// 當window.history[type]函數(shù)被執(zhí)行時，這個return出來的函數(shù)就會被執(zhí)行return function(){// 執(zhí)行原先的方法let rs = originMethod.apply(this, arguments)// 然后自定義事件let e = new Event(type.toLocaleLowerCase())// 將原先函數(shù)的參數(shù)綁定到自定義的事件上去，原先的是沒有的e.arguments = arguments// 然后用window.dispatchEvent()主動觸發(fā)window.dispatchEvent(e)return rs;} } window.history.pushState = resetHistoryFun('pushState') // 覆蓋原來的pushState方法 window.history.replaceState = resetHistoryFun('replaceState') // 覆蓋原來的replaceState方法window.addEventListener('pushstate', reportBothEvent) window.addEventListener('replacestate', reportBothEvent)

（2）規(guī)則二界定——怎么判斷頁面失去焦點，得到焦點？

失去焦點，得到焦點。我們主要進行如下這兩個事件的EventListener：

引入JSSDK

window.addEventListener('focus', ()=>{console.log('頁面得到焦點') });window.addEventListener('blur', ()=>{console.log('頁面失去焦點') })

（3）規(guī)則三界定——怎么判斷瀏覽器tab切換離開，切換回來？

tab切換離開，切換回來。我們主要進行如下這一個事件的EventListener：

引入JSSDK

document.addEventListener('visibilitychange', () => {if(document.hidden) {console.log('頁面離開')} else {console.log('頁面進入')} })

注意：如果一個行為同時滿足2個及2個以上的規(guī)則時，只會取一個規(guī)則上報數(shù)據(jù)。避免不重復上報數(shù)據(jù)。

3.3 埋點設計

3.3.1 埋點個數(shù)

為了得到pv和uv的相關數(shù)據(jù)，我們設計了2個埋點，1個為頁面進入時上報的埋點，另外1個為頁面離開時的埋點，上報的數(shù)據(jù)都是一對的，離開-進入頁面為一對，失去焦點-得到焦點為一對，切換tab離開當前頁面-返回當前頁面也為一對；

為什么要設計2個埋點？設計2個埋點，能覆蓋全面上述我們所說的3種規(guī)則場景；其次，方面計算頁面停留時長；最后就是方便邏輯判斷，避免重復上報；

3.3.2 參數(shù)的設計

按照不同的需求，參數(shù)的設計分為如下4類：

• pv，uv需要參數(shù)，開發(fā)者傳入?yún)?shù)：unique_id——標識用戶唯一標識、topic_id——當前網(wǎng)站唯一標識、current_env——當前網(wǎng)站環(huán)境，默認為prod，可用戶傳入；

• pv，uv需要參數(shù)，sdk內部獲取參數(shù)：duration——頁面停留時長、last_page_url——上個頁面url、page_url——當前頁面url；

• SDK需要的參數(shù)，幫助判斷事件觸發(fā)類型，SDK內部獲取參數(shù)：eventType

• 用戶其他需要補充的參數(shù)：自定義參數(shù)

3.4 數(shù)據(jù)上報

數(shù)據(jù)上報方式是XMLHttpRequest、window.navigator.sendBeacon，基于h5sdk上報邏輯架構。

圖（4）

3.5 兼容性和容錯性

關于兼容性，依賴于window對象、不兼容IE6、IE7，IE8;

關于容錯性，對通用化內部邏輯做了try catch的容錯兼容，保證出錯時不影響業(yè)務主邏輯運行，同時上報一個出錯的事件類型，知道出錯的原因，以便提前做好對應的優(yōu)化方案。

3.6 個人數(shù)據(jù)保護合規(guī)

為了保護好用戶的個人數(shù)據(jù)及其隱私并滿足法律法規(guī)要求，在埋點的設計、采集、使用等環(huán)節(jié)需要進行充分的隱私保護設計。例如，在埋點設計階段，需要確定標識符的選擇、埋點參數(shù)的最小必要、采集頻率的最小必要等；在埋點的采集、使用階段，需要確保相關處理行為的透明、可控，包括對用戶進行告知，獲取用戶的有效同意，提供撤回同意的渠道等等。

四、數(shù)倉方案

埋點方案已經(jīng)具備，接下來的工作就是設計一套接入高效，拓展便捷的數(shù)倉分析模型；為實現(xiàn)以上既定的分析目標，模型設計過程中需要解決以下核心問題。

4.1 核心問題列表

4.2 模型分層標準

介紹模型設計前，先說下vivo 數(shù)倉模型分層基本原則，及本次模型分層思路，各層模型設計原則參照《vivo中臺數(shù)倉建設方法論》，層級設計摘要如下：

4.3 模型層級架構

通過核心問題拆解發(fā)現(xiàn)，為實現(xiàn)通用分析模型方案，需要從數(shù)據(jù)接入層收口，在數(shù)據(jù)接入時統(tǒng)一參數(shù)解析，統(tǒng)一字段命名，并設置相應的應用id字段，區(qū)分各個業(yè)務數(shù)據(jù)源；接著需要生成活躍數(shù)據(jù)明細表，可統(tǒng)計相應的基礎分析，頁面分析指標；同時為滿足留存分析的需要，我們需要構建相應的活躍全量表，留存分析主題表基于活躍增量表和活躍全量表生成，用戶活躍信息通過打標簽的方式標記。至此涉及三個主題分析的模型規(guī)劃完畢。層級劃分原則及規(guī)劃邏輯模型明細，如：圖（5）

圖（5）

從分層架構圖可看出H5通用分析模型分為明細層(dw)、輕度匯總層(dma)、分析主題表 (dmt) 和指標層(da); 其中輕度匯總層可作為中間數(shù)據(jù)提供行業(yè)分析師及數(shù)據(jù)開發(fā)、業(yè)務產(chǎn)品等查詢分析使用；匯總層作為分析平臺通用分析模型報表數(shù)據(jù)源，導入mysql存儲，前端基于mysql表實現(xiàn)數(shù)據(jù)展示,各個模型設計細則如下：

數(shù)據(jù)模型規(guī)劃及設計的核心在于三點：確定appid和用戶id映射關系，留存方案實現(xiàn)及留存記錄入庫bitmap方式讀寫。

1、確定appid和用戶id映射關系-unique_id 關聯(lián)設計

多業(yè)務id統(tǒng)一

## 明細層收口數(shù)據(jù),統(tǒng)一id字段 SELECT xx,xx1,CASE WHEN appid IN(1) THEN 1 WHEN appid IN(2) THEN 2 WHEN appid IN(3) THEN 3 WHEN appid IN(4,5,6,...) THEN 4 ELSE 0 END AS id_flag ,CASE WHEN appid IN(1) THEN id1WHEN appid IN(2) THEN id2WHEN appid IN(3) THEN id3 WHEN appid IN(4,5,6,...) THEN IF(NVL(params['id1'],'')='',NVL(params['id2'],'NA'),params['id1']) ELSE 'NA' END AS unique_id ,appid FROM ods_table_name_XXX a -- 各個接入業(yè)務線數(shù)據(jù)源 odsWHERE day='${today}'AND hour = '${etl_hour}'-- APPID 和 事件id 要匹配新增AND appid in (1,2,3 ...)AND 事件id in (XXX|167,XXX|168,...);## id字段后續(xù)關聯(lián)使用方式 ## 增量關聯(lián)全量，確定是否新用戶 SELECT if(b.unique_id is null,1,0) AS is_new FROM ( SELECT *FROM table_XXX_hiWHERE day= '${today}'AND hour = '${etl_hour}'GROUP BY XX) a-- 取全量表唯一 unique_id 作為關聯(lián)條件，判斷新老用戶-- 新用戶是相對于歷史全量的LEFT JOIN ( SELECT unique_id,appidFROM ( SELECT unique_id,appid,row_number() over(partition by unique_id,appid order by 活躍日期 asc) as rn_0FROM table_XXX_dfWHERE day='${etl_date}') aWHERE rn_0 = 1) bON a.unique_id = b.unique_id AND a.appid = b.appid;

2、留存方案實現(xiàn)及留存記錄入庫bitmap方式讀寫

留存方案

## 利用bitmap思想，留存標簽滿8位轉化為16進制組合到retain_tag之前，這樣可以利用很少的位數(shù)記錄較長的活躍情況 ## 示例代碼如下 SELECT user_unique_id,if(length(tmp_retain_tag) = 8,is_active,concat(is_active,tmp_retain_tag)) as tmp_retain_tag-- 如果tmp_retain_tag長度為8的時候，將數(shù)據(jù)轉化為十六進制添加到retain_tag前，并將本字段清空，從頭開始計數(shù),if(length(tmp_retain_tag) = 8,concat(con_tmp_retain_tag,retain_tag),retain_tag) as retain_tag,is_activeFROM (SELECT unique_id-- 前一天的臨時存儲，與con_tmp_retain_tag保持一致,tmp_retain_tag -- 如果轉換為十六進制后的長度不為2，則在左邊添加0 ,if(length(conv(tmp_retain_tag,2,16)) = 2,conv(tmp_retain_tag,2,16),concat('0',conv(tmp_retain_tag,2,16))) as con_tmp_retain_tag -- 歷史軌跡,retain_tag ,first_value(is_active) over(partition by unique_id,appid,topic_id order by first_active_day desc) as is_activeFROM( SELECT unique_id,topic_id,appid ,first_active_day,last_active_day-- 留存標簽,'0' as is_active,tmp_retain_tag -- 形如 11101010,retain_tag -- 形如 A0E3FROM table_active_XX_df -- 活躍全量表WHERE day= '${last_etl_date}'UNION ALLSELECT unique_id,topic_id,appid ,day as first_active_day,day as last_active_day-- 留存標簽 ,'1' as is_active,'' as tmp_retain_tag,'' as retain_tagFROM table_active_XX_hi -- 活躍明細表WHERE day= '${etl_date}') a ) b WHERE rn =1;## 留存指標統(tǒng)計：## 以3日內及第3日留存為例 WITH tmp_table AS ( SELECT DAY,unique_id,appid,首次活躍日期,CONCAT(tmp_retain_tag,retain_tag) AS login_trace FROM (SELECT DAY,unique_id,tmp_retain_tag,appid,首次活躍日期,IF(nvl(retain_tag,'') <> '',CONV(SUBSTR(retain_tag,1,8),16,2),'') AS retain_tag-- 如果retain_tag為空時，直接取空值。如果長度超過8位數(shù)，取最后八位數(shù)；如果長度不超過8位數(shù)，取全部。如果是30日內新用戶，長度不超過8位FROM table_active_XX_df WHERE DAY = 統(tǒng)計日) x1 ) ## 以3日內及第3日留存為例： SELECT -- 第N日留存指標：第N日來訪,SUM(IF(SUBSTR(login_trace,3,1) = '1',1,null)) AS retain_cnt_3th-- N日內留存指標:N日內訪問過1次或N次,SUM(IF(instr(SUBSTR(login_trace,2,2) ,'1')= 0,null,1)) AS retain_cnt_between_3thFROM (SELECT '統(tǒng)計日-2天' AS dt,unique_id,REVERSE(SUBSTR(login_trace,1,3)) AS login_trace,appidFROM tmp_table WHERE SUBSTR(login_trace,3,1) = '1' AND 首次活躍日期 = 統(tǒng)計日-2天 ) X GROUP BY dt,appid;

4.4 模型數(shù)據(jù)流圖

至此，模型的設計落地全部完成，模型包含埋點數(shù)據(jù)表2張，dw明細層模型1張，維表1張，dma輕度匯總主題層2張，dmt主題表2張，任務層深4層，模型層2層，模型數(shù)據(jù)接入0.5人日可完成。

數(shù)據(jù)流圖如下：

圖（6）

五、數(shù)據(jù)展示

模型數(shù)據(jù)展示可基于用戶行為分析平臺，數(shù)據(jù)指標存儲使用 MySQL 數(shù)據(jù)庫，數(shù)據(jù)展示邏輯實現(xiàn)如下：

圖（7）

5.1 報表展示

報表配置完成后，各個分析模塊的前臺展示示例如下：

圖（8）應用概況報表

圖（9）用戶留存報表

圖（10）頁面分析報表

六、未來展望

至此，H5通用分模型落地流程已介紹完畢。本文主要是基于業(yè)務初期訴求，快速落地通用的、統(tǒng)一的數(shù)據(jù)解決方案，滿足業(yè)務分析人員在產(chǎn)品初期最迫切的分析需求。隨著業(yè)務的不斷發(fā)展迭代，運營產(chǎn)品的分析方向也會不斷的擴展和深入，同時不同的業(yè)務關注點不同，針對分析模型的訴求也不盡相同。例如在業(yè)務中后期，簡單的訪問留存分析已經(jīng)支撐不了更進一步的決策制定，此時針對頁面訪問的路徑分析模型；針對營銷分析的訂單轉化模型、歸因分析模型；針對頁面跳轉分析的用戶漏斗模型等需求會相應變多。

所以，為更好的支撐業(yè)務目標達成，H5通用分析模型系列在后期會根據(jù)業(yè)務訴求落地相應的分析模型，持續(xù)為產(chǎn)品運營提供高效穩(wěn)定的數(shù)據(jù)解決方案。

END

歡迎加入大數(shù)據(jù)|數(shù)倉技術交流群。

進群方式：請加微信（微信號：dataclub_bigdata），回復：加群，通過審核會拉你進群。

(備注：行業(yè)-職位-城市)

福利時刻

01. 后臺回復「數(shù)據(jù)」,即可領取大數(shù)據(jù)經(jīng)典資料。

02.?后臺回復「轉型」,即可傳統(tǒng)數(shù)據(jù)倉庫轉型大數(shù)據(jù)必學資料。

03. 后臺回復「加群」,或添加一哥微信ID：dataclub_bigdata??拉您入群（大數(shù)據(jù)|數(shù)倉|分析）或領取資料。

！關注不迷路~ 各種福利、資源定期分享?！

總結

以上是生活随笔為你收集整理的用户行为分析模型实践——H5通用分析模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。