微梦 - 邪少个人博客首先了解一下为什么需要前端埋点监控
前端监控的目的是：
获取用户行为以及跟踪产品在用户端的使用情况，并以监控数据为基础，指明产品优化的方向。
前端监控可以分为三类：数据监控、性能监控和异常监控。
(1)数据监控
数据监控，顾名思义就是监听用户的行为。常见的数据监控包括：
- PV/UV:PV(page view)，即页面浏览量或点击量。UV:指访问某个站点或点击某条新闻的不同IP地址的人数
- 用户在每一个页面的停留时间
- 用户通过什么入口来访问该网页
- 用户在相应的页面中触发的行为
统计这些数据是有意义的，比如我们知道了用户来源的渠道，可以促进产品的推广，知道用户在每一个页面停留的时间，可以针对停留较长的页面，增加广告推送等等。
(2)性能监控
性能监控指的是监听前端的性能，主要包括监听网页或者说产品在用户端的体验。常见的性能监控数据包括：
- 不同用户，不同机型和不同系统下的首屏加载时间
- 白屏时间
- http等请求的响应时间
- 静态资源整体下载时间
- 页面渲染时间
- 页面交互动画完成时间
这些性能监控的结果，可以展示前端性能的好坏，根据性能监测的结果可以进一步的去优化前端性能，比如兼容低版本浏览器的动画效果，加快首屏加载等等。
(3)异常监控
此外，产品的前端代码在执行过程中也会发生异常，因此需要引入异常监控。及时的上报异常情况，可以避免线上故障的发上。虽然大部分异常可以通过try catch的方式捕获，但是比如内存泄漏以及其他偶现的异常难以捕获。常见的需要监控的异常包括：
- Javascript的异常监控
- 样式丢失的异常监控
常用前端埋点方案总结
如何实现前端监控，实现前端监控的步骤为：前端埋点和上报、数据处理和数据分析。首要的步骤就是前端埋点和上报，也就是数据的收集阶段。数据收集的丰富性和准确性会影响对产品线上效果的判别结果。
目前常见的前端埋点方法分为三种：代码埋点、可视化埋点和无痕埋点。下面一一介绍每一种埋点的方法。
(1) 代码埋点
代码埋点，就是以嵌入代码的形式进行埋点，比如需要监控用户的点击事件，会选择在用户点击时，插入一段代码，保存这个监听行为或者直接将监听行为以某一种数据格式直接传递给server端。此外比如需要统计产品的PV和UV的时候，需要在网页的初始化时，发送用户的访问信息等。
代码埋点的优点：
- 可以在任意时刻，精确的发送或保存所需要的数据信息。
缺点：
- 工作量较大，每一个组件的埋点都需要添加相应的代码
(2)可视化埋点
通过可视化交互的手段，代替代码埋点。将业务代码和埋点代码分离，提供一个可视化交互的页面，输入为业务代码，通过这个可视化系统，可以在业务代码中自定义的增加埋点事件等等，最后输出的代码耦合了业务代码和埋点代码。
可视化埋点听起来比较高大上，实际上跟代码埋点还是区别不大。也就是用一个系统来实现手动插入代码埋点的过程。
缺点：
- 可视化埋点可以埋点的控件有限，不能手动定制。
(3)无埋点
无埋点并不是说不需要埋点，而是全部埋点，前端的任意一个事件都被绑定一个标识，所有的事件都别记录下来。通过定期上传记录文件，配合文件解析，解析出来我们想要的数据，并生成可视化报告供专业人员分析因此实现“无埋点”统计。
从语言层面实现无埋点也很简单，比如从页面的js代码中，找出dom上被绑定的事件，然后进行全埋点。
无埋点的优点：
- 由于采集的是全量数据，所以产品迭代过程中是不需要关注埋点逻辑的，也不会出现漏埋、误埋等现象
缺点：
- 无埋点采集全量数据，给数据传输和服务器增加压力
- 无法灵活的定制各个事件所需要上传的数据
三、前端埋点方案选型和前端上报方案设计
第一章中介绍了前端所需要监听的信息，在第二章中介绍了前端埋点的常见方式，本文来根据需求，来定制我们的埋点和上报方案。
(1)监控数据
首先我们需要明确一个产品或者网页，普遍需要监控和上报的数据。监控的分为三个阶段：用户进入网页首页、用户在网页内部交互和交互中报错。每一个阶段需要监控和上报的数据如下图所示：
(2)埋点方案
在实际项目中考虑到上报数据的灵活定制，以及减少数据传输和服务器的压力，在所需埋点处不多的情况下，常用的方式是代码埋点。
以用户进入首页为例，我们在首页渲染完成后会发送事件类型和类型相关的数据给server端，告知首页的监控信息。
(3)上报周期和上报数据类型
如果埋点的事件不是很多，上报可以时时进行，比如监控用户的交互事件，可以在用户触发事件后，立刻上报用户所触发的事件类型。如果埋点的事件较多，或者说网页内部交互频繁，可以通过本地存储的方式先缓存上报信息，然后定期上报。
接着来确定需要埋点上报的数据，上报的信息包括用户个人信息以及用户行为，主要数据可以分为：
- who: appid(系统或者应用的id),userAgent(用户的系统、网络等信息)
- when: timestamp(上报的时间戳)
- from where: currentUrl(用户当前url)，fromUrl(从哪一个页面跳转到当前页面)，type(上报的事件类型),element(触发上报事件的元素）
- what: 上报的自定义扩展数据data:{},扩展数据中可以按需求定制，比如包含uid等信息
前端如何实现全局 PV 统计，以 Vue 应用为例。
方案一
通过在入口文件 index.js 全局定义 Router.beforeEach：
import App from './app'
import Router from './router'
Router.beforeEach((to, from, next) => {
App.logEvent({
type: 'visit',
name: to.name,
time: new Date().valueOf(),
params: {
from: {
name: from.name,
path: from.path,
query: from.query
},
to: {
name: to.name,
path: to.path,
query: to.query
}
}
})
next()
})停留时长可通过 （跳转页 time – 当前页 time） 获知，但关闭应用时如何统计？监听应用关闭 onbeforeunload + onunload？
其中 App.logEvent 为自定义 Vue 插件 App 中的 method，用于向服务器发起 埋点上报请求：
import Request from './utils/request'
const App = {
// ...
logEvent (opts) {
Request({
url: '/log/event',
method: 'POST',
data: {
type: opts.type,
name: opts.name,
time: opts.time,
params: opts.params || {}
}
})
}
}
App.install = (Vue, options) => {
Vue.prototype.$app = {
// ...
logEvent: App.logEvent
}
}
export default App方案二
通过在入口文件 index.js 全局注册混入 beforeRouteEnter、beforeRouteLeave 对象：
import Vue from 'vue'
Vue.mixin({
beforeRouteEnter (to, from, next) {
next(vm => {
vm.$app.logEvent({
type: 'visit',
name: to.name,
time: new Date().valueOf(),
params: {
from: {
name: from.name,
path: from.path,
query: from.query
},
to: {
name: to.name,
path: to.path,
query: to.query
}
}
})
})
},
beforeRouteLeave (to, from, next) {
this.$app.logEvent({
type: 'visit',
name: to.name,
time: new Date().valueOf(),
params: {
from: {
name: from.name,
path: from.path,
query: from.query
},
to: {
name: to.name,
path: to.path,
query: to.query
}
}
})
next()
}
})关闭应用时 beforeRouteLeave 是否触发？
上述方案存在明显缺陷：
- 官方曰慎用全局混入对象！！！
- 对于页面同名钩子函数 beforeRouteEnter、beforeRouteLeave，如何 merge？如何 next？
- 含子路由的页面将调用 2 次 beforeRouteEnter、beforeRouteLeave，PV 无形翻倍…
我猜此刻有打全局混入 created、destroyed 并通过 this.$route 获知访问对象主意的人了，试试看？
令人不知所措的输出，打印次数与 路由表 长度一致嗷~
其中 this.$app.logEvent（vm.$app.logEvent） 等同方案一中 App.logEvent，不再赘述。
如何恰当选取全局 PV 统计方案？
- SPA 应用：仅单入口，在入口文件全局定义 Router.beforeEach 方便可行。
- MPA 应用：多入口，在每个入口文件定义 Router.beforeEach？可封装公用逻辑（伪装单入口），免去重复构造 entry 的成本。
- SPA + MPA 混合应用：emmmmmm…采用 MPA 应用的统计方案。
- SSR 应用：为追求更好的 SEO 而采用服务端渲染（SSR）。以 Jinja（Python 模板）为例，调用 TemplateView 则为渲染页面（不同于前后端分离项目，服务端无法获知接口调用与页面渲染的对应关系），统计其调用次数及 TemplateName 可知页面 PV。
至于 UV，统计 PV 时采集 userId 去重即可。若应用无用户管理体系，采集 IP、deviceId 也可粗略得知 UV（不精准）。
功能点击量统计
不同功能的点击量不同，同一功能不同区域的点击量也不同：
按钮点击量，影响因素包含按钮 外观、位置、入口 等等（在此不考虑刚需）。按钮外观属 UI 设计范畴，按钮位置可通过分析用户点击热力图调整，按钮入口可通过分析触发源分布调整。
举一实例：
运营同学会将一张图片裁切成 n 个区域，点击每一区域所推荐商品不同。统计区域点击坐标，据热力图调整商品排序以求 利益最大化。
前端如何实现功能点击量统计？
本人将功能点击分两类：
- 带业务接口请求
- 无业务接口请求
方案一
将埋点上报混入业务接口请求，无接口请求的点击采用自定义上报：
其中 param keys 指代需上报的业务请求参数 key list（并非全部参数均需随埋点上报）。
上述方案大大节约请求数，但存在明显缺陷：
- 将埋点上报混入业务接口，上报 crash 不仅丢失统计数据，还将影响主功能。
- 统计与业务 高耦合，两者尽量不混于同一服务。
方案二
将所有点击事件视为同一类，走统一上报接口：
logEvent (opts) {
Request({
url: '/log/event',
method: 'POST',
data: {
type: opts.type,
name: opts.name,
time: opts.time,
params: opts.params || {}
}
})
}上述方案也存在明显缺陷：
- 请求量翻倍：但统计与业务服务拆分后，请求并非同一组服务器承担。
- 待上报的点击事件函数均需调用 logEvent：封装一枚附带埋点上报的 组件，以 Vue 为例。
<template>
<div class="vc-trace" @click="triggerClick">
<slot></slot>
</div>
</template>
<script>
import Request from './utils/request'
export default {
name: 'Trace',
props: {
type: {
type: String,
default: ''
},
name: {
type: String,
default: ''
},
from: {
type: String,
default: ''
},
params: {
type: Object,
default: () => ({})
}
},
methods: {
triggerClick () {
Request({
url: 'XXX/log/event',
method: 'POST',
data: {
type: this.type,
name: this.name,
from: this.from,
time: new Date().valueOf(),
params: this.params
}
})
}
}
}
</script>方案本无优劣，适合才更重要，需综合考虑 产品设计、产品使用度、服务利用率 等等。例使用度较低应用可将统计与业务混于同一服务以节约成本，使用度较高应用可采取 本地缓存、批量上报 以降低服务压力，但批量上报是否加大统计 误差？
