B端體驗度量衡:用戶行為監控篇
編輯導語:在項目流程中,大部分人認為設計師只會追求視覺好看,不懂業務,所以設計師的話語權一般不高。本文作者從用戶行為監控方面分析B端的體驗度量衡,希望能幫助設計師拿到話語權。
在實際項目流程之中,通常設計師的的話語權不高,這個來源于大家對于設計師本身的刻板印象(只會追求視覺好看)。但是顯示情況好多設計師也不懂業務,所謂的設計的出發點就只有視覺。我也是希望能幫助到同行們拿到話語權。
01 為什么我們要學體驗度量衡?
針對項目前期中期后期,體驗度量衡有不同的作用。項目前期主要是找設計目方向,找到合適的業務目標確定設計目標從而能說服別人認同自己的想法。
項目中期主要常常場景是制定目標以及之后的向上級要資源,設計過程中不光涉及到頁面設計還涉及到了團隊資源(用戶調研,開發資源支持等等),每一項資源調用和配合都要講清楚業務上的“必要性”說服別人來跟你進行配合。
項目后期主要場景是拿設計結果(不論正負),來為設計進行證明自身設計的價值。經常性是用來進行復盤和職位晉升報告(向上報告),為自己爭取更多的話語權。
02 B端常見的體驗度量衡
常見的體驗度量衡主要是分為4類:
- 使用度/路徑
- 使用效率檢測
- CES/NPS
- 業務指標
使用度/路徑檢測包括:
- PV
- UV
- 操作步數
使用效率檢測包括:
- 完成率
- 完成效率
CES和NPS包括:
- 凈省力度(CES)
- 凈推薦值 (NPS)
業務指標就比較多了,例子:
- GMV/PMV
- 續費率
- 月活/周活/日活
- 客服成本
- 設計/開發成本
針對不同業務/階段/目的/功能/流程選擇不同的指標,這個需要結合業務去談。
按照數據進行區分:使用度/路徑檢測和使用效率屬于用戶行為監控,CES和NPS屬于體驗度量衡指標,GMV/續費率等屬于業務指標。篇幅有限,這一篇主要是講用戶行為監控。
03 用戶行為監控
用戶行為監控物理映射的是實際生活中的監控攝像頭,監控用戶的行為/時間/步驟/位置/人數/從哪里來/去了哪里/接下來要去哪里的等等情況。
本質是通過埋點,檢測用戶的瀏覽,操作系統的各類數據。通常分成3類監控使用頻率,監控使用效率以及性能監控。
1. 使用頻率監控
1)常見參數
頻率監控的常用參數:
- pv:用戶進入頁面或者功能的次數
- UV:進入到功能或者是功能的用戶數,通?;赑V進行查重
- 曝光率:首屏進入到用戶視野中的次數/使用次數,通常在監控曝光率的埋點是監控功能的點擊率
注意點:實際工作中很多人誤把只要功能被用戶看到了就算一個次數(例如選項卡未選的候),其實這是一個誤區這會導致最后統計的錯誤影響到最后設計的結果。
2)埋點前需要做什么?
埋點之前有個埋點評審,通常要說明:
- 為什么要埋點?——這里主要是講賣點對于業務/用戶/商業的價值
- 埋什么點?——這里會給一個表格,分為模塊,功能,字段。開發會轉化為KEY的值(具體開發去操作)
- 怎么做?——開發區完成
埋點對于產品經理和設計師的意義不同。如果是產品經理發起的埋點主要是針對新上線功能的使用頻率,如果是設計師的話更多情況是流程或者是功能的優化。
注意點:開發有能力把全部的點給埋上,但是埋點貴精不貴多,埋點過多的話會讓開發懷疑你埋點的意義是什么,而且在后期拿到數據的時候也會因為數據過多導致分析的難度增加。所以在埋點之前一定要想好為什么要埋點。
如何建立篩選維度也是一個很需要思考的事情。
3)如何建立篩選維度
常見的埋點參數(請根據你的業務和目的進行選擇):
- 時間-必要字段:要不然需要的是從項目1.0到現在的所有時間段
- PV/UV:這個具體的要看業務
- 商家ID:這里根據業務可以變化,比如電商里面的商家ID,視頻產品里面中的發布者ID等等
- 主營類目:根據主營業務進行,比如淘寶就是電商
- 用戶ID:常見的是表格業內的篩選,不同的角色有不同的的字段權限,用戶甚至可以自定義模板。工作臺也是能根據角色來進行區分,不同的角色有不同的工作臺。
- 來源標記:例如文章的來源等等
具體的要看你的業務類型/處在的階段/埋點的目的等等信息進行自己判斷。
4)第三方BI平臺
建立BI分析平臺需要一定的資金和技術的作為基礎,往往一些公司沒有多余的能BI分析平臺,所以第三方BI平臺隨之誕生。比較有名氣的:神策百度移動統計(主要針對移動端)、友盟、騰訊MTA。
一些公司擔心數據泄露又不缺少建立的條件,所以會自己建立BI平臺。
2. 使用效率監控
1)常見參數
監控使用效率主要參數是兩個完成率和完成效率,分別的計算公式是:
- 完成率=完成結果頁PV/新建頁面PV*100%
- 完成效率(完成時長的倒數)=訪問結果頁的時間刻度-完成表單頁的時間刻度
接下來分解兩個參數的取值范圍以及實際情況可能會遇到的誤區。
2)完成率
完成率常見的誤區是實際工作中有些用uv(進入功能/頁面的人數,基于PV去重)代替PV,導致測試出來的數據并不準確。造成的這個原因有:
- 用戶可能會多次打開或者是多次關閉頁面
- 完成率是基于任務完成度進行計算的,任務完成才是關鍵
- uv是獨立訪問,通?;赑V進行去重,但是無法統計任務的個數
3)完成效率
計算公式:
完成效率(完成時長倒數)=訪問結果頁時長-訪問表單頁面刻度
通常取值范圍:
- 中位數:可以免受最大值或者最小值等極端情況的影響
- 眾數:出現最多次數的數據
匯報小技巧:對上級進行匯報的時候,匯報比較大的數字。比如:修改前操作時間是5分鐘,修改后是2分鐘。按照完成利率的計算就是提高60%,完成效率150%。那你贊找完成效率去匯報,上級會更滿意。
4)性能監控
性能監控主要是監控前端頁面的響應速度,作為設計師只能發起體驗項目,無法進行執行,幫到的忙不多。
通常的判斷標準2-5-10原則:
- 2:首頁2秒內響應速度,如果是官網的情況下需要更快的反應速度
- 5:普通的的頁面響應速度要在5秒以內
- 10:復雜的查詢以及表單頁面響應速度要在10秒以內
一點超過這個這個標準用戶就會大概率離開。
04 測試周期以及數據對比
常規的測試周期:
- 7日:主要是針對營銷活動等需要短期數據的進行測試,從而驗證運營活動是否達到立項之前的目標
- 14日或者是30日:常用于B端新功能的測試周期使用
真實項目中,有一些項目總是急著要去數據驗證,上線后1個月就需要驗證需求/設計的必要性。作為一個打工人可以理解這個問題,因為在公司里面很多時候是依靠數據驗證自己的價值以及在升值加薪時候的用。
但是這里沒有考慮到用戶學習新功能需要一段時間(常規是一個月),在用戶學習的過程中某些數值會降低(完成率或者是完成效率),而會導致測試的準確性失真從而導致回滾。所以,通常數據對比的隔月的舊數據進行對比。
重點再安利一遍“不要用下一個月的數據進行驗證”,而是用隔月的數據進行驗證??!比如7月底上線的功能,驗證的數據應該是是9月的數據。
05 總結
從整體來講學會體驗度量衡能讓我們的設計驗證是否符合用戶跟場景,以及在做向上管理的時候有不錯的效果。其中完成率跟完成效率能實施對用戶行為的監控而獲得客觀的數據,性能監控主要是開發效果的驗證。
最后再安利一遍:不要拿下一個月的數據進行對比,要拿隔月的數據進行對比!
資料來自 美芳老師《且曼B端設計》
本文由 @一只雞腿 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
本文由 @一只雞腿 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
怎么監控用戶的不正常操作呢?
文章是好文章,就是不往腦子里進啊。嗚嗚嗚嗚
一篇分析B端體驗度量衡與用戶行為監控間的關系全面詳細的文章。
謝謝夸獎