在线上项目中,需要统计产品中用户行为和使用情况，从而可以从用户和产品的角度去了解用户群体，从而升级和迭代产品，使其更加贴近用户。用户行为数据可以通过前端数据监控的方式获得，除此之外，前端还需要实现性能监控和异常监控。性能监控包括首屏加载时间、白屏时间、http请求时间和http响应时间。异常监控包括前端脚本执行报错等。
实现前端监控有三个步骤：前端埋点和上报、数据处理和数据分析。
什么是埋点？
百度原话：埋点分析，是网站分析的一种常用的数据采集方法
其实通俗的讲前端埋点主要是为了运营以及开发人员采集用户行为数据，以及页面性能等数进行后续的数据分析，举一些例子：比如，拿到页面在各种网络下的加载时间，再比如拿到用户在某个页面的停留时间！
埋点的目的是什么？
获取用户行为以及跟踪产品在用户端的使用情况，并以监控数据为基础，指明产品优化的方向。
前端监控
前端监控可以分为三类：数据监控、性能监控和异常监控。下面我们来一一的了解。
数据监控
数据监控，顾名思义就是监听用户的行为。常见的数据监控包括：
- PV访问来量（Page View）
- UV访问数（Unique Visitor）
- 记录操作系统和浏览器
- 记录用户在页面的停留时间
- 用户在相应的页面中触发的行为
- 用户通过什么入口来访问该网页
统计这些数据是有意义的，比如我们知道了用户来源的渠道，可以促进产品的推广，知道用户在每一个页面停留的时间，可以针对停留较长的页面，增加广告推送等等。
性能监控
性能监控指的是监听前端的性能，主要包括监听网页或者说产品在用户端的体验。常见的性能监控数据包括：
- 不同用户，不同机型和不同系统下的首屏加载时间
- 白屏时间
- http等请求的响应时间
- 静态资源整体下载时间
- 页面渲染时间
- 页面交互动画完成时间
这些性能监控的结果，可以展示前端性能的好坏，根据性能监测的结果可以进一步的去优化前端性能，比如兼容低版本浏览器的动画效果，加快首屏加载等等。
异常监控
此外，产品的前端代码在执行过程中也会发生异常，因此需要引入异常监控。及时的上报异常情况，可以避免线上故障的发上。虽然大部分异常可以通过try catch的方式捕获，但是比如内存泄漏以及其他偶现的异常难以捕获。常见的需要监控的异常包括：
- Javascript的异常监控
- 样式丢失的异常监控
如何埋点?
在上一节中介绍了前端监控的作用，那么如何实现前端监控呢，实现前端监控的步骤为：前端埋点和上报、数据处理和数据分析。首要的步骤就是前端埋点和上报，也就是数据的收集阶段。数据收集的丰富性和准确性会影响对产品线上效果的判别结果。
目前常见的前端埋点方法分为三种：手动埋点、可视化埋点和无痕埋点。下面一一介绍每一种埋点的方法。
手动埋点
手动埋点，也叫代码埋点，即纯手动写代码。调用埋点 SDK 的函数，在需要埋点的业务逻辑功能位置调用接口，上报埋点数据，像友盟、百度统计等第三方数据统计服务商大都采用这种方案。
手动埋点让使用者可以方便地设置自定义属性、自定义事件；所以当你需要深入下钻，并精细化自定义分析时，比较适合使用手动埋点。
手动埋点的缺陷就是，项目工程量大，需要埋点的位置太多，而且需要产品开发运营之间相互反复沟通，容易出现手动差错，如果错误，重新埋点的成本也很高。这会导致整个数据收集周期变的很长，收集成本变的很高，而且效率很低。因为手动埋点需要开发人员完成，所以每次有埋点更新，或者漏埋点，都需要重新走上线发布流程，更新成本也高，对线上系统稳定性也有一定危害。
可视化埋点
可视化埋点，也叫框架式埋点、无痕埋点。解决了纯手动埋点的开发成本和更新成本，通过可视化工具快速配置采集节点（圈点），在前端自动解析配置，并根据配置上传埋点数据，比起手动埋点看起来更无痕，这里的配置数据可以设置过滤条件，避免针对所有元素（比如全埋点），可以在调用开启自动监控API时通过设置一些特征属性，来过滤不符合条件的元素，实现只针对某些元素进行自动上报数据的需求。
比如国外比较早做可视化的是Mixpanel，国内较早支持可视化埋点的有TalkingData、诸葛IO，2017年腾讯的MTA也宣布支持可视化埋点；相比于手动埋点更新困难，埋点成本高的问题，可视化埋点优化了移动运营中数据采集的流程，能够支持产品运营随时调整埋点，无需再走发版流程，直接把配置结果推入到前端，数据采集流程更简化，也更方便产品的迭代。
可视化埋点配置化能力相对手动埋点更强，是对手动埋点的补充而不是代替，很多手动埋点点都可以通过好的规划和架构变为可视化埋点。
无埋点
无埋点，也叫自动埋点、全埋点。无埋点并不是没有任何埋点，所谓"无"只是不需要工程师在业务代码里面插入侵入式的代码。只需要简单的加载了一段定义好的SDK代码，技术门槛更低，使用与部署也简单，避免了需求变更，埋点错误导致的重新埋点。
无埋点的优点：
- 由于采集的是全量数据，所以产品迭代过程中是不需要关注埋点逻辑的，也不会出现漏埋、误埋等现象
缺点：
- 无埋点采集全量数据，给数据传输和服务器增加压力
- 无法灵活的定制各个事件所需要上传的数据
埋点方案比较
根据工作中对埋点的对比和整理，我们简单比较部分埋点方案：
对于语义明确的UI事件，自动埋点的数据一般会比手动埋点更加准确，更贴近真正的用户行为，也更节省开发成本，侵入性更低。
主要是因为自动埋点语义简单明确，不像手动埋点由于开发习惯、代码风格、人的理解误差、分支处理等各种不确定因素变得没那么清晰明了。
自动埋点可降低原来手动埋点的个数和复杂性，使之更简化。
比如：进入“商品详情页面”（展现），目前包括5个手动埋点，实际上用自动埋点只需要一个就够了，而且自动埋点不会遗漏。从数据来看，一个自动埋点的PV已经超过5个手动埋点之和。
自动埋点可采集界面环境数据，但是数据不够纯，需要进一步去噪
自动埋点能采集到大部分用户“看到的而且有用数据”。比如：“价格”这一属性，手动埋点可直接定义“amout: 5.2“来轻松获取数据，而自动埋点获取的是一串文本： “价格预估5.2元”，若要获取精确的5.2这个数值，就需要进一步解析。
自动埋点无法替代手动埋点，但可大大减少手动埋点工作量可预想的是，在用户行为分析上，自动埋点可以满足很大一部分需求函数级的埋点无法用自动埋点代替，后台非UI的事件也无法用自动埋点代替，自动埋点无法携带当时的业务场景数据，这些都表明了自动埋点无法完全替代手动埋点。
但单就用户行为分析来讲，自动埋点是可以覆盖用户的一些基本行为路径的，并能做一些较浅层次的分析。如果需要探究用户行为背后的原因、或需要进一步深入分析行为的时候，就是需要更多的后台逻辑事件、需要携带更多属性值的时候，就需要通过手动埋点来完成。所以，但是深层次的分析是你的重点，就需要使用手动埋点来解决。
埋点类型虽然当前也就这几类解决方案，而且真实的使用请求会根据业务混合使用多种埋点类型。但是我们除了选择好埋点类型外，要展开埋点工作，面临的沟通协调，如何准确多团队达成共识，并确保各方对业务和埋点深度理解，做要的工作和面临的挑战会更大。想要做好埋点工作，埋点需求的整理很重要，且需要遵守一定的原则。
埋点需求整理原则
原则是基于一系列问题展开，并基于这些问题确定埋点需求，我作为FE的RD，针对这些原则，虽然至今也没有真正全面的做到，但是如果遵循这些原则，将会受益良多（也欢迎大家补充问题内容），当你能清楚的回答这些问题，埋点工作将会更顺利的开展：
HOW LONG
- 埋点可用周期是多久，持续几个版本可以？
- 生命周期结束后是否可以考虑下掉？
HOW MUCH
- 现有的埋点哪些可以满足我的部分埋点需求？
- 哪些现有的埋点可以替代我要的部分埋点？
- 新的埋点有多少？这些埋点是否是最必要的？
HOW
- 怎样证明新功能效果？
- 需要哪些埋点？
- 我该怎么埋这些点？
- 部分埋点的计算逻辑是什么？
- 数据结果怎么看？漏斗？同环比？
WHO
- 我的产品设计面对的用户群里是谁？
- 用户特征是什么？
- 这部分特征用户对功能预期的数据结果是什么？
- 用户习惯是什么？
WHAT
- 我的新产品是什么？
- 新产品包含哪几个模块？
WHY
- 涉及新产品的目的是什么，为了解决什么问题？
WHERE
- 新功能展示在产品端的哪个位置？
- 在哪些版本生效？
- 哪些功能的展示或作用在哪里需要跟服务端等交互？
WHEN
- 功能是在用户场景什么时候调用产生？
- 调用过程中什么时候和服务端交互？
- 功能调用正常情况下需要大概需要多长时间？
- 什么情况会影响调用结果？
- 调用有风险的时候，是否需要加监测？
埋点规范
清楚了埋点的思路，要让埋点顺利进行，且不影响线上功能，则需求严格的埋点规范和治理方案。
埋点命名规范
我们当前的做法是埋点名称只能是由字母、数字、下划线组成，并保证在应用内唯一，比如sw是展示，ck是点击。
常用规则的举例如下：
比如行为埋点：{团队|业务|角色}_{组件|页面}_{具体元素}_{动作}
示例：
yourteam_fc_all_msg_ck
autoplatform_flowtab_sw ： autoplatform代表业务线，flowtab 代表功能，sw代表页面操作，sw是展示，ck是点击
uber_comt_share_ck ：uber业务线，comt评价组件，share分享按钮，ck点击
埋点流程规范
如果你发现每天有大量埋点错误反馈，并导致很多错误的分析结论，一个错误的分析结果还不如没有数据分析结果。造成这个问题的原因包括：
前端埋点涉及复杂的交互，难以找准埋点位置；
埋点的验收流程不完善，没有经过测试和产品经理的测试和验收，验证不完备；
好的埋点需求应该和业务功能需求同等重要，也需要经历软件开发的整个生命周期，如果能严格按照一个规范的流程处理埋点，以上问题会得到更好的解决。
注意事项
一些埋点安全性问题：
如果你使用普通的http 协议，在数据传输的过程存在被劫持(包括不限于：JS代码注入等)的可能性，造成H5页面中出现诸如：未知的广告或者原网页被重定向等问题。为了降低此类事件发生的可能性，建议最好使用https 协议（倡导全站https），以确保数据传输过程的完整性，安全性。
版本迭代的时候埋点需要注意什么？
- 如果是公用模块，可以非常放心安全的全量迁移埋点；
- 如果是新增模块，那就需要注意是否遵循了最新的埋点规范，有没有重复的埋点命名存在，埋点是否符合业务逻辑；
- 如果是下线模块，那就需要评估下线后对数据的影响范围，而且要第一时间充分周知相关方，让各方参与评估；
- 如果是更新模块，需要评估在原有埋点上需要修改的埋点内容，是否需要重新埋点，删除不需要的埋点，而且要修改功能的数据承接。
参考文档：
[基于指令和混合的前端通用埋点方案]
[前端监控和前端埋点方案设计]
[前端埋点统计方案思考]
[前端埋点总结]
[前端监控和前端埋点方案概述]
[美团点评前端无痕埋点实践]
[去大厂，你就应该了解前端监控和埋点!]