DataWorks數據埋點的設計及未來發展的思考

03-30

什麼是前端埋點？

馬總曾經說過現在是DT時代（大數據的時代）。

數據已經成為一家公司最寶貴的財富，越來越多的互聯網公司開始重視數據的應用。數據應用的過程是：數據收集 -> 數據整理（數據同步）-> 數據分析 -> 數據可視化。

前端埋點是用戶行為數據採集領域非常重要的手段，指的是針對特定用戶行為或事件進行捕獲、處理和發送的相關技術及其實施過程。

當然前端埋點上報也不僅僅有用戶行為數據的採集，還有一個很重要的領域——前端健康度分析。包括採集頁面載入性能，js報錯收集，介面出錯上報，自定義測速等等。

為什麼要進行前端埋點

埋點可以幫助分析人員獲取真正需要的業務數據及其附帶信息，對產品發展、業務決策和指導運營有非常重要的作用。

在不同場景下，業務人員關注的信息和角度可能不同。典型的應用場景如淘寶活動運營，以及PD和UED。前者注重來源渠道和廣告效果，而後兩者更在意產品本身流程和體驗的優化。這就需要通過埋點採集到對應的數據，以數據為依據來做決策和判斷。

打個比方，城市要提高一個路口的通過率，那必須要重新調整交通信號燈的邏輯。光看是不行的，我們需要同時拿到路口各個時間段和各個方向的車輛流動量，這就需要在相應的節點上安裝攝像頭和交通流量計數器。埋點同理。

DataWorks的產品和埋點需求

DataWorks是阿里集團內最大最優秀的一站式大數據平台，整合了大數據設計和開發、運維監控、數據集成、數據管理，數據安全，數據質量等產品，並打通演算法平台pai，形成了完整的大數據閉環。

需求背景

目前整個DataWorks所有前端產品缺少一個統一化的埋點方案，導致產品和UED無法準確地拿到用戶數據來輔助決策。

鑒於此背景，我們在為DataWorks做埋點和數據上報的時候，遇到了不小的挑戰。

需要上報的數據

UV/PV（支持單頁應用）
所有按鈕鏈接的點擊事件
導航點擊事件
表格篩選表單的使用情況
操作系統和瀏覽器信息
前端性能數據
前端報錯記錄
介面返回時間
介面報錯信息，包含errorCode，requestId等

碰到的問題

首先，DataWorks是一個數據平台，包含產品15+，涉及到的頁面將近50個，如果使用傳統埋點方式，工作量巨大。
因為歷史遺留問題，產品的前端技術棧不統一，有jquery、requirejs、react、angular1.x，還有一些自研的前端框架，導致無法使用統一的埋點規則進行數據採集上報。
DataWorks的很多產品都是複雜的單頁應用，而且需求交互迭代特別頻繁，對用戶行為數據埋點上報的拓展性和靈活性有非常高的要求。

其他業務需求

業務上對用戶的角色、BU等信息進行分析有需求，所以在上報的數據中需要帶上當前用戶信息及一些產品自定義的信息。
能夠有一個地方可以看到所有產品的PV/UV，及在線時長，流失率等指標。
針對定製化的需求，能夠方便地對上報的數據進行抽取分析，並輸出報表。
能夠支持專有雲的埋點上報。

埋點設計

設計原則

能夠支持基礎的PV/UV以及前端健康度的上報，也可以支持用戶自定義上報。
盡量做到無痕，或者儘可能少的代碼改動。降低接入埋點的工作量。
能夠提供快速的數據抽取分析的方法。
可以讓開發者針對不同的產品，在每次數據採集的時候，傳入自定義數據。例如，用戶信息，項目信息等。
默認全部記錄，可設置抽樣上報，並提供開關，關閉埋點功能。
統一入口，比如在公共頭裡統一接入埋點，再對外暴露方法，讓各個產品設置自己的埋點配置。

技術選型

集團內比較成熟的兩個方案：

aplus：可以進行採集用戶的PV/UV，並統計頁面的在線時長，流失率等指標，而且提供了頁面可視化展示各項數據。
retcode：更專註於對前端健康度的監控和報警，並提供了靈活的自定義上報介面。另外retcode的源日誌數據比較開放，更方便做後續的數據分析。

針對DataWorks的數據上報需求，我們決定使用retcode進行主要的數據上報，aplus也會默認接入（阿里的Nginx會默認在頁面中插入aplus的js）。

但在埋點需求中有一項aplus和retcode都無法實現，就是「所有按鈕鏈接的點擊事件」。這個需求就需要使用到「無痕埋點」（在「無痕埋點」的場景下，數據監測工具一般傾向於在監測時捕獲和發送儘可能多的事件和信息，而在數據處理後端進行觸發條件匹配和統計計算等工作，以較好地支持關注點變更和歷史數據回溯。）。

但因為DataWorks的產品技術棧不統一，尤其當下業界在react和angular框架的無痕埋點方向上基本屬於空白狀態。所以我設計了一套埋點機制，來實現不同前端框架的下的無痕埋點，並將採集到的事件和數據通過retcode進行數據上報。

架構設計

從結構上劃分，分為底座和插件兩大塊。

底座：負責插件的裝載、數據的封裝處理和上報。
插件：不同前端框架的埋點方案都基於規定好的數據格式開發插件，並按需插入到底座來實現埋點數據採集。

從功能上劃分，底座總共分為三層，既數據採集層、數據處理層及數據傳輸層。

底座設計

上面講到底座分為三層：

數據採集層，提供了一整套的插件接入機制。底座自身並不提供數據採集的功能，它本身只是一個容器，允許各種插件按照一定的規則插入到底座中，提供數據採集的功能。
數據處理層：提供了數據的規範，各個插件需要依照該數據規範把採集到的數據進行包裝（例如加入各個產品配置的業務數據），然後傳給數據傳輸層。
數據傳輸層：封裝retcode進行埋點上報。

這樣設計的好處是底座不負責採集，採集的工作由插件實現。而插件機制又保證了整個埋點機制的拓展性，甚至未來其他的開發者也可以基於這套底座和規範，去開發各種前端框架的埋點上報。

插件設計

我們目前開發了jQuery、react及fetch的埋點採集插件。它們前端事件和請求數據的採集方案，主要是通過Hack通用的前端框架，在事件處理函數上做文章。具體Hack的方式下面會描述。

優點：能夠較為精確地定位到具體的選擇元素以及其功能，並且可以結合框架的優勢傳遞業務數據，更能滿足我們在複雜業務場景下處理數據的需求。
缺點：必須要在執行用戶代碼之前執行我們的埋點代碼。

jQuery的埋點方式：

第一步：改寫jQuery的事件綁定方法（如on，click，delegate等）
第二部：判斷如果是click，則記錄selector，並對回調函數做一層封裝。
第三部：執行回調封裝的時候，會把selector傳入函數內，上報上去。

註：這裡selector需要注意區分，因為有可能是通過parent或者find找到的，我們需要根據selector以及prevObject來精確查找具體的元素。

React的埋點方式：

通過改寫React.createElement，其中可以拿到組件傳遞的Property，通過Property可以進行判斷，如果含有onClick事件的話，則在此事件中進行數據的上報操作。整個過程中可以上報Component名稱以及Component的父子關係。

請求採集方案：

目前對於jQuery的Ajax。主要做法是修改ajax的beforeSend函數和complete函數，來對ajax進行統一的處理及上報。

如果是fetch，則hack瀏覽器原生的fetch方法，來對請求進行包裝，上報請求信息。

其他框架Angular、vue、backbone....

如果想使用我們的這套埋點機制，任何前端框架只需要遵循傳輸的數據格式，然後實現各自的點擊事件採集即可。

解決的問題和優化

優化：

1. 優化pv/uv數據的採集，由於用戶在使用DataWorks時，頁面不會關閉，導致PV/UV數據不準確。所以增加用戶每日首次激活頁面的時候也會進行PV/UV採集。

2. jQuery插件中，減少不必要的全局事件，例如綁在body上，用來隱藏右鍵下拉菜單的事件。

解決掉的問題：

1. retcode必須在頁面文檔流載入的時候引入，否則不會上報PV/UV和頁面載入性能數據。這個問題很嚴重，因為我們的基礎庫是通過公共頭統一引入的，這個時候文檔流已經執行完畢，所以我們通過手動調用retcode提供的spm上報介面來實現PV/UV的上報。另外頁面載入性能數據，也通過瀏覽器的PerformanceTiming API進行手動採集上報。

2. jQuery的on事件綁定方法，在hack的時候需要提取guid，並賦給hack的函數，否則off的時候會找不到對應的函數。

2. 推動七星陣支持retcode數據上報。

後期計劃

本期主要目標在於產出數據，即實現對買點數據的採集、上報、匯總工作。後續工作可以從前端及後端數據處理兩個方向進行發展。

前端方向:

製作瀏覽器插件：基於埋點數據，開發類似Udata的瀏覽器插件，能夠幫助PD、UED、運營對頁面上用戶的行為數據有個直觀的認識，從而支撐他們的產品設計和決策。這個插件的數據來源可以是實時數據，也可以是離線數據。
數據可視化：與集團內部的一些自定義報表工具打通，能夠快速方便得進行數據可視化展現。

後端數據處理方向：

1. 自動生成離線任務：DataWorks本身就是一整套的大數據平台，能夠實現數據的抽取、分析和運維。後續將考慮搭建一套機制，能夠自動的生成調度任務去幫用戶進行數據分析。

即形成了數據收集 -> 數據整理（數據同步）-> 數據分析 -> 數據可視化的閉環。