使用者體驗,能不能用資料說話,別說“我感覺…”
前言
“我感覺這樣使用者體驗會好一些。”
“那可不一定,萬一使用者就喜歡這樣呢?”
“你覺得費這麼大的力氣提升了少數人的一點點體驗,划算嗎?”
“你怎麼就知道是少數人了!你不做怎麼知道就只有少數人會用呢?”……
需求評審會上一場劍拔弩張的關於使用者體驗的討論正在進行中。坦白說,使用者體驗的確是一門玄學,有很多不確定性,就像 iPod 造出來之前,可能只有賈伯斯覺得這玩意兒會火。
但在很多場合下,尤其是 to B 產品中,其理性設計會給使用者體驗帶來非常多的確定性。即我們把產品設計當做一次次實驗測試,用合適的指標去度量、反饋,就會越來越接近那“絲滑般”的使用者體驗。
今天就和大家聊一聊使用者體驗的度量。首先會和大家講講使用者體驗度量指標,如何選取合適的指標,比如什麼時候應該用 DAU,什麼時候應該用使用時長,這些指標背後有沒有一個框架(套路)可以參考。其次會講講如何評價某個指標的值,比如我告訴你,某 APP 的 DAU 是 10000, 但其實 10000 這個數字本身沒有任何意義,只有放在時空對比,即橫向與競友或者是全量市場對比,縱向和該 APP 的歷史資料對比,才有意義。那麼如何比較,也是有一套科學的方法。然後會講講業界一些體驗度量工具。最後聊一下我親身經歷的一次“不成功”案例,聊一下理論之外的實踐教訓,和大家共勉。
01、如何選取合適的指標——測量啥
測量指標千千萬,有多少個目標,就會有多少個指標。在使用者體驗領域,大概有以下幾個框架來選擇指標。
1)按照主觀和客觀分:把指標劃分為“行為性指標”和“態度型指標”。
2)Google 的 HEART 框架。
3)阿里在 HEART 框架基礎上衍生出來的 PTECH 框架。
4)最後也和大家分享一下我自己思考的基於馬斯洛需求模型的框架。
1.1 按照主觀和客觀分
我們可以把指標劃分為“行為性指標”和“態度型指標”。
行為性指標:即使用者怎麼使用產品的。比如點選次數,點選率,任務成功率(使用者是否能完成他想做的事情),完成任務所花時長, 任務過程中所遇到的報錯次數,完成任務所需點選次數等。
態度型指標:即使用者的主觀評價。最常見的是三大主觀指標:使用者推薦指數,使用者滿意度指數,使用者易用性指數等。
1.2 Google 的 HEART 框架
1.3 阿里的 PTECH 框架
1.4 基於馬斯洛需求模型的框架
最後,基於我個人的經驗和思考,我們也可以根據產品處於“馬斯洛需求層次”的哪個層次來選擇指標。眾所周知,馬斯洛需求將使用者心理需求由低到高分為五個層次:
1)生理需求;
2)安全需求;
3)歸屬和愛的需求;
4)被人尊重的需求;
5)自我實現的需求。
以我們最熟悉的產品微信為例,可以把其中的不同功能歸屬在不同的層次,當然不同功能可能會從低階需求轉化到高階需求,在這裡,為了簡化分析過程,我們假設下表提到的功能都是未經迭代的最初設計版本。
在這個框架中,我們在選擇指標時,切忌同一時間段用多個指標衡量,追求“木桶理論”,而是要基於一個“篤定”的目標用“舍九取一”的做法在一個需求層次內選擇一個最核心的需求去驅動,然後圍繞這個核心來拆解影響核心指標的要素,不斷迭代反饋,直到目標達成,進化到下一個目標,再開始新一輪的“進化”。我把馬斯洛需求從低到高的進化過程畫了一個圖,來說明這個“進化”過程。
有了以上的思維框架支援,我們可以按照實際需求選取合適的指標。那麼指標選好了,指標的值也拿到了,比如某個頁面的平均瀏覽時長是60秒,這個60秒代表什麼,如何評價這個值是好還是壞?我們有一系列的方法。
02、怎麼評價度量值
總的來說,任何一個單一的值都是沒有意義的,唯有把這個值置於對比之中,才有價值,常見的對比場景有:
在時間維度的縱向對比:例如今天和昨天的資料對比。時間維度的對比評估就是我們經常提起的同比、環比、趨勢圖等模型。
在空間維度的橫向對比:例如抖音和微信影片號的平均每天使用時長,或者是A/B測試中A、B樣本的對比。關於A/B測試中,如何對比A、B樣本的差異性,公眾號裡有同學已經講得非常清楚了,可以參考這篇:《資料應用系列(1)-ab測試》,這裡不再贅述。
當我們知道如何選擇使用者體驗度量指標和評判方法後,就可以靈活運用各種工具來開始你的體驗提升戰略了。接下來我們簡單介紹幾種工具。
03、度量工具介紹
這裡拿出筆者比較熟悉的幾個工具,按照資料來源獲取、獲取後怎麼分析資料、分析後怎麼展現三個維度來分享,供大家參考。
3.1 Google Analytics(谷歌分析)
Google Analytics (谷歌分析) 是 Google 提供的網站分析工具,其原理是透過前端載入 Google Analytics 的 js 指令碼,透過瀏覽器把 C 端客戶的行為資料上報,之後在 Google Analytics 中進行資料視覺化展現。
資料獲取方面:它是無埋點分析工具,即無需在前端對使用者的每次行為進行埋點上報,幾乎可以記錄使用者的所有行為。
獲取後怎麼分析資料:首先它幾乎涵蓋了上述的所有指標,且付費使用者還可以自定義指標。在分析模型方面,幾乎提供了常見的所有模型。
分析後怎麼展現:谷歌分析的資料視覺化是從廣告效果分析演化而來,遵循【流量從哪裡來-->流量是誰(有些什麼特徵)-->流量來了之後轉化如何-->流量又去向了哪裡】的模型展現給使用者(如下圖所示)。不過,GA 也提供個性化報表讓使用者自由分析,但流量模型分析仍然是它的最大優勢。
使用注意事項:
GA 是一款非常強大,但免費版對流量有一定限制,即在一段時間內埋點上報到一定數量就會停止上報, 所以對於大流量(日活十萬級)的應用,可能就謹慎選擇。
無埋點的上報的方法也可能會有非常多的指標展現給使用者,對於初入門的使用者學習曲線比較長。筆者最開始使用的時候,也是抓不住重點,這裡瞅瞅,那裡看看,感覺很酷,但是胡亂分析一通後,感覺對體驗的提升沒有太多參考價值。
GA 的報告對不同的應用沒有區別對待,導致 GA 的報告並不夠簡潔。
3.2 Segment+Amplitude
Segment 和 Amplitude 並不是同一家公司,之所以放在一起是因為筆者主要把 Segment 作為埋點採集工具,把 Amplitude 當做分析、視覺化工具。二者都是開放平臺,Amplitude 可以透過介面方式讀取 Segment 的埋點資訊。二者加起來大家可以類比國內的神策資料。這個組合可以說是筆者目前見到的最好的分析工具,沒有之一。
資料獲取方面:主要由 Segment 完成,埋點上報方法是事件上報,即前端可以指定哪些行為進行埋點上報,這種方式會使後面的分析更加簡潔,重點突出。
獲取後怎麼分析資料:分析模型由 Amplitude 完成,包含客戶分群、漏斗分析、留存分析、參與度分析、使用者全生命價值分析、使用者全生命週期分析、使用者 session、使用者組成、使用者粘度分析、路徑分析、路徑使用者分析、指南針預測分析(從使用者行為中找到產品的 aha 時刻)、使用者畫像、歸因分析、實驗結果分析十五種分析模型。這也正是 Amplitude 的精髓之處,不過筆者也不是所有的模型都研究過,感興趣的同學可以在其官網的部落格文章中學習,部落格內容非常深入,只是因為是英文,理解起來稍有困難,對英文障礙較大的同學可以藉助翻譯工具來閱讀。筆者關於資料分析模型的知識和應用幾乎有 60% 從那裡學來的。
分析後怎麼展現:Amplitude 的視覺化是完全由使用者自主設計,但ta也提供了不同行業的模板,和 google 的“千篇一律”相比是超級大的優勢。
總的來說,Segment+Amplitude 組合如果金錢允許,而你恰恰也需要一款強大的分析工具,Segment+Amplitude 是最佳選擇。如果不是,那麼去官網學習是非常非常好的學習資源,且 Amplitude 的線上 Demo 版提供所有的能力,大家可以盡情享用。 (Amplitude | The Digital Optimization System:)
3.3 其他工具
上述兩個工具幾乎是全能選手,可能日常工作中,更為實用的是一些“小而美”的工具,這裡做個簡單的一句話介紹,大家按需取用。
位元組旗下火山引擎 A/B 測試:專注於 A/B 測試。文件中心-火山引擎。
Hotjar:以熱力圖起家,後來涵蓋使用者問卷調研分析、使用者行為錄屏等分析。Hotjar: Website Heatmaps & Behavior Analytics Tools
Tealeaf:使用者行為錄屏起家,後來擴充套件到全面的客戶體驗度量的工具。
RRWeb:開源的使用者行為錄屏工具,免費但使用起來不是很順暢,體驗欠佳。
04、我的一次實踐
最後來談談我的一次失敗的實踐,這次實踐發生在半年以前,最近反思後歸於兩個主要原因:
1)同一時間段關注的指標太多。
2)向上管理做的太少,沒有爭取到足夠的資源將反饋迭代到產品中。
比如最開始在選指標的時候我們在阿里 PTECH 框架基礎上增加了自己個性化的一些指標,下圖是當時我們定義的度量模型腦圖。為了獲取圖中的這些資料,也是費勁了九牛二虎之力,導致團隊在花了大量時間之後,也只是調研了一個現狀,沒有帶來領導看得見的結果,大家也沒有成就感。
向上管理方面,領導沒看到結果,資源確實沒法傾斜,於是導致後期即使我們透過這些指標看到了一些產品需要提高的地方,也沒有爭取到資源迭代。最後整體效果欠佳。
如果讓我重來一次,可能是從業務目標出發去選擇單一指標,而不是為了顯得自己很酷而套用一整套模型,調動大規模的資源拿指標。每次迭代後看效果,直到效果有明顯呈現再向上彙報,爭取更多的資源。
05、總結
本文從一場“體驗之爭”開始,和大家一起分享了我對使用者體驗度量的重新認識,從怎麼選擇指標,到怎麼評價指標再到如何利用工具,幾乎是過去一年中關於使用者體驗的全部理解,最後以一次實踐給大家說說我踩過技術坑和非技術坑, 供大家參考。
此時已是凌晨,剛剛資料自留地的朋友發來訊息和我確認定稿,我說“正在寫,深夜思如泉湧” 。也很高興你能看到我的文章,我們下次見!
參考文章:
1)Matters of the HEART: How to Measure UI and UX Design:
2)如何度量體驗,阿里PTECH/UES模型:
來自 “ 一個資料人的自留地 ”, 原文作者:@Simba;原文連結:https://mp.weixin.qq.com/s/5-zm22syIUE4glnuZaQrfQ,如有侵權,請聯絡管理員刪除。
相關文章
- Think Different - 從蘋果的使用者體驗說JavaEye的使用者體驗蘋果Java
- 親身體驗了一把vite,感覺真的沒有說的那麼好,很多坑Vite
- 如何做到用資料說話(一)
- 別隻會說“感覺不對”了,遊戲策劃也要懂一點視覺表現遊戲視覺
- 說說敏捷大資料敏捷大資料
- 同事有話說 | 那些所謂的敏捷儀式感敏捷
- 有些大資料,我們們床上說……大資料
- 說說資料分析中的資料建模
- 說說 Python 的變數以及簡單資料型別Python變數資料型別
- 說說你對資料結構的理解?有哪些?區別?資料結構
- 說說資料庫事務資料庫
- 關於輕應用,我有話要說...
- 過元宵:你們程式設計師能不能好好說話啊程式設計師
- 說說我和Mac(二)Mac
- 說說我和Mac(一)Mac
- 四說大資料時代“神話”:從大資料到深資料大資料
- 用資料說話:北京房價資料背後的資料
- 針對Sybase資料庫無法啟動的情況,我有話要說資料庫
- 白話說框架框架
- 話說快取快取
- 資料基礎架構如何演進,西部資料有話說架構
- 資料處理,會“說話”的大機器——資料資訊圖
- OCR迴圈:說說遊戲中的挑戰與體驗遊戲
- 白話說大資料演算法C4.5大資料演算法
- 說說我對 WSGI 的理解
- 我最想對七年級的我說的幾句話
- 《蔣勳說宋詞》讀後感
- 如何說服別人?用故事代替資料
- oracle 各資料型別dump說明(三)Oracle資料型別
- oracle 各資料型別dump說明(二)Oracle資料型別
- oracle 各資料型別dump說明(一)Oracle資料型別
- 用資料說話,億級海量資料分析效能瓶頸如何破?
- 資料庫克隆實驗系列-環境說明資料庫
- 說說我眼中的IT界加班文化
- 說說我眼中的Vue和ReactVueReact
- 關於性的問題,讓大資料來說話大資料
- Elasticsearch 創始人 Shay Banon:讓資料自己說話Elasticsearch
- 跟UI好好說話UI