導讀：大道至簡的數據分析方法論三部曲（包括數據分析方法論、數據體系構建方法論、數據治理方法論這三部分），我通過本文深入淺出得總結出了一套易學易用的數據分析方法論，讓你快速掌握數據分析方法中最核心、最常用的要點，滿足大部分的日常需求。

01 數據分析方法論

學習對大多數人而言是一件痛苦的事情，尤其看著厚厚的專業書籍、各種難以理解又缺乏解釋說明的術語定義，會讓這種痛苦加劇。但是有些書或文章能將複雜的理論用非常通俗、口語化的方式講來，讓讀者不費勁，一下就能明白。這些內容實在是讀書人的一種福音。說到底，互聯網思維中的用戶思維談了這麼久，教育、培訓類內容的創作者們也應該好好改變一下，站在讀者的角度說話了。

本文談的是數據分析方法。根據筆者對眾多企業的接觸和了解，雖然現在大部分企業都對數據越來越重視，但目前仍有相當多的企業和從業者還沒有摸清數據分析的門道，不知道自己的數據該怎麼分析，希望得專業人員的到幫助。

一、數據分析方法一點也不神秘

筆者以前學習數據分析方法時也很痛苦，看了不少書，內容很多，但難以記全，更難以運用，後來加入永洪科技給眾多企業做數據分析系統，通過大量的項目實踐，才慢慢能談得上入門。

好的方法論應該是易學易用的。現在，本文就努力嘗試用最簡單易懂的文筆，讓初學數據分析的人看完就能理解並掌握數據分析方法中最核心、最常用的要點，至少能滿足90%的日常需求。做到這一點，必須將博大精深的數據分析方法提煉成人們能記得住的3點，而不是30點，再濃縮到一篇文章的篇幅，而不是一本書的厚度。

1. 數據分兩種，維度和度量，分析就是維度和度量的組合

下面是一個最簡單的消費者購物的數據例子。

先不管這個數據表是存在excel里還是資料庫里，只關注數據本身。表裡涉及到的數據項（或者叫欄位）有「訂單ID」、「用戶ID」、「地區」、「年齡」、「訂單金額」、「訂單商品」、「訂單時間」。

這些數據項有什麼差異呢？總體而言，數據分兩種，一種叫維度，一種叫度量（或者叫指標）。上面這個例子里，「訂單金額」是度量，其餘數據項都是維度。

可以看出，度量是具體的計算用的量化數值，而維度是描述事物的各種屬性信息。我們在做數據分析時，歸根結底就是在不停的做各種維度和度量的組合，比如北京地區的訂單金額總和，21到30歲用戶的訂單金額平均數；或者單獨對維度和度量進行數學公式計算，比如所有的訂單金額總和，用戶數（用戶ID的不重複計數）等等。

從數據類型上看，度量都是數值，但是數值不一定是度量，比如訂單ID，雖然是數值，但是不是度量而是維度，而時間、文本類的數據都是維度。

有一點需要格外注意，維度和度量是可以轉換的。比如要看「年齡」的平均數，這裡的「年齡」就是度量，要看19歲用戶的訂單情況，這裡的「年齡」就是維度。對於一個數據項而言，到底它是維度還是度量，是根據用戶的需求而定的，很像量子效應，狀態只有需求確定後才會隨之確定。

另外，維度可以衍生出新的維度和度量，比如用「地區」維度衍生出一個大區維度，「北京」、「天津」都對應「華北大區」，或者用「年齡」維度衍生出一個年齡範圍維度，20到29歲=「青年人」，30到39歲=「中年人」，40到49歲=「資深中年人」。再比如上述的平均年齡，就是用「年齡」維度衍生出一個度量。

度量也可以衍生出新的維度和度量，比如用「訂單金額」度量衍生出一個金額範圍維度，100元以下對應「小額訂單」，500元以上對應「大額訂單」等等。再比如用「收入」度量和「成本」度量相減，可以得到一個「利潤」度量。

2. 做判斷用對比

下面提出一個問題：企業A今年收入8000萬，是高還是低？大家看著這個問題，應該會感到無從判斷，因為沒有參照物，即沒有對比。因此，拿到一個數據，要判斷是好是壞是高是低，必須要進行對比。

首先，企業A可以跟自己比。如果前年收入2000萬，去年收入4000萬，那今年8000萬算很好了。去年收入1個億，今年8000萬就是糟糕了。這叫縱向對比。

其次，企業A也可以跟其他人比。同行的幾家競爭對手企業今年都收入幾個億，那企業A的8000萬就不理想。這叫橫向對比。

第三，企業A還可以對比不同的維度和度量。比如競爭對手都做全國市場，企業A只做山東市場。企業A在山東市場的收入比競爭對手在山東市場的收入高，那麼就本地區而言，企業A做的更好，而放眼全國，企業A做的就有局限。比如如果競爭對手都做了十幾年，而企業A剛做四五年，那企業A就算做的不錯，但如果成立的時間相仿的競爭對手已經過億了，那企業A就算做的不夠好。這叫綜合對比。

孩子考試考了95分，家長很高興，因為知道滿分是100分，有參照物。最近一次考試考了80分，家長會發火，因為過去的95分成了新參照物。後來一問，發現這次卷子出難了，孩子已經是班級第一了，就又轉怒為喜，這裡其他孩子就成了參（xi）照（sheng）物（pin）。

對比的參照物不同，得到的判斷結論也就不同。為了避免結論片面、不客觀，應該盡量多用綜合對比。

3. 找原因用細分

今年利潤下降了，老闆很生氣，下令查找原因，緝拿「嫌犯」。原因怎麼找呢？注意是找原因，不是找理由。很多人往往不知道如何查找原因，最後給出的都是理由。

先看一個示例的原因結論是什麼——「因為四季度華南區域洗衣機的銷量下降了，導致了今年利潤的下降」。讓我們分析一下這個原因有什麼特點。

我們會發現，這個原因是由時間、區域、產品這三個維度和銷量這一個度量組成的，於是我們可以知道，對於問題原因的查找定位，本質上就是在回答哪些維度下的哪些度量的下降或上升，導致了問題的發生。

這就是在做細分。

我們可以按維度細分，有多少維度，就可以有多少種細分的方向。比如看是去年所有月份都下降了，還是只有某幾個月下降。如果是後者，那麼就可以縮小查找的數據範圍。聚焦到這幾個月後，可以再看是哪些區域下降了，進一步細分。

入手的維度的先後順序影響不大，問題原因涉及的維度也無法預知，因此可以從任意一個維度作為入口開始進行細分。

如果出問題的指標有相關的先導指標，則要想進一步挖掘問題原因，細分後還要看不同的度量，比如上述的原因結論示例是「因為四季度華南區域洗衣機的銷量下降了，導致了今年利潤的下降」，問題是「利潤」而原因是「銷量」，因為利潤是通過別的度量計算衍生出來的。

細分無止境，細到什麼地步才夠呢？答案是，到可操作的區間才夠。

比如就細分到「四季度利潤下降，其它季度沒有下降」，還是沒有解決問題的辦法，必須細到哪個時間段哪個區域哪條產品線，直到細到某一個最終責任人，才具有可操作性。需要注意的是，在真實情況中，問題往往不一定只有一個原因，而是多個原因綜合起來形成的。

我司永洪科技主推的一站式大數據分析平台軟體，為什麼提供「縮放」和「筆刷」兩種交互操作，就是為了滿足「對比」和「細分」兩種場景。

舉一個例子，如下圖，左圖是各產品的收入毛利對比，右圖是各品類利潤趨勢，現在用戶想聚焦到「花茶」品類下的三種產品上，看看它們的利潤如何。

這時用戶就可以使用「縮放」功能，圈選代表這3種產品的3根柱子，點擊「縮放」按鈕，這時左邊圖表只剩下這3種產品，而右邊的利潤趨勢則顯示這3個產品的利潤總和趨勢。這就是在做「細分」。

有人可能會問，這個效果很類似篩選，為什麼不在旁邊放一些篩選器來實現呢？篩選器可以有，但現實情況中，當我們在一個圖表上發現問題，不一定就能很容易地找到與其對應的篩選條件，尤其是散點圖。因此，直接在圖表上選擇會非常方便高效。

再舉一個例子，下圖是產品利潤趨勢分析，用戶發現從2009年7月開始，利潤有連續4個月的下滑（如紅框所示），用戶想知道為什麼。

這時用戶就可以使用「筆刷」功能，在趨勢圖上選中這4個月的點，點擊「筆刷」按鈕，同一報告頁面的其他圖表就會淡化，然後突出顯示用戶選中的7到10月在這個圖表上的佔比，所以下圖中左邊的圖表高亮顯示出的矮的綠柱子，就是這些產品在這4個月的銷售收入。

與「縮放」不同，「筆刷」方便用戶將局部數據和整體數據進行對比。因為在上面這個例子中，單純看哪些產品這4個月銷售收入的絕對值低，並不能說明什麼，有些產品本來賣的就少，一定要看哪些產品在這4個月相對表現不好。

先判斷數據好不好，再分析原因是什麼，數據分析的環節鏈條基本就算完整了。

二、怎麼看待機器學習/數據挖掘等這類高大上的內容？

什麼時候去碰機器學習/數據挖掘這樣高大上的內容？一句話，先把上述的數據發分析方法做到遊刃有餘，再搞那些高大上的。不要迷信複雜的演算法，很多企業內部數據分析的大拿，往往都是深度理解業務，用的都是普通的計算方法，就能完成很精彩實用的分析過程。

機器學習/數據挖掘等什麼時候會用到？簡單而言，數據項多到人眼看不過來的時候會用到。如果總共就十來個數據項，每個拿出來單獨出張圖看一眼就看出端倪了，其實就不太需要用挖掘演算法。如果總共幾百個數據項，想看某一個數據項是受哪幾個數據項影響最大，人眼看不過來，用挖掘演算法就比較合適。

02 數據體系構建方法論

與「不知道該怎麼分析」一樣，「不知道該分析什麼」同樣是很多人常問的問題之一。事實上，如果知道了方法，雖然不能做到沒有一蹴而就，但是也能明晰如何一步步堅實地打造屬於自己的數據體系路徑。

與第一篇文章一樣，本文會用最簡單質樸的語言來講清楚數據體系構建的路徑。簡單來講，就是先梳理出數據指標體系，再將其落地到BI（商業智能，其實叫業務智能更對味）系統里。

三、由上至下地梳理數據指標體系

1.確定目標

這是第一個應該問自己的問題。花大力氣做數據分析，最終為了什麼呢？如果這都沒想清楚，那數據體系肯定無從下手。

是想提高用戶活躍度、增加用戶、增加銷量，還是別的什麼目標？這麼一想，好像我都想要。都想要沒有問題，但是會讓工作的邊界無限蔓延，導致事情無法推進。所以，應該從最關心的那個目標/KPI入手。

那麼，什麼問題才是我們最需要關心的目標呢？

對於不同領域、不同階段的公司和不同角色的用戶而言，這個問題的答案都不一樣：對於很多公司老闆來說，利潤就是他們最關心的目標；對於非售賣產品/服務的公司或政府而言，也許客戶滿意度是最關心的目標；對於交易平台類公司或早期電商公司而言，利潤不是重點，交易量是最關心的目標。

最關心的目標搞定了，下面是不是可以解決都想要的問題了呢？並不是這樣。大數據帶來的最大一個誤區就是數據量和欄位數越多越好。但是，在真正解決具體業務問題時，我們一定是從大數據的全集中切出相關的一個子集來使用的。

對於單人而言，無論是老闆還是執行層，同時關注的目標/KPI都不宜過多。同時看幾十個KPI，想像一下也知道會很暈，且耗費時間。但是，對企業而言確實有很多KPI都是非常重要的。這該怎麼辦？可以分解到多人，即不同角色一起協作，每個角色關注自己的目標，所有角色合在一起是公司所有目標/KPI的全集。

假設老闆最關注的目標是利潤，利潤=收入-成本，可以將這個目標分解為由銷售總監來關注收入，運營總監來關注成本。當然，並不是說老闆不能看收入，而是把常規性的關注目標鎖定在一個可行的範圍之內。

2.分解指標

目標確定了，下一步是分解出相關的指標。

針對目標，需要哪些指標來監控或分析能達成目標呢？比如利潤，相關指標就是收入和成本，當然這太粗了，收入有哪幾類，成本有哪幾類，都應該考慮進去。比如對於零售行業的銷售額，可以分解為客流量、進店率、購買率、客單價和復購率等。

所以，分解的方式有很多種，需要遵循MECE原則（完全窮舉，相互獨立）。

3.細化欄位

針對指標的計算公式，涉及到哪些欄位，分別在哪些庫的哪些表裡，是否需要數據清洗，清洗規則是什麼等。

比如購買率，是通過公式「購買人數/進店人數」算出來的，購買人數又是對「客戶ID」進行計數計算得出來的，這些指標涉及到的欄位對應到資料庫里哪張表的哪個欄位，需要梳理清楚，這部分就需要IT人員或資料庫管理員的介入和配合了。

4.非功能需求

上述第3步完成之後，我們其實已經算是梳理完了指標體系，可以落地了，但為了讓最終形成的數據系統更加完備、友好、可用，還需要一些非功能需求的梳理。

UI：偏好什麼樣的展示風格，這點看著無關緊要，但實際上用戶每天都會與數據系統打交道，美觀、體驗好的系統UI會讓用戶更加喜歡。

頁面流：哪些相關指標擺放到同一個報告頁面上，頁面之間的層次關係如何，用戶可以在頁面之間如何跳轉。

許可權：誰能看哪些數據範圍，誰能看哪些欄位和指標，需要有統一的許可權控制，避免出現數據安全問題。

ETL：數據從數據源同步到分析系統的頻率如何，規則如何。

集成：是否需要在界面、預警消息等層面與其它系統進行集成。

性能：看不見摸不著，但是直接決定系統可用性。如果數據量大時需要幾分鐘甚至幾十分鐘才能看到結果，相信這個系統就不會有人願意用了。

5.系統實施

上述4項完成之後，我們就形成了《數據運營系統需求文檔/實施方案》，即可落地到數據運營系統里，然後，再根據報告頁面數量、數據準備複雜度等確定工作量和時間計劃。

三、由下至上地實施落地到BI系統

1.連接數據

根據需求文檔/實施方案，一步步進行系統搭建工作。這個系統有的企業稱之為大數據平台，有的企業稱之為BI系統。大數據平台的範疇會更廣一些，但對企業數據化運營而言，BI一定是核心構成。

那麼，無論是開發還是基於像永洪科技一樣的第三方工具快速實施，系統搭建的第一步都是連接各個數據源，打通和各個數據源之間的通路。

在企業里，數據環境往往是異構的，數據源可能包括資料庫、Hadoop系列平台、Excel文件、日誌文件、NoSQL資料庫、第三方介面等，需要對每種數據源都有快速友好的對接方式。

最終，我們在系統里能看到所需要的各個數據源中所有的表格和欄位。

2.數據處理

數據源里的數據往往是有或多或少的不規範性存在的，比如有重複記錄，比如有遺漏的空值，比如有明顯不合理的異常值（比如有2020年的成交訂單），還可能有同一個事物在系統中存在多個名稱的情況。

這些數據如果不做一些處理或稱之為清洗的工作，是會對分析的準確性產生很大影響的，所以需要做些預處理。這個過程往往是最耗時、最枯燥的，但也是十分重要的。

作者提醒：這個環節的問題將在下一篇《大道至簡的數據治理方法論》文章中再深入探討。

3.數據建模

數據處理好了，下一步就該做數據建模了。

一提到建模，非技術背景的用戶就生畏，覺得高深不可理解。其實建出的模是個什麼東西呢？簡單來講，把多張表關聯到一起，就是一個數據模型。

比如，公司要做績效分析，需要員工的工齡、學歷、項目數、項目金額、項目利潤率等指標，其中工齡、學歷在個人信息表裡，項目數、項目金額在項目表裡，項目利潤率在財務表裡，這三張表有個共同欄位「員工編號」，通過這個欄位把這三張表關聯起來，這就是一個數據模型，一個績效分析主題的數據模型。

4.製作數據報告

基於建好的數據模型，我們就可以開始製作數據報告了。

數據模型提供了基礎數據和欄位，按照需求將它們以公式進行組合，用合適的圖表類型進行展示，將相關指標擺放到同一個報告頁面上，配置好頁面之間的層次關係和跳轉關係。以下是基於永洪科技一站式大數據分析平台製作的Demo。

5.非功能需求實現

經過第4步之後，我們的數據系統已基本成型，剩下的就是實現上述的各個非功能需求了。這樣，一個完備、友好、可用的數據運營系統就上線了。

上線並不是工作的終點，業務需求時刻都會變化或新增，需要能夠快速迭代調整，數據處理、建模、製作數據報告等操作需要高度工具化，以保證靈活可配置。第三方工具對比自開發的優勢也在這點上體現尤為明顯。

歸根結底，做數據的目的要麼是為了提升管理（節流），要麼是業務創新（開源）。一個系統化的數據體系將是數據化運營的核心支柱。

03 數據治理方法論

過往的項目中，筆者也時常遇到這樣的情況，客戶用永洪科技的產品做了一些精美專業的數據報告，卻因數據不準而影響了報告的使用價值。

前兩篇文章筆者分別探討了面對數據指標如何分析，以及如何構建系統化的數據體系，本文是「數據化運營方法論系列」文章的第三篇，重點探討的核心話題是——數據治理。

數據治理是一項基礎工作，在很多人眼中是一項苦活兒累活兒，但是越是這樣的工作越是不能忽視，基礎打紮實了，上層建築才會更穩固。

下面，筆者先從臟數據的種類及處理方法談起。

四、臟數據的種類及處理方法

首先，我們來了解一下臟數據的種類，明白我們可能會面對哪些問題。

1. 數據缺失：

缺一些記錄，或者一條記錄里缺一些值(空值)，或者兩者都缺。原因可能有很多種，系統導致的或人為導致的可能性都存在。如果有空值，為了不影響分析的準確性，要麼不將空值納入分析範圍，要麼進行補值。前者會減少分析的樣本量，後者需要根據分析的計算邏輯，選擇用平均數、零、或者等比例隨機數等來填補。如果是缺一些記錄，若業務系統中還有這些記錄，則通過系統再次導入，若業務系統也沒有這些記錄了，只能手工補錄或者放棄。

2 . 數據重複：

相同的記錄出現多條，這種情況相對好處理，去掉重複記錄即可。但是怕就怕不完全重複，比如兩條會員記錄，其餘值都一樣，就是住址不一樣，這就麻煩了，有時間屬性的還能判斷以新值為準，沒有時間屬性的就無從下手了，只能人工判斷處理。

3. 數據錯誤：

數據沒有嚴格按照規範記錄。比如異常值，價格區間明明是100以內，偏偏有價格=200的記錄;比如格式錯誤，日期格式錄成了字元串;比如數據不統一，有的記錄叫北京，有的叫BJ，有的叫beijing。對於異常值，可以通過區間限定來發現並排除;對於格式錯誤，需要從系統級別找原因;對於數據不統一，系統無能為力，因為它並不是真正的「錯誤」，系統並不知道BJ和beijing是同一事物，只能人工干預，做一張清洗規則表，給出匹配關係，第一列是原始值，第二列是清洗值，用規則表去關聯原始表，用清洗值做分析，再好一些的通過近似值演算法自動發現可能不統一的數據。

4 . 數據不可用：

數據正確，但不可用。比如地址寫成「北京海淀中關村」，想分析「區」級別的區域時還要把「海淀」拆出來才能用。這種情況最好從源頭解決，即數據治理。事後補救只能通過關鍵詞匹配，且不一定能全部解決。

五、BI對數據的要求

接下來，我們了解一下BI對數據的要求，結合上面臟數據的種類，中間的規避手段就是數據治理。

1 . 結構化：

數據必須是結構化的。這可能是句廢話，如果數據是大段的文本，比如微博，那就不能用BI做量化的分析，而是用分詞技術做語義的分析，比如常說的輿情分析。語義分析不像BI的量化分析一樣百分百計算準確，而是有概率的，人的語言千變萬化，人自己都不能保證完全理解到位，系統就更不可能了，只能儘可能提高準確率。

2 . 規範性：

數據足夠規範。這麼說比較含糊，簡單來講就是解決了上述各類臟數據的問題，把所有臟數據洗成「乾淨數據」。

3 . 可關聯：

如果想將兩個維度/指標做關聯分析，這兩個維度/指標必須能關聯上，要麼在同一張表裡，要麼在兩張有可關聯欄位的表裡。

六、數據治理的原則

前面講了臟數據的處理方法，但那些都是治標不治本的應對方法，且需要長期耗費大量時間和人力來做這種痛苦的工作。要想從根本上改善臟數據的問題，還是需要做好數據治理的規範工作。

簡單來講，數據治理就是要約束輸入，規範輸出。

1 . 約束輸入：

你永遠想不到用戶會輸入哪些值，所以別給用戶太多發揮的空間，做好約束工作。該用戶填寫的，系統必須設置為「必填」;值有固定選項的，一定用列表讓用戶選，別再手工輸入;系統在錄入提交時就做好檢查，格式不對，值不在正常範圍內，直接報錯的情況必須讓用戶重新輸入;設計錄入表單時盡量原子化欄位，比如上面說的地址，設計時就分成國家、省、市、區、詳細地址等多個欄位，避免事後拆分;錄入數據保存的數據表也盡量統一，不要產生有大量相同數據的表，造成數據重複隱患。

2 . 規範輸出：

老闆看不同人做的報表，同一個「收益率」指標，每張報表的值都不一樣，老闆的內心一定是崩潰的，不知該罵誰，只能全罵。排除計算錯誤的情況，一般都是統計口徑不一致造成的。所以要統一語義，做一個公司級別的語義字典(不是資料庫的數據字典)。所有給人看的報告上的指標名稱，都要在語義字典中備案，語義字典明確定義其統計口徑和含義。不同統計口徑的指標必須用不同的名詞。如果發現一個詞已經在語義字典中有了，就必須走流程申請註冊一個新詞到語義字典。

七、數據治理的落地

臟數據的處理需要ETL工具，語義字典不一定要藉助於系統。事實上，由於這類系統過於複雜，國內鮮見實施成功的案例，用Excel加制度就能達到很好的效果。

關於落地推廣策略，說來也簡單，老大拍板說必須實行，再用優先話語權吸引一個部門試點，再橫向擴展。哪個部門先落地，哪個部門就能按最符合自己習慣的用詞來命名指標，相當於占坑。後面的部門都要遵從前人的標準，重名但意義不同的指標需要另外找詞兒命名。這樣就不怕沒人積極主動。

以上，就是精鍊版的數據治理方法論。大家都知道這是個苦活，但是筆者還要提醒的是，越晚動手越苦。有了經驗以後，做新業務系統設計時，大家就可以充分考慮數據治理的規範了。

推薦閱讀：

相关文章