前端埋点统计方案思考

埋点即监控用户在应用表现层的行为，于产品迭代而言至关重要。埋点数据分析是产品需求的来源，检验功能是否达预期的佐证。前端较服务端更接近用户，本小白将在此对前端埋点统计方案述说一二。

采集埋点数据可做如下分析（以百度统计为例）：

将 用户属性 、 用户行为 转化各类可视化图表：

不同产品对数据的关注角度不同，可按需采集。如信息流产品对停留时长的关注度更高（统计页面访问 & 跳出时间），商城类较注重“复购率”（统计新老用户），广告类更追求最大限度。

埋点统计通常分两类：

页面访问量统计
功能点击量统计

页面访问量统计

页面访问量统计通常分两类：

PV ：页面访问人次
UV ：页面访问人数

页面访问量，并非仅仅取决于其内容吸引力，影响因素包含入口外观、位置、深度等等（在此不考虑刚需）。入口外观属 UI 设计范畴，入口位置可通过分析用户点击热力图调整，入口深度可通过分析用户访问路径调整。

用户点击 热力图 形如：

将核心页面入口置于热力图红色区域？

采集页面加载 from 、 to 以获知用户访问路径：

分析可知用户普遍 访问深度 、每一深度 & 每一页面的 流失率 等，依照结果调整核心页面入口源、入口深度？

页面访问量，也并非仅仅取决于产品设计。假若 PV 稳定的页面访问量爆跌，便需考虑其加载成功率了（或许是枚技术 bug）。

前端如何实现全局 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>

方案本无优劣，适合才更重要，需综合考虑 产品设计 、 产品使用度 、 服务利用率 等等。例使用度较低应用可将统计与业务混于同一服务以节约成本，使用度较高应用可采取 本地缓存 、 批量上报 以降低服务压力，但批量上报是否加大统计误差？

本文所述仅冰山一角，欢迎大家留言宝贵经验~