作者：vivo 互聯網大資料團隊- Zhao Wei、Tian Fengbiao、Li Xiong

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

一、背景

針對用戶行為資料進行采集有個專業術語叫埋點，在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

/**
 * 拼接通用化上報引數
 * @param {string} 重寫路由事件型別
 */
function resetHistoryFun(type){
    // 將原先的方法復制出來
    let originMethod = window.history[type]
    // 當window.history[type]函式被執行時，這個return出來的函式就會被執行
    return function(){
        // 執行原先的方法
        let rs = originMethod.apply(this, arguments)
        // 然后自定義事件
        let e = new Event(type.toLocaleLowerCase())
        // 將原先函式的引數系結到自定義的事件上去，原先的是沒有的
        e.arguments = arguments
        // 然后用window.dispatchEvent()主動觸發
        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）規則二界定——怎么判斷頁面失去焦點，得到焦點？

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

引入JSSDK

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

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

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

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

引入JSSDK

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

注意：如果一個行為同時滿足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統一

## 明細層收口資料,統一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  id1
             WHEN appid IN(2)  THEN  id2
             WHEN 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     -- 各個接入業務線資料源 ods
 WHERE day='${today}'
   AND hour = '${etl_hour}'
   -- APPID 和 事件id 要匹配新增
   AND appid  in (1,2,3 ...)
   AND 事件id  in (XXX|167,XXX|168,...);

## id欄位后續關聯使用方式
## 增量關聯全量，確定是否新用戶
SELECT if(b.unique_id is null,1,0) AS is_new
FROM
(
SELECT *
  FROM table_XXX_hi
 WHERE day= '${today}'
   AND hour = '${etl_hour}'
 GROUP BY XX
       ) a
       -- 取全量表唯一 unique_id 作為關聯條件，判斷新老用戶
       -- 新用戶是相對于歷史全量的
  LEFT JOIN ( SELECT unique_id,appid
                FROM      
               ( SELECT unique_id
                        ,appid
                        ,row_number() over(partition by unique_id,appid order by 活躍日期 asc)  as rn_0
                   FROM table_XXX_df
                  WHERE day='${etl_date}'
                ) a
                WHERE rn_0 = 1
             ) b
      ON a.unique_id = b.unique_id AND a.appid = b.appid;

2、留存方案實作及留存記錄入庫bitmap方式讀寫

留存方案

## 利用bitmap思想，留存標簽滿8位轉化為16進制組合到retain_tag之前，這樣可以利用很少的位數記錄較長的活躍情況
## 示例代碼如下
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的時候，將資料轉化為十六進制添加到retain_tag前，并將本欄位清空，從頭開始計數
       ,if(length(tmp_retain_tag) = 8,concat(con_tmp_retain_tag,retain_tag),retain_tag)    as retain_tag
       ,is_active
  FROM
(
    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_active
       FROM
      ( SELECT unique_id
               ,topic_id
               ,appid 
               ,first_active_day
               ,last_active_day
               -- 留存標簽
               ,'0' as is_active
               ,tmp_retain_tag -- 形如 11101010
               ,retain_tag       -- 形如 A0E3
          FROM table_active_XX_df  -- 活躍全量表
         WHERE day= '${last_etl_date}'
         UNION ALL
        SELECT 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_tag
          FROM table_active_XX_hi  -- 活躍明細表
         WHERE day= '${etl_date}'
         ) a
) b
WHERE rn =1;

## 留存指標統計：## 以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位數，取最后八位數；如果長度不超過8位數，取全部，如果是30日內新用戶，長度不超過8位
          FROM table_active_XX_df WHERE DAY = 統計日
        ) 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_3th
 FROM (
       SELECT '統計日-2天' AS dt
              ,unique_id
              ,REVERSE(SUBSTR(login_trace,1,3)) AS login_trace
              ,appid
         FROM tmp_table WHERE SUBSTR(login_trace,3,1) = '1' AND 首次活躍日期 = 統計日-2天
) X GROUP BY dt,appid;

4.4 模型資料流圖

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

資料流圖如下：

圖（6）

五、資料展示

模型資料展示可基于用戶行為分析平臺，資料指標存盤使用 MySQL 資料庫，資料展示邏輯實作如下：

圖（7）

5.1 報表展示

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

圖（8）應用概況報表

圖（9）用戶留存報表

圖（10）頁面分析報表

六、未來展望

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

所以，為更好的支撐業務目標達成，H5通用分析模型系列在后期會根據業務訴求落地相應的分析模型，持續為產品運營提供高效穩定的資料解決方案，

用戶行為分析模型實踐（一）—— 路徑分析模型
用戶行為分析模型實踐（二）—— 漏斗分析模型

分享 vivo 互聯網技術干貨與沙龍活動，推薦最新行業動態與熱門會議，

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/543136.html

標籤：大數據

上一篇：ClickHouse(12)ClickHouse合并樹MergeTree家族表引擎之AggregatingMergeTree詳細決議

下一篇：DataX插件二次開發指南

用戶行為分析模型實踐（三）——H5通用分析模型

一、背景

二、分析模型概述

2.1 術語解釋

2.2 模型概述

2.2.1 分析模型主題

2.2.2 分析指標定義

三、埋點方案

3.1 業務目標

3.2 自動采集

3.2.1 什么是自動采集

3.2.2 如何自動采集

3.2.3 自動采集的三大規則場景

3.2.3.1 三大規則場景的界定

3.3 埋點設計

3.3.1 埋點個數

3.3.2 引數的設計

3.4 資料上報

3.5 兼容性和容錯性

3.6 個人資料保護合規

四、數倉方案

4.1 核心問題串列

4.2 模型分層標準

4.3 模型層級架構

4.4 模型資料流圖

五、資料展示

5.1 報表展示

六、未來展望