雪花新聞

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

開場介紹

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

建設價值

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

數據埋點的業務價值

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

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

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

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

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

關鍵結構

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

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

渾儀的總體架構圖

總體架構預覽

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

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

系統關鍵架構

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

數據採集

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

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

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

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

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

採集數據分析

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

具體事件攔截

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

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

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

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

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

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

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

數據分析

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

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

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

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

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

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

那麼怎麼才能讓平均時長,具有價值呢?

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

數據應用

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

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

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

操作系統,瀏覽器佔比,可以點擊細查:

其他

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

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

❉ 作者介紹 ❉

相關文章