一共包括兩個部分：
2. 如何利用這些數據（三個案例說明）；
本文所使用的監測工具是nEqual提供的及策小程序監測模塊。
一、如何獲取符合業務需求的數據？
常規數據監測是指不管小程序是什么類型的，我們都需要獲取的數據，除了基礎代碼還包括來源、頁面與頁面路徑、分享、用戶屬性等數據。
自定義事件監測是指一些具有特殊業務場景的數據監測，比如含有交易功能的小程序，在提交訂單時需要監測訂單里的商品、數量、金額等數據。如果小程序內有廣告位，還需要監測廣告的曝光和點擊數據。
接下來介紹常規數據監測和自定義事件數據監測具體的監測方法。
1常規數據監測
在部署代碼之前，你需要注冊一個小程序的賬號，然后在賬號后臺添加合法域名，每個監測工具的域名不一樣，具體域名可以咨詢你使用的工具廠商。
其次是來源數據監測，這里先說下小程序都有哪些入口，有哪些能直接監測，有哪些不行。
小程序的入口接近70個，包含發現欄小程序主入口、頂部搜索框的搜索結果頁、朋友圈廣告、搜一搜結果頁、發現欄小程序主入口搜索框的搜索結果頁、聊天會話中的小程序消息卡片等，詳細入口列表，可以查看小程序開發文檔的鏈接：https://developers.weixin.qq.com/miniprogram/dev/framework/app-service/scene.html。
這些入口中，有些是我們可以加參數監測的，比如小程序的二維碼，這里說的二維碼也是用一段url生成的，和網站監測原理一樣。在做網站來源監測的時候，我們會在url上添加link tag來區分不同的流量渠道和廣告類型等。
比如投放到新浪上的banner廣告，我們可能就會加上參數?
utm_source=sina&utm_media=banner&utm_campaign=cwa（這是谷歌分析的標準格式），同樣在小程序里也能用這種方式實現，只是每個工具的參數標識不一定一樣，有些是兼容utm的，有些有自己的標識。
比如nEqual的及策用md標識來源類型，用pl標識來源詳情，這個鏈接pages/index?md=Qr_code&pl=mendian_a代表的是來自A門店的二維碼。和網站來源參數另一個共同點是這些參數可以只寫一個，也可全都不寫。
有些是無法加參數監測的。無法添加參數的來源類型需要工具從微信那調取場景值。前面提到小程序有接近70個入口，每個入口都有相對應的場景值，監測工具可以通過調用小程序定義好的場景值來判斷各種來源帶來的用戶數據。
有些朋友問，我想監測頁面A被某人分享出去后帶來多少人訪問，是否能實現。這種場景是可以實現的，需要我們做一些自定義事件監測。
以及策這個工具為例，在 path 后動態加上用戶動作名稱的昵稱，這樣就可以統計該分享者最終帶來多少用戶了。
Page({
??onShareAppMessage:?function?()?{
??????jice.track("onshare",?{????
????????title:?"自定義分享標題",?
????????path:?"/page/user"?+?"md=share&pl="?+?app.globalData.userInfo.nickName??
????})
??}
})
另一個常規監測就是用戶屬性的數據，當用戶打開你的小程序并且使用微信登錄，會調用以下方法回傳用戶數據。
this.getUserInfo(function(userInfo){
????jice.addUserIdentifier({
????????openid:?openid,?//?openidid
????????unionid:?unionid,?//?unionid
???????nickname:?userInfo.nickName,???//昵稱
???????wxgender:?userInfo.gender,???//性別
???????wxcity:?userInfo.city,???//微信設置城市
???????wxprovince:?userInfo.province,???//微信設置省份
???????wxcountry:?userInfo.country,???//微信設置國家
???????avatarurl:?userInfo.avatarUrl????//頭像url
???})
})
當用戶用微信登錄小程序的時候，我們會獲得用戶的open id，有可能的情況下會獲得union id，在之前我講公眾號用戶運營的文章里有詳細講過這兩種id的區別，如果你有多個公眾號、小程序的時候（在同一認證主體下），假設有一個用戶關注了你三個公眾號并且登錄過一個小程序，每個公眾號和小程序都會給這個用戶記錄一個open id，并且都不一樣，這對于你來說是不符合你的業務需求的，你還是希望能把這個用戶識別為一個人，這時候微信就提供另一個id叫union id來將這個用戶的open id進行統一標識，所以在你的平臺上，一個用戶對應一個union id。
除了用戶登錄后的open id或者union id，還有一個id是你收集到的用戶手機號或者郵箱，通過這個用戶id你可以將用戶訪問你網站、APP等平臺的數據統一整合進來。
2?自定義事件數據監測
為了解決好這些業務場景的數據監測問題，以下內容主要會和大家介紹特定交互監測、自定義變量監測、廣告位曝光點擊監測。
特定交互監測（事件監測）
拿我最常用的小程序舉例，因為每周都要組織大家打籃球，要確定大部分朋友打球的時間，所以會用到投票的小程序。
如果我們監測騰訊投票的小程序，我特別想知道頁面上點擊單選投票和多選投票的點擊數量是多少，這時候我們需要部署小程序事件的代碼，還是以及策為例，分別給這兩個按鈕部署事件代碼jice.track(‘danxuan’)和jice.track(‘duoxuan’)，這樣就可以實現對這兩個按鈕的監測。
那有朋友就問了，如果我不僅僅想監測這個按鈕的點擊次數，我還想監測這個按鈕里的文字內容呢？這就涉及到了自定義變量了，為了更好地解釋這個問題，我直接引到自定義變量監測模塊。
自定義變量數據監測
當我們想要監測很多特定的動態數據的時候，比如訂單信息、注冊信息等，因為每個用戶購買的商品五花八門、注冊提交的手機號等信息具有唯一性，所以無法用簡單的事件來監測，而是要監測更為詳細的動態信息，所以才有自定義變量存在的可能性。
比如下圖中的訂單信息，用戶購買了酒店的單人餐，兩份。我想要在用戶點擊“確認下單”按鈕的時候，把訂單里商品名“盤古七星酒店因緣庭單人餐”、數量“2”、總額“200元”等數據監測回來，我們需要用這樣的代碼
jice.track(‘qrxd’,?{spmc:‘/*商品名稱*/’,shuliang:‘/*數量*/’,zonge:'/*合計金額*/'});
廣告位曝光點擊監測
要實現廣告位數據的監測，首先要在監測工具中添加作為渠道方的小程序，然后嵌入基礎代碼以及需監測的事件代碼、用戶屬性代碼（這些代碼前面都有詳細介紹），同時需在工具中添加廣告主的小程序，最后將以下代碼部署在廣告位上。注意：代碼中appid為廣告主的appid，即工具生成的應用id。
Javascript
//曝光
jice.adTrack(“appid”,“view”,?{???
???adtype:?“banner”,??//廣告位，可選banner/timeline，或自定義值???
???adct:?“audi?suv”?//?廣告內容標識??
???adv:?“audi”??//廣告主名稱
})
?//點擊
jice.adTrack(“appid”,“click”,?{???
???adtype:?“banner”,??//廣告位，可選banner/timeline，或自定義值???
???adct:?“audi?suv”?//?廣告內容標識??
???adv:?“audi”??//廣告主名稱
})
//appid?為及策為每個廣告主分配的不同應用id;
二、案例：拿到數據該如何優化業務
1漏斗分析
可口可樂繼昵稱瓶、歌詞瓶、臺詞瓶之后，應用小程序推出社交活動：密語瓶。這個活動的玩法是用戶通過掃描小程序的二維碼進入小程序頁面后選擇喜歡的密語，然后上傳照片與密語結合后生成圖片分享給好友，最終達到娛樂與傳播的目的。
通過數據積累，我們構建了以下漏斗。
找到泄露的原因，也就找到優化的方法。
2表單分析
- 重填率：發現用戶反復修改的表單項，計算公式：與該表單項發生>1次互動的人數/所有與該表單項互動的人數；
- 人均填寫次數計算公式：該表單項的互動次數/該表單項的互動人數
- 平均填寫時長：了解各表單項耗費用戶的時長；
- 表單項流失率：判斷流失的用戶都是從哪個表單項離開的。
- 還有很多指標，比如表單空白項、填寫路徑等
這個表單在用戶進入表單頁面嘗試填寫到點擊提交，有將近三分之二的用戶離開了，我們想知道到底是哪些因素導致用戶流失。
在大量數據中，我們發現了幾個有意思的數據。其中一個是下圖中展現的，用戶在放棄填寫前最后互動的表單，此圖可以分析出用戶是因為哪個表單項離開的。
帶著對這些數據的好奇，我體驗了一下表單流程，發現在選擇經銷商的時候表單選項中只有經銷商的名稱，但是我并不知道經銷商的位置到底離我有多遠，我還需要通過地圖APP去查看經銷商的位置，這樣勢必造成用戶的重復填寫和流失。
3自定義變量事件分析
我們需要在密語提交頁面的提交按鈕上部署事件代碼，代碼示例如下：
jice.track(‘mytj’,?{my:‘/*密語*/’});
好了，具體的分析案例不多做介紹了。相信這篇文章可以幫助大家梳理小程序數據監測的基本方法。而案例部分，大家會發現與以往的網站分析、APP分析并沒有特別本質的區別，而考驗你的地方在于對業務與用戶的理解以及數據的定義與解讀。
本文為@運營喵原創，運營喵專欄作者。
