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

什么是埋點(diǎn)

埋點(diǎn)，它的學(xué)名是事件追蹤（Event Tracking），主要是針對(duì)特定用戶行為或業(yè)務(wù)過(guò)程進(jìn)行捕獲、處理和發(fā)送的相關(guān)技術(shù)及實(shí)施過(guò)程。埋點(diǎn)是數(shù)據(jù)領(lǐng)域的一個(gè)專業(yè)術(shù)語(yǔ)，也是互聯(lián)網(wǎng)領(lǐng)域的一個(gè)俗稱。埋點(diǎn)是產(chǎn)品數(shù)據(jù)分析的基礎(chǔ)，一般用于推薦系統(tǒng)的反饋、用戶行為的監(jiān)控和分析、新功能或者運(yùn)營(yíng)活動(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)入頁(yè)面）、leave_page（離開(kāi)頁(yè)面）。

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

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

主流方案

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

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

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

• 可供DA使用的信息較少

• 接入簡(jiǎn)單，幾乎無(wú)侵入，不需要額外的開(kāi)發(fā)成本

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

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

• 缺點(diǎn)：

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

• 工作量大，而且對(duì)代碼侵入性很大，后期維護(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)聽(tīng)和收集過(guò)程開(kāi)發(fā)人員無(wú)感知。例如公司的tea

• 暫時(shí)想不到

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

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

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

• 缺點(diǎn)：

常見(jiàn)埋點(diǎn)屬性

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

常見(jiàn)埋點(diǎn)事件

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

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

Performance.timing

常見(jiàn)性能指標(biāo)

FP

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

FCP

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

FMP

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

TTI

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

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

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

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

資源加載指標(biāo)

window.performance.getEntriesByType('resource')會(huì)返回當(dāng)前頁(yè)面加載的所有資源（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ò)誤，通過(guò) addEventListener('error', callback, true)在捕獲階段捕捉資源加載失敗錯(cuò)誤。

• js 執(zhí)行錯(cuò)誤，通過(guò) 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ò)誤，通過(guò) addEventListener('unhandledrejection', callback)捕捉 promise 錯(cuò)誤，但是沒(méi)有發(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)聽(tīng) 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)聽(tīng) 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è)場(chǎng)景中，需要考慮兩個(gè)問(wèn)題：

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

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

Beacon

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

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

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

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

navigator.sendBeacon(url, data);

其中 data 參數(shù)是可選的，它的類型可以為 ArrayBufferView, Blob, DOMString 或者 FormData。如果瀏覽器成功地將 beacon 請(qǐng)求加入到待發(fā)送的隊(duì)列里，這個(gè)方法將會(huì)返回 true ，否則將會(huì)返回 false使用Beacon時(shí)需要后臺(tái)需要使用post方法接收參數(shù)，考慮到跨域問(wèn)題，后臺(tái)還需要改造接口配置CORS。同時(shí)請(qǐng)求頭必須滿足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的兼容性問(wèn)題是不可避免的，不過(guò)可以充分利用大部分瀏覽器會(huì)在頁(yè)面卸載前完成圖片的加載的特性，通過(guò)在頁(yè)面添加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請(qǐng)求方式，不同服務(wù)器針對(duì)uri的長(zhǎng)度有限制，長(zhǎng)度超過(guò)限制時(shí)會(huì)出現(xiàn)HTTP 414錯(cuò)誤，所以還要注意上報(bào)頻率，減少一次性上傳的屬性過(guò)多。

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.

兼容方案