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

一、數據化用戶體驗的定義

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

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

• 框架層：產品的導航和信息設計，關系到內容信息的易讀性和易懂性;

• 結構層：交互方式以及信息架構，直接影響產品的易用性和使用效率;

• 范圍層：功能設計以及內容，決定用戶需求的滿足度以及產品價值傳遞;

• 戰略層：商業模式、產品模型以及目標用戶，產品原始的立足點。

下文內容將從數據的角度來說明如何去評估和定義用戶體驗。

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

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

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

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

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

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

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

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

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

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

1、APM 的 3 個方案目標

(1)對平臺各業務流程的處理結果、故障、性能等進行埋點量化，了解平臺產品與服務的性能現狀。

在這一階段，通過埋點、數據采集等方式，了解現階段狀態，比如某些報錯、加載的具體情況和表現。

(2)實現數據實時監控，快速排查并定位異常原因。

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

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

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

2、APM 的埋點部署思路

面向用戶的 APM 埋點思路是將用戶操作后，產品反饋生成的全流程進行拆解，在所有可能會出現體驗的環節進行埋點。

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

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

以上是整個方案的埋點思路，數據人員可以按照這個思路，對用戶反饋的整個鏈條中可能會面對的加載、報錯等環節，部署相應的埋點。

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

(1)業務處理結果

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

(2)報錯提示

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

(3)頁面加載失敗

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

(4)APP 崩潰

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

4、面向用戶的 APM 方案的應用思路

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

(1)故障的優化分析

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

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

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

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

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

人均報錯次數 = 報錯觸發總次數 / 報錯觸發總人數

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

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

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

報錯退出率 = 報錯后離開次數 / 報錯觸發總次數

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

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

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

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

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

圖 1 注冊報錯的退出率

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

(2)故障的監控預警

監控預警可以幫助我們去提升故障的響應速度和效率，但核心問題是如何去建這套監控預警體系。

監控預警體系搭建思路

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

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

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

監控預警體系搭建實例

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

首先，可以根據場景將預警體系分級。比如在互金理財產品中，我們可以根據營收場景、關鍵支持場景、功能場景進行劃分。營收場景包括支付、充值等，關鍵支撐場景包括注冊、體現等，功能場景包括領取優惠券、簽到等。

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

圖 2 監控預警體系搭建實例

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

神策分析的預警功能

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

圖 3 神策分析的預警功能

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

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

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

『不容錯過的精彩內容』

▼▼▼

• 海馬體照相館攜手神策數據：99.7% 的攝影滿意度，離不開專業與數據驅動

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

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

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

收藏★公眾號，及時獲取精彩內容

關注

神策數據

幫助客戶實現數據驅動。

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。