如何實現用戶行爲的動態採集與分析

開場介紹

哈嘍，大家好，我是清音，來自政採雲前端團隊。從去年開始負責用戶行爲採集與分析體系的建設。很高興有機會能在這裏給大家分享我們從 0-1 建設用戶採集與分析系統的經驗。

建設價值

首先來說一下，爲什麼我們要做這樣一個用戶行爲分析的系統？

數據埋點的業務價值

客滿部門的同學想要更精準的定位，用戶高頻問題，降低諮詢量，提升用戶滿意度。陸續有幫助用戶答疑解惑的功能模塊上線，但是，其效果無法衡量。

運營想知道哪個廣告位，哪個 資源位更有價值 ？哪些人是自己的 目標客戶 ？

產品和設計同學想要 提升用戶體驗 。開發同學在不斷迭代功能版本上線。那這些我們以爲的優化點，效果究竟如何？怎麼去衡量？都需要 數據指標支撐 接下去的工作。

我們將這個用戶行爲採集與分析的系統取名爲爲渾儀，數據採集服務上線一年半，目前渾儀平臺的日誌數量已經達到了 16 億，每個工作日收集的數量大約在 1000 萬左右，前端內部建立了虛線的興趣小組，從採集需求，設計方案到落地，總的人力成本是在 90 人天左右。

後面我會分四個部分去介紹渾儀系統，首先是關鍵架構的總體介紹，然後分成數據採集、分析和應用三個模塊詳細介紹。

關鍵結構

渾儀系統總體流程可以歸納爲三大步。首先，收集數據，然後進行數據處理，最後，數據透出展示。

而支撐這三大部門，實現了 4 個功能模塊：

• 數據採集的 SDK
• 數據處理和數據存儲的服務
• 進行坑位級數據展示的 Chrome 插件
• 系統級數據展示的站點

渾儀的總體架構圖

總體架構預覽

首先來看下渾儀的總體架構圖，我們收集了三端的數據，PC、H5 和 APP。

在 PC 端和 H5 使用了兩套 sdk 去監聽不同的事件。然後將監聽到的事件通過 rest 接口上報給數據處理的服務，存儲至阿里雲日誌服務中。我們進行了測試環境和真線環境，兩個環境的數據隔離。測試環境的 sdk 會走協商緩存的形式去刷新，真線會使用強緩存，並且進行版本控制；由於真線數據量龐大，我們會定期將日誌庫一年半以上的歷史數據數據存儲至 OSS。每天會有定時任務，篩選一部分數據存儲到數據庫中。另外還會和外部的很多系統進行交互。

• 權限系統：主要控制渾儀站點的訪問權限；
• 性能系統：輸出一些高頻訪問頁面，進行性能檢測；
• 運維平臺，用來部署系統；和大數據平臺會做一些數據的交互，我們會將行爲數據推給大數據平臺，也會從平臺上撈取一些業務相關的數據。

系統關鍵架構

從上圖重點模塊的詳細架構圖可以看到。左邊這一個模塊，是面向用戶進行行爲採集的，右邊模塊是面向內部用戶；提供給用戶非常豐富的數據可視化展示。除了有可視化的站點，還提供了 Chrome 的插件，進行數據的展示，還作爲一個 pass 平臺，對外提供一些 SQL 查詢，報表 Excel 導出，和提供 API 拉取報表的數據，也可以基於現有的數據進行二次開發。

數據採集

首先講一下數據採集模塊的實現。我們採集了頁面進入和離開，用戶點擊和滾屏事件，還有一些標準的自定義事件。頁面進入、離開和滾屏的事件我們能進行自動化的採集，點擊以及自定義事件需要，前端同學配合，進行代碼植入。

那麼我們怎麼做到零代碼的自動化採集呢？

• 首先我們在頁面當中通過項目編譯過程當中，爲項目植入了項目 ID，掛載頁面的 head 部分
• 然後在進入頁面的時候，根據頁面的路徑，去自動生成頁面 ID，掛載在 body 節點上
• 最後在用戶進入頁面和離開頁面的時候，數據採集的 SDK 能自動拿到項目 ID，頁面 ID，去定位一個唯一的頁面，做到自動化的上報進入和離開的事件

以點擊事件爲例，當前觸發點擊事件的 DOM 點，我們稱之爲坑位。坑位的外層包裹的 DOM 節點我們稱之爲區塊。這兩者需要以代碼侵入的方式，進行掛載，爲了降低掛載的成本，我們也提供了一些工具去幫助他們進行操作。

統一的站點中我們提供了埋點申請的功能，在申請完成之後點擊生成代碼，但馬上會詳細列出需要掛載的位置以及 ID，開發人員只需要將生成的代碼粘貼到需要埋點的位置即可。

另外上一場我們講到了搭建，通過搭建系統生成的頁面也會自動植入這些位置 ID，有了這些數據之後，我們就可以開始進行一次完整的上報。

採集數據分析

上圖是我們會上報的一些數據。這裏的 xy 軸座標可以用來生成用戶點擊區域的熱力圖，反映一個頁面上用戶主要的關注點。如下圖：

• 操作系統、分辨率、瀏覽器 這些信息可以讓我們分析當前平臺主流用戶的一些主流瀏覽器，用來確定平臺的兼容情況
• 如果是 APP 端還會有例如是客戶端版本，手機型號，當前網絡情況的一些其他的數據
• logType 對事件進行分類
• evt 去具體的指定事件類型
• createTime 是事件發生時間，可以用來串聯事件發生的前後順序記錄了
• utmCnt 是觸發位置用來把當前的事件定位到具體的 dom 節點
• uuid 是訪客的唯一標識，每次用戶進入頁面之後，SDK 會去 cookie 中查找它，如果沒有的話，我們就會生成，並且將過期時間設爲永久。記錄用戶的 IP 地址可以追溯到用戶的省市區
• userId 可以和 uuid 關聯起來，將無意義的訪客，關聯到平臺的用戶，形成詳細的用戶畫像
• utmfrom 標記了來源的位置，後面會詳細講 a 鏈接的跳轉，這個字段是用來串聯前後的鏈路
• 綠色框內的上報信息，我們可以歸結爲瀏覽器頁面相關的一些信息，紅色框內的是事件相關的一些信息，藍色框內的信息，我們可以歸結爲用戶相關的信息

具體事件攔截

我們將 四個目標事件都委託在了 document 上 ，所有這些事件只要觸發都會被攔截，但是經過特定的篩選，只有能 獲取到坑位 ID 和區塊 ID 的 target 上觸發的事件纔會被上報 。這讓我們收集的數據更加精準，如果在這裏不做篩選的話，上報的數據變得大而全，數據量就會特別龐大，就把目前的代碼侵入式埋點切換爲了全埋點，這也會讓數據的分析變得比較困難。

從上圖可以看見，剛進入頁面的時候，默認會有一個 push 請求發送。每次點擊的時候也會有一個 push 請求發出去，但是它的歸類都是是在 other 裏面。

這是因爲離開的過程當中，發送 HTTP 請求通常都會被 cancel，而我們使用 sendBeacon 就是一種用來保證數據被髮送的方法，他能在 unload 的或者 beforeunload 的事件處理器中發起一個 HTTP request 來發送數據，這樣就能確保我們離開頁面的請求會被記錄下來。

在數據上報這裏我們還使用 ** 標籤 主要是爲了 保證瀏覽器的兼容性 。因爲目前，IE 是不支持 sendBeacon 方法的，而我們平臺還有一部分用戶還在使用 IE，我們也在持續的關注 IE 的使用比例，所以這部分的數據也會很重要。爲了能收集到更多 IE 的使用數據，我們會先判斷 sendBeacon 方法是否可用，不可使用的時候，會使用 ** 進行，請求的發送。而 cors 是我們最常見的一種跨域請求發送的方式，它能夠使用 post 的請求，讓我們批量上報的一些數據能夠不超出長度的限制，能夠成功發送。

同樣能夠發送單一維度的一些上報數據之外，我們還需要，上報的數據能夠串聯起整個用戶瀏覽的流程。當中最常見的一種方式就是鏈接的跳轉。

可能就有人會問爲什麼不用 refer 去串聯整個流程呢？主要還是因爲他的維度太粗了。他只能進入來源頁面而不能記錄，來源於頁面上哪個位置。

• 當我們進入頁面的時候，我們會生成 當次進入頁面的唯一標識 ID
• 到用戶點擊一個鏈接的時候，我們會將當前的項目 LED 頁面 ID 區塊 ID 和當前 a 鏈接的坑位下標
• 最後是，生成頁面時生成的 ID 5 個標記 id 拼成一個 uTM 值，在頁面跳轉之後，SDK 會從頁面的 URL 上面獲取，uTM 值進行上報

這樣我們就能確認，當前頁面的來源是來源於上一個頁面的哪一個位置的鏈接點擊，也讓鏈接的點擊行爲變成一個自動化採集的事件，只要當前區塊被植入了區塊 ID，它下面的 所有 a 鏈接點擊都會被記錄下來，用於串聯整個流程 。

數據分析

在數據處理部分我們使用了阿里雲的 LOG Service，他的一個非常大的好處就是能提供日誌的實時消費接口，查詢手段也非常豐富；能夠添加實時索引；目前可以滿足我們大部分的查詢需求。

在數據分析的過程當中，非常重要的一個點怎麼樣讓我們採集到的數據轉化爲可理解的指標。

上圖我們的一個主要流程，要進行數據的分析，首先要先搭建指標，然後能獲取到需要分析的點的數據之後，再進行數據分析，最後將數據應用到實際的場景中。

根據之前採集到的數據，我們很容易就能計算出頁面的 PV、UV、點擊數、曝光數一些基礎的指標，但是我們要怎麼把它轉換成一個漏斗模型？

那就是去拼接這些基礎數據。以我們平臺的流水貸流程舉例：

• 進入申請詳情頁之後，我們可以將進入頁面的 UV 作爲第 1 個數據
• 將點擊立即申請打開協議彈窗，點擊人數作爲第二個數據，以此類推，就成組裝成一個 漏斗模型
• 我們可以計算出每個步驟相對於前一步的數量百分比，這就是一個無序的漏斗
• 假設部分用戶可能從第三步直接進入，這時候就可能存在百分比超過 100% 的情況
• 如果是有序漏斗，會以用戶爲維度進行篩選，我們會從前到後過濾每一步的用戶就表示，我們只會保留從第 1 部，按照順序進入到最後一步的那些用戶，並不把從中間進入的一些用戶計算在內。這樣就使得轉化百分比必定小於等於 100%，也讓數據更具有參考價值

下面是一個設置置信區間的場景：

• 頁面停留時長其實就是頁面進入和頁面離開的時間差，最快的情況下用戶 1s 就離開了頁面
• 但是也有可能用戶在中間中斷了操作但一直沒有關閉窗口，導致停留時間非常的長
• 在樣本比較少的情況下這樣特殊的數據可能會拉昇了頁面的平均訪問時長，使得平均時長超過了 4 個小時，這時候平均訪問時長可能失去了參考價值
• 這裏的中位數指的是將用戶訪問時長從小到大排序之後，取中間的數值，得到了 22 分 8 秒，這時候，中位數更能反映頁面實際的使用情況

那麼怎麼才能讓平均時長，具有價值呢？

我們可以設置置信區間，根據頁面具體情況排除頁面使用時長大於 5 小時或 8 小時的用戶，然後再來看整個頁面的平均訪問時長，或者是藉助柱狀圖，查看時長的總體分佈和趨勢。

數據應用

當前分析模型主要分爲 事件分析，頁面分析，轉化分析和用戶分析四大塊 ，內部還分成了 10 幾種小的指標；還在自定義設置中提供了幫助指標建立的工具；

• 事件分析是用戶行爲分析的基礎也是最常用的功能， 次數、分佈、間隔 ，通過事件分析可以創建各種分析報表。頁面基於各個頁面的行爲數據，針對性的優化着陸頁的頁面佈局，增加着陸頁的訪問吸引力。熱力圖分析，通過將用戶行爲進行可視化展示，幫助我們深入 分析用戶對內容及功能的注意力

• 轉化分析是用戶行爲分析中最重要的分析模型，通過轉化分析可以找出用戶行爲的轉化路徑和漏斗，提升平臺的整體轉化率。從觸達用戶到用戶完成轉化的整個過程中都存在轉化率

• 用戶分析能夠很好的幫助我們 確定產品的目標用戶羣，用戶的行爲習慣，掌握用戶的活躍和留存特徵 ，通過用戶分羣可以實現精細化的用戶運營

從單個頁面的角度來看，我們就可以得到很多維度的數據，可以通過插件展示在頁面上；

這是一個數據看板，實時查看自定義的核心指標和報表，對 關鍵指標做實時掌握 ，幫助用戶實時發現問題。

操作系統，瀏覽器佔比，可以點擊細查：

• 訪問次數、訪問人數
• 熱力圖：通過座標，分辨率換算，得到熱圖
• 路徑分析：可以看到來源和去向
• 這裏是自定義設置的功能：用於創建事件和漏斗

其他

渾儀算是一個比較基礎的數據採集分析的產品，後面還有很多可擴展的點。

如果公司目前發展階段還沒有需要自建一個這樣的系統，但業務有需要這樣的能力，也可以考慮第三方的一些產品，如果出於平臺數據安全的考慮，他們中也有一部分是支持本地化部署的；