智慧小程式檔案館——埋點統計
埋點，又叫打點，俗話說：埋點要是埋得好，資料統計差不了。今天我們就和大家探討一下如何進一步提升我們埋點的準確性～～
資料的準確性和全面性對於智慧小程式而言意義非凡：資料對於線上問題排查、效能優化、業務增長都起著至關重要的作用。 而作為小程式的開發者，是不是經常會遇到資料統計不準確的問題，資料就像是這個季節忽高忽低的溫度，而每當資料統計出現問題，總能感覺老闆在磨刀霍霍。。。
智慧小程式本身提供了自定義事件分析，可進行自定義事件埋點，但是在某些場景下需要進行特殊的埋點操作時，我們要怎麼辦呢？
swanId
由於我們宿主應用並不一定強制使用者登入，因此使用者也有可能處於未登入狀態，使用者肯定不希望被強行登陸，所以我們對使用者裝置的唯一標識解決方案是SwanId。
新版的ofollow,noindex">
swan.getSwanId
API在登陸前後都會返回同一個值。
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
關於使用者停留時長
即使用者在某一個頁面的停留時長。
埋點是應該考慮在起點頁面渲染完成，終點使用者離開這個頁面，示例如下:arrow_down:：
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則記做一個新的使用者即可。