hello 大家好，相信在我們日常的工作中，常會遇到一些問題需要「數據分析」的幫助：

比如在進行方案設計時需要知道用戶行為數據來輔助決策；再比如實驗結束后，發現指標下跌但不知道原因；以及不知道方案上線后應該監測什么數據來驗證設計的有效性等等諸多場景。

那今天就通過這篇文章來幫助大家了解數據分析的基本方法。

*聲明：下方列舉的例子和方法，是我個人在工作中常用的數據分析方法，世界上沒有一種方法適用于所有人，這里提供的方法也僅供大家參考，希望每個人都可以根據自身情況因地制宜因人而異開展實踐。

更多數據分析干貨：

一、數據分析的定義

在學習任何一樣東西前，要先了解它的定義：

百度百科中對數據分析的定義是-“數據分析是指用適當的統計分析方法對收集來的大量數據進行分析，將它們加以匯總和理解并消化，以求最大化地開發數據的功能，發揮數據的作用。數據分析是為了提取有用信息和形成結論而對數據加以詳細研究和概括總結的過程。”

定義中提到數分是收集數據、整理消化并發揮作用的過程，那結合我們自身的設計行業，數據分析在設計全流程可以發揮什么作用呢？

二、數據分析在設計全流程中的作用

設計前：發現問題，發現機會點，了解不同人群用戶習慣等等

設計中：輔助在多個設計方案中決策

項目上線后：方案 ab 測試，復盤總結經驗，推測 ab 結果的原因，驗證設計價值等

三、數據分析的流程

在日常工作中，從獲得數據到作用于實踐的整個數據分析的流程是：

1. 確認問題和目標：明確要用數據去回答什么問題
2. 知道要看什么數據
3. 獲取/提取數據
4. 對獲得的數據進行清洗和處理
5. 對獲得的數據進行可視化
6. 將數據應用在業務中，回答第一步中的問題，和進一步的思考與解釋

今天，我們在短短一篇文章中無法展開講每個流程怎么做，因此今天我們就聚焦回答這個流程中最最核心的一個問題，也就是第二步——“怎么知道自己要看什么數據？？”

為什么只聚焦這一個問題？原因是其他的流程節點在各類數據分析的課程中都有詳細的講解，并且這些都是可以通過快速閱讀課程掌握的“技能”，而今天我們聚焦的“明確要看哪些數據”問題，是展開整個分析的思維核心所在。

四、案例演示

為方便理解，我們先引入「三位設計師」例子。

為了讓之后的描述更易懂，讓我們先來引入 3 個例子/場景，大家嘗試帶入下方例子的主人公視角，思考在下方的例子中，到底要收集什么數據，來幫助主人公解決問題？

設計師小 A 遇到的問題：在設計餐廳列表的篩選時，針對「餐廳品質」與「價格區間」的篩選方案，線上是將二者合并到一個篩選彈窗中，而產品經理發現這兩個篩選都很高頻，希望將這兩個篩選分成兩個篩選入口都平鋪在列表上，此時對篩選的方案二人有所爭論。小 A 難以決策到底哪種更好？

設計師小 B 遇到的問題：在餐廳詳情頁改版中，進行了三種改動：1.刪減了部分用戶不關注的標簽，2.為了首屏屏效，壓縮了首屏中點評的高度，3.增加了餐廳亮點介紹模塊。在即將上線時，他不知道如何衡量/度量的每一個改動點的數據效果，不知道如何證明這些設計改動是有效的？

設計師小 C 遇到的問題：在一次大刀闊斧的全流程改版中，針對用戶下單的每一步（頻道-列表-詳情-填寫-訂單）進行了全面的優化，既有頁面框架的優化又有信息的精簡，最終的實驗數據是下跌的，但卻不知道數據不好的原因？

讓我們帶著上述三個人的問題進入下個環節，在遇到了上述問題之后，接下來我們就要去思考，該收集什么數據來回答這些問題。

五、如何確定自己要收集什么數據？

現在，我們就來介紹數據分析流程中最重要的一步——如何知道自己要看什么數據。不同的場景需要看的數據復雜程度不同，我自己在工作中最常用的明確自己需要哪些數據的方式主要有三種：

1. 在簡單場景下，你可能只需要看某一個數據

如果我們遇到的只是一些很簡單的問題，例如只是需要看某個功能的使用率，那只用去收集個別指標數據即可。

為此，我們需要提前了解各類數據指標的定義和通常的用途。下圖為大家列出了常用的數據指標和其含義。

舉個「簡單場景」的例子，在上方設計師小 A 的例子中，設計師小 A 遇到的問是相對簡單的場景，他遇到的問題是在設計餐廳列表的篩選時，針對「餐廳品質」與「價格區間」的篩選方案，線上是將二者合并到一個篩選彈窗中，而產品經理發現這兩個篩選都很高頻，希望將這兩個篩選分成兩個篩選入口都平鋪在列表上，此時對篩選的方案二人有所爭論。小 A 難以決策到底哪種更好？

于是他決定去看以下數據：「餐廳品質」的篩選 UV、「價格」的篩選 UV，以及用戶組合同時使用二者的篩選 UV。最終發現使用「餐廳品質」篩選的人，和使用「價格」篩選的人中，大多數人都是組合同時在使用兩個篩選，因此最終考慮將這兩個篩選放在同一個面板中。

2. 在復雜場景下，你可能需要使用常見的「模型」，來幫助自己明確要看什么數據

數據分析模型就是“指標的合集體”，模型存在的意義是“指導我們在什么場景下可以組合地、有邏輯地去看一組數據”，讓自己更有章法地收集數據。

下方列舉了互聯網行業常見的數據分析模型。

當然除了根據模型知道自己需要看什么數據，也可以根據這次關注的「頁面模塊」的類型，來判斷這種類型的模塊通常會關注什么數據，如下圖提到的不同類型模塊關注的數據指標通常不同。

來源于「神策數據」《互聯網業務數據分析實戰》

接下來我們繼續以之前提到的設計師小 B 為例子，看下他是如何運用模型來明確自己要收集什么數據的。回顧設計師小 B 遇到的問題：

在餐廳詳情頁改版中，進行了三種改動：1.刪減了部分用戶不關注的標簽，2.為了首屏屏效，壓縮了首屏中點評的高度，3.增加了餐廳亮點介紹模塊。在即將上線時，他不知道如何衡量/度量的每一個改動點的數據效果，不知道如何證明這些設計改動是有效的？

于是他套用了專門度量用戶體驗的 GSM 模型，來推出為了評估設計改動帶來效果，需要收集哪些數據。如下圖，在 GSM 模型表格中的每一欄中填寫后，他就對要收集什么數據來評估改動效果了然于心。

3. 當面對模型無法解決的場景，可能需要「自建模型」來明確要收集什么數據

當面對更復雜的場景時，如果用我上述的模型都無法回答你要收集什么數據時，你就需要自己來建立模型了，大家不要被“自建模型”這個字眼恐嚇到，它其實非常簡單，跟我一起往下看。

什么場景會連常用的模型都無法解決呢？比如就像我之前提到的設計師 C，他面對的問題是：在一次大刀闊斧的全流程設計改版中，最終的實驗數據是負的，但是卻不知道實驗數據差的原因，要對實驗數據進行歸因分析。他想要推測可能是哪個改動最終導致了數據下降。

此時，用常用的模型無法解答，怎么辦？

答案是——“像偵探一樣思考！”

讓我們來回憶一下曾經看過的推理片/偵探片，一名偵探為了找到真相事實，常用的思考方法之一是“先在腦中發散出所有可能性假設，然后逐一用能收集到的數據佐證每個假設是否成立，不斷收集線索，不斷驗證假設是否成立”。（當然真實場景會比這復雜的多，這里只是想舉例子說明數據分析就像偵探推理一樣，先窮舉發散一切假設，再收集證據來驗證）

因此我們在面對非常復雜的問題時，也可以從一個結局出發（如實驗數據下跌這個結局），窮舉發散一切原因，并尋找數據來驗證原因是否成立。

有人可能會問：怎么窮舉原因呢？毫無章法的隨便發散？

不，而是有方法的去發散，在發散時，可以用到「結構化」和「公式化」的思維進行發散?！附Y構化」意思是：我們在發散原因時，事情 A 和它的原因上下之間必須呈因果關系/依賴關系，相互獨立完全窮盡，并且每一個論點都是可驗證的?！腹交挂馑际侵缚梢园凑沼嬎愎降姆绞桨l散。如下圖。

現在讓我們帶入設計師 C 的視角，思考當我們面對一次大刀闊斧的設計改版時，當最終數據下跌時，該如何找到數據下跌的原因。

小 C 在發現數據下跌后，開始發散窮舉數據下跌的原因：

第一輪發散：先排查不同渠道、不同用戶群體、新客老客之間是否有差別，最終收集數據后它發現 App 站內渠道的數據下跌。

第二輪發散：小 C 沿著 app 站內這條思路，從頁面漏斗中排查原因，發現在詳情頁上向填寫頁轉化這層漏斗數據下跌。

第三輪發散：既然詳情頁向下級頁面的轉化降低，那開始思索到底是哪個模塊導致的呢？于是在窮舉詳情頁所有能夠跳轉下級頁面的路徑后發現，其中詳情頁的套餐 A 模塊向填寫頁的轉化下降，最終將原因收窄到這個模塊中。

之后，結合本次對「套餐 A」的改動點：本次實驗將卡片上的標簽弱化并減少展示排數，同時展示的標題、副標題都更少了，猜測是這些改動點導致的數據下降，最終再結合定性用戶調研后發現，用戶確實認為自己關注的信息看不全導致下單猶豫。

最終在這一層層發散之下，小 C 終于找到了導致數據下跌的原因所在：

以上就是本文的全部內容，感謝大家的閱讀！

參考資料：

1. 《七周成為數據分析師》系列課程，作者：秦路
2. 《互聯網業務數據分析實戰》系列課程，作者：張濤