小程序用戶行為數據監測與分析以及案例分享
小程序現在火了。但是應該如何監測小程序的數據呢？相信這是一個大家都關心的問題。這篇文章對這個問題進行解答。一共包括兩個部分：
1. 如何獲得小程序相關數據（常規數據和自定義事件數據）；
2. 如何利用這些數據（三個案例說明）；
本文所使用的監測工具是nEqual提供的 及策 小程序監測。
一、如何獲取符合業務需求的數據？
在數據監測中分為兩大部分，常規數據監測和自定義事件數據監測。 常規數據監測 是指不管小程序是什么類型的，我們都需要獲取的數據，除了基礎代碼還包括來源、頁面與頁面路徑、分享、用戶屬性等數據。 自定義事件監測 是指一些具有特殊業務場景的數據監測，比如含有交易功能的小程序，在提交訂單時需要監測訂單里的商品、數量、金額等數據。如果小程序內有廣告位，還需要監測廣告的曝光和點擊數據。接下來介紹常規數據監測和自定義事件數據監測具體的監測方法。
1、常規數據監測
先講解一下基礎代碼的部署。在部署代碼之前，你需要注冊一個小程序的賬號，然后在賬號后臺添加合法域名，每個監測工具的域名不一樣，具體域名可以咨詢你使用的工具廠商。
添加域名示例
添加完域名后要引入JS，將下載的SDK文件放入 util 目錄下，然后在 app.js 第一行添加js代碼。SDK文件和JS代碼在工具廠商那都能下載到。其次是來源數據監測，這里先說下小程序都有哪些入口，有哪些能直接監測，有哪些不行。小程序的入口接近70個，包含發現欄小程序主入口、頂部搜索框的搜索結果頁、朋友圈廣告、搜一搜結果頁、發現欄小程序主入口搜索框的搜索結果頁、聊天會話中的小程序消息卡片等，（詳細入口列表，回復“小程序”獲取）。這些入口中，有些是我們可以加參數監測的，比如小程序的二維碼，這里說的二維碼也是用一段url生成的，和網站監測原理一樣。在做網站來源監測的時候，我們會在url上添加link tag來區分不同的流量渠道和廣告類型等。比如投放到新浪上的banner廣告，我們可能就會加上參數?utm_source=sina&utm_media=banner，同樣在小程序里也能用這種方式實現，只是每個工具的參數標識不一定一樣，有些是兼容utm的，有些有自己的標識。比如及策用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
})
}
})
|
一個需要介紹的字段是$share_depth，這個屬性值會記錄分享的層級：如果某個小程序頁面被A、B和C三人依照 A -> B -> C 的順序進行分享，則 A 的分享會被標記為1級分享，B的分享會被標記為2級，C 則為3級。 如果某用戶打開自己分享的頁面不會增加 $share_depth 的值。通過這個字段可以看到某個頁面被分享的層級有多深。另一個常規監測就是用戶屬性的數據，當用戶打開你的小程序并且使用微信登錄，會調用以下方法回傳用戶數據。
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 })})
關于用戶id打通，因為涉及到用戶id，這里延伸介紹下監測小程序的工具根據哪些id來判斷用戶，當用戶在未登錄的情況下，工具會給用戶隨機生成一個id，相當于網站監測里的cookie，只是每家工具的叫法不一樣，神策的叫uuid，易觀方舟的叫originallid等。（是否有官方叫法）這種id極不穩定，如果你換了設備或者刪除小程序，這個id隨之重新生成或者消失。當用戶用微信登錄小程序的時候，我們會獲得用戶的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、漏斗分析
漏斗分析是很常見的做轉化流程、表單等業務分析的模型，在宋星老師的 大課堂 上有介紹過漏斗的主要形態，如下圖。
漏斗圖
最理想的狀態當然是沒有流失，全部都轉化了，但這是不可能的嘛。正常的流程都會存在一定的流失率，但是有些嚴重的泄漏點是值得我們關注的，這些嚴重流失的用戶到底去了哪里，找出原因也就找到了優化的方法。 可口可樂繼昵稱瓶、歌詞瓶、臺詞瓶之后，應用小程序推出社交活動：密語瓶。這個活動的玩法是用戶通過掃描小程序的二維碼進入小程序頁面后選擇喜歡的密語，然后上傳照片與密語結合后生成圖片分享給好友，最終達到娛樂與傳播的目的。
在這個活動中，其中有一個流程是：打開首頁-點擊“蜜語從哪來”按鈕-輸入密語-確認提交-生成圖片分享。 通過數據積累，我們構建了以下漏斗。
密語制作分享轉化漏斗
從上圖可以看出用戶從首頁點擊“蜜語從哪來”進入密語定制流程的用戶流失率較高，只從這個數據來看，首頁的流失量是很大的，對于這個營銷活動，最重要的目標是引導用戶定制自己的密語然后分享。后來我們從另一個漏斗數據里看出沒有進入以上漏斗的用戶中除了一部分直接退出小程序，另一部分進入了“密語表情DIY”，進入了另一個定制密語的流程里。所以雖然從漏斗里看出流失率大，但是并不是壞事。
第二個需要注意的泄漏點在最后的分享，最后一個環節的轉化率非常低，這個數據引起我們的注意，我們需要分析是不是頁面分享引導出現問題，后來經過排查發現是因為不支持分析朋友圈導致很多用戶無法分享。
找到泄露的原因，也就找到優化的方法。
2、表單分析
在表單分析中，有幾個核心的指標需要重點關注。
- 重填率：發現用戶反復修改的表單項，計算公式：與該表單項發生>1次互動的人數/所有與該表單項互動的人數；
- 人均填寫次數計算公式：該表單項的互動次數/該表單項的互動人數
- 平均填寫時長：了解各表單項耗費用戶的時長；
- 表單項流失率：判斷流失的用戶都是從哪個表單項離開的。
- 還有很多指標，比如表單空白項、填寫路徑等
接下來看下看個汽車行業客戶在投放廣告后如何通過數據發現表單問題的。大家知道汽車廣告投放最主要的目的有預約試駕、申請手冊、購車意向等，這里面都涉及到了讓用戶提交個人信息。所以提交個人信息的表單設計變得尤為重要。這個表單在用戶進入表單頁面嘗試填寫到點擊提交，有將近三分之二的用戶離開了，我們想知道到底是哪些因素導致用戶流失。我們想知道到底是哪些因素導致用戶流失。在大量數據中，我們發現了幾個有意思的數據。其中一個是下圖中展現的，用戶在放棄填寫前最后互動的表單，此圖可以分析出用戶是因為哪個表單項離開的。
用戶放棄填寫前最后互動的表單項
大家可以看到“經銷商”這個表單項是導致用戶離開的最主要的因素，結合重填率分析結果，發現用戶在選擇經銷商時平均重復填寫超過兩次，重填率接近一半。帶著對這些數據的好奇，我體驗了一下表單流程，發現在選擇經銷商的時候表單選項中只有經銷商的名稱，但是我并不知道經銷商的位置到底離我有多遠，我還需要通過地圖APP去查看經銷商的位置，這樣勢必造成用戶的重復填寫和流失。
經銷商選項下拉列表
有朋友就問了，那怎么辦呢？要不要在小程序里添加個地圖功能或者跳轉到地圖的功能？這樣處理的話明顯把問題復雜化了，這樣要增加多少開發和產品的工作量？有個比較簡單的辦法是填寫經銷商簡稱，并在簡稱后添加“近某條路”或者“近某地鐵站”之類的大致位置信息，讓用戶大概了解哪個經銷商離自己近即可。
3、自定義變量事件分析
在前面可口可樂的案例里，在制作密語瓶的流程中，有一個環節是讓用戶提交自己想要寫的密語。那我們如何能獲取到用戶提交了什么密語？這里就要用到前面提到的自定義變量的事件監測方法了。我們需要在密語提交頁面的提交按鈕上部署事件代碼，代碼示例如下：
jice.track(‘mytj’, {my:‘/*密語*/’});
部署后即可監測用戶提交了哪些密語、提交的次數等。
密語提交內容事件報告
密語內容分布
從數據里面可以看出這個活動面對的人群很大一部分是鹿晗的粉絲（為了做這個分析，專門查了“LH7”是啥意思，暴露年齡了）。有些密語對我這個“上年紀的人”確實有些費解，大家看到有好玩的可以教我下是啥意思，幫我填補下鴻溝哈哈。好了，具體的分析案例不多做介紹了。相信這篇文章可以幫助大家梳理小程序數據監測的基本方法。而案例部分，大家會發現與以往的網站分析、APP分析并沒有特別本質的區別，而考驗你的地方在于對業務與用戶的理解以及數據的定義與解讀。關于小程序的文章就先寫到這，歡迎大家留言交流。
