前端数据采集与埋点

最近在读张云龙的文章，其中有一句话是这样的。

日志上报用 new Image().src=xxx

事实上，这不是我第一次见到这句话了。前年第 12 届的 D2 大会上，就有一个专题是「把监控系统做到极致」，其中讲到了“两行代码就能打造一个前端实时监控平台”。

// 前端
window.onerror = function (a, b, c, d, e) {
  ;(new Image).src = `/m?p=${location.href}&a=${a}&b=${b}&c=${c}&d=${d}&e=${e.stack}`
}

// 服务端
tail -f access.log | awk '/m/ { c++; print c, $0} {}'

不巧的是，当时我才疏学浅，并不能理解为什么这样做。

数据采集

采集第一式 —— Image Beacon

尽管云龙的文章已经发布了四年，第 12 届 D2 大会也过去了两年，时至今日，new Image 的方法仍然还是业界的普遍实践。

这种方式有一个术语叫 Image Beacon，翻译过来是「图片信标」。

这个方案有什么优点呢？

不会有跨域问题
不占用请求限额
不会阻塞页面加载
常用的 1x1 像素 GIF 大小只有 43B，甚至可以直接返回 204 No Content 节省网络请求开支
有完整的 HTTP 请求和响应（可以监听 onerror 或者 onload 事件）

采集第二式 —— Web Beacon API

navigator 下提供了专门用于数据采集的 sendBeacon，这个方法是异步非阻塞的，从而最大限度地减少与其它关键操作的资源抢占。目前，Google Analytics 现在用的就是这种方式。

它的使用方法很简单。

navigator.sendBeacon('/log', data);

CanIUse 中 sendBeacon 的兼容性统计

根据 CanIUse 的统计，这个 API 仅在 iOS 11.2 和 Android 4.4.4 以上版本才支持。这是一个比较相对比较苛刻的要求，所以采用这种方案时需要进行降级处理。

埋点

埋点第一式 —— 主动触发上报

这个很好理解，调用数据采集的 SDK 或者库函数中的发送接口直接发送数据。

「主动触发上报」的优点是可以精准控制，并且能够更方便地自定义上报的内容。当然，它的缺点也很明显，每一处埋点都需要增加相应的代码，侵入性强，更新埋点方案时代价也很高。

埋点第二式 —— 标签埋点

「标签埋点」通常借助 HTML 的 data-* 属性，与「主动触发上报」最大的不同体现在侵入性上。

这是一种很常见的用法，比如在淘宝首页上你就能找到很多具有 data-spm 属性的 HTML 标签。

比如，在下面的例子中，我们可以在 SDK 中对 data-higo-* 的所有属性集中处理。

<div data-higo-goods="111"></div>
<div data-higo-goods="222"></div>
<div data-higo-collection="333"></div>
<div data-higo-video="111"></div>

本质上是将业务代码转移到了 SDK 中，降低一些侵入性。

埋点第三式 —— 无埋点

无埋点方案的核心思想是尽可能收集所有的操作数据，然后在通过数据分析平台配置哪些数据需要在系统里面进行分析。

这种方式可以解决数据的「回溯」问题，因为所有分析用到的数据在一开始就已经完全收集，无论之后怎么调整分析的指标，都可以应用到之前的数据中。这是其它埋点方案所不具备的。

这种方式的缺陷也很明显，由于收集的信息较多，将会占用更多的传输带宽。同时，它也不能灵活地自定义属性。

云龙有一句话我特别认同。

性能问题一定是一个工程问题和统计问题。

而统计，恰恰是我们目前所欠缺的。期待我们拥有更加全面的前端监控体系。