前端埋点数据收集及上报方案实战

什么是埋点

埋点，它的学名是事件追踪（Event Tracking），主要是针对特定用户行为或业务过程进行捕获、处理和发送的相关技术及实施过程。埋点是数据领域的一个专业术语，也是互联网领域的一个俗称。埋点是产品数据分析的基础，一般用于推荐系统的反馈、用户行为的监控和分析、新功能或者运营活动效果的统计分析等。埋点包含两个重要概念：事件（event），属性（param）

• 事件（event）：应用中发生了什么，例如用户操作、系统事件或系统错误。以你拍一产品为例，包含以下事件：enter_page（进入页面）、leave_page（离开页面）。

• 属性（param）：为了描述用户群细分而定义的属性，例如语言偏好或地理位置。以“进入课后练习”事件为例，它包含如下事件属性：enter_from（从哪个页面来），class_id（课程id）等。

• 属性值（value）：属性的维度，即行为触发时的具体维度。例如：enter_from：home（主页）、system（系统）等。

主流方案

• 无痕埋点（全埋点），利用浏览器或APP自带的监听方式，对用户的浏览页面、点击等行为进行收集，一般用于粗颗粒度的数据分析，例如公司的slardar

• 数据噪声大，不管有用没有，数据都会被收集

• 无法定制化埋点，无法采集到指定事件和业务属性

• 可供DA使用的信息较少

• 接入简单，几乎无侵入，不需要额外的开发成本

• 用户操作行为收集非常完整，几乎不会遗漏

• 优点：

• 缺点：

• 代码埋点，前端开发人员在代码中自定义监听和收集

• 工作量大，而且对代码侵入性很大，后期维护也不是很方便

• 可以精确埋点，具备明确的事件标识

• 业务属性非常丰富

• 埋点触发方式可以灵活定义

• DA使用更方便和精确

• 优点：

• 缺点：

• 埋点sdk，sdk向外暴露上报埋点的接口，监听和收集过程开发人员无感知。例如公司的tea

• 暂时想不到

• 业务开发只需关注事件标识、业务属性等

• 兼顾无痕埋点优点和代码埋点的优势

• 优点：

• 缺点：

常见埋点属性

通常前端是按照页面维度统计埋点的，常见的事件属性如下：

常见埋点事件

性能数据采集方案

目前性能指标数据大部分来源于 window.performance API。

Performance.timing

常见性能指标

FP

FP (First Paint)指标通常会反映页面的白屏时间，而白屏时间会反映当前 Web 页面的网络加载性能情况，当加载性能非常良好的情况下，白屏的时间就会越短，用户等待内容的时间就会越短，流失的概率就会降低。该指标可以通过 performance.getEntriesByType('paint') 方法获取 PerformancePaintTiming API 提供的打点信息，找到 name 为 first-paint 的对象，描述的即为 FP 的指标数据，如下图所示：

FCP

FCP (First Contentful Paint) 为首次有内容渲染的时间点，在性能统计指标中，从用户开始访问 Web 页面的时间点到 FCP 的时间点这段时间可以被视为无内容时间，一般 FCP >= FP。该指标可以通过 performance.getEntriesByType('paint') 方法获取 PerformancePaintTiming API 提供的打点信息，找到 name 为 first-contentful-paint 的对象，描述的即为 FCP 的指标数据，如下图所示：

FMP

FMP（First Meaningful Paint），即首次绘制有意义内容的时间，当整体页面的布局和文字内容全部渲染完成后，即可认为是完成了首次有意义内容的绘制。所以 FMP 衡量了用户看到网页的主要内容的时间，是用户体验角度的一种重要的衡量指标。前端业界现在比较认可的一个计算 FMP 的方式就是「页面在加载和渲染过程中最大布局变动之后的那个绘制时间 」。可通过 MutationObserver 监听每一次页面整体的 DOM 变化，触发 MutationObserver 的回调，在回调计算出当前 DOM 树的变动分数，分数变化最剧烈的时刻，即为 FMP 的时间点。

TTI

TTI（Time To Interactive），即从页面加载开始到页面处于完全可交互状态所花费的时间。页面处于完全可交互状态时，满足以下 3 个条件：

1. 页面已经显示有用内容。

2. 页面上的可见元素关联的事件响应函数已经完成注册。

3. 事件响应函数可以在事件发生后的 50ms 内开始执行。

资源加载指标

window.performance.getEntriesByType('resource')会返回当前页面加载的所有资源（js、css、img...）的各类性能指标，可用于静态资源性能数据采集。主要类型有：script、link、img、css、xmlhttprequest、beacon、fetch、other。PerformanceResourceTiming - Web APIs | MDN

其他指标计算方式

错误数据采集方案

目前所能捕捉的错误有三种:

• 资源加载错误，通过 addEventListener('error', callback, true)在捕获阶段捕捉资源加载失败错误。

• js 执行错误，通过 window.onerror捕捉 js 错误。

• 跨域的脚本会给出 "Script Error." 提示，拿不到具体的错误信息和堆栈信息。此时需要在script标签增加crossorigin="anonymous"属性，同时资源服务器需要增加CORS相关配置，比如Access-Control-Allow-Origin: *

• promise 错误，通过 addEventListener('unhandledrejection', callback)捕捉 promise 错误，但是没有发生错误的行数，列数等信息，只能手动抛出相关错误信息。

// 在捕获阶段，捕获资源加载失败错误
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)

// 监听 js 错误
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()
    })
}

// 监听 promise 错误 缺点是获取不到行数数据
addEventListener('unhandledrejection', e => {
    monitor.errors.push({
        type: 'promise',
        msg: (e.reason && e.reason.msg) || e.reason || '',
        time: Date.now()
    })
})

数据上报方案

在这个场景中，需要考虑两个问题：

• 如果数据上报接口与业务系统使用同一域名，浏览器对请求并发量有限制，所以存在网络资源竞争的可能性。

• 浏览器通常在页面卸载时会忽略异步ajax请求，如果需要必须进行数据请求，一般在unload或者beforeunload事件中创建同步ajax请求，以此延迟页面卸载。从用户侧角度，就是页面跳转变慢。

Beacon

可以看到，除开ie浏览器，目前主流现代浏览器对beacon的支持率非常高。Beacon - MDN文档Beacon 接口用来调度向 Web 服务器发送的异步非阻塞请求。

• Beacon 请求使用 HTTP POST方法，并且不需要有响应。

• Beacon 请求能确保在页面触发 unload 之前完成初始化。

通俗的讲就是，Beacon可将数据异步发送至服务端，且能够保证在页面卸载完成前发送请求（解决ajax页面卸载会终止请求的问题）。使用方法如下：

navigator.sendBeacon(url, data);

其中 data 参数是可选的，它的类型可以为 ArrayBufferView, Blob, DOMString 或者 FormData。如果浏览器成功地将 beacon 请求加入到待发送的队列里，这个方法将会返回 true ，否则将会返回 false使用Beacon时需要后台需要使用post方法接收参数，考虑到跨域问题，后台还需要改造接口配置CORS。同时请求头必须满足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的兼容性问题是不可避免的，不过可以充分利用大部分浏览器会在页面卸载前完成图片的加载的特性，通过在页面添加img的方式上报数据。

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请求方式，不同服务器针对uri的长度有限制，长度超过限制时会出现HTTP 414错误，所以还要注意上报频率，减少一次性上传的属性过多。

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.

兼容方案

欢迎自荐投稿到《前端技术江湖》，如果你觉得这篇内容对你挺有启发，记得点个 「在看」哦