編輯導語：數據分析是推進業務項目正常進行的必要步驟之一，其中，包含了監控、觀察、分析等步驟。那麼在這些步驟中，有哪些方面是需要注意的？相應的，數據後台設計又應該如何操作？本篇文章裡，作者就數據分析與數據後台設計思路做了梳理和闡述，一起來看一下。

許多年以後，面對諸多的數字時，我一定會想起老師教我假設檢驗的那個遙遠的夏天。

模仿《百年孤獨》回憶了一下大學學習試驗統計設計課程，彼時的我對于統計學、試驗設計等枯燥的課程滿不在意，草草學習混完學分，以緻于在本科畢業做畢業設計時又不得不惡補做實驗、監控數據、觀察分析，分析數據的知識，撰寫完論文感歎總算脫離了苦海。

但是人生總是有很多“宿命”一般的輪回，當我畢業以後以為脫離了苦海，不用再和枯燥的數字和統計學打交道，然而工作後的數字依然是我離不開的東西。當開發人員每每質疑我，讓我拿出數據以及分析結論來證明我的觀點以及需求可靠性時，我就和《百年孤獨》裡的奧雷利亞諾上校一樣陷入回憶懷疑過去的選擇。

記得做畢業設計實驗時，每次緊緊地盯着實驗數據，生怕數據波動實驗出現異常。實驗結束後整理收集好的數據，每過一段時間就要對着一長串跨日的數據想有沒有問題，最後靠着人工整理成的Excel“數據後台”再進行深入分析整理，我至今都還記得使用假設檢驗流程，其中用正交試驗方法論證了結論的顯著性。勉強完成了一篇看似科學的論文，就這麼糊塗的畢業了。

而幾年後工作受挫的某一天，想起曾經也這麼“專業”地做過數據分析，為什麼現在反倒面對數據隻能望數生歎了。

于是我想着通過我寫畢業論文的這個小故事，分享一些關于數據分析以及設計數據後台的思路，不談具體的方法，從思考方向上分享一些經驗，幫助諸君找到解決問題的思路與方向帶來啟發。

首先談談數據分析的方向。

我将數據分析按照執行順序分為監控、觀察以及分析三個部分，可以理解為監控數據是觀察數據的基礎，觀察數據是分析數據的來源，分析數據是一次數據分析行為的結果。那麼就讓我們從監控數據開始。

一、監控

平時我們經常說看數據，其實看數據就是監控數據了。監控數據還沒有到觀察或者分析數據過程，監控的目的在于發現當前的實驗或者産品發展是否存在問題或者觀察效果。監控數據最大的意義在于及時發現問題以及及時調整，避免問題的産生。

之所以說監控是數據分析最初的過程，是因為數據分析的目的在于解決問題，而當前并沒有明确的問題目标需要解決的時候，監控便是最經常進行的一個數據管理環節，此時監控更加偏重于解決隐患。

以上的概念比較枯燥與抽象，不妨看看以下兩個例子來感受一下監控的意義。

遊戲是目前我們經常接觸的産品了，作為遊戲的開發者而言，監控同時在線人數，可以幫助開發者及時了解遊戲的運行情況以及評估當前服務器等資源的壓力情況。

監控同時在線人數，需要細粒度的時間，快速響應的數據計算以便幫助分析者高效且直觀地了解遊戲同時在線玩家的人數，并做好應對措施。

SLB（負載均衡）是網絡服務中常見的功能，對于運維或者服務端開發工程師而言，監控SLB是保證自身服務正常的必須步驟。

與上一例中遊戲同時在線人數監控一樣，SLB的監控需要極細的時間力度，且非常快速的數據計算，以便運維及服務端工程師及時的了解當前情況，避免服務産生異常。

監控數據是整個數據分析環節的基礎，所有的想法均來源于每一次監控獲取的信息。對于監控數據，需要達到以下幾個要求方能保證監控的質量與效率：

1. 數據計算要高時效性；
2. 數據時間粒度小；
3. 數據指标精簡，核心；
4. 以可視化圖表體現。

前兩點在舉例過程中已有說明，細粒度的時間與快速的計算相應可以及時及客觀的響應。由于監控是一個高頻的行為，我們不可能針對實驗或者産品運行中的每個關注指标都進行監控，所以監控數據時，根據目的必須挑選最為核心、重要的指标監控。

為了保證監控的效率，像我畢業設計時一樣依靠人工記錄數據的方式十分低效，因為單純的數字很難直觀地反應出數據的變化，因此好的可視化圖表可以非常有效地幫助分析者發現問題或者評估效果。

監控數據作為數據分析的基礎，是一個看起來技術含量不高但頻繁的行為，這個看似枯燥的行為需要對目标、數據極其敏感與了解，方能真正地發現問題以及客觀的評估效果。

監控的關鍵在于讓我們知道，存在問題嗎？

二、觀察

接着聊聊觀察數據。

監控數據更多在于發現問題與評估效果，由于監控數據更多聚焦于某一天的某個時段，時間周期很短，在大多數實驗以及産品運行過程中，監控的數據偏少且時間短，無法作為有效且合理的參考，此時我們需要更多的數據指标、更長周期的數據來對比、評估，這個觀察數據的行為建立在監控的基礎上。

我們當然可以不監控直接觀察數據，監控的确并不是觀察的充分條件。但是少了監控，我們會缺少更加實時、及時以及詳細的數據參考來支持判斷。因為觀察數據的目的與作用在于通過多指标、長時間的數據對比、觀察數據起伏等變化來定位發現問題或是分析是否存在問題、是否按照預期發展，相對于監控的數據更加宏觀的觀察數據更加消耗精力，但監控依然是一個非常重要的行為。

以我親身經曆的一個小故事為例子。

曾經我所負責的遊戲連續兩天用戶數都差不多，但是兩天的用戶時長卻有顯著差别。由于這兩天并沒有關注實際情況，在過了将近十天後回顧分析時一時無法得出有效的觀點。

當時的我與同伴排除了産品出現異常、産品兩天内有更新導緻功能不同等會造成兩天存在顯著變化的情況。當時負責監控用戶增長的同伴提供了一個線索，在後一天中由于遊戲政策問題會有部分用戶出現實名認證的過程，導緻玩家進入遊戲後被實名認證窗口卡在初始無法進入遊戲。

随後我們查詢了這兩天的同時在線人數曲線，發現第二天曲線比前一天要明顯低很多，而且從實名認證開始就出現了顯著的下滑。因此我們得出了以下幾個觀點。

雖然用戶進入了遊戲，但是有部分用戶未實名認證，導緻他們無法進行遊戲，有部分人因為各種原因未及時實名認證選擇了退出遊戲，因此造成了同時在線人數的下滑。

兩天統計到的用戶數量差别不大，是因為用戶都進入了遊戲，但是後一天的部分用戶因為實名認證的原因很快就退出了遊戲，造成這一天用戶的平均時長下滑。

這是一個簡單的例子，其實當時的我們完全可以憑借因為實名認證導緻用戶無法登錄進而造成用戶退出無法遊戲來解釋時長的下滑，但是這個觀點本身就需要一些數據來支持。

此時我們監控同時在線人數就能為這個觀點提供一定的支持。所以觀察數據是建立在監控數據的基礎之上。從觀察數據的過程中，我們得出了一些觀點從而找到執行策略的思路以及依據就是這個過程最大的意義。

觀察數據需要較長時間的數據、較多的數據指标進行綜合對比、評估方能針對一個問題得出合理的觀點。

指标數值的變化之所以能反應問題，是因為這個指标是目标問題具有顯著性影響的因素。很多的問題分析時，是需要确認多個因素的影響能力方能得出問題結論，所以觀察數據時對于數據的要求也更高，觀察時數據當滿足以下幾個要求時可為觀察過程提供足夠的支持：

1. 數據粒度以日為主，時間區間長；
2. 數據指标多維度、多角度；
3. 數據主要以表格體現，圖片為輔。

日粒度以及更大粒度的數據是為了觀察時有更豐富的數據便于對比，比如互聯網産品中日留存、周留存與月留存能反應産品在不同時間維度下的留存能力。

數據指标多維度多角度更多體現在需要足夠數量的核心指标幫助觀察數據時進行對比。由于前兩點的要求，此時可視化的圖相比監控數據過程重要性降低，此時數據表格可以更加便利的展示數據，當然表格 圖是更好的選擇。

同樣舉兩個例子。

上圖是友盟機型分析的示例圖，其中提供了新增用戶與啟動次數兩個核心指标，用以分析不同機型的新用戶在遊戲中的表現，進而分析不同機型用戶的質量。這是一類以聚焦日粒度為主亦可跨日分析的多指标數據。

上圖是友盟整體趨勢的示例圖，其中提供了多個體現用戶數量、留存率、時長、啟動次數等與用戶行為直接相關的指标幫助分析者觀察數據。

與上一個例子不同點在于，雖然都是多指标觀察，但是這個例子是聚焦于跨時間對比分析的數據，因為活躍、新增用戶數作為一個數值容易受推廣、活動、節假日等因素直接影響，此時不同日期的數值對比意義并不大，這時候加上留存、時長等綜合型的指标，通過不同時間的綜合對比觀察，就可以更加便捷且客觀地得出觀點。

以上兩個例子分别代表了聚焦于某天内多個影響因素以及聚焦于長時間多個影響因素的觀察行為，對于不同的觀察數據行為，在數據的呈現以及表現上也有不同。

觀察的關鍵則在于讓我知道，問題是什麼。

三、分析

最後到了分析數據環節。

我并沒有講分析數據的方法或者工具的打算，本文的目的依然是分享一些我的數據分析思路以及根據思路而衍生的數據後台設計經驗，通過思路可以幫助大家思考找到解決問題的方向與啟發。所以在分析數據這個環節依然談的還是從監控到觀察最後到分析這個過程的一些看法。

當我們觀察數據以後，此時腦海中已經收獲了不少的信息，将這些信息進行整合根據目标進行思考的過程我稱之為分析。

分析的目的與意義在于發現問題或者是驗證結論，這是兩件事。如果目标是發現問題，那麼從衆多的數據指标中、從多維度多角度的數據中發現問題，是一個主動且存在未知性的行為。而如果目标是驗證結論，那麼問題是清晰的，我們需要的是從數據中找到證據，這是一個相對被動且已知的行為。

當問題已知的情況下，不論是找到問題的影響因素還是已知影響因素來确認對問題的影響，都已經有了非常明确的目标，此時分析數據的意義就是找到支撐問題解決方法的依據或是解決方法的思路。

因為分析數據的目标在于找到解決方法，所以分析數據時對于數據的要求比觀察數據更高，根據分析數據的行為，要求更為直接：

1. 足夠的數據指标作為基礎用于分析；
2. 足量的數據（時間粒度、時間長度）作為依據；
3. 使用一定的科學方法得出合理結論。

足夠的指标以及足量的數據是為了保證在使用分析方法時有足夠的内容得出客觀的結論，否則在缺少支持的情況得出的結論依然值得質疑。

分析這個環節考驗的是分析者對于數據的掌握程度、對于問題的明确程度以及對于分析方法的了解程度。很多時候不必過于偏重于方法的賬号，對于日常中的很多問題，對問題的理解到位加上對于數據的高度理解加上簡單的方法也可以得出有效的結論。

分析方法建立在對于統計學、概率統計等數據科學的基礎上，不在結合問題與目标的基礎上盲目追求掌握方法，并不會對數據分析有太好的幫助。缺乏監控和觀察的過程，直接拿到數據也未必能有合理的判斷，因為缺少長時間觀察監控數據造成對數據的理解，很容易被先入為主的想法影響從發現問題變成驗證先入為主的想法。分析的過程已經脫離了數據後台，此時需要靠紮實的态度與數據科學知識幫助自己。

結合分析這部分，我僅以我個人的經驗總結了幾條數據分析與數據後台的想法：

1. 通過多種監控來觀察數據，通過觀察數據得出分析思路，通過分析得出結論；
2. 看數據的不同行為，提升效率的方式不同，需要後台提供不同的功能來滿足；
3. 後台更多的是為監控和觀察提高效率，分析依賴于數據分析者本身的主觀行為、能力。

最後還想分享的是，多學、多讨論，數據分析這件事通過讨論交流得來的知識與信息，往往比掌握一個看似高端而不常用的分析方法來的實在。

分析的關鍵在于讓我知道，該做什麼。

第二大部分談談數據後台的設計思路。

在了解了數據分析的過程以及各過程的目标、關鍵至後，針對不同過程，數據後台在功能的支持上也有針對性與特殊性。

在監控數據與觀察數據過程中，後台可以通過圖、表格高效的展示數據，幫助分析者在看數據時思考獲取信息，而分析數據則需要分析者脫離後台的限制根據目标問題進行分析，此時便已經脫離後台了。可以說數據後台奠定了分析數據的基石，因為所有思考分析都來源于數據後台的每一個指标、每一張圖以及每一個表格，分析過程依賴于分析者而非後台。

如今的數據類産品已經發展成為監控觀察以後台為主，分析思考以工具為主的模式。數據後台提供的是原材料，而像PowerBI、FineBI以及tableau這樣的商業智能工具成為了分析數據的利器。數據後台更多在于滿足監控與觀察，而對于分析過程而言便捷的提供數據獲取功能即可，之後的事情則需要交給具有強大分析功能的各類工具。

那麼還是從監控數據開始。

在前文舉例說明監控數據的要求時，遊戲的同時在線人數與阿裡雲SLB監控兩個例子突出了可視化圖、細時間粒度的特點，但這隻是針對了範圍很小的一些數據指标。

以一個電商類産品為例，我需要實時了解交易金額、交易筆數、同時在線人數等指标時，就需要一個更為綜合的監控界面幫助分析者快速了解情況，此時在後台的設計上則不能簡單的根據需求用可視化圖的方式羅列指标展示，因為不同指标在監控對比時時間粒度上不一樣。比如同時在線人數可以精細到分鐘粒度，而交易金額則可以到小時粒度。

根據例子中這種情況，在後台的設計上，監控環節需要根據需求針對性的設計，這裡推薦的設計思路是使用個性化可定制的監控面闆。

監控面闆可以由後台開發者事先設計好可提供的指标、圖表由分析者進行選擇組合成自己需要的樣子，可以理解為當一個Excle中放了非常多的數據，你可以自己排版各種數據與圖表，然後在一個sheet中看自己關注的内容。

這裡以友盟的分析看闆為例。

這類看闆的特點是可以先定義好所需的各類指标以及圖表，然後由分析者自己進行組合，即可滿足分析個性化的監控需求，同時還可以将不同時間粒度、不同類型指标根據各自特點設計成不同的圖或者表，從而滿足不同角色的監控數據需求。

監控類後台的特點在于盡量将需要關注的内容放在一個菜單頁面中，便于分析者快速獲取信息，不需要切換至不同的菜單。圖加表格的組合，可以充分發揮各自特點，對于數值趨勢的變化通過趨勢圖或者柱狀圖體現，輔以直接展示數值的表格，更加直觀的了解數據。

接下去的觀察數據環節在後台設計的思路上則有許多需要關注的重點。

1）圖為主和圖表結合的後台頁面設計思路

首先看幾個來自talkingdata以及GameAnalytics的示例，兩個後台均選擇了遊戲版Demo。

首先對于遊戲而言，開發者、運營者首要關注的重點均為用戶、收入，具體的指标即為用戶數量、留存、時長、收入、ARPU、ARPPU等指标。這都是典型的多指标組合的觀察需求。

由于遊戲類産品需要觀察的數據衆多，所以需要進行分類，一般來說會區分用戶類，包含但不限于活躍用戶數、新增用戶數、啟動次數、用戶時長、用戶留存等指标，而收入類指标則包含但不限于内購收入、付費人數、付費次數、ARPU（每用戶人均付費金額）、ARPPU（每付費用戶人均付費金額）、首付用戶數等指标，因為指标分類清晰且内容衆多，所以将其分類成不同的菜單有利于根據目标問題針對性的分析。

這種菜單的分類的原則就是各個指标之間的關聯性。在示例的三個後台中，均采用了圖為主的展示方式，在talkingdata後台中則還有切換圖和表的模式，但是優先展示的依然是圖。

這種後台設計思路的原因在于觀察數據時，每個指标都分别配上可視化的圖可以更直接的表現數據的變化起伏、對比多和少。每個指标都有獨立的圖展示，非常有效的為觀察數據提供了直觀的數據展示，這個比起表格有着非常直接的效率優勢。

多圖的組合可以快速的收獲各個指标的信息，以talkingdata示例圖為例，不論是跨日的趨勢分析、還是同日内的各年齡層收入分析，都可以快速地看到趨勢、多少，不同類型指标通過不同圖的組合，很容易突出各自關注的重點。收入使用趨勢圖，可以了解到近期收入的穩定性，而各年齡層收入則是集中在一天，可以快速了解對比不同年齡的付費能力，這都是圖的優勢。

以圖為主的設計思路優勢非常容易感受到，但是缺陷也非常明顯，當分析者需要多指标綜合對比觀察時，這個設計思路下分散的指标則難以将數據聚合起來，此時觀察數據時就較為麻煩。這種情況下圖加表組合的後台頁面思路便十分有效的解決了這個問題。

針對這個設計思路，請看來自友盟與天幕的示例圖。

同樣與前一個例子一樣，兩個後台數據針對指标進行了分類而分成了不同菜單，每個菜單中又是多個指标排列的情況。

友盟與天幕的後台都采用了上圖下表的設計思路，上圖的思路與前文以圖為主的設計思路類似，都是通過可視化圖直觀、高效展示數據的特點直接的為分析者提供數據。

前文也談到圖的缺點在于無法同時展示多個指标在一個圖中，每張圖能獲取的指标有限且多指标同時放在一個頁面裡圖太多且不好整合，此時友盟與天幕的示例中下方羅列了多個指标的表格則有效地解決了這個問題。

上面的圖可以切換展示下方不同的指标，且可根據指标的特點設計為突出分析思路的趨勢圖、柱狀圖或是其他可視化圖，下方則可以将這個菜單中需要分析的指标排列開，便于分析者更加全面的綜合對比分析。

為什麼會有這兩種常見的設計？似乎二者用起來并沒有很大的區别。

從用戶界面的設計角度來說，以圖為主的思路更容易吸引眼球，圖加表的模式相對枯燥。從使用者體驗來說，區别則很大。以圖為主的模式，将各個指标用圖的方式展示，并分散開，和監控數據非常類似。每個指标通過圖都可以快速的獲取到超過數值帶來的多或者少的信息。

以前文GameAnalytics示例圖為例，收入分析中通過圖不僅快速了解了當前收入、付費人數次數、ARPU等數值，還看到了這幾個指标的發展趨勢，用圖快速的提供了每個指标數值加變化兩種信息。下圖天幕示例圖同樣展示了類似的收入指标，但是采用的是上圖下表的組合。

這裡的圖隻展示了一個指标，分析者需要通過表格方能快速獲取各個指标數值信息。

這種設計思路下的對于分析者的思考而言，更多提供的是相比分散的圖更加綜合的多指标對比信息。分析者可以快速地從表格選擇衆多指标，與不同時間的同指标進行對比，而分析某個指标之時可以切換上方的圖來分析具體指标。從單個指标的分析效率上來說弱于以圖為主的方式，但是想要更加全面的分析時，表格的優勢就非常明顯了。

二者最大的區别在于獲取數據信息時，關注點集中于某個指标的程度多還是少，一次想要獲取的指标數量多與少，綜合對比的程度強與弱。

區别可以說清楚，但是真正在設計做選擇時，并沒有明确的邊界用以選擇。

對于以上區别，在實際設計中還是要根據使用者的習慣以及産品本身來選擇。比如說像阿裡雲一樣的運維工程師常用的數據後台，監控需求是遠大于觀察與分析數據需求的，此時除了監控數據的界面設計需要圖，日常觀察的一些數據也可以多以圖為主，在日常觀察過程中便于從變化中發現隐患。

像遊戲或是常見的資訊、工具類軟件的數據後台，通常會是不同類型的指标羅列綜合分析，此時輪流把每個指标的圖看過去，反倒不如通過表格來展示。

觀察數據與監控數據最大的不同在于數據内容更多，數據指标數量更多，日常分析時對于數據内容需求的多和少即是判斷後台頁面設計的基礎準備，多則以圖加表為主，少則以圖為主。

判斷标準不唯一，關鍵還是在于設計者需要充分考慮分析者對于數據信息量的獲取需求進行判斷。

2）數據和表格

日常在表格中展示的數據一般有兩種，一種是以時間維度展示，另一種則是以某個分析對象為目标展示，具體看一看以下的例子。

阿裡雲支出的示例圖中展示的是某個月各項服務的支出，talkingdata渠道分析展示的是某時間段内各個渠道的新增用戶、收入、留存等指标。在分析的目标重要性優于時間時，此時數據的分析角度優先時當前的目标其次才是時間。

就阿裡雲支出例子而言，此時關注當月各項服務的支出，是優于各項服務在各月的支出；talkingdata的這個例子中，關注渠道用戶質量優于各個渠道每天的用戶數據。

這個以表格為主的設計，是為了滿足非常具體的分析需求而産生的。在上一部分中談到了圖加表的設計思路，這時提供了非常綜合的數據信息，多出現在以時間優先的數據中。而當時間不再是第一關注重點時，此時直接體現數據方面，圖則是輔助，表格成為了重點。

像上面兩個例子一樣，這種情況非常具體，出現在觀察數據的重點在于某個具體的問題，表格中不再是聚焦時間加指标的列表，而是關注分析目标加指标的列表，此時多以表格的方式直接展示數據，就算有可視化的圖，也不再是常見的趨勢圖或者柱狀圖，而是餅狀圖或者直方圖，用來展示當前分析目标中各個因素的組成以及組成數值的多少，這樣偏重分析結果的圖反倒不重要。

這裡體現了兩種不同的數據分析思路，前一點中談到的後台設計思路多以基于時間維度來分析，而這一點中則是反過來，基于具體的分析目标之後才是時間維度，所以最後在數據的呈現上前者是時間序列的表格，後者時間成為了數據的一個屬性，表格是目标的組成因素。

兩種分析思路決定了後台不同的設計。反過來後台不同的設計對于使用的分析者而言帶來的功能效果也不一樣，前者突出通過時間來對比分析，後者弱化時間，突出對比同一個目标下的不同因素。

3）分析

分析數據的環節是數據分析整個過程中最重要的過程，這個過程脫離了後台帶給分析者的内容，依賴于分析者自身的思考。從後台設計的來說，除了前文談到的思路之後，針對分析這個環節隻需要考慮做好數據導出功能，可滿足分析者方便的自行組合整理數據即可。

洋洋灑灑數千字下來，最後做幾句總結。

1. 分析應該脫離于後台的束縛，以問題為核心進行思考；
2. 如果是用數據驗證猜想，在使用數據分析方法的同時注意數據足夠多、指标足夠豐富；
3. 如果是通過數據發現問題，在對比、觀察的同時注意無特殊情況下的異常起伏；
4. 如果是使用數據得出一些結論，小心先入為主的限制，盡量從數據的變化中總結行為，根據行為闡述結論，盡可能減少主觀的影響。

以上是筆者自己數據分析的一些經驗之談，比較抽象，但是筆者希望的是更帶給更多人啟發而不是問題的答案。如果筆者的經驗之談能真的為你帶來有用的啟發，不勝榮幸；如果這通篇毫無實操性可言，多是通識性的内容讓你無所收獲，那麼請你莫吝惜言語，給予二三建議，筆者不勝感激。

本文由 @問夢孤獨 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部