神策數(shù)據(jù)依據(jù)服務(wù)?1000 多家行業(yè)標桿企業(yè)的實踐經(jīng)驗推出《產(chǎn)品用戶體驗的數(shù)據(jù)化評估》白皮書，主要圍繞用戶體驗的“操作”和“反饋”兩部分對用戶體驗的數(shù)據(jù)化評估展開說明。下文將簡單介紹：

一、數(shù)據(jù)化用戶體驗的定義

用戶體驗可以從很多的維度進行定義，《用戶體驗要素》里將用戶體驗分為五個層次，具有較強的主觀性和戰(zhàn)略性。這五個層次為表現(xiàn)層、框架層、結(jié)構(gòu)層、范圍層和戰(zhàn)略層。

• 表現(xiàn)層：產(chǎn)品界面的視覺體驗，是用戶拿到一款產(chǎn)品后，對產(chǎn)品的第一印象;

• 框架層：產(chǎn)品的導航和信息設(shè)計，關(guān)系到內(nèi)容信息的易讀性和易懂性;

• 結(jié)構(gòu)層：交互方式以及信息架構(gòu)，直接影響產(chǎn)品的易用性和使用效率;

• 范圍層：功能設(shè)計以及內(nèi)容，決定用戶需求的滿足度以及產(chǎn)品價值傳遞;

• 戰(zhàn)略層：商業(yè)模式、產(chǎn)品模型以及目標用戶，產(chǎn)品原始的立足點。

下文內(nèi)容將從數(shù)據(jù)的角度來說明如何去評估和定義用戶體驗。

以某個電商購物的操作體驗流程為例。

用戶來到 APP 首頁，點擊 banner，看到商品詳情頁，之后加入購物車，這四個步驟組成一個非常常見的操作流程。但如果從用戶的角度出發(fā)，“用戶體驗”包含的內(nèi)容顯然并不止這四個步驟。

不僅僅是用戶打開首頁，點擊某個 banner，其實隨后等待頁面加載的過程也是“用戶體驗”中應(yīng)當包含的一部分。接著，用戶進入詳情頁后下滑瀏覽商品詳情，同時又會出現(xiàn)圖片信息加載的場景，最后用戶選中商品加車，獲取加車成功反饋，完成這一購物的操作流程。在此流程中出現(xiàn)的加載、報錯等都是用戶體驗范疇的組成部分。

在上述的購物過程中，用戶體驗的內(nèi)容可以被分為兩部分：一部分是用戶自己的“操作”，一部分是操作后產(chǎn)品的“反饋”。

首先，用戶的點擊、下滑等行為都是“操作”的范疇，與大眾直觀認知的“用戶體驗”一致。信息架構(gòu)是否合理高效、 操作方式是否符合習慣 / 容易學習都直接影響使用者的操作體驗，是屬于產(chǎn)品交互體驗的范疇。可以通過相應(yīng)的數(shù)據(jù)指 標來衡量操作體驗的好壞程度，比如表單填寫是否高效，購買流程是否易用等。

其次，反饋是指用戶在產(chǎn)品上操作后，產(chǎn)品給出的所有反饋體驗過程，包括系統(tǒng)是否給出反饋、反饋是否及時、錯誤后反饋提示是否合理等，直接影響產(chǎn)品或系統(tǒng)是否可用，屬于產(chǎn)品可用性的范疇。失敗反饋和反饋過慢是需要重點關(guān)注的內(nèi)容，因為這兩者都會打斷用戶體驗流程，可以用相應(yīng)的數(shù)據(jù)指標進行分析優(yōu)化。

《產(chǎn)品用戶體驗的數(shù)據(jù)化評估》白皮書中將介紹兩種評估方案，其一為應(yīng)用性能管理評估方案(APM)，該方案主要介紹如何通過數(shù)據(jù)去衡量 APP 的反饋性能以及用戶體驗的性能等；其二為功能流程交互體驗評估方案，該方案主要介紹如何通過數(shù)據(jù)的方法去對產(chǎn)品流程的優(yōu)劣、效率等方面進行評估。

由于篇幅限制，本文將主要介紹“應(yīng)用性能管理評估方案(APM)”，獲取白皮書全文內(nèi)容可點擊文末“閱讀原文”。

二、反饋評估面向用戶的應(yīng)用性能管理 (APM)評估方案

應(yīng)用性能管理(Application Performance Manangement), 對企業(yè)系統(tǒng)實時監(jiān)控以實現(xiàn)對應(yīng)用程序性能管理和故障管理的系統(tǒng)化的解決方案。通常分為針對前端用戶操作與針對后端業(yè)務(wù)運轉(zhuǎn)兩個方面，本部分主要圍繞面向用戶層面的即前端用戶操作方面的應(yīng)用性能管理方案，即如何通過埋點的方式進行分析與優(yōu)化。

1、APM 的 3 個方案目標

(1)對平臺各業(yè)務(wù)流程的處理結(jié)果、故障、性能等進行埋點量化，了解平臺產(chǎn)品與服務(wù)的性能現(xiàn)狀。

在這一階段，通過埋點、數(shù)據(jù)采集等方式，了解現(xiàn)階段狀態(tài)，比如某些報錯、加載的具體情況和表現(xiàn)。

(2)實現(xiàn)數(shù)據(jù)實時監(jiān)控，快速排查并定位異常原因。

在一些電商或理財類產(chǎn)品中，能否購物、能否投資等核心業(yè)務(wù)是其本身的強需求，需要通過實時監(jiān)控來進行預警的快速定位，在這部分將重點介紹如何搭建預警體系。

(3)通過數(shù)據(jù)分析持續(xù)迭代應(yīng)用性能與用戶體驗，為平臺業(yè)務(wù)指標(轉(zhuǎn)化率、成功率)帶來正向影響，甚至直接提升。

當了解了現(xiàn)狀、預警體系之后，接下來要通過一些指標和模型，去迭代和優(yōu)化用戶性能及體驗，最終帶來正向的影響從而實現(xiàn)商業(yè)目標。

2、APM 的埋點部署思路

面向用戶的 APM 埋點思路是將用戶操作后，產(chǎn)品反饋生成的全流程進行拆解，在所有可能會出現(xiàn)體驗的環(huán)節(jié)進行埋點。

比如用戶在 APP 注冊時，點擊“下一步”按鈕，APP 在向服務(wù)端發(fā)送注冊請求前，客戶端會對用戶填寫信息進行規(guī)則判斷，比如手機位數(shù)是否 11 位，密碼規(guī)則是否符合平臺要求等，當不符合規(guī)則要求時，就會出現(xiàn)報錯，此時我們就可以在前端報錯環(huán)節(jié)進行埋點監(jiān)控。如果前端的規(guī)則判斷沒有問題，前后端就會進行交互，向服務(wù)端進行請求，此時可能出現(xiàn)由于網(wǎng)絡(luò)信號弱等問題導致請求發(fā)送失敗而報錯，在此環(huán)節(jié)同樣可以進行埋點。就服務(wù)端而言，其內(nèi)部也會出現(xiàn)相應(yīng)的報錯并且可進行埋點的環(huán)節(jié)，但本白皮書主要聚焦前端體驗領(lǐng)域，服務(wù)端暫不討論。

服務(wù)端處理請求之后，會返回相應(yīng)的請求結(jié)果(也會有無結(jié)果返回的情況出現(xiàn)，在此不做分析)，比如點擊注冊的返回，結(jié)果可能是該手機號已注冊，即用戶收到報錯的反饋，此時可以部署埋點。另外在加載過程中，由于網(wǎng)絡(luò)環(huán)境等原因，很可能出現(xiàn)電商產(chǎn)品的圖片、H5 活動頁面等加載困難等場景，這同樣是用戶可以直接感知的領(lǐng)域，可以在此環(huán)節(jié)進行埋點。

以上是整個方案的埋點思路，數(shù)據(jù)人員可以按照這個思路，對用戶反饋的整個鏈條中可能會面對的加載、報錯等環(huán)節(jié)，部署相應(yīng)的埋點。

3、面向用戶的 APM 埋點方案

(1)業(yè)務(wù)處理結(jié)果

針對注冊、支付等核心業(yè)務(wù)，在后端部署埋點，當收到前端請求后，后端處理完成返回結(jié)果時觸發(fā)。常見的場景為:注 冊、充值、購買、實名認證等。

(2)報錯提示

在 APP、web、小程序等前端進行埋點，當前端出現(xiàn)報錯時觸發(fā)，可以將前端規(guī)則報錯、接口請求報錯，以及反饋結(jié)果報錯全部融合。因為無論是哪種報錯，實際上還是要站在用戶的角度來去進行埋點，即只要用戶在前端接收到一個彈窗報錯時，就會進行相應(yīng)的埋點。常見的場景：手機號位數(shù)錯誤，前端文案報錯，以及短視頻下拉刷新內(nèi)容，返回內(nèi)容失敗等。

(3)頁面加載失敗

在 APP、web 等前端進行埋點，頁面加載失敗時，由前端觸發(fā)，常見的場景:活動 H5 頁面加載失敗。

(4)APP 崩潰

在 APP 進行埋點，由 APP 崩潰時觸發(fā)，常見的場景：APP 崩潰閃退。

4、面向用戶的 APM 方案的應(yīng)用思路

本方案的分析應(yīng)用主要分為兩個部分，一部分是通過分析減少故障、優(yōu)化故障，比如對注冊流程中的報錯環(huán)節(jié)、注冊結(jié)果進行埋點，通過分析報錯滲透率、退出率等指標評估故障對注冊流程的影響并確定迭代優(yōu)先級。第二部分是監(jiān)控預警，指對平臺關(guān)鍵業(yè)務(wù)結(jié)果以及核心體驗場景的性能指標進行監(jiān)控，建立起一整套的預警體系，提高業(yè)務(wù)故障的響應(yīng)速度與效率，比如對注冊成功率這個核心指標進行小時監(jiān)控，出現(xiàn)異常波動時及時通知對應(yīng)負責人員。

(1)故障的優(yōu)化分析

報錯、失敗會直接導致用戶體驗流程的中斷，嚴重時導致用戶離開，阻礙轉(zhuǎn)化。因此，優(yōu)化分析的指導思路是減少報錯影響、優(yōu)化報錯體驗。

故障診斷除了分析報錯場景的基本數(shù)據(jù)，還要分析報錯對于業(yè)務(wù)的影響程度如何，比如對于轉(zhuǎn)化流程的影響、對于業(yè)務(wù)轉(zhuǎn)化的影響。可以按照下述思路進行:

第一，分析報錯影響面，常用報錯滲透率指標:報錯滲透率 = 報錯的觸發(fā)人數(shù) / 活躍人數(shù)(常用 APP 啟動人數(shù))

滲透率表示在我們產(chǎn)品的活躍用戶中，報錯或其他故障的影響面有多大，比如一百位活躍用戶中，到底有多少人會遇到這種情況。

第二，分析報錯嚴重程度，常用報錯的人均次數(shù)指標，它表示用戶遇到報錯情況的頻率如何，常常也會按接口名稱、業(yè)務(wù)場景、網(wǎng)絡(luò)類型等維度下鉆分析，找到報錯最嚴重的那批場景。

人均報錯次數(shù) = 報錯觸發(fā)總次數(shù) / 報錯觸發(fā)總?cè)藬?shù)

第三，報錯原因分析，報錯埋點時加上錯誤原因、技術(shù)錯誤代碼等信息，就能了解到各個場景故障的詳細原因。在進行技術(shù)迭代時，除了了解報錯的影響面、嚴重程度，技術(shù)錯誤原因能夠幫我們更準確地評估迭代成本，決定報錯迭代的優(yōu)先級。

第四，分析報錯對產(chǎn)品轉(zhuǎn)化的影響。在產(chǎn)品轉(zhuǎn)化漏斗中加入報錯事件，分析報錯對于最終轉(zhuǎn)化的影響。比如注冊流漏斗由注冊首頁→注冊二頁→注冊成功三個事件組成。如果我們想要分析注冊二頁的密碼設(shè)置報錯對轉(zhuǎn)化的影響，把漏斗分析改為注冊首頁→注冊二頁→密碼設(shè)置報錯→注冊成功。這時，注冊二頁→報錯的轉(zhuǎn)化率含義是本環(huán)節(jié)報錯滲透率，而將報錯→注冊成功的轉(zhuǎn)化率與原注冊二頁 - 注冊成功的轉(zhuǎn)化率進行比較，就能分析到報錯對于用戶轉(zhuǎn)化的影響。

最后，分析報錯帶來的用戶離開影響。我們可以很直觀感受到的場景是，當用戶在 APP 遇到一個嚴重報錯時，他可能因為這個報錯而離開，此時可以通過報錯退出率來進行評估:

報錯退出率 = 報錯后離開次數(shù) / 報錯觸發(fā)總次數(shù)

報錯觸發(fā)總次數(shù)很好理解，那么如何定義“報錯后離開次數(shù)”呢?我們以一個“加車流程”的案例詳細說明:

平臺上有三位用戶來購買 iPhone，A 用戶來到詳情頁就觸發(fā)了報錯，但他并沒有離開，而是繼續(xù)點擊購物車，將 iPhone 加車成功，完成支付結(jié)算。因此，報錯并沒有導致他退出詳情頁或者離開 APP。

B 用戶來到詳情頁點擊購物車，此時報錯提示庫存不足，iPhone 沒能加車成功，用戶 B 帶著不滿的情緒離開 APP。從行為上來看，報錯后用戶發(fā)生了 APP 退出的事件，所以這是一次“離開”的報錯。

C 用戶來到詳情頁后觸發(fā)活動結(jié)束的報錯，于是他不再繼續(xù)購買而選擇去做其他事情，雖然他沒退出 APP，但是已經(jīng)從購買流程(詳情頁→加車→結(jié)算)中離開，因此，我們也可以定義這是一次“離開”的報錯。

神策分析中的 Session 模塊可以靈活選擇分析哪些行為(比如只選購買流程事件時，上述 B、C 用戶的報錯都是處于行為序列的末尾)，行為切割的時間規(guī)則，因此，利用 Session 分析我們就能方便地計算出功能流程中報錯事件的退出率。進而，如果用報錯文案做維度下鉆，還能看到不同報錯事件的退出率。比如可借助退出率分析得到注冊流程內(nèi)的信息填寫情況:手機位數(shù)不足 11 位、密碼不符合大小字母規(guī)則、驗證碼錯誤等等提示造成的退出情況。

圖 1 注冊報錯的退出率

上述提到的漏斗分析以及 Session 分析都能分析報錯對業(yè)務(wù)轉(zhuǎn)化的影響，兩者有何差異呢?簡單來講，漏斗分析用于報錯對業(yè)務(wù)轉(zhuǎn)化的基本面了解，而 Session 分析用于交互過程的報錯影響。比如注冊流程中，先通過漏斗診斷報錯對業(yè)務(wù)影響，再用 Session 分析在哪個交互環(huán)節(jié)的報錯問題更嚴重。

(2)故障的監(jiān)控預警

監(jiān)控預警可以幫助我們?nèi)ヌ嵘收系捻憫?yīng)速度和效率，但核心問題是如何去建這套監(jiān)控預警體系。

監(jiān)控預警體系搭建思路

指標變動多大時候觸發(fā)報警，是預警體系搭建的核心問題。比如電商的支付環(huán)節(jié)，30 日支付成功率在 80% 左右，那么報警閾值設(shè)置多少合適呢?是 70% 還是 10% ?兩者可能都會帶來問題。

如果將報警閾值設(shè)定為 10%，那么帶來的直觀問題是輕微的故障將被忽略，只有非常嚴重的故障才會被發(fā)現(xiàn)，對于支付這樣的核心場景來說，輕微的故障也會直接帶來成交金額的損失。

而如果將報警閾值設(shè)定為 70%，雖然輕微故障也能覆蓋上，但將會發(fā)生頻繁的誤報情況。比如當支付成功率從 80% 降至 69% 時，很有可能是渠道或者其他因素造成的波動，而不是故障，相關(guān)人員仔細排查后很有可能不會發(fā)現(xiàn)故障。久而久之，大家對于報警的信任度下降，慢慢就會忽視報警信息，沒起到預警的作用。

監(jiān)控預警體系搭建實例

從上面的例子可以看到，給某個關(guān)鍵指標設(shè)置偏高、偏低的預警閾值都會有其局限性。因此，在實際搭建預警體系過程中，不能將預警直接“一刀切”，而是要進行分級處理，場景的重要性決定預警閾值的寬松程度以及對應(yīng)的報警觸發(fā)方式。

首先，可以根據(jù)場景將預警體系分級。比如在互金理財產(chǎn)品中，我們可以根據(jù)營收場景、關(guān)鍵支持場景、功能場景進行劃分。營收場景包括支付、充值等，關(guān)鍵支撐場景包括注冊、體現(xiàn)等，功能場景包括領(lǐng)取優(yōu)惠券、簽到等。

另外可以根據(jù)嚴重等級將預警體系分級。比如關(guān)鍵支撐場景和功能場景根據(jù)其嚴重程度可能只需兩檔預警等級，而營收場景則需將預警等級分為三檔，當出現(xiàn)支付成功率降至最小值等極為嚴重的情況出現(xiàn)時，將啟動最緊急的預警方式將故障信息通知所有相關(guān)人員，而在一些重要程度稍低的場景，只需通知核心成員即可，無需通知全體人員。

圖 2 監(jiān)控預警體系搭建實例

圍繞場景分級和嚴重程度分級，是搭建預警體系的核心思路。而具體的閾值設(shè)置，高效的方法是結(jié)合過往數(shù)據(jù)確定經(jīng)驗值，再根據(jù)執(zhí)行反饋結(jié)果持續(xù)迭代。

神策分析的預警功能

登錄神策分析頁面，在事件分析模型的頁面右方找到“預警建設(shè)”，點擊之后可進入如下界面。

圖 3 神策分析的預警功能

神策分析的預警功能支持自定義設(shè)定時間段，但要注意避開業(yè)務(wù)數(shù)據(jù)低谷期，常見的低谷時段如凌晨 1-5 點，如果在此時間段有 5 人進入支付頁面，4 人流失，支付成功率只有 20%，但這并不是因為業(yè)務(wù)故障，只是因為用戶數(shù)量少導致的數(shù)據(jù)波動。所以在選擇預警時間時，要注意避開業(yè)務(wù)低谷期。

另外，需要結(jié)合業(yè)務(wù)的周期特點，做不同的預警設(shè)置，比如證券行業(yè)的交易與非交易時段其用戶活躍數(shù)等指標相差很大，需要設(shè)置不同閾值。

由于篇幅限制，獲取“功能流程交互體驗評估方案”以及全本白皮書，可點擊文末“閱讀原文”下載。?

『不容錯過的精彩內(nèi)容』

▼▼▼

• 海馬體照相館攜手神策數(shù)據(jù)：99.7% 的攝影滿意度，離不開專業(yè)與數(shù)據(jù)驅(qū)動

• 重磅 |《從零到一搭建推薦系統(tǒng)指南》白皮書上線

• 一文解讀：如何從 0 到 1 打造小程序爆款裂變

• 盤它：上線 2 個月碾壓微信、抖音，音遇登頂 App Store 榜幕后的數(shù)據(jù)真相

收藏★公眾號，及時獲取精彩內(nèi)容

關(guān)注

神策數(shù)據(jù)

幫助客戶實現(xiàn)數(shù)據(jù)驅(qū)動。

↙↙↙點擊“閱讀原文”，免費下載白皮書

“在看”，你就戳戳我??

總結(jié)

以上是生活随笔為你收集整理的白皮书下载 |《产品用户体验的数据化评估》的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。