關於埋點方案的思考

關於埋點方案的思考

來自專欄一個前端專欄7 人贊了文章

數據埋點

數據埋點是指針對特定用戶或事件行為進行捕獲、處理、發送的相關技術和實施過程；通過對事件的埋點布置追蹤用戶行為，我們對這些埋點數據進行統計分析，可以進一步優化產品和運營決策。

埋點服務通常的做法是服務端訪問日誌 + 前端代碼埋點，服務端日誌能夠幫助記錄用戶的數據訪問行為，前端埋點可以收集更多的view端數據、用戶的操作行為和界面變化。兩者的結合可以分析用戶在界面的操作行為帶來的數據轉化。

前端代碼埋點

作為前端開發者，我們的關注的重點在對界面變化的埋點。第一階段我們使用的是代碼埋點，實現思路是通過約束統計欄位和定義通用行為在每次發送過程按規範設置，擴展欄位用以增加個性化收集的能力。通過JS-SDK統一實現，開發者不需要關注內部實現，只需要注意埋點細節。

埋點代碼示例：

//初始化import Tracker from path/to/tracker.js //引入JS-SDKlet tracker = new Tracker(options)//點擊提交按鈕觸發代碼埋點function onClick(){//業務邏輯 tracker.send({ id: 556, tracking_type: submit ... })}

埋點從觸發到收集的過程：

在代碼埋點流程中，JS-SDK為開發者提供了規範數據、生成&維護必須欄位（用戶ID、會話ID、渠道來源...）、自定義行為和發送的能力，實現了埋點的工具化。

但代碼埋點是命令式編程，需要明確的為希望監測的用戶行為添加代碼確保觸發時發送到伺服器端。通過初始化預置和傳參tracker.send格式化埋點數據並發送到伺服器端收集。發送時我們需要傳參唯一標識，用以用戶行為分析；所以這種方式我們還需要有額外註冊和維護事件ID的工作。

代碼埋點在實際應用過程中，作為開發者遇到的問題：

1.埋點代碼耦合業務邏輯2.需要額外維護和記錄埋點的事件標識3.監測點多和業務複雜時易出錯

簡單來說就是影響開發和測試效率，所以我們展開另一種思路無埋點來嘗試解決。

無埋點

為了簡化埋點過程，我們開始做無埋點技術或者叫做可視化監測的嘗試。

無埋點技術方案是把代碼埋點的命令式編程轉化為聲明式編程；我們通過全量收集用戶行為，在伺服器端增加過濾和去重機制來實現自動化收集。

埋點代碼示例：

//初始化import Tracker from path/to/tracker.jslet tracker = new Tracker(options)

無埋點流程：

與代碼埋點不同無埋點技術方案中我們希望自動化捕獲全量的用戶行為和生成唯一標識，將事件抽象歸類,數據與回溯得到觸發事件的唯一頁面元素路徑一起上報。

所以在實踐中我們增加了中間層Nodejs服務，用以生成&維護埋點ID、元素路徑的去重合併和過濾噪點、查詢服務...

按照上圖流程在處理去重合併元素路徑後，會判斷埋點是否新增走不同流程。

在這個實現中，開發者只需要引入埋點JS-SDK就可以自動化收集和發送數據，因為發送了唯一元素路徑在做埋點可視化的過程就更方便，可以做到在埋點頁面中還原埋點數字圖和熱力圖方便數據分析。

但在實際使用中，無埋點方案也不能解決所有場景：

1.很難追蹤業務邏輯2.對於事件的抽象不能滿足所有場景3.串聯用戶行為的天然劣勢

埋點方案

埋點方案我們確定為 代碼埋點 + 無埋點 結合的方式。代碼埋點用以追蹤業務邏輯和自定義行為，無埋點自動化做全量收集通過實現更多的事件抽象來提高埋點效率。希望支持更多的事件抽象，來解耦無必要的代碼埋點與業務邏輯。在埋點中需要上報一些業務數據時，在無埋點中開發者不能主動發送，有些場景需要做一些約束開發者將數據寫入DOM自定義屬性。

後續也會將Perfomance API頁面性能檢測、錯誤收集等和埋點SDK整合開發者可自定義開啟，這樣可以統一接入前端日誌。

更多的想法

關於串聯埋點用戶行為由於無埋點方案生成和維護埋點ID對於開發者和使用者透明，所以對於用戶行為路徑的分析更困難。思考的解決方法是考慮做埋點路徑的本地存儲和定時上報，但會有數據延遲的可能，但更遠的意義在於本地存儲可以做用戶個性化分析更方便做類似「千人千面」和精準推薦的需求。

推薦閱讀：