前端埋點(diǎn)數(shù)據(jù)收集及上報(bào)方案實(shí)戰(zhàn)

什么是埋點(diǎn)

埋點(diǎn)，它的學(xué)名是事件追蹤（Event Tracking），主要是針對特定用戶行為或業(yè)務(wù)過程進(jìn)行捕獲、處理和發(fā)送的相關(guān)技術(shù)及實(shí)施過程。埋點(diǎn)是數(shù)據(jù)領(lǐng)域的一個(gè)專業(yè)術(shù)語，也是互聯(lián)網(wǎng)領(lǐng)域的一個(gè)俗稱。埋點(diǎn)是產(chǎn)品數(shù)據(jù)分析的基礎(chǔ)，一般用于推薦系統(tǒng)的反饋、用戶行為的監(jiān)控和分析、新功能或者運(yùn)營活動(dòng)效果的統(tǒng)計(jì)分析等。埋點(diǎn)包含兩個(gè)重要概念：事件（event），屬性（param）

• 事件（event）：應(yīng)用中發(fā)生了什么，例如用戶操作、系統(tǒng)事件或系統(tǒng)錯(cuò)誤。以你拍一產(chǎn)品為例，包含以下事件：enter_page（進(jìn)入頁面）、leave_page（離開頁面）。

• 屬性（param）：為了描述用戶群細(xì)分而定義的屬性，例如語言偏好或地理位置。以“進(jìn)入課后練習(xí)”事件為例，它包含如下事件屬性：enter_from（從哪個(gè)頁面來），class_id（課程id）等。

• 屬性值（value）：屬性的維度，即行為觸發(fā)時(shí)的具體維度。例如：enter_from：home（主頁）、system（系統(tǒng)）等。

主流方案

• 無痕埋點(diǎn)（全埋點(diǎn)），利用瀏覽器或APP自帶的監(jiān)聽方式，對用戶的瀏覽頁面、點(diǎn)擊等行為進(jìn)行收集，一般用于粗顆粒度的數(shù)據(jù)分析，例如公司的slardar

• 數(shù)據(jù)噪聲大，不管有用沒有，數(shù)據(jù)都會(huì)被收集

• 無法定制化埋點(diǎn)，無法采集到指定事件和業(yè)務(wù)屬性

• 可供DA使用的信息較少

• 接入簡單，幾乎無侵入，不需要額外的開發(fā)成本

• 用戶操作行為收集非常完整，幾乎不會(huì)遺漏

• 優(yōu)點(diǎn)：

• 缺點(diǎn)：

• 代碼埋點(diǎn)，前端開發(fā)人員在代碼中自定義監(jiān)聽和收集

• 工作量大，而且對代碼侵入性很大，后期維護(hù)也不是很方便

• 可以精確埋點(diǎn)，具備明確的事件標(biāo)識(shí)

• 業(yè)務(wù)屬性非常豐富

• 埋點(diǎn)觸發(fā)方式可以靈活定義

• DA使用更方便和精確

• 優(yōu)點(diǎn)：

• 缺點(diǎn)：

• 埋點(diǎn)sdk，sdk向外暴露上報(bào)埋點(diǎn)的接口，監(jiān)聽和收集過程開發(fā)人員無感知。例如公司的tea

• 暫時(shí)想不到

• 業(yè)務(wù)開發(fā)只需關(guān)注事件標(biāo)識(shí)、業(yè)務(wù)屬性等

• 兼顧無痕埋點(diǎn)優(yōu)點(diǎn)和代碼埋點(diǎn)的優(yōu)勢

• 優(yōu)點(diǎn)：

• 缺點(diǎn)：

常見埋點(diǎn)屬性

通常前端是按照頁面維度統(tǒng)計(jì)埋點(diǎn)的，常見的事件屬性如下：

常見埋點(diǎn)事件

性能數(shù)據(jù)采集方案

目前性能指標(biāo)數(shù)據(jù)大部分來源于 window.performance API。

Performance.timing

常見性能指標(biāo)

FP

FP (First Paint)指標(biāo)通常會(huì)反映頁面的白屏?xí)r間，而白屏?xí)r間會(huì)反映當(dāng)前 Web 頁面的網(wǎng)絡(luò)加載性能情況，當(dāng)加載性能非常良好的情況下，白屏的時(shí)間就會(huì)越短，用戶等待內(nèi)容的時(shí)間就會(huì)越短，流失的概率就會(huì)降低。該指標(biāo)可以通過?performance.getEntriesByType('paint')?方法獲取?PerformancePaintTiming API?提供的打點(diǎn)信息，找到 name 為 first-paint 的對象，描述的即為 FP 的指標(biāo)數(shù)據(jù)，如下圖所示：

FCP

FCP (First Contentful Paint) 為首次有內(nèi)容渲染的時(shí)間點(diǎn)，在性能統(tǒng)計(jì)指標(biāo)中，從用戶開始訪問 Web 頁面的時(shí)間點(diǎn)到 FCP 的時(shí)間點(diǎn)這段時(shí)間可以被視為無內(nèi)容時(shí)間，一般 FCP >= FP。該指標(biāo)可以通過?performance.getEntriesByType('paint')?方法獲取 PerformancePaintTiming API 提供的打點(diǎn)信息，找到 name 為 first-contentful-paint 的對象，描述的即為 FCP 的指標(biāo)數(shù)據(jù)，如下圖所示：

FMP

FMP（First Meaningful Paint），即首次繪制有意義內(nèi)容的時(shí)間，當(dāng)整體頁面的布局和文字內(nèi)容全部渲染完成后，即可認(rèn)為是完成了首次有意義內(nèi)容的繪制。所以 FMP 衡量了用戶看到網(wǎng)頁的主要內(nèi)容的時(shí)間，是用戶體驗(yàn)角度的一種重要的衡量指標(biāo)。前端業(yè)界現(xiàn)在比較認(rèn)可的一個(gè)計(jì)算 FMP 的方式就是「頁面在加載和渲染過程中最大布局變動(dòng)之后的那個(gè)繪制時(shí)間?」?？赏ㄟ^ MutationObserver 監(jiān)聽每一次頁面整體的 DOM 變化，觸發(fā) MutationObserver 的回調(diào)，在回調(diào)計(jì)算出當(dāng)前 DOM 樹的變動(dòng)分?jǐn)?shù)，分?jǐn)?shù)變化最劇烈的時(shí)刻，即為 FMP 的時(shí)間點(diǎn)。

TTI

TTI（Time To Interactive），即從頁面加載開始到頁面處于完全可交互狀態(tài)所花費(fèi)的時(shí)間。頁面處于完全可交互狀態(tài)時(shí)，滿足以下 3 個(gè)條件：

1. 頁面已經(jīng)顯示有用內(nèi)容。

2. 頁面上的可見元素關(guān)聯(lián)的事件響應(yīng)函數(shù)已經(jīng)完成注冊。

3. 事件響應(yīng)函數(shù)可以在事件發(fā)生后的 50ms 內(nèi)開始執(zhí)行。

資源加載指標(biāo)

window.performance.getEntriesByType('resource')會(huì)返回當(dāng)前頁面加載的所有資源（js、css、img...）的各類性能指標(biāo)，可用于靜態(tài)資源性能數(shù)據(jù)采集。主要類型有：script、link、img、css、xmlhttprequest、beacon、fetch、other。PerformanceResourceTiming - Web APIs | MDN

其他指標(biāo)計(jì)算方式

錯(cuò)誤數(shù)據(jù)采集方案

目前所能捕捉的錯(cuò)誤有三種:

• 資源加載錯(cuò)誤，通過?addEventListener('error', callback, true)在捕獲階段捕捉資源加載失敗錯(cuò)誤。

• js 執(zhí)行錯(cuò)誤，通過?window.onerror捕捉 js 錯(cuò)誤。

• 跨域的腳本會(huì)給出 "Script Error." 提示，拿不到具體的錯(cuò)誤信息和堆棧信息。此時(shí)需要在script標(biāo)簽增加crossorigin="anonymous"屬性，同時(shí)資源服務(wù)器需要增加CORS相關(guān)配置，比如Access-Control-Allow-Origin: *

• promise 錯(cuò)誤，通過?addEventListener('unhandledrejection', callback)捕捉 promise 錯(cuò)誤，但是沒有發(fā)生錯(cuò)誤的行數(shù)，列數(shù)等信息，只能手動(dòng)拋出相關(guān)錯(cuò)誤信息。

//?在捕獲階段，捕獲資源加載失敗錯(cuò)誤
addEventListener('error',?e?=>?{
????const?target?=?e.target
????if?(target?!=?window)?{
????????monitor.errors.push({
????????????type:?target.localName,
????????????url:?target.src?||?target.href,
????????????msg:?(target.src?||?target.href)?+?'?is?load?error',
????????????time:?Date.now()
????????})
????}
},?true)

//?監(jiān)聽?js?錯(cuò)誤
window.onerror?=?function(msg,?url,?row,?col,?error)?{
????monitor.errors.push({
????????type:?'javascript',
????????row:?row,
????????col:?col,
????????msg:?error?&&?error.stack??error.stack?:?msg,
????????url:?url,
????????time:?Date.now()
????})
}

//?監(jiān)聽?promise?錯(cuò)誤?缺點(diǎn)是獲取不到行數(shù)數(shù)據(jù)
addEventListener('unhandledrejection',?e?=>?{
????monitor.errors.push({
????????type:?'promise',
????????msg:?(e.reason?&&?e.reason.msg)?||?e.reason?||?'',
????????time:?Date.now()
????})
})

數(shù)據(jù)上報(bào)方案

在這個(gè)場景中，需要考慮兩個(gè)問題：

• 如果數(shù)據(jù)上報(bào)接口與業(yè)務(wù)系統(tǒng)使用同一域名，瀏覽器對請求并發(fā)量有限制，所以存在網(wǎng)絡(luò)資源競爭的可能性。

• 瀏覽器通常在頁面卸載時(shí)會(huì)忽略異步ajax請求，如果需要必須進(jìn)行數(shù)據(jù)請求，一般在unload或者beforeunload事件中創(chuàng)建同步ajax請求，以此延遲頁面卸載。從用戶側(cè)角度，就是頁面跳轉(zhuǎn)變慢。

Beacon

可以看到，除開ie瀏覽器，目前主流現(xiàn)代瀏覽器對beacon的支持率非常高。Beacon - MDN文檔Beacon 接口用來調(diào)度向 Web 服務(wù)器發(fā)送的異步非阻塞請求。

• Beacon 請求使用 HTTP?POST方法，并且不需要有響應(yīng)。

• Beacon 請求能確保在頁面觸發(fā) unload 之前完成初始化。

通俗的講就是，Beacon可將數(shù)據(jù)異步發(fā)送至服務(wù)端，且能夠保證在頁面卸載完成前發(fā)送請求（解決ajax頁面卸載會(huì)終止請求的問題）。使用方法如下：

navigator.sendBeacon(url,?data);

其中 data 參數(shù)是可選的，它的類型可以為?ArrayBufferView,?Blob,?DOMString?或者?FormData。如果瀏覽器成功地將 beacon 請求加入到待發(fā)送的隊(duì)列里，這個(gè)方法將會(huì)返回 true ，否則將會(huì)返回 false使用Beacon時(shí)需要后臺(tái)需要使用post方法接收參數(shù)，考慮到跨域問題，后臺(tái)還需要改造接口配置CORS。同時(shí)請求頭必須滿足CORS-safelisted request-header，其中content-type的類型必須為application/x-www-form-urlencoded,?multipart/form-data, 或者text/plain。

type?ContentType?=?'application/x-www-form-urlencoded'?|?'multipart/form-data'?|?'text/plain';

const?serilizeParams?=?(params:?object)?=>?{
????return?window.btoa(JSON.stringify(params))
}

function?sendBeacon(url:?string,?params:?object)?{
??const?formData?=?new?FormData()
??formData.append('params',?serilizeParams(params))
??navigator.sendBeacon(url,?formData)
}

Image

sendBeacon的兼容性問題是不可避免的，不過可以充分利用大部分瀏覽器會(huì)在頁面卸載前完成圖片的加載的特性，通過在頁面添加img的方式上報(bào)數(shù)據(jù)。

function?sendImage(url:?string,?params:?object)?{
??const?img?=?new?Image()

??img.style.display?=?'none'

??const?removeImage?=?function()?{
????img.parentNode.removeChild(img)
??}

??img.onload?=?removeImage
??img.onerror?=?removeImage

??img.src?=?`${url}?params=${serilizeParams(params)}`

??document.body.appendChild(img)
}

由于img圖片為get請求方式，不同服務(wù)器針對uri的長度有限制，長度超過限制時(shí)會(huì)出現(xiàn)HTTP 414錯(cuò)誤，所以還要注意上報(bào)頻率，減少一次性上傳的屬性過多。

HTTP 1.1 defines Status Code 414 Request-URI Too Long for the cases where a server-defined limit is reached. You can see further details on RFC 2616. For the case of client-defined limits, there is no sense on the server returning something, because the server won't receive the request at all.

兼容方案

歡迎自薦投稿到《前端技術(shù)江湖》，如果你覺得這篇內(nèi)容對你挺有啟發(fā)，記得點(diǎn)個(gè)?「在看」哦