使用者體驗數字化平臺落地

作者介紹：

魏子翔，2017年7月加入去哪兒網，主要負責Android原生和跨端框架方向的研發和維護，期間主導了客戶端架構升級、穩定性提升、效能最佳化等多個重點專案，近期專注於使用者體驗最佳化治理相關事務。

一、背景介紹

（一）關於我們

我們先看下網上對數字化平臺的解釋，是指由人員、流程和工具組成的定製化平臺，即服務產品，使團隊能夠快速開發、迭代大規模運營的數字化服務。

再來介紹下去哪兒網的業務，去哪兒網是一個典型的線上旅遊平臺，它上面的業務繁多，有機票、酒店、度假、火車票、汽車票等，細分業務線多達近40個，業務功能更新迭代快、同時伴隨著產品開發人員更替、多技術棧混合使用，產品邏輯複雜多變。

（二）為什麼做體驗平臺

那麼我們為什麼要開發使用者體驗數字化平臺，其實有以下幾個方面的原因：

第一個是不同業務線對於相同指標口徑和採集方式不一致，拿頁面可互動時間指標來說，口徑上有從頁面跳轉或者從頁面建立開始採集的，採集方式上有使用插樁來也有手動埋點實現的。這樣來看會比較混亂，不同的業務線也沒辦法橫向對比，透過使用者體驗平臺，在框架層面確定一致的採集方案，並統一指標採集口徑。

第二個是對體驗維度的關注側重點不同，比如有的業務線更關注應用的穩定性，有的業務更關注應用的流暢度，透過平臺可以補齊各業務線的差異，確定不同指標的優先順序，梳理出統一的使用者體驗度量模型。

第三個也是最重要的是，客戶端作為業務的主要入口，其所提供的使用者體驗是非常重要的。雖然我們一直都在致力於提升使用者體驗，但是我們缺少系統化的定量評價的手段，清楚的說明我們的使用者體驗當前處於狀態和水平。透過該平臺可以建立一個有效的機制，讓我們對使用者體驗有量化認知，同時也讓我們的日常治理活動可觀測，更好的適應不斷變化的環境，建立可持續的技術和運營基礎。

二、體驗度量模型

既然已經知道了構建使用者體驗平臺的原因，那麼重要的就是我們的體驗度量模型，其中會包括我們的評測維度，評分標準以及如何對資料進行度量分析等。

（一）模型

接下來介紹下我們的使用者體驗度量模型：

透過上述模型我們可以看出，主要是對流暢度、穩定性、能耗、磁碟佔用和使用者反饋五個方面進行評測，對使用者使用應用相關的資料進行採集。如圖中所示每個指標有P1 P2 P3標識，這代表著指標的重要程度，數字越小越重要。級別的劃分是依據對使用者體驗影響的大小來評定的。

關於指標的選取我們是採取了業內關注+自身經驗的結合：啟動時間、崩潰、卡頓等都是業內各個大廠重點關注的指標，口徑也比較統一；除此之外我們也透過使用者投訴，整理沉澱下來了頁面30秒後臺被殺和應用發熱指標。每個指標選擇背後也都有對應的理論支撐。

流暢度指標：我們可以很容易透過業內的研究報告看到其中的價值，減少使用者可見時間，可以提升使用者留存率和交易量。

1. Google發現頁面載入時間超過3秒 53%的使用者將停止訪問

2. Amazon發現載入時間每延長1秒一年就會減少16億美元的營收

3. FPS和卡頓會帶來頁面重新整理不穩定、視覺感官畫面不連貫的問題

穩定性指標、能耗指標：導致使用者流失，減少收益，打斷使用者正常操作。

1. 切後臺短時間被殺或者使用過程發生crash，屬於中斷性的，打斷了使用者的正常操作，對使用者傷害很大

2. 手機使用期間發熱和切後臺被殺，由使用者反饋，值得關注，因為據統計，73%的效能體驗問題都是由使用者發現的，遇到問題98%的使用者會選擇沉默或離開，僅有2%的核心使用者才會進行投訴反饋。

磁碟佔用指標：減少磁碟佔用可以提升使用者轉化率。

1. 當手機儲存空間不夠用時，會優先刪除佔用儲存空間較大的app

2. Google play資料分析一個 APK 的大小每增長 6 MB，下載轉化率就有 1% 的降低，如下圖:

（二）指標評分

針對每個指標級別指標劃定不同的得分標準，用於區分不同級別在整體得分中的權重，如下圖所示：

有了上面的指標模型和得分標準，然後可以對收集上來的指標進行得分計算，下邊我就基於穩定性的 Andorid 崩潰指標介紹一下資料處理流程及計分規則：

1. 確定指標級別

Andorid 崩潰屬於 P1 級別。

2. 確定該指標值所處的好中差範圍

附：Android 崩潰率範圍 好:小於 0.04% ；中:0.04% - 0.08%；差:大於 0.08% 。

假設 Android 崩潰率為 0.05% ，那麼所屬範圍為中等。

3. 查詢指標級別和所處分數階梯

所以當前 Andori d崩潰率指標為 P1 級別中等，得分為 4 分。

（三）度量分析

根據使用者體驗的指標得分，我們可以從全域性和細分兩個維度來進行度量分析：

全域性維度

• APP全域性

• 團隊全域性

細分維度

• 團隊指標

• 頁面指標

APP 全域性維度比較好理解，只要把收集上來的資料解析處理，但是我們是怎麼對頁面以及團隊進行度量的呢，這就取決於我們在採集指標時把指標資料和頁面做了繫結，這樣頁面的得分其實就是該頁面所有指標的得分聚合，為了便於使用者使用，我們做了百分制的處理，如圖所示：

團隊的度量就更簡單了，我們把頁面和團隊進行關聯（具體的關聯方式可以關注下面講到的使用者體驗指標收集），團隊指標透過頁面指標聚合即可。

三、體驗資料收集

體驗資料的收集是要為上面的使用者體驗度量模型服務，在度量分析中有一個重要的點就是指標資料和頁面團隊的關係，這裡我跟大家聊一下指標資料的關聯處理實現。

（一）頁面歸屬

我們在上文度量模型中可以看出來，我們度量的最小維度是 APP 的頁面，那麼我們要怎麼把所有的指標都和頁面繫結呢？

其中有些指標是天然和頁面有關聯的，比如頁面的可互動時間，頁面的渲染成功率等，這種資料直接把資料所屬頁面關聯即可。但是有些指標是和頁面關聯性不大的，像崩潰和卡頓，比如在 APP 在使用者瀏覽首頁時發生了崩潰，但是真正崩潰原因是地圖元件程式碼導致的，對於這類指標我們採取的策略是和真實的使用者體驗掛鉤，還是剛才的例子，我們把這個地圖元件導致崩潰的頁面就歸屬在首頁，而不掛在地圖元件的頁面上，因為使用者感受到的就是在首頁的時候崩潰了，影響了也是首頁的使用者體驗。所以類似這種指標都以發生頁面為準即可

（二）團隊歸屬

既然指標已經可以和頁面的歸屬問題已經解決，接下來需要考慮頁面和團隊怎麼關聯，其實這個問題也好解決，我們可以給頁面生成一個持久化 ID ，然後對每個頁面 ID 關聯上頁面所屬的團隊資訊即可。那麼應該如何實現呢？

我們可以參考客戶端埋點方案，大體分為三類：手動埋點，視覺化埋點，無埋點(自動插樁)方案。類比當前的需求，需要在編譯前就要確定頁面和團隊的關聯關係，那麼可以考慮手動新增頁面ID和自動插樁注入頁面ID的方式，先來看下這兩種方案對比：

方式	手動新增	自動插樁
優勢	程式碼清晰，按需設定頁面ID，定製性比較強	業務無感接入，維護成本低，覆蓋率高
不足	業務開發工作量大，維護成本高	技術難度相比較手動新增稍高
適用場景	定製或複雜場景收集，或者針對一些邊界場景的補充	邏輯不復雜，需要覆蓋率高的場景

透過上面表格不難看出自動插樁覆蓋率高，接入和維護成本比較低，且技術難度中等，最終我們選用自動插樁的方式生成元件 ID ，整體流程如下：

1. 編譯前透過後端介面獲取頁面 ID 等資訊

2. 編譯時對頁面 Activity/Fragment/ViewController 生成 ID 值並插樁 getPageId 方法

3. 編譯後把頁面 ID 和所屬元件等資訊，透過介面傳輸到後端進行更新儲存

這樣使用者體驗資料就可以透過頁面 ID 找到所屬的團隊了，然後我們再看一下客戶端技術實現的關鍵點：

Android 端在 apk 打包的編譯期，採用 Gradle Transform + ASM 技術統一處理 class 位元組碼檔案，我們採用兩個序列的 Transform 處理位元組碼，因所有程式碼都是靜態程式碼，無法動態獲取類的繼承關係樹，TransformA 負責掃描所有類的父子關係對映表，TransformB 根據類的繼承關係，判斷是否繼承自 Activity/Fragment ，然後查詢後端統一的儲存服務，判斷其是否已生成 ID ，如果有則直接在類中插樁增加 getPageId 方法，沒有則透過我們自研的演算法生成新的 ID 值並透過後端介面更新到資料庫。

iOS 端同樣採用編譯期注入，但技術實現與 Android 有細微差異，iOS 在業務元件庫打包時注入方法：使用 clang 工具庫 libTool ，在編譯時提前預處理 .m 原始檔，透過 ast 節點資訊判斷是否繼承自 ViewController，並在其子類插入 getPageId 方法，ID 資料同樣儲存在後端資料庫進行增刪改查。

具體流程如下：

（三）指標

因為本篇文章主要介紹平臺落地，指標收集方式實現就不展開講了。這塊網上相關介紹也有很多，不過大家需要關注使用者體驗資料的收集本身也會帶來效能損耗，可以採取抽樣採集策略，但是抽樣的多少需要自己把控，過少也會導致資料的波動，至於指標的一些方案選型，業務定製化場景等相關資訊如果有需要可以評論區討論。

四、平臺運營計劃

接下我們來看看運營計劃是如何建立可持續的技術和運營基礎的。

（一）目標

我們的運營目標穩步提升公司中位線：重點推進未達標團隊達到基線標準；激勵已達標團隊不斷尋求向上突破，達成優秀/卓越更高層次目標

（二）階段

年初我們進行了數字化平臺的搭建，上線後經過了一段時間的執行，得到了使用者的良好反饋，同時也在反饋的基礎上將模型打磨的更加精確合理。模型建立後我們主要進行了以下幾個階段：

1. 試執行：接受使用者的反饋，解決邊界值情況讓資料更加精確；真實資料驗證並進行模型調整，讓度量更加準確

2. 建立基線：經過試執行的驗證之後建立基線，讓各團隊對自己的現狀有初步的掌握

3. 專項治理：基於基線進行統一提升

（三）方案

我們的運營方案主要分為以下三個部分：

1. 日常運營

對使用者使用過程中的問題進行答疑解惑同時收集使用者反饋，從而實現模型的不斷最佳化完善，主要透過以下幾個方式：

• 日常答疑；

•  建議反饋；

• 變更周知。

2. 月度彙報

透過平臺月度資料統計讓各團隊，主要負責人對數字化變動有直觀的瞭解，同時如果有問題直接暴漏出來推動改進，主要包含以下幾個部分：

• 團隊達標情況和變更趨勢；

• 各模組達標情況和變更趨勢；

• 指標、團隊排行榜；

• 三/四級團隊詳情；

• 公共/團隊改進。

如圖所示：

3. 激勵策略

每半年對在數字化中有突出進步的團隊和應用負責人進行激勵，更好的讓大家提升。

五、總結

（一）效果

1. 業務線的最佳化得到了很好的體現，下面截圖是公司某業務線專項治理的指標趨勢效果圖：

2. 應用出現體驗問題時也從指標上得到反饋，下面是客戶端卡頓問題上升後，卡頓指標趨勢效果圖：

3.最後讓我們看下全域性看板下的使用者體驗平臺效果：

（二）小結

使用者體驗數字化平臺從立項到現在已經 10 個月了，開發階段也踩過不少的坑，指標的合理性也會被質疑，度量模型也做過調整，但總體來說使用者體驗平臺帶來了很好的反饋，預期目標也已經達成：

1. 統一使用者體驗度量模型以及指標採集方式和口徑

2. 建立一個有效的機制，讓我們對研發過程有量化認知，同時也讓我們的日常治理活動可觀測，建立可持續的技術和運營基礎。

（三）展望

未來規劃主要有以下幾個方面進行最佳化推進：

1. 改善評分策略，使曲線更平穩，減少不必要的波動；

2. 收集指標相關的過程資料，整理輸出更多的治理實踐；

3. 針對不同維度的資料進行定向分析，如：高低端機。