智能小程序档案馆——埋点统计

埋点，又叫打点，俗话说：埋点要是埋得好，数据统计差不了。今天我们就和大家探讨一下如何进一步提升我们埋点的准确性～～

数据的准确性和全面性对于智能小程序而言意义非凡：数据对于线上问题排查、性能优化、业务增长都起着至关重要的作用。而作为小程序的开发者，是不是经常会遇到数据统计不准确的问题，数据就像是这个季节忽高忽低的温度，而每当数据统计出现问题，总能感觉老板在磨刀霍霍。。。

智能小程序本身提供了自定义事件分析，可进行自定义事件埋点，但是在某些场景下需要进行特殊的埋点操作时，我们要怎么办呢？

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则记做一个新的用户即可。

总结：

用户行为数据非常庞大，有以下几点需要客官们特别注意：

找到真正重要的用户行为数据非常关键，一定要有从多个同样的用户行为中找到最重要的那个的火眼金睛哦。
清晰和简介的数据格式上报。
上报数据优化，节约开销。