阅读 674

前端监控与埋点

97d3d85197695390f108cb2343706beb
前端小兵,不吝赐教

背景

在线上项目中,我们需要统计下用户在使用该产品的行为与使用情况,通过这些统计数据进行处理与分析,从用户的角度去了解该产品的使用与体验,从而更好的进行产品的迭代与升级,更加符合用户的体验,更加贴近用户使用习惯。 因此,我们在业务中需要添加一些用户行为统计的需求,如:

  • 收集用户在页面的浏览量或点击量
  • 访问某个站点不同 IP 的人数
  • 用户在页面中停留的时间
  • 用户在页面中触发的行为
  • 用户滚屏行为

这些都是用户数据的统计点,这也是前端数据监控的着重点。除了数据监控,前端监测还包括了性能监控和异常监控。性能监控有以下:

  • 首屏加载时间
  • 白屏加载时间
  • http 响应时间
  • 资源下载整体时间
  • 页面渲染时间
  • 页面交互动画完成时间

异常监控包括了:监控脚本异常与样式异常。

为什么需要前端监控

埋点就是用户数据的采集,获取用户行为以及跟踪产品用户体验情况。 埋点后,将收集到的用户数据进行监控及处理,并以之为基础,指明产品优化的方向,是产品需求的来源,检验功能是否达到预期的佐证。 数据采集与上报是整个流程中的重要一环,只有确保前端数据生产的全面、准确、及时,最终的数据结果才是可靠的、有价值的。

前端监控分为三种:数据监控、性能监控、异常监控。如下图所示:

20190626132331

数据监控可以知道用户的来源,可以促进产品的推广,知道用户在页面中停留的时间,可以针对停留较长时间的页面进行广告推送等,增加推广源。

性能监控可以让开发人员更好的对产品进行有效的优化操作,增强用户体验。

异常监控可以及时上报异常情况,可以避免线上故障的发生与减少故障带来的损失。

常见工作流程如下:

image

前端数据采集

前端数据采集也就是前端埋点和上报,前端埋点方法有三种:代码埋点,可视化埋点和无痕埋点。 埋点的技术实质,是先监听软件应用运行过程中的事件,当需要关注的事件发生时进行判断和捕获。

代码埋点

代码埋点就是以嵌入代码的形式进行埋点,例如用户通过点击事件触发某个接口调用,我们就可以在点击调用的接口中,插入一段代码或者传入某些参数,将数据直接传递给服务端。 如:

  • 在用户登录应用时,可以将用户信息传送到服务器,统计该用户的登录次数,或者其他信息。
  • 在用户点击跳转某个页面时,可以将 from, to 路由地址传输给服务器进行统计,可以清楚知道用户的访问轨迹

优点:可以在任意时刻,精确的发送或保存所需要的数据信息。

缺点:工作量大,每个组件的埋点代码都需要相对应的添加。

{
    ----------------接口本身提供----------------
    currentUrl,
    fromUrl,
    timestamp,
    userAgent:{
       os,
       netWord,
    }
    ----------------业务代码配置和自定义上报数据----------------
    type,
    appid,
    data:{
        uid,
        uname
    },
    ...
}
复制代码

可视化埋点

通过可视化工具配置采集节点,在前端自动解析配置并上报埋点数据,从而实现所谓的“无痕埋点”,代表方案是已经开源的 Mixpanel,可以从 这篇文章 了解 Mixpanel 的使用。

优点:埋点只需业务同学接入监控,无需在开发中插入代码。

缺点:可配置组件有限,不能手动定制,只有可视化工具提供。

无埋点

无埋点不是说不需要埋点,而是所有的前端事件都被绑定一个标识,通过这个标识把所有有关的事件都记录下来,不需要开发人员添加额外代码。 通过定义上传记录文件,配合解析文件,将数据变成我们想要的数据,并由数据分析人员进行分析实现无埋点统计,代表方案是国内的 GrowingIO。 GrowingIO 并不是免费的,在开发测试可以有一个免费的账号使用,如果项目正式上线后就需要收费了。

优点:无需开发,业务人员埋点即可;先上报,后埋点。

缺点:sdk 开发人员需提供一套无痕埋点技术成品,包括能正确获取 PV,UV,Action,Time 等多项统计指标。前期技术投入大。

无埋点和可视化埋点均不需要开发支持,仅数据业务同学进行设置即可。但两者数据上报-埋点设置存在较大的差异:无埋点支持在数据上报之后再进行埋点设置,因而数据采集与上报的量远远大于可视化埋点。

何时进行监控

介绍了上面三种埋点方式,那我们在产品项目中如何去运用呢?什么时候进行埋点,什么地方进行监控呢?

其实监控时间分为三部分:

  • 用户进入应用初始化
  • 用户在应用中的交互与交互后的响应
  • 用户在应用中所触发捕获的错误

20190702100536

如何设计监控

如何设计我们产品所需要监控的数据? 我们需要考虑 Web 端真实用户体验数据,从访问速度、页面运行稳定性和服务调用成功率三个方面监控前端的健康度,来不断的升级迭代我们的产品。

可通过以下几个方面进行细分:

  • 页面性能日志:网络请求耗时、DOM 解析耗时、资源加载耗时、白屏时间、页面完全加载时间等...

  • 访问统计日志:统计 PV、UV 数据

  • 页面稳定性日志:监控页面脚本的错误率来衡量页面的稳定性

  • 接口调用日志:提供接口调用结果及耗时等相关信息,可以让开发人员快速发现并定位出错的问题

  • 自定义上报日志

如何优化监控数据的上报

在添加完监控数据后,可能会增加接口请求或者页面渲染的压力,这时我们就需要优化我们的前端监控代码或者请求的接口。

HTTP No Content

有的日志上报只关心日志是否有上报,而不关心上报的数据,如:监控用户点击某个按钮触发次数,这个我们只要上报服务器一个事件即可,完全不需要有返回内容。所以我们使用 HTTP HEAD 上报的方式,可以避免响应体响应数据而造成的资源损耗,只要有一个请求状态码记录就可以。

fetch(`${url}?t=click&page=foo&target=btn`, {
  mode: "no-cors",
  method: "HEAD",
});
复制代码

HTTP 2.0

HTTP 2.0 头部压缩

每次的 HTPP 请求中都会携带一些相同的请求资源及特性,如 HOST、user-agent、Accept 等。这些数据占用 300-800 byte 的传输量,如果还携带 cookie ,请求头可能占据 1 kb 的空间,而实际所需要上报的日志数据仅占 50 byte。 在 HTTP 1.x 中,每次日志上报请求头都携带了大量的重复数据导致性能浪费。

而 HTTP/2 头部压缩采用 Huffman Code 压缩请求头,并用动态表更新每次请求不同的数据,从而将每次请求的头部压缩到很小。

HTTP/1.1

http1 x

HTTP2

http2

HTTP 2.0 多路复用

用户浏览器和日志服务器之间产生多次 HTTP 请求,而在 HTTP/1.1 Keep-Alive 下,日志上报会以串行的方式传输,并让后面的日志上报延时。

http1单路

然而 HTTP 2.0 使用了多路复用,能够合并上报,节省网络链接开销。

http2多路复用

总结

在本文中介绍了以下几点:

  • 什么是前端监控:统计用户在使用该产品的行为与使用情况
  • 为什么需要前端监控:更好的进行产品的迭代与升级,指明产品优化的方向,检验功能是否达到预期
  • 何时进行前端监控:用户在进入应用、用户在应用中的交互以及用户在交互中的报错
  • 如何设计监控:以页面性能、访问量、页面稳定性、接口调用情况等方向入手
  • 如何优化监控与数据上报:只传请求头部,无需返回值;采用 HTTP 2.0 的头部压缩与多路复用特性

在设计前端监控时,我们需要多方面去考量,在不影响业务性能的前提下,完成我们的监控。 即使是在业务访问量较大或者性能要求较高的情况下,我们也需要做好前端监控,这是我们产品开发与迭代必不可少的一部分,也是我们产品提升与自我佐证的方法之一。

参考资料

站在巨人的肩膀上看得更远

关注下面的标签,发现更多相似文章
评论