數據包括性能指標、監控數據以及通過埋點得到的業務數據，而數據分析是體驗優化的最後一環。
通過數據來量化當前的工作，從而證明工作是否高效，優化是否有效等問題。
量化的工作包括代碼質量和業務數據。
一、代碼質量
代碼質量的數據來源於思維導圖中的性能指標和監控體系，包括 SLA、慢響應、前端錯誤、白屏和首屏時間等，以折線圖的形式描述趨勢變化。
因爲我們組維護着大量的 Node 服務，所以指標中就會包含多個服務端數據。其中慢響應作爲我們組的北極星指標。
所謂北極星指標，也叫第一關鍵指標，是指在產品的當前階段與業務/戰略相關的核心指標，一旦確立就像北極星一樣指引團隊向同一個方向前進。
1）SLA
SLA 是指服務質量保證，參考的指標是異常狀態碼接口占比，即報 500、502、503 和 504 的接口。
其中 500 是代碼錯誤，我們可以通過日誌做排查。我們公司要求 SLA 的值要至少達到 5 個 9，即 99.999XX%。
如果要實現 6 個 9，按照我們公司每日的體量，每天只能允許 4 個以內的接口異常，維護成本比較大。
在 500 的錯誤碼中，監控接口占據了 94% 左右，主要是因爲上傳的數據量太大導致報錯，服務端限制 1M，最終在上傳時就做大小限制。
還有一個佔據了 6.2% 的錯誤接口主要是邏輯不夠嚴密，邊界條件沒有處理好，修復後就降到了 0。
502 是轉發的後端服務不存在，503 是沒有轉發或服務掛起，如果大量報，可以去找下運維。
504 是由後端服務出問題導致的超時引起的，例如數據庫因爲一條耗時的查詢語句而被掛起。
2）慢響應
慢響應是那些響應時間超過 2 秒的接口，在內部又將慢響應分爲對外業務慢響應和對內後臺慢響應，主要精力會放到對外業務上。
公司要求對外的慢響應占比要控制在萬分之 2 以內，對內就比較松，只要不是很慢，可以操作就行。
造成慢響應的原因有一種是內部邏輯慢，另一種是受調用的接口影響而變慢。
第一種就可以我們自己解決，第二種就需要找協作組配合解決了。
有一個佔了業務慢響應 67.4% 數量的監控列表接口，屬於前者，在內部會查詢一張 430W 的大表 6 次。
優化手段也很直接，就是減少查詢次數，降到 1 次，慢響應次數一下子減少了 95%。
還有個舉報接口，也屬於前者，這張表也比較大，增加查詢條件，觸發索引，就立竿見影的把速度提上來了。
該慢響應次數一下子減少了 90%。這兩個接口優化後，業務慢響應總佔比從萬分之 0.23 降低到萬分之 0.1。
有一個內容審覈的服務，由於架構缺陷導致優化成本很高，後面直接遷移後，後臺慢響應占比從最高的萬分之 98.13 降低到萬分之 9.79。
3）前端錯誤
前端錯誤就是通過監控系統蒐集到的錯誤日誌，分爲腳本錯誤和通信異常。
腳本錯誤就是 JavaScript 的異常，例如用 undefined 當對象讀取屬性。
一個項目中的腳本錯誤在修復後，從高峯的 4073 降低至246，減少了 93.96%，進一步的保障項目質量。
雖然也能蒐集圖像請求的錯誤，但是卻不能獲取到錯誤原因，可能是用了代理或靜態服務器偶爾的波動。
曾經在內容審覈的頁面，有段時間每日上報的圖像錯誤最高達到 28827，之後動態的將圖像質量降低 70%，錯誤上報量從降低至 1641。
通信異常其實也是 500、502 和 504 接口，之前的接口異常數量會包括靜態資源以及內部的服務調用。
而此處的通信異常只包含從客戶端發起的那部分接口，可以簡單理解爲其子集，不過有時候發現 502 和 504 的統計兩邊會有略微差異。
4）白屏和首屏時間
白屏就是等待白屏的時間（FP），首屏更確切的說是首次有意義的內容加載時間（FMP）。
之前做過一套性能監控系統，白屏比較好計算，而首屏比較複雜，我們這邊採用最簡單的埋點的方式。
也就是手動的在某個階段記錄首屏時間，比較麻煩的是需要將線上頁面逐個添加，不過也沒多少個，所以還能接受這個笨辦法。
以首屏爲例，1 秒內佔 72%左右，2 秒內佔 19% 左右，若以 1.2 秒爲邊界的話，那優化的空間還是蠻大的。
初步排查後，發現主要慢在 DOM 解析，這讓我蠻詫異的，經過 Chrome DevTools 的性能分析後，定位到了腳本尺寸上。
加載的腳本有點多，並且有一個 chunk-vendors.js 腳本還比較大，下載時間有點長。
因此在加載和運行時就會延長 DOM 的解析，影響白屏時間。
二、業務數據
業務數據大多來源於分佈在頁面各處的埋點，經過數據分析後能得出各類報表，可以直觀的查看業務是在增長還是下降亦或是持平。
在體驗優化後，查看下相關數據的前後變化，就能知道此次優化是否成功了。
我們組的工作效率也是業務數據的一部分，但是這塊比較難量化，不可能通過代碼行數來判別，因此就想到了需求提測率和雙月用戶滿意度評分。
1）需求提測率
公司每雙月會開一次需求討論會，羅列本雙月的需求。
我會以這份列表爲基礎，自己再開一份在線列表，記錄所有需求的狀態，並且會將不在此列表中的零碎需求也記錄。
這份列表有 5 列，包括需求名稱、線上BUG數、功能點數量、狀態和備註。
其中狀態又包括設計、提測、上線、延期等，可以一眼就能反映出需求所處的階段。
線上 BUG 數就是字面意思，而功能點數量是 QA 提供的，他們在寫測試用例時就會有這個數據。
不過沒多久，線上 BUG 數和功能點數量沒有維護起來，因爲很多管理後臺需求經常都不寫用例，而活動比較常規，結構差不多也就不會細寫。
線上 BUG 數因爲每次都比較少的，偶爾會有幾個，所以也就不怎麼寫了。
我的需求提測率是按提測狀態來統計，而不是上線狀態。
因爲有時候是需要多端聯調的，經常會碰到協作方因爲種種原因無法配合聯調或延期。
提測是指 QA 可以驗收需求，所以要說明此處的聯調問題並不是指我們寫好界面，然後等服務端給接口。
而是比如我們完成管理後臺的前後端功能，提供數據源，服務端沒有時間處理這批數據，類似於這種場景。
2）雙月用戶滿意度評分
這是一張問卷調查，滿分是 5 分，收集大家對我們組工作的反饋，對當前存在的問題可以做出針對性的優化。
需要填寫所處部門，需求類型（後臺或活動），是否達到預期，維度包括成果、溝通、響應等。
最後還有兩個可選項，就是填寫意見或建議，以及最想表揚的同學及其理由。
若是正面反饋，那自然很好；若是負面反饋，那就要總結。
在實際執行後，發現大家很少會提意見，每次的分值也差不多。
但是每次點名表揚的都比較多，大家對我們組的工作都比較滿意。
3）北極星指標
我們公司每個組都會有北極星指標（例如用戶新增數、XX營收、主動聊天率等），瞭解各個組的指標變化其實就能瞭解公司業務的變化。
公司每個組長都會要求填寫雙月的 OKR，OKR 的內容其實也是圍繞着北極星指標來的，閱讀每週的備註，也能瞭解些業務變化。
如果有條件的話，那些細分下來支撐北極星指標的各類核心指標也可以去了解下。
以會員爲例，包括日付費人數、日下單量、首次充值人數、連續包月續訂人數、會員購買 UV 等。
在更好的理解業務後，並且有數據支撐，相信能更容易、更科學的找到真正需要優化的點，做到技術賦能業務增長。