埋点,又叫打点,俗话说:埋点要是埋得好,数据统计差不了。今天我们就和大家探讨一下如何进一步提升我们埋点的准确性~~
数据的准确性和全面性对于智能小程序而言意义非凡:数据对于线上问题排查、性能优化、业务增长都起着至关重要的作用。 而作为小程序的开发者,是不是经常会遇到数据统计不准确的问题,数据就像是这个季节忽高忽低的温度,而每当数据统计出现问题,总能感觉老板在磨刀霍霍。。。
智能小程序本身提供了自定义事件分析,可进行自定义事件埋点,但是在某些场景下需要进行特殊的埋点操作时,我们要怎么办呢?
swanId
由于我们宿主应用并不一定强制用户登录,因此用户也有可能处于未登录状态,用户肯定不希望被强行登陆,所以我们对用户设备的唯一标识解决方案是SwanId。
新版的swan.getSwanIdAPI在登陆前后都会返回同一个值。
UV的统计逻辑
UV指智能小程序的当天访问人数。
UV是当天SwanId去重之后的数字,统计UV的逻辑放在App的onShow中比较适合,先说一下这个函数触发的几个场景分别是:小程序首次被调起、小程序后台切前台。 下面我们实践一下:
App({
onShow(options) {
swan.getSwanId({
success: res => {
this.gloablData.uuid = res.data.swanid;
}
});
swan.request({
url: 'https://host/path?query',
data: {
uid: this.gloablData.uuid
},
success() {
// 这里是打点成功之后的操作
},
fail() {
// 如果走到这里,说明失败了,可能是因为网络抖动的一些因素,那么我们把点存储在缓存,在退出小程序的时候再发送
swan.setStorageSync('uid', this.gloablData.uuid);
}
});
},
onHide() {
if (swan.getStorageSync('uid')) {
// 如果缓存有uid,证明onShow的统计发送失败了,再次发送一次
swan.request({
url: 'https://host/path?query',
data: {
uid: this.gloablData.uuid
},
success() {
// 发送成功后及时清除storage,也可以提升性能
swan.setStorageSync('uid', '');
}
});
}
}
});
复制代码
PV的统计逻辑
PV 是指当天页面的访问次数。
好多人在这里翻车了,苦不堪言,导致加班到深夜查数据。简单还原下事故现场,有一些PV的统计参数需要从App的onLaunch或者onShow里通过异步请求(requestParams)获取,而真正发送PV打点(requestPageView)是在Page的生命周期里完成的,那么问题来了,requestParams的回调结果和requestPageView请求哪个在前哪个在后,很头疼对不对? 有人说在requestParams的回调里给globalData加一个flag标识,requestPageView的时候去判断一下,那这个时候有问题: 如果这个flag按照你得预期存在,万事大吉,如果不存在呢?setTImeout还是setInterval都不合适吧。 有没有解决的办法?of course!这里引入一个队列的概念,直接上代码,一目了然~~
app.js
App({
onShow(options) {
// mock requestParams
swan.request({
url: 'https://host/path?query',
data: {
path: options.path,
query: options.query,
scene: options.scene
},
success(result) {
this.globalData.callBackArr.forEach(callBack => {
// 此处遍历执行Page级生命周期的注册的App的回调函数
callBack();
});
}
});
},
globalData: {
// 定义一个存储回调函数队列
callBackArr: []
}
});
// index.js
//获取应用实例
const app = getApp();
Page({
data: {
...
},
onLoad: function () {
app.onLoadCallback = data => {
if (data != '') {
// 可以在此处进行pv上报操作
}
}
app.globalData.callBackArr.push(app.onLoadCallback);
},
onShow: function () {
app.swanCallback = data => {
if (data != '') {
// 可以在此处进行pv上报操作
}
}
app.globalData.callBackArr.push(app.swanCallback);
}
})
复制代码
关于转化率
最近很多开发者反馈说转化率降低,而且一降就是50%,为啥会有这么大的gap?难道是用户一夜之间就变心了?心中充满自责,是我们的产品不好用了还是用户转移到其他竟品小程序了?冰冻三尺非一日之寒,况且我们也没有太大的改动,还是再看看代码逻辑吧~~
看了代码之后我们会发现,在点击支付会跳转到支付页面,而当前待支付的页面的PV上报在onLoad里,导致支付完成后会再次跳转到当前的待支付页面,导致又一次触发了onShow,pv++,转化率 = 支付pv/待支付pv,相当于待支付PV加了一倍,整体降低50%。
关于转化率的计算的逻辑尽量都放在onLoad生命周期中处理,避免出现中间页跳转(支付页面)影响最终PV
关于用户停留时长
即用户在某一个页面的停留时长。
埋点是应该考虑在起点页面渲染完成,终点用户离开这个页面,示例如下⬇️:
Page({
data: {
startTime: 0
},
onReady() {
this.setData({
startTime: Date.now()
});
},
onHide() {
let lengthOfStay = Date.now() - this.data.startTime;
swan.request({
url: 'https://host/path?query',
data: {
pageFlag: 'page/index/index',
lengthOfStay: lengthOfStay
}
});
}
});
复制代码
新访问的用户数
针对新增用户数我们需要借助SwanId,在后台数据库里对SwanId进行过滤,对于数据库路没有的SwanId则记做一个新的用户即可。
总结:
用户行为数据非常庞大,有以下几点需要客官们特别注意:
- 找到真正重要的用户行为数据非常关键,一定要有从多个同样的用户行为中找到最重要的那个的火眼金睛哦。
- 清晰和简介的数据格式上报。
- 上报数据优化,节约开销。