本文根據神策數據高級分析師劉偉《產品用戶體驗數據化評估》直播整理，本文主要內容如下：
網際網路產品用戶體驗的定義用戶體驗數據化評估產品性能分析一、網際網路產品用戶體驗的定義
每一個人針對不同顏色、不同頁面、不同結構的網際網路產品，都會有一些不同的主觀感受，簡單來說這就是一種用戶體驗。但如何客觀評估用戶體驗的好壞呢？這種主觀的評價能否成為產品在後續進行迭代優化時的可靠依據呢？
比如不同的電商平臺在用戶註冊頁面，會有不同的頁面設置及風格。有些頁面簡潔明了，輸入手機號與驗證碼即可完成註冊，有些頁面具體而豐富，會讓用戶輸入用戶名、手機號、密碼等多條信息，並根據選項設置相關按鈕，完成註冊。針對如上情況，不同的用戶就會對不同平臺的註冊頁面產生不同的主觀感受。
1
「傳統」用戶體驗研究
用戶體驗研究已有一些通用研究方法。比如 Google 的用戶體驗測量框架 HEART，包括愉悅感、參與感、接受度、留存度、任務完成率五個維度。通過填寫表單及問卷的方式收集用戶數據，或是通過志願者去做用戶研究。
但這些方式的人力成本投入都非常高，一個用戶體驗的小專題研究都可能需要耗時 2~3 周，量表填寫以及數據回收也需要很多專業人員的投入。
在大數據時代，人們開始利用類似神策分析等數據採集工具去代替人力採集數據，再基於已採集的數據，即用戶在產品內進行操作或者進行互動的一些行為數據，進行用戶體驗層面的分析。
2
網際網路產品使用流程
下面通過還原網際網路產品使用流程，探索用戶體驗數據化評估的思路。
以某電商平臺 APP 的啟動和使用為例。用戶通過點擊桌面的 APP 的圖標進入 APP，根據頁面展示的各種內容進行點擊，與 APP 產生交互，下圖是一個完整的使用路徑整理。
從技術邏輯的角度而言，當用戶進入 APP 的頁面內容後，該頁面即向前端發起請求，再由服務端返回頁面內容，在前端通過頁面加載，用戶才能進行閱讀理解，然後再到進一步點擊各種 icon 等內容發生跳轉，可進入到一個完整的使用流程或者行為處理流程。
3
用戶體驗定義
在上述的產品使用流程中，包含兩類的內容，一類是用戶點擊，一類是開發者的反饋，基於此，我們引入了用戶體驗的定義：基於「操作」與「反饋」，兩個交互層面的關鍵變量，進行用戶體驗的評估、後續的數據採集以及優化標準的具體制定。
操作指在產品界面上，用戶的操作流程，屬於產品交互體驗的範疇。比如表單的互動設計是否高效，包括重點內容是否突出、按鈕操作是否便利等。
反饋指用戶操作後，產品的反饋過程與結果，屬於產品可用與性能的範疇。比如用戶提交的註冊密碼不符合規則時是否給出報錯，以及報錯文案是否提示正確等。
二、用戶體驗數據化評估
1
真實環境下的用戶操作路徑
以一個註冊頁面為例。用戶的操作路徑如下：
到達註冊頁—>輸入手機號—>獲取驗證碼—>輸入驗證碼—>輸入密碼。
在這個過程中可能遇到的問題是：密碼報錯和驗證碼過期。那用戶操作路徑就變成：
到達註冊頁—>輸入手機號—>獲取驗證碼—>輸入驗證碼—>輸入密碼—>密碼報錯—>輸入密碼—>點擊註冊—>驗證碼過期—>獲取驗證碼—>輸入驗證碼—>點擊註冊
2
用戶體驗評估兩大關鍵指標
基於上述用戶操作路徑，我們提出針對用戶體驗數位化評估的兩大關鍵指標：操作（交互）步長、操作（交互）耗時。
操作（交互）步長，即為了達到這個目標，用戶進行操作的步驟有多少？在上一個場景中——用戶從註冊頁到註冊成功的平均操作步數。
操作（交互）耗時，即用戶從註冊頁到註冊成功所需時長，在上一個場景中——用戶從註冊頁到註冊成功的平均時長，上述用戶操作路徑中的「驗證碼過期」環節，這就是產品內耗時較久環節。
（1）產品流程的操作步長分析
一個完整的產品功能流程，會有它的最短轉化路徑，即所有鏈路暢通的情況下的轉化路徑，這個路徑由業務流程、產品設計所決定，以上文註冊頁面的整個路徑為例，最短路徑即用戶正確填寫每一步信息，流暢順利完成註冊的路徑。但是實際過程中，除了最短路徑以外，還可能出現 s 型路徑（如中間出現了密碼報錯和驗證碼過期的場景），這意味著用戶在實際操作過程中，可能經歷了 n 個環節，而這 n 個環節有可能是同一個環節，經歷了 n 次。
基於路徑梳理，我們可以對交互平均深度進行分析：
由於過程中可能會出現重複與回退操作，所以轉化用戶的平均交互深度大於最短交互深度。
而最短交互路徑深度大於流失用戶的平均交互深度，是因為其中包含「跳出、中途退出」兩種情況：
跳出：用戶進入流程，但是未進行任何操作，就離開中途退出：用戶進入到流程，有了具體的操作行為後，因遇到故障、阻塞點等原因中途退出轉化用戶的平均交互深度分析，主要是為了了解轉化用戶都是在重複做哪些行為，以開戶流程為例，針對一個轉化成功的用戶，聚焦其在銀行的開戶流程可能會經歷多個環節，包括具體操作過程有多少，以及哪些環節和步驟是重複操作的等等。
神策的 Session 分析，可以完成對轉化用戶的平均交互深度分析。首先篩選出轉化成功的用戶，看用戶的平均交互深度。其次排查重複操作步驟，可以將各個環節的操作次數和佔比進行羅列，就能知道在哪一個環節和步驟進行重複操作的頻率比較高，即哪一個環節可能存在問題，有潛在的優化空間。
流失用戶最典型的表現是未完成業務流程，所以需要關注用戶到底在哪一個環節退出了整個交互流程，以及退出的比例是多少？所以針對流失用戶的平均交互深度，重點是分析各項行為的退出率，了解用戶到底在哪些環節退出。
所以，針對流失用戶的交互深度分析，可以採用兩種方法：
Session 分析：可以建立多個指標，查看各個環節的退出率的表現，然後定位需要優化的環節和低效環節路徑分析：排查重複和錯誤的操作使用場景是影響交互轉化時長的關鍵因素。從業務出發，可以確定場景的關鍵因素：
用戶屬性，比如年齡在理財 APP 的功能場景、國家在跨國電商的支付流程環境屬性，比如網絡狀態對於大多的驗證碼場景業務屬性，比如機票改期的延誤改和自願改（2）產品流程的耗時分析
神策主要通過三種方式來進行耗時分析：
漏鬥分析。以註冊轉化漏鬥為例，關注每個環節轉化時間的中位數，在整個註冊轉化的行為路徑之上，關注整體目標達成率或是各個環節的達成率，進一步觀察具體達成目標中間花費的時間以及需要重點優化的環節。
多維分析。以開戶流程的平均耗時為例，神策可以在開戶完成的事件或者開戶完成的行為這一個節點去上報整個開戶流程的耗時，還可以通過觀測它具體的耗時變化趨勢和針對耗時的關鍵因素進行分析。比如關注不同的網點註冊或者是年齡差異，通過這種更細顆粒度的多維下鑽，真正揭示一些低效環節的關鍵因素。
間隔分析。神策通過計算用戶行為序列中兩個事件的時間間隔，得到業務轉化環節的轉化時長分布。比如說 A 事件是註冊申請，B 事件是修改成功，兩個事件上報會產生一個時間節點或時間戳，用 B 事件減去 A 事件即可看作該環節的所用耗時。
三、產品性能分析
用戶某些較差的產品體驗可能由於某些錯誤文案或網絡情況等原因導致。可從數據層面，定位這些場景問題出現的關鍵因素，實現產品的性能分析。產品性能分析，具體指根據前後端交互邏輯通過核心場景的埋點數據採集，實現產品錯誤、性能與業務處理相關分析。
這三大場景用戶側的產品性能埋點如下：
錯誤類（包括網絡報錯、加載失敗、APP 崩潰等）性能類（加載時長、接口返回時長等）業務類（支付結果 & 失敗原因等）下面將以報錯為例，闡述用戶側的性能分析方法。
1
報錯的基本情況
針對報錯的基本情況，可根據核心指標或者總體指標，對其做進一步拆解。首先關注總體指標，即總的報錯次數。
總報錯次數 = 日活人數 報錯滲透率 人均報錯次數
分析報錯的用戶影響面：報錯滲透率 = 報錯的觸發人數 / 日活人數（常用 APP 啟動人數）分析各報錯的頻繁程度：報錯人均次數 = 報錯觸發總次數 / 報錯的觸發人數然後根據具體的指標表現，日活人數、報錯滲透率、人均報錯次數再進一步去分析報錯的原因。如果在整個報錯行為中有錯誤代碼，也可以根據錯誤代碼查看錯誤原因。
如果有一些錯誤代碼本身的邏輯出現問題，那就不僅需要按錯誤代碼去查看，還要按照一些常用的維度，比如網絡狀態、作業系統、作業系統版本、業務場景、接口名稱等維度方式下鑽。最後綜合具體指標還原、分析、解決問題。
2
報錯的業務影響
如何通過數據去佐證一個報錯場景對業務的影響是重中之重。在一個業務流程監控場景下，我們可以通過漏鬥分析，分析一個業務流程從開始到完整的過程中出現的報錯情況，分析阻塞點對整個流程的影響有多大。
上圖左側的流程為：註冊首頁—>輸入驗證碼—>註冊成功，可看到該業務的轉化漏鬥和目標達成率。當我們在正常的轉化漏鬥中加入「報錯提示」步驟（用戶在輸入驗證碼之後，遇到報錯提示），可得到右側的漏鬥圖。
可知前三個環節的轉化率、註冊成功率都很高，但在報錯後的註冊成功率僅約 4%。之後根據錯誤提示和錯誤原因，進行下鑽分析。
所以通過這種方式，能夠比較清晰地評估出具體的一個錯誤發生場景對業務達成會有哪些影響，以及它的影響面有多廣。
以上以應用場景為例，具體到如何實現埋點方案和數據上報還是一部分較為複雜的內容，不僅涉及接口，還涉及報錯和具體業務的處理。
3
報錯的預警搭建
神策的埋點思路是：在前端報錯、內容加載報錯等環節進行埋點監控。核心的邏輯仍以前後端的交互邏輯為例，從前端請求反饋，再到前端加載（或處理）環節，進行埋點。
以一個驗證碼或密碼輸入為例，我們會在前端判斷一些規則，比如大小寫、特殊字符是否符合該規則，如果不符，就會拋出規則報錯。如果判定沒有問題，即向服務端也就是後端發起請求，在請求的過程中，受限於網絡或接口等問題，可能會出現請求報錯，比如伺服器錯誤，此時就需要對錯誤進行分析解決。
在後端的處理過程中，有兩種情況：
自有服務：需要進行判定，然後根據返回的解決結果進行結果錯誤的提交第三方服務：根據第三方反饋的一些錯誤，進行請求結果的採集，然後判斷前端請求是否出錯，以及計算在整個過程中從服務端發起請求到訪問請求的服務端處理耗時有多少，可以進一步評估處理的耗時梳理用戶操作的行為流程，再把它抽象成事件去做埋點。下表是圍繞三大場景的產品性能分析埋點方案：
業務處理結果可以作為一個目標達成率去監控，但是無法實現時時刻刻地刷新結果，需要建立一個能夠自動提醒、自動報警的監控體系，在該體系之下，實現一些報錯監控或性能監控。
預警體系的核心點在於如何平衡報警的依據。比如跨境電商，有可能會出現一些網絡問題的報錯，或者是有一些影響力度比較小的報錯，那什麼樣的預警或範圍才是正常的呢？這個度應該如何去把控？
神策的建議是，監控預警體系搭建的思路之一是根據場景重要性建立起分級的預警體系，場景的重要性決定了預警閾值的寬鬆程度以及對應的報警觸發方式。下面我們以互金理財為例，介紹一套預警分級體系：
由圖可知，先根據不同閾值劃分不同的嚴重等級，然後選取不同的預警方式以及預警通知範圍。這些具體的閾值劃分和預警方式僅僅是一個參考，核心的思路還要圍繞各類產品類的各個場景去構建不同的預警分級體系。
神策分析內有指標預警模塊，可以根據一些特定的指標，例如流程目標達成率、流程的一些具體操作或是一個步驟的轉化率，使用預警功能進行具體的預警配置，理清預警分級的思路，實現預警體系的建立。
兩點注意事項：
預警設置避開業務數據低谷期，常見的如凌晨 1-5 點活躍人數低的時段結合業務的周期特點，做不同的預警設置，比如證券行業的交易與非交易時段設置不同閾值本次分享的內容到此結束，感謝大家的聆聽。