一、背景

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

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

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

二、分析模型概述

2.1 術(shù)語解釋

2.2 模型概述

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

圖（1）應(yīng)用生命周期內(nèi)指標分析情況

2.2.1 分析模型主題

本次通用分析模型圍繞以下分析主題構(gòu)建。

• 【基礎(chǔ)分析】：從用戶瀏覽次數(shù)，人均訪問頁面數(shù)，人均使用時長，新老用戶等基礎(chǔ)指標展示用戶訪問大盤數(shù)據(jù)。
• 【頁面分析】：面向具體頁面，分析用戶訪問pv,uv,訪問時長等核心指標，有針對性的發(fā)現(xiàn)頁面訪量薄弱環(huán)節(jié)，為合理化頁面管理提供數(shù)據(jù)支撐，協(xié)助產(chǎn)品經(jīng)理通過信息重組，提升頁面訪問量。
• 【留存分析】：通過用戶的留存，了解目前的產(chǎn)品現(xiàn)狀（用戶的哪些行為導(dǎo)致留存率的不同）; 判斷產(chǎn)品的改進有無效果（用戶行為是否發(fā)生了改變導(dǎo)致留存率的提升）；留存分析反映了用戶由初期的不穩(wěn)定用戶轉(zhuǎn)化為活躍用戶，穩(wěn)定用戶，忠誠用戶的過程。

2.2.2 分析指標定義

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

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

2、頁面分析：頁面訪問相關(guān)pv，uv，時長等指標

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

3、留存分析：新用戶留存，活躍用戶留存  包括：N日內(nèi)留存 和 第N日留存。

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

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

三、埋點方案

3.1 業(yè)務(wù)目標

• 采集用戶的pv，uv數(shù)據(jù)，幫助產(chǎn)品同學(xué)了解目前的產(chǎn)品現(xiàn)狀，并不斷改進產(chǎn)品；
• 自動采集，對pv，uv等這類埋點，業(yè)務(wù)無需再開發(fā)，打開開關(guān)即可采集這類數(shù)據(jù)。

3.2 自動采集

3.2.1 什么是自動采集

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

3.2.2 如何自動采集

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

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

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

綜上三大場景總結(jié)如下：

1. 頁面切換時，進行采集，即url變化時觸發(fā)的事件；
2. 頁面失去焦點，得到焦點時，進行采集。即focus，blur事件；
3. 頁面通過瀏覽器tab切換離開，切換回來時，進行采集，即visibilitychange事件；

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

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

（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中，如果一個頁面內(nèi)有多個tab，當切換tab時，開發(fā)者也改變他的url的window.location.pathname，此時也會認為是頁面切換，也會產(chǎn)生上報數(shù)據(jù)，如下這種情況。

圖（2）

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

圖（3）

c、關(guān)于路由的EventListener

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

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

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

引入JSSDK

/**
 * 拼接通用化上報參數(shù)
 * @param {string} 重寫路由事件類型
 */
function resetHistoryFun(type){
    // 將原先的方法復(fù)制出來
    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ù)。避免不重復(fù)上報數(shù)據(jù)。

3.3 埋點設(shè)計

3.3.1 埋點個數(shù)

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

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

3.3.2 參數(shù)的設(shè)計

按照不同的需求，參數(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內(nèi)部獲取參數(shù)：duration——頁面停留時長、last_page_url——上個頁面url、page_url——當前頁面url；
• SDK需要的參數(shù)，幫助判斷事件觸發(fā)類型，SDK內(nèi)部獲取參數(shù)：eventType
• 用戶其他需要補充的參數(shù)：自定義參數(shù)

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

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

圖（4）

3.5 兼容性和容錯性

關(guān)于兼容性，依賴于window對象、不兼容IE6、IE7，IE8;

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

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

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

四、數(shù)倉方案

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

4.1 核心問題列表

4.2 模型分層標準

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

4.3 模型層級架構(gòu)

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

圖（5）

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

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

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

多業(yè)務(wù)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  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     -- 各個接入業(yè)務(wù)線數(shù)據(jù)源 ods
 WHERE day='${today}'
   AND hour = '${etl_hour}'
   -- APPID 和 事件id 要匹配新增
   AND appid  in (1,2,3 ...)
   AND 事件id  in (XXX|167,XXX|168,...);


## id字段后續(xù)關(guān)聯(lián)使用方式
## 增量關(guān)聯(lián)全量，確定是否新用戶
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 作為關(guān)聯(lián)條件，判斷新老用戶
       -- 新用戶是相對于歷史全量的
  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、留存方案實現(xiàn)及留存記錄入庫bitmap方式讀寫

留存方案

## 利用bitmap思想，留存標簽滿8位轉(zhuǎn)化為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ù)轉(zhuǎn)化為十六進制添加到retain_tag前，并將本字段清空，從頭開始計數(shù)
       ,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                            
            -- 如果轉(zhuǎn)換為十六進制后的長度不為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;


## 留存指標統(tǒng)計：## 以3日內(nèi)及第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日內(nèi)新用戶，長度不超過8位
          FROM table_active_XX_df WHERE DAY = 統(tǒng)計日
        ) x1
)
## 以3日內(nèi)及第3日留存為例：
SELECT -- 第N日留存指標：第N日來訪
       ,SUM(IF(SUBSTR(login_trace,3,1) = '1',1,null))    AS retain_cnt_3th
       -- N日內(nèi)留存指標:N日內(nèi)訪問過1次或N次
       ,SUM(IF(instr(SUBSTR(login_trace,2,2) ,'1')= 0,null,1))  AS retain_cnt_between_3th
 FROM (
       SELECT '統(tǒng)計日-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 首次活躍日期 = 統(tǒng)計日-2天
) X GROUP BY dt,appid;

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

至此，模型的設(shè)計落地全部完成，模型包含埋點數(shù)據(jù)表2張，dw明細層模型1張，維表1張，dma輕度匯總主題層2張，dmt主題表2張，任務(wù)層深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）應(yīng)用概況報表

圖（9）用戶留存報表

圖（10）頁面分析報表

六、未來展望

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

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