前端监控与前端埋点方案
https://blog.csdn.net/sinat_36521655/article/details/114650138
用户行为数据可以通过前端数据监控的方式获得,除此之外,前端还需要实现**性能监控和异常监控。**性能监控包括首屏加载时间、白屏时间、http请求时间和http响应时间。异常监控包括前端脚本执行报错等。
前端监控的目的是:
获取用户行为以及跟踪产品在用户端的使用情况,并以监控数据为基础指明产品优化的方向。
前端监控可以分为三类:数据监控、性能监控和异常监控。
「前端监控的种类」
(1) 数据监控
数据监控,顾名思义就是监听用户的行为。常见的数据监控包括:
- PV/UV:PV(page view),即页面浏览量或点击量。UV:指访问某个站点或点击某条新闻的不同IP地址的人数
- 用户在每一个页面的停留时间
- 用户通过什么入口来访问该网页
- 用户在相应的页面中触发的行为
统计这些数据是有意义的,比如我们知道了用户来源的渠道,可以促进产品的推广,知道用户在每一个页面停留的时间,可以针对停留较长的页面,增加广告推送等等。
(2) 性能监控
性能监控指的是监听前端的性能,主要包括监听网页或者说产品在用户端的体验。常见的性能监控数据包括:
- 不同用户,不同机型和不同系统下的首屏加载时间
- 白屏时间
- http等请求的响应时间
- 静态资源整体下载时间
- 页面渲染时间
- 页面交互动画完成时间
这些性能监控的结果,可以展示前端性能的好坏,根据性能监测的结果可以进一步的去优化前端性能,比如兼容低版本浏览器的动画效果,加快首屏加载等等。
(3) 异常监控
此外,产品的前端代码在执行过程中也会发生异常,因此需要引入异常监控。及时的上报异常情况,可以避免线上故障的发上。虽然大部分异常可以通过try catch的方式捕获,但是比如内存泄漏以及其他偶现的异常难以捕获。常见的需要监控的异常包括:
- Javascript的异常监控
- 样式丢失的异常监控
「前端埋点方案」
实现前端监控的步骤为:**前端埋点和上报、数据处理和数据分析。**首要的步骤就是前端埋点和上报,也就是数据的收集阶段。数据收集的丰富性和准确性会影响对产品线上效果的判别结果。
埋点,它的学名是事件追踪(Event Tracking),主要是针对特定用户行为或业务过程进行捕获、处理和发送的相关技术及实施过程。埋点是数据领域的一个专业术语,也是互联网领域的一个俗称。
埋点是产品数据分析的基础,一般用于推荐系统的反馈、用户行为的监控和分析、新功能或者运营活动效果的统计分析等。
埋点包含两个重要概念:事件(event),属性(param)
- 事件(event):应用中发生了什么,例如用户操作、系统事件或系统错误。以你拍一产品为例,包含以下事件:enter_page(进入页面)、leave_page(离开页面)
- 属性(param):为了描述用户群细分而定义的属性,例如语言偏好或地理位置。以“进入课后练习”事件为例,它包含如下事件属性:enter_from(从哪个页面来),class_id(课程id)等。
- 属性值(value):属性的维度,即行为触发时的具体维度。例如:enter_from:home(主页)、system(系统)等。
常见埋点事件
事件 | 上报时机 | 描述 |
---|---|---|
页面停留 | 当前页面切换或者页面卸载时 | 记录前一页浏览时间 |
pv | 进入页面时 | 页面访问次数,uv只需要根据deviceId过滤 |
交互事件 | 用户交互事件触发时 | 比如点击、长按等 |
逻辑事件 | 符合逻辑条件时 | 比如登陆、跳转页面等 |
常见埋点属性
属性 | 描述 |
---|---|
uid | 用户id,若用户未登陆,则返回特定标识id |
url | 当前事件触发页面的url |
eventTime | 触发埋点的时间戳 |
localTime | 触发埋点时的用户本地时间,使用标准YYYY-MM-DD HH:mm:ss格式表示,方便后期直接使用字符串查询 |
deviceType | 当前用户使用的设备类型,比如apple、三星、chrome等 |
deviceId | 当前用户使用的设备id |
osType | 当前用户使用的系统类型,比如windows、macos、ios、android等 |
osVersion | 当前用户使用的系统版本 |
appVersion | 当前应用版本 |
appId | 当前应用id |
extra | 自定义数据,一般是序列化的字符串,且数据结构应保持稳定 |
目前常见的前端埋点方法分为三种:代码埋点、可视化埋点和无痕埋点。
(1) 代码埋点
代码埋点,就是以嵌入代码的形式进行埋点,比如需要监控用户的点击事件,会选择在用户点击时,插入一段代码,保存这个监听行为或者直接将监听行为以某一种数据格式直接传递给server端。此外比如需要统计产品的PV和UV的时候,需要在网页的初始化时,发送用户的访问信息等。
代码埋点的优点:
- 可以在任意时刻,精确的发送或保存所需要的数据信息。
缺点:
- 工作量较大,每一个组件的埋点都需要添加相应的代码
(2) 可视化埋点
通过可视化交互的手段,代替代码埋点。将业务代码和埋点代码分离,提供一个可视化交互的页面,输入为业务代码,通过这个可视化系统,可以在业务代码中自定义的增加埋点事件等等,最后输出的代码耦合了业务代码和埋点代码。
可视化埋点听起来比较高大上,实际上跟代码埋点还是区别不大。也就是用一个系统来实现手动插入代码埋点的过程。
缺点:
- 可视化埋点可以埋点的控件有限,不能手动定制。
(3) 无埋点
无埋点并不是说不需要埋点,而是全部埋点,前端的任意一个事件都被绑定一个标识,所有的事件都别记录下来。通过定期上传记录文件,配合文件解析,解析出来我们想要的数据,并生成可视化报告供专业人员分析因此实现“无埋点”统计。
从语言层面实现无埋点也很简单,比如从页面的js代码中,找出dom上被绑定的事件,然后进行全埋点。
无埋点的优点:
- 由于采集的是全量数据,所以产品迭代过程中是不需要关注埋点逻辑的,也不会出现漏埋、误埋等现象
缺点:
- 无埋点采集全量数据,给数据传输和服务器增加压力
- 无法灵活的定制各个事件所需要上传的数据
「性能数据采集方案」
目前性能指标数据大部分来源于 window.performance API。
Performance.timing
常见性能指标
指标名 | 描述 |
---|---|
FP | 页面首次绘制时间 |
FCP | 页面首次有内容绘制的时间 |
FMP | 页面首次有效绘制时间,FMP >= FCP |
TTI | 页面完全可交互时间 |
FID | 页面加载阶段,用户首次交互操作的延时时间 |
MPFID | 页面加载阶段,用户交互操作可能遇到的最大延时时间 |
LOAD | 页面完全加载的时间(load 事件发生的时间) |