如何建立起一套有效的APP監控體系

概論：

移動APP有著自己獨特的運行環境和使用場景，相比后端服務，移動APP質量同樣需要做到可視、可控。移動APP是近幾年剛剛出現的新產品形態，如何保障 移動APP質量是一個新的挑戰和話題。今天，我們重點介紹APP端問題如何發現、如何定位、如何止損，以及如何建立起一套有效的監控體系，為APP穩定應用保駕護航。分為“端問題概述、端質量監控方案、端監控能力建設”三個章節。

1端問題概述

app客戶端產品上線前，會經過全面而且嚴謹的測試再發布到應用商店。但，發布后產品質量如何，以往更多地依賴于用戶的反饋信息。對于較大規模的app產品，測試人員無法做到覆蓋到全部的手機機型和ROM。在這種情況下，如何知道一款產品到用戶手中的質量呢？此時，需要一套完善的質量監控方案，建立一套牢固的監控體系。這樣，對線上產品的APP質量問題才能第一時間召回，并做到快速修復。

1.1常見問題

1.適配問題

客戶端測試過程中，測試工程師會覆蓋當前比較主流廠商的機型和ROM,以及市面用戶量比較大的Android/iOS版本。但，畢竟無法覆蓋到市面上所有的機型和ROM，尤其是android系統的手機。所以，用戶在下載一款app后經常反饋在自己的手機上頁面很丑，甚至有的文字重疊，控件位置顯示不正確等問題。

舉一個實際遇的問題，當app上線后收到用戶反饋，提到有些頁面滑動比較卡頓，容易造成誤點擊，用戶使用的機型是一款比較主流的手機。在獲取到用戶反饋后，測試工程師馬上找到同款手機進行復現，但未復現用戶反饋的問題。后來從用戶得知復現的手機和用戶的手機雖然相同，但是廠商自己定制的ROM版本不同，后來通過研究ROM代碼發現廠商在新版ROM中設計了一些新的邏輯處理，會直接導致app出現卡頓。研發人員對此做了適配解決了卡頓的問題。此類案例證明，務必對主流手機及ROM更新保持較高的質量敏感性，時刻關注廠商升級。快速應變，及時適配到主流機型和ROM。

2.用戶體驗問題

通常，產品經理設計產品功能時，考慮得也不一定很全面，往往抱著試錯的心態來設計產品，并希望通過用戶反饋來得知產品的好壞，以及用戶的進一步需求。一旦考慮不周，往往就是取悅一部分用戶，同時傷害到一部分用戶。舉一個實際例子，某一搜索類產品，產品經理為讓用戶在夜間瀏覽時有更好的視覺體驗，增加了夜間瀏覽模式的功能。考慮到讓用戶更方便的設置夜間模式，產品設定為晚上20點以后自動彈出一個浮層，詢問用戶是否設置夜間模式，而且一鍵即可設定，方便了用戶對夜間模式的啟用。但，產品經理忽略了一個重要的問題，晚上用戶啟用夜間模式后，第二天早上如何便捷地切換回白天模式？ 而產品并沒有在早上也設置一個浮層做一鍵切換。這樣，很多用戶在白天也開啟了夜間模式，使用體驗是很糟糕的。問題在于，切換回白天模式的功能雖然具備，但是入口隱蔽，用戶很難找到。從這個問題可以看出，產品體驗是設計出來的，需要在用戶的實際應用中得到檢驗。

3.流量問題

當前，中國的4G資費相對歐美和日韓目前還是比較高的，同時免費的公共wifi覆蓋也不高，用戶對非wifi下的移動流量消費是很在意的。那么，一款移動app產品如何利用最少的流量下提供更多的功能？通過客戶端緩存是一個常見的技術。舉一個實際例子，以小說閱讀為例，小說目錄一般是羅列很多書籍供用戶來選擇，這些書籍一般都有書籍名，數據封面圖及書籍簡介組成。一個頁面的數據有150kb，而且這個頁面是小說書單的主入口，所有關于小說的操作都要由這個頁面開始。如果用戶反復請求這個頁面，不僅造成流量的浪費也會給服務端帶來很大的請求壓力。為此，將這個頁面的數據緩存到客戶端本地，如果用戶在非wifi的網絡下就不發送請求，如果在wifi網絡環境下每間隔一定時間去服務端請求一次數據，然后將老數據刪除，并將新的數據寫到本地，以便用戶能夠獲取到最新內容。這樣，不僅解決了流量問題，也解決了一些低配手機本地內存經常不足的問題。從這個問題來看，在產品設計時多從用戶的角度出發考慮問題，用戶不一定直觀地感知到，但實實在在的增加了用戶體驗，且減少不必要的流量消費，你說何樂而不為呢。

1.2 問題特征

上節介紹了三類常見問題。有些問題是比較容易復現和解決的，也有一些問題相對是有難度的。舉幾個例子：

場景一：用戶反饋在WIFI網絡下無法發起搜素，搜索結果異常。在WIFI環境下復現，無法復現用戶反饋的問題，這時往往會歸結為網絡不穩定造成的。但用戶可能當時確實是遇到了問題，這種無法穩定復現的問題，往往歸結為偶發性的問題。

場景二：用戶反饋離線下載的小說為什么有時候還需要網絡。由于用戶離線的小說是個連載的小說，當用戶閱讀完離線的內容后，假設這時候小說有更新了，產品經理為了讓用戶能夠連續的閱讀就將產品設計成聯網發送在線請求才能繼續閱讀，這和用戶的認知就比較相違背。但，如果用戶閱讀完已經離線的部分，用戶看到書沒寫完，也會關心為何沒有新的內容呢。類似的這種問題歸結為長尾問題，需要從產品策略上持續優化來解決。

APP運行在用戶手機端，并且聯網到后端服務，許多質量問題也有其自己的獨特性。因此，需要通過不同手段，來實現問題的發現、定位和修復。

1.3 面臨挑戰

對于上述提到的問題，大家可能會問：這些問題該如何發現，對于這些問題如何確定是否做馬上修復，哪些問題才算長尾問題？這就是下面將要介紹的線上問題的召回方式和問題影響面的評估。用戶反饋是召回問題的一種方式，但是這種被動的召回不足以滿足快速召回線上問題的要求，所以搭建一整套完善的監控系統就非常必要了。

1.監控的挑戰

對于客戶端產品，一旦發布出去就很難有效的控制產品的質量。為此，產品經理和數據分析師往往在產品發布前提出的監控及統計需求，研發工程師開發設計用于監控統計目的的代碼，將用戶的行為、產品的crash等核心質量信息以日志的方式上傳到服務端，這些用戶所產生的數據就為后續分析產品及質量問題提供了原始的數據依據。

2.影響面的判斷

利用客戶端上傳的用戶日志及客戶端崩潰信息，進行統計分析。結合線上問題，可進行影響面的評估。影響面評估主要有三類，包括嚴重問題，特定場景復現問題，不影響主要功能問題。

1) 嚴重問題一般是要發小版本來修復的問題

2) 特定場景復現問題一般不會發小版本修復，但一定會在下一個版本進行修復

3) 不影響主要功能問題視下一個版本的排期進行修復或刪減掉

2端質量監控方案

由于APP載體多種多樣，產品質量問題表現形式有很多種。我們以最通用的APP為例，總結為以下幾種：

- 來自APP產品所依賴的后端服務的問題

- 來自APP產品自身的問題，包括穩定性問題，表現為： 應用crash（崩潰）、ANR（APPlication Not Responding）、網絡錯誤、請求響應時間長、用戶交互不流暢、機型、ROM適配度不夠引起的兼容性問題。

- 來自APP和后端服務之間的鏈路問題，通 常有：網絡問題造成的丟包、TCP重傳等等。

對于APP質量監控，可以從三個方向去布局一套完善的監控體系：問題發現、問題定位、問題止損。

2.1 問題發現

由于APP受用戶機型、手機ROM、網絡環境、用戶操作路徑差異的影響較大，QA無法保證在測試階段暴露所有問題，這就要求我們建立一套線上問題發現體系，及時召回已經交付到線上的移動產品。一套完善的線上問題發現體系，通常來說需要根據產品的核心業務，抽象出核心指標，實現指標量化；制定質量標準，提供實時監控報警。 

根據我們的經驗，APP應用的質量指標包括但不局限于：安裝成功率，崩潰率，ANR比例，網絡錯誤比例，請求響應時間等。質量指標與具體的應用功能緊密相關。理論上抽取指標后，如何量化是最關鍵也是最困難的一步。量化需要有效的問題信息獲取途徑，日志埋點是一種非常通用的方法，而另外一種途徑，用戶反饋， 雖然常常被開發者忽略，卻同樣重要。 

2.1.1 用戶反饋：海納百川

一款應用想要在應用市場份額中分得一杯羹，長久地留住用戶，需要依賴良好的應用功能和產品體驗。用戶反饋代表著市場對這款應用的滿意度，能夠直接反映用戶的判斷和訴求，也是這款應用迭代改進的第一手資料，前期我們可以通過市場調研等方式獲取反饋，但是受限于人力和時間成本，我們很難在用戶量巨大的時候復用此法，或者說市場調研始終只能采樣而無法全量覆蓋。 

基于上述，只有提供一個入口，讓所有用戶的反饋可以如江河入海，匯于一處，我們才能獲取到來自不同地域、不同網絡、不同機型、不同場景下的用戶反饋，進而聚類、分析、改進我們的產品。

用戶反饋的通用方法并無太多新奇之處，市面上很多移動應用都會在應用設置頁面中附上一個用戶反饋的入口，如圖2.1中百度云和愛奇藝視頻的用戶反饋界面。

我們必須要明白一點，如今快節奏的生活中，用戶愿意提交一個反饋，那這個問題對他/她來說一定是一個很大的困擾，而且他/她又是一個比較忠實的用戶，同時對這款應用抱有期待，希望開發者可以改進。所以一旦這個產品開始提供更穩定或者功能更多的收費服務來嘗試變現，那么這部分用戶會是最大的潛在群體。 

一個普通的用戶反饋頁，卻是于細微處見真章的最好實例，這兩個頁面的設計告訴我們用戶反饋的重要原則：

• 反饋入口路徑盡可能短：上述的兩個反饋入口都在應用的設備界面，進入反饋頁面需要2步操作。這一復雜度剛剛好，如果一個反饋需要用戶操作4、5步才能找到，那么用戶的熱情會被這種來自技術的傲慢消磨殆盡。

• 反饋內容的提交成本盡可能低：左側圖片中愛奇藝的用戶反饋，不僅事先列出了用戶最可能遇到的幾種問題，還在頁面下方給出了常見問題的FAQ。不要小看了這一細節，我們可以通過這樣的方式，在無形之中完成一次用戶問題反饋+調查問卷。

• 對用戶的答復應該盡可能的快：如果想要給用戶反饋的過程提供更實時的體驗，那就要求我們在用戶反饋頁面完成一個IM的功能，這對大多數處于創業階段的開發者來說并不現實，所以我們建議采用集成插件的方式來達到這一目的。 

下面推薦幾款常用的用戶反饋平臺：

1)    美洽，基于HTML5開發，只需在IOS/Android支持H5的瀏覽器中打開即可，無需安裝任何軟件程序，代碼植入，一步到位，簡化溝通流程。

2)    Udesk：支持Android、IOS以及APIcloud三大平臺，可以對用戶反饋的數據做統計分析，并展示結果。

3)    Freshdesk，致力于中小企業網站在線客服技術支持的網站，提供中小企業網站的在線服務質量和用戶體驗度。 

除了在應用中直接反饋，也可以創建用戶群（QQ，微信或其他企業級IM），針對嚴重問題可以第一時間發現，直接與用戶溝通，輔助復現、抓取問題現場信息等，這些對問題的定位和解決是至關重要的。 

2.1.2 日志埋點：秣馬厲兵

在一個移動應用設計之初，開發者通常考慮的是功能、架構、開發周期等問題，這一類問題通常直接影響應用的發布周期，但是大家往往會忽略一個重要的過程，那就是日志埋點。

為何要埋點

通過用戶反饋發現問題畢竟有一定的延時，甚至有一些線上問題會阻塞用戶反饋，例如：連續頻繁的崩潰，用戶反饋模塊自身的Bug等。要想更迅速及時的暴露問題，需要我們主動出擊，獲取用戶操作的關鍵信息。

埋點于何處

日志埋點的原則：好的埋點可以達到一夫當關萬夫莫開的效果，將所有我們需要的信息通過日志的形式打印出來，選擇性或者全量的上傳給應用的后端服務，用于支持問題發現或服務改進。

受限于APP應用的運行環境，我們不可能在所有的地方進行埋點，筆者在多年的軟件開發維護過程中，也見過由于日志添加不當引起程序崩潰問題。 

根據自身經驗，我們總結出下列日志埋點的建議：

1）由目標驅動埋點：一個移動應用，開發者或者用戶希望了解的服務指標，必須由日志埋點解決；

2）日志框架通用：應用的第一個版本在日志框架上面花的時間，直接影響后續版本的開發效率。通用和穩定是這個框架必須要考慮的問題。

3）日志上傳：對于已經獲取的埋點日志，我們必須考慮它對用戶流量及交互流暢度方面的影響——畢竟它的上傳使用的是用戶網絡，尤其是在收費的移動網絡下更要慎重。有如下手段可參考：日志壓縮和私有協議、用抽樣上傳代替全量監控；如果日志對時效性的要求不高，可以考慮采用打包整體上傳代替實時上傳的方式，甚至可以每天上傳一次。這些都需要在框架中提前做好部署工作。

4）日志安全：用戶日志中可能包含用戶個人信息、用戶行為及隱私，一旦信息泄露，可能給用戶造成經濟、安全等方面的損失，嚴重影響用戶對應用的信任。故日志安全是重中之重，目前行之有效的方法主要有加密和使用安全協議。相對于加密算法較容易被破解的風險，安全協議提供了更嚴密的保護。目前應用比較廣泛的安全協議主要有https，spdy等。

2.問題定位

線上問題的快速定位和解決可以直接縮短用戶體驗受損的時間，通常有以下幾種定位思路：

1）日志分析法

當遇到一個問題時，我們最先想到的可能就是查看日志，用戶日志是定位問題的最直接的信息來源和方法。日志分析又可以分為兩種手段：一是從統計學的角度分析大 量的問題日志，總結聚類，通過其中共性的特征，發現潛在的問題；另一種是針對某個有明確問題反饋的用戶，查詢其一段時間內的所有操作流程及結果，通過上下 文推測問題原因，也可以輔助線下復現。

當然并不是所有的問題都可以通過用戶日志定位，比如日志不全或日志提供的信息并不足以精確定位問題，怎么辦呢？那就要求我們能夠復現這一問題。

2）問題復現法

通過用戶對問題的現象描述，以及已有的用戶日志，嘗試線下復現。復現時需要關注用戶的機型，平臺，網絡類型，是否設置了代理，甚至是用戶所處的地理位置（不 同地域的運營商網絡可能有較大差異）等，結合應用所提供服務的邏輯，推測可能出現該問題的原因，盡量增加復現的可能性。

3）推測驗證法

當然，APP的問題很大程度上依賴于當時的問題環境，包括機型，平臺，網絡情況，手機安裝的應用等，都給線下復現帶來了巨大的困難。而現有的問題日志又不足 以精準定位。在這種情況下，可以通過問題的現象描述和以有的日志，推測可能的問題原因，埋點監控，通過分級發布的模式，當問題再次發生時，驗證哪個推測是 root cause。

4）上下游合作分析

有些功能需要多方合作實現，當這些模塊出現問題時，大家通力合作，可能就會離問題的解決更近一步。

3.問題止損

線上問題時時刻刻影響著用戶體驗，及時止損很有必要。問題止損不僅僅是指定位到了問題的root cause從而實現徹底解決，也包括在問題徹底解決之前，如何將對用戶的不良影響降到最低。 

對于APP產品，不能像后端服務那樣通過緊急下線/上線補丁解決問題，只能依賴于應用發版，而用戶的升級轉化也是一個比較漫長的過程。在這種困境中，云端控制和熱修復為我們帶來了曙光。下面主要闡述云端開關控制的思路。 

針對APP上影響/風險比較大的功能模塊，預先設置好開關，發生問題時，可以通過云端下發關閉指令，及時止損。云端控制是一個概念，實現方式因業務和功能而 異。受限于自身經驗，我們無法提供通用的多平臺解決方案，但是大道至簡，我們希望提醒開發者的是：從代碼設計開始，考慮應用、系統、服務三個維度的容災 性。 

一個簡單的例子：我們可以把功能開關置于一個獨立的Web Server中，APP采用輪詢或者更加精準的動態策略去訪問這個靜態文件，當服務某個環節出現問題時，只需要修改WebServer中的開關文件，關閉相關功能或者將相應的服務導向備用地址，即可快速的止損。

另外一種方式和上述方案類似，只不過實現的時候不使用訪問云端文件，而是由服務端直接向所有APP應用下發指令，用于啟停某些功能甚至調整某些內部模塊的邏輯。這種方式更直接，但是對APP的代碼的開發提出了相當高的要求：

1）  模塊間代碼耦合度要極低，從而能夠做到動態調整邏輯；

2）  如果云端控制只用于事故止損，那么就要求所有受影響的應用必須保持后臺在線或者前臺運行的狀態。不過具體到當前市場份額最大的幾個手機/移動操作系統，我們可以通過推送通知的方式的，盡可能由用戶主動喚起應用，借此來獲得下發云端命令的機會； 

我們建議開發者可以綜合考慮應用的代碼風格、業務類型、風險類型，來選擇某一止損的方案。上述兩種方案并非最優解，實際的開發過程中可能需要綜合多種方案來達到高可用服務的標準。 

同時，目前業界也涌現出一些成熟的解決方案，如iOS平臺的APP動態更新服務JSPatch(http://jspatch.com)就是一個專注于此領域的平臺，開發者可以試用、借鑒。

3監控體系建設

3.1質量標準

1.什么是質量標準：

質量標準是產品生產、檢驗和評定質量的技術依據。產品質量特性一般以定量表示，例如強度、硬度、化學成分等；所謂標準，指的是衡量某一事物或某項工作應該達到的水平、尺度和必須遵守的規定。而規定產品質量特性應達到的技術要求，稱為“產品質量標準”。--（百度百科）

客戶端作為與用戶直接與用戶打交道的產品，其用戶體驗是衡量一個客戶端的重要部分。用戶體驗包含了視覺、友好性、易用性等等方面。但是其視覺等方面很難通過量化的方式進行度量。但是產品的核心功能等卻是通過一些數據的度量來衡量產品的易用性等。因此，產品的質量標準就應運而生。

在服務類產品中，常用SLA（Service-Level Agreement）作為衡量產品服務等級的量化指標。按照業務的需求對業務的，對業務的服務指標制定量化的標準，通過量化的標準來衡量和驅動產品的服務越來越好。例如作為APP產品中的crash率，是衡量一個APP穩定性的數據指標，通過對crash率的統計數據衡量分析，來保證每個發版的APP健壯性得到保障。

2. 質量標準應如何制定：

質量標準的目的是通過對業務數據的量化與衡量來保證服務的質量，通過質量標準的衡量來推動業務質量變得越來越好。那么應該如何來制定質量標準呢？

根據百度云的經驗，質量標準的建立大致總結為：一個核心、三個階段：

一個核心：時刻以產品線的業務發展為核心

三個階段：初期階段、中期階段和進階階段

為什么質量標準的建立要圍繞發展來制定。舉個例子，比如百度錢包，錢包在初始階段，其核心的業務指標為發展用戶，那么用戶的登錄，日活等指標為錢包的最核心的指標，當時錢包還沒有APP端，顯然，更不會有Crash率等方面的標準。在錢包發展到一定階段，綁卡用戶變成了錢包的另一個核心指標。那么幫卡率變成了業務的核心發展指標。相應的核心質量標準也應該變為綁卡成功率。因此，質量標準的制定一定要圍繞業務發展為核心。

在業務發展的不同階段所設定和采納的質量標準也是不盡相同的，按照標準由粗到細，量化難度由易到難的階段一步一步發展而來的。

初期階段：業務發展的初期或者業務發展到一定的階段，通過需求或者用戶反饋來收集到產品線在發展過程中需要核心保證的top功能，這個核心的功能是一個產品生存的支柱，也就是我們需要通過質量標準來衡量我們核心業務提供的服務好壞程度。舉個例子，客戶端的崩潰情況，是每個產品線所要保證的最基本的質量防線，崩潰率的高低，決定了用戶的留存情況，因此，所有產品線都應將崩潰率作為最基本質量標準。而對于不同的產品線，則有各自自身的核心業務指標，比如手百，死鏈的情況則是關系到用戶體驗的最核心指標；下載的成功率是百度云用戶體驗的最核心指標；定位和路線的準確性是地圖最核心的用戶體驗指標。這些也就是各個產品在最初建立質量標準時最關系的方向。

中期階段：中期階段，是在初期階段的質量指標建立完之后，并且在指標的數據獲取，指標的計算公式都得到檢驗之后（尤其是得到peer角色的認可），進入到成熟階段。中期階段的目標是建立多個完整的子業務質量閉環。客戶端的呈現在用戶面前的服務能力和用戶體驗，是每個業務的綜合能力體驗，對于客戶端自身的業務、服務端的服務能力、中間網絡抖動情況都密不可分。因此，想要達到一個服務單元的完整質量閉環，必須能cover到整個業務鏈條中的每個質量節點。比如百度云的下載業務，一個完整的下載，從層級上面看，大致分為三個層級：1.APP自身下載邏輯，主要涉及到下載的重試、并發、容錯等 2. 中間業務層， 主要是在下載過程中的下載分發、防盜鏈、PASS校驗、CDN回源等等。3. 底層數據拉取，主要是分片數據的重組文件、跨機房的文件拉取等等。所以要完成一個整個下載的質量閉環，必須cover整個質量閉環的關鍵節點， 每個關鍵節點都會指定相應節點的標準，每個節點的質量好壞的變化，都會在端的質量數據中有所體現。 

進階階段：進階階段是在中期階段相對成熟之后，針對于業務復雜的每個子業務都能通過服務單元中的核心節點數據來對質量做出評價。進階階段，對于每個細節的標準都很全面。任何影響到產品體驗，和客戶端的運行質量的，都能通過數據分析得到。在中期階段，有了各個垂類業務的數據，以及在垂類的鏈條上面的關鍵節點的數據，能夠清晰的知道垂類業務的質量。對于比較復雜的業務，其每個質量節點影響的不單單是一個垂類的業務。在進階階段，通過對詳細子業務以及子業務之間的關系進行聯系與刻畫，形成了一張聯動的質聯網。

3.質量標準的用處：

質量標準的設定主要的目的是通過質量標準的驅動來驅使業務質量變好。質量標準按照覆蓋范圍來分主要分為兩大類：一是通用型，比如 crash率；二是與自身業務緊密相關的。

1)    質量標準最初級的用處：衡量業務的好與壞。通過量化的手段，對于業務的服務，APP的運營質量，進行度量。

2)    發現業務中的缺陷：通過對服務單元中的質量數據度量，發現業務質量中的薄弱環節，對于問題的發現和業務的優化提供數據支撐。

3)    業務貢獻：通過對質量數據的分析與整合，對于產品策略提供數據支撐和評判。

3.2能力指標

1. 數據獲取的能力：

基礎數據是質量標準建立的基石，數據獲取是一個產品線成熟度的一個標識。一般APP的數據獲取途徑主要有兩大類：1. 通用第三方統計平臺：例如mtj以及一些第三方的數據統計平臺，通過提供SDK的方式，對APP的運行狀態等指標進行統計上報，并給出圖形化的分析報告。2. 自身業務的數據上報：通過業務埋點或者自己編寫的SDK捕捉上報。針對自身埋點或者自己編寫SDK的方式，更加靈活。但是需要投入相應的人力和機器資源。

2. 數據分析的能力：

在數據獲取的基礎之上，數據分析是數據轉化成質量數據、質量標準的必經之路。數據分析的過程，是離散的業務數據，通過按照對業務梳理的方面進行劃分、統計聚合，變為對業務有用的數據。業務數據的分析的能力集中體現在兩個方面：1. 數據計算能力，對于離散數據的計算，需要大量的數據計算才能完成，一套高效、運行流暢的計算框架是對于大數據計算的前提。2. 業務梳理能力，需要對業務的理解和上下游串聯有比較細粒度的認識。3. 業務數據分析的能力，對于統計后的數據，能夠對應到業務的表現，并能通過數據的變化來預測或者對于平臺業務的好壞。

3. 質量數據的閉環：

質量數據的閉環是一個比較長期的過程，通過對數據的獲取、數據的分析后，得出業務中不合理或者比較薄弱的地方，通過制定合理的優化方案，對業務進行調整優化。然后循環往復來達到質量數據的閉環。

3.3數據利用

數據分析，是整個監控的最核心，也是難度最大的工作。數據分析，是結合業務的邏輯，通過基礎數據進行計算統計后，分析對應到業務邏輯。通過數據的變化，來解釋業務的變化與好壞程度。

數據可視化，是數據監控的一個效果展示。好數據展示，能保證用戶更好的分析數據的變化與數據直接的內在聯系。數據的可視化的重要程度也是不言而喻，其像發動機的潤滑油，能夠讓整個監控體系，更高效，更加順暢的運轉起來。