为什么大厂前端监控都在用GIF做埋点？(1)

它指的是通过一定的手段来获取用户行为以及跟踪产品在用户端的使用情况，并以监控数据为基础，为产品优化指明方向，为用户提供更加精确、完善的服务。

❞

前端监控

---

一般来讲一个成熟的产品，运营与产品团队需要关注用户在产品内的行为记录，通过用户的行为记录来优化产品，研发与测试团队则需要关注产品的性能以及异常，确保产品的性能体验以及安全迭代。

「所以前端监控一般也分为三大类：」

数据监控（监控用户行为）

• PV/UV: PV(page view)：即页面浏览量或点击量；UV（unique visitor）：指访问某个站点或点击某条新闻的不同 IP 地址的人数

• 用户在每一个页面的停留时间

• 用户通过什么入口来访问该网页

• 用户在相应的页面中触发的行为，等…

统计这些数据是有意义的，比如我们知道了用户来源的渠道，可以促进产品的推广，知道用户在每一个页面停留的时间，可以针对停留较长的页面，增加广告推送等等。

性能监控（监控页面性能）

• 不同用户，不同机型和不同系统下的首屏加载时间

• 白屏时间

• http 等请求的响应时间

• 静态资源整体下载时间

• 页面渲染时间

• 页面交互动画完成时间，等…

这些性能监控的结果，可以展示前端性能的好坏，根据性能监测的结果可以进一步的去优化前端性能，尽可能的提高用户体验。

异常监控（监控产品、系统异常）

及时的上报异常情况，可以避免线上故障的发上。虽然大部分异常可以通过 try catch 的方式捕获，但是比如内存泄漏以及其他偶现的异常难以捕获。常见的需要监控的异常包括：

• Javascript 的异常监控

• 样式丢失的异常监控

埋点上报

---

OK，上面我们说到了前端监控的三个分类，了解了一个产品需要监控哪些内容以及为什么需要监控这些内容，那么我们应该怎么实现前端监控呢？

实现前端监控，第一步肯定是将我们要监控的事项（数据）给收集起来，再提交给后台进行入库，最后再给数据分析组进行数据分析，最后处理好的数据再同步给运营或者是产品。数据收集的丰富性和准确性会直接影响到我们做前端监控的质量，因为我们会以此为基础，为产品的未来发展指引方向。

现在常见的埋点上报方法有三种：手动埋点、可视化埋点、无埋点

手动埋点

手动埋点，也叫代码埋点，即纯手动写代码，调用埋点 SDK 的函数，在需要埋点的业务逻辑功能位置调用接口，上报埋点数据，像**[友盟]、[百度统计]**等第三方数据统计服务商大都采用这种方案。手动埋点让使用者可以方便地设置自定义属性、自定义事件；所以当你需要深入下钻，并精细化自定义分析时，比较适合使用手动埋点。

手动埋点的缺陷就是，项目工程量大，需要埋点的位置太多，而且需要产品开发运营之间相互反复沟通，容易出现手动差错，如果错误，重新埋点的成本也很高。

可视化埋点

通过可视化交互的手段，代替上述的代码埋点。将业务代码和埋点代码分离，提供一个可视化交互的页面，输入为业务代码，通过这个可视化系统，可以在业务代码中自定义的增加埋点事件等等，最后输出的代码耦合了业务代码和埋点代码。

可视化埋点的缺陷就是可以埋点的控件有限，不能手动定制。

无埋点

无埋点则是前端自动采集全部事件，上报埋点数据，由后端来过滤和计算出有用的数据。优点是前端只要一次加载埋点脚本，缺点是流量和采集的数据过于庞大，服务器性能压力山大。

为什么都用GIF来做埋点？

---

发现过程

首先说一下我是怎么发现的，前一段时间，产品提了个需求，说我们现在的书籍曝光上报规范并不是他们想要的数据，并且以后所有页面的书籍上报都统一成最新规范。

曝光规范：

• 书籍出现在可视区并停留1秒，算作有效曝光

• 书籍不能重复曝光，假如它一直在可视区滚动时只能上报一次

• 当它移出可视区后再回到可视区，再按第一点进行曝光

OK，既然要所有页面统一，那就只能封装成通用库来使用了，这里实现逻辑就不贴了，想看的私聊我发你，主要的难点就是停留时长计算，以及曝光标记。

const exposeReportClass = new exposeReport({

scrollDom: “”,  // 滚动容器，建议指定一个滚动容器，不传默认为window

watchDom: “.bookitem”, // 监听的dom,建议使用class类，标签也支持

time: 1000             // 停留有效时长ms

});

// 提供两个上报方法

exposeReportClass.didReport(()=>{

// 手动上报

//callback

})

exposeReportClass.scrollReport(()=>{

// 滚动上报

//callback

})

//

具体业务逻辑之需要放在对应的callback里面，而上报逻辑开发者无需考虑，因为我底层已经统一处理好了。

然后我再测试的时候就发现，上报发的请求居然是通过图片发起的，并不是我们认为的接口上报。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Web前端开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上前端开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：前端）

结尾

正式学习前端大概 3 年多了，很早就想整理这个书单了，因为常常会有朋友问，前端该如何学习，学习前端该看哪些书，我就讲讲我学习的道路中看的一些书，虽然整理的书不多，但是每一本都是那种看一本就秒不绝口的感觉。

以下大部分是我看过的，或者说身边的人推荐的书籍，每一本我都有些相关的推荐语，如果你有看到更好的书欢迎推荐呀。

戳这里免费领取前端学习资料

bntDv8Z-1713641567319)]

结尾

正式学习前端大概 3 年多了，很早就想整理这个书单了，因为常常会有朋友问，前端该如何学习，学习前端该看哪些书，我就讲讲我学习的道路中看的一些书，虽然整理的书不多，但是每一本都是那种看一本就秒不绝口的感觉。

以下大部分是我看过的，或者说身边的人推荐的书籍，每一本我都有些相关的推荐语，如果你有看到更好的书欢迎推荐呀。

戳这里免费领取前端学习资料