智慧小程式檔案館——埋點統計

百度智慧小程式學院發表於2018-11-08
原文網址 : https://juejin.im/post/5be3f2f2f265da614f6fcbcc

埋點，又叫打點，俗話說：埋點要是埋得好，資料統計差不了。今天我們就和大家探討一下如何進一步提升我們埋點的準確性～～

資料的準確性和全面性對於智慧小程式而言意義非凡：資料對於線上問題排查、效能優化、業務增長都起著至關重要的作用。 而作為小程式的開發者，是不是經常會遇到資料統計不準確的問題，資料就像是這個季節忽高忽低的溫度，而每當資料統計出現問題，總能感覺老闆在磨刀霍霍。。。

智慧小程式本身提供了自定義事件分析，可進行自定義事件埋點，但是在某些場景下需要進行特殊的埋點操作時，我們要怎麼辦呢？

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則記做一個新的使用者即可。

總結：

使用者行為資料非常龐大，有以下幾點需要客官們特別注意：

  1. 找到真正重要的使用者行為資料非常關鍵，一定要有從多個同樣的使用者行為中找到最重要的那個的火眼金睛哦。
  2. 清晰和簡介的資料格式上報。
  3. 上報資料優化，節約開銷。

相關文章