前端埋点统计方案思考
栏目: JavaScript · 发布时间: 5年前
内容简介:埋点即监控用户在应用表现层的行为,于产品迭代而言至关重要。埋点数据分析是产品需求的采集埋点数据可做如下分析(以百度统计为例):
埋点即监控用户在应用表现层的行为,于产品迭代而言至关重要。埋点数据分析是产品需求的 来源 ,检验功能是否达预期的 佐证 。
采集埋点数据可做如下分析(以百度统计为例):
将 用户属性 、 用户行为 转化各类可视化图表:
不同产品对数据的关注角度不同,可按需采集。如信息流产品对停留时长的关注度更高(统计页面访问 & 跳出时间),商城类较注重“复购率”(统计新老用户),广告类更追求最大限度。
埋点统计通常分两类:
-
页面访问量统计
-
功能点击量统计
页面访问量统计
页面访问量统计通常分两类:
-
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>
方案本无优劣,适合才更重要,需综合考虑 产品设计 、 产品使用度 、 服务利用率 等等。例使用度较低应用可将统计与业务混于同一服务以节约成本,使用度较高应用可采取 本地缓存 、 批量上报 以降低服务压力,但批量上报是否加大统计 误差 ?
本文所述仅冰山一角,欢迎大家留言宝贵经验~
作者:呆恋小喵
我的后花园: https://sunmengyuan.github.io/garden/
我的 github: https://github.com/sunmengyuan
原文链接: https://sunmengyuan.github.io/garden/2018/12/13/trace.html
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
深度探索C++对象模型
斯坦利•B.李普曼 (Stanley B. Lippman) / 侯捷 / 电子工业出版社 / 2012-1 / 69.00元
作者Lippman参与设计了全世界第一套C++编译程序cfront,这本书就是一位伟大的C++编译程序设计者向你阐述他如何处理各种explicit(明确出现于C++程序代码中)和implicit(隐藏于程序代码背后)的C++语意。 本书专注于C++面向对象程序设计的底层机制,包括结构式语意、临时性对象的生成、封装、继承,以及虚拟——虚拟函数和虚拟继承。这本书让你知道:一旦你能够了解底层实现模......一起来看看 《深度探索C++对象模型》 这本书的介绍吧!