01 業務和數據的閉環

業務和數據，可以理解為映射關系，數據是業務在數字世界里的另一個它。舉個例子來說：你衣服鞋子的尺碼、喜歡吃什么口味的菜、愛看什么內容的文章、什么時候起床和睡覺等等，所有這些個人的數據都在云端被記錄著，它就是你在數字世界里的映射。網上之前流行的一句話很有意思：手機可能比你自己還要了解你。就是因為它里面存儲了一個數據的你。

我相信大家都清楚，手機用的越頻繁，越多個人的數據被記錄，它就會越好用，然后你就會用的更頻繁。業務和數據就是這樣的閉環促進關系：業務越全面、越深入的被線上化，反過來數據對業務的賦能就會越大。

• 業務數據化?
  業務線上化，存儲業務所產生的數據，記錄業務；
• 數據業務化?
  分析收集的業務數據，評估業務狀態，指導業務發展，提升效率；

▲圖1 業務和數據閉環

02 認知：數據、信息和知識

接下來我們會就其中的數據分析環節展開來講，在這之前，先宏觀的了解一下從數據到決策會經歷怎樣的一個過程。

我們時刻都在被數據所記錄著：年齡、身高、體重、消費金額、運動步數等等，如果只是單純的去看這些數字是沒有意義的，要用心去思考數字背后鮮活的業（靈）務（魂）。業務是有靈魂的！當我們從這些數字中發現業務背后的信息，再將這些數據和信息轉化成一組規則來輔助我們決策（知識）的時候，數據就會變得很有價值。這個過程就是：從數據到信息，再到決策（知識）。

跟大家舉個生活中的例子：體溫39度是單純的數字，背后的信息是發燒了，做出的決策（知識）就是需要去醫院看病。

對于上面總結的從數據到決策的過程，我們往往會說成根據數據分析的結果去做決策，雖然這樣的說法沒問題，但不夠直接，實際上我們是基于業務理解去做決策的，而數據是幫助我們加深業務理解的工具。數據賦能業務一般會經歷四個環節：數據表現、業務原因、業務策略和作用方式。最開始我們通過數據去評估業務狀態，發現業務表現異常，再全面的分析數據并結合一線的調研反饋，反復的進行猜想和數據驗證，弄清楚數據表現背后的業務原因，然后思考解決問題的策略，再落地執行，監控后續效果并不斷的迭代，直到問題被解決，業務發展進入正軌。

再就剛才提到的生病發燒的例子詳細解釋一下數據賦能業務的過程：體溫39度是數據表現，背后的身體原因是發燒了（業務原因），醫生說需要打點滴退燒（業務策略），之后你就躺在病床上，護士過來給你輸液（作用方式），這些流程走完之后，后續還會要求你持續的測量體溫（監控落地效果），如果還一直不退燒的話，可能還需要繼續去輸液吃藥（不斷的迭代業務策略），直到最后體溫恢復正常（問題被解決），身體進入健康狀態（業務發展進入正軌）。

03 業務策略的閉環

分析數據定位業務問題，基于業務理解，確定解決策略，到最終正向的影響業務，整個過程中，業務策略存在兩個閉環：邏輯閉環和業務閉環。

• 邏輯閉環
  數據分析的過程，邏輯上要閉環，論據要能夠支持結論的成立；
• 業務閉環
  策略在業務上的落地執行要閉環，不斷的調整迭代；

這兩個閉環是互相影響的，首先要做到的就是論證邏輯閉環，保證結論可以站得住腳。等真正落地執行的時候，業務上可能行不通，就需要基于新的業務理解去迭代論證邏輯，形成新的邏輯閉環，再去落地執行，直到在業務上可以跑通。

所以在數據分析過程中會常出現兩類問題：

• 邏輯閉環相關
  ?不接地氣，指的是策略的邏輯論證沒問題，但離業務上跑通還很遠；
• 業務閉環相關
  ?策略沒有落地或者落地反饋周期太長，導致業務理解只停留在當時分析數據的節點，沒有得到驗證反饋；

那我們在工作中怎么判斷業務策略是否接地氣呢？主要分成兩步：

1. 深入思考策略成立的業務假設是什么？
2. 調研判斷業務假設是否成立？

舉個例子：你設計了一套完整的針對B端商家的權益方案，希望牽引商家按平臺的方向去做生意，假設權益方案在邏輯上沒問題，但要真正落地有效的話，就會涉及到一些業務假設需要成立：

1. 平臺可以很好的觸達商家，商家也能夠理解權益方案；
2. 權益方案細節，商家真的很在意；
3. ……

接著就需要去調研這些業務假設是否真的成立？如果成立的話，那么該策略落地有效的概率就會很大；如果商家理解不了復雜的權益方案，或者商家對權益根本不在意，那說明該業務策略是不接地氣的，就需要及時做出調整。當然，策略是否有效的前置調研驗證是很有必要的，但有時候調研結果并不能直接推導出策略有效或者無效，那就需要設計好的落地方案，快速驗證迭代。

最后也類比過來，判斷某個人是否懂業務：如果這個人通篇都在講數學邏輯，沒有業務判斷，或者有些業務判斷明顯是不成立的，那大概率這個人就不太懂業務。要做出正確的決策首先邏輯上要成立，另外在業務上也要行得通。

04 數據分析與指標體系

如今不論是企業還是個人發展，整體都在往數據方向轉型，數據變得越來越重要。企業需要數據資產保持行業競爭力、產品需要根據數據分析的結果來迭代、運營需要通過數據來評估活動效果等等，越往后，數據思維、分析能力會逐漸變成橫向能力被大家所掌握，人人都會數據分析肯定是未來的趨勢。所以我覺得大家在這個窗口期選擇數據領域是非常明智的。

建立指標體系是數據分析的第一步。

數據指標中心是規范化開發指標并對其進行管理維護的系統，將指標的組成部分解耦拆分開來，并在邏輯表中進行規范性的定義，在此基礎上，后續可以按照一定規則進行自由拼裝，實現自定義指標的功能。

在我們日常的數據工作中，指標的重要性毋庸置疑，指標來源于業務的場景化呈現，業務也通過指標來透視出問題，但也正因為如此重要，使用如此頻繁，所以導致指標也出現各種混亂、難用、難找等等問題。所以我們必須有一套合理合規的指標治理方法，并將這套方法轉化成工具，通過固定流程去約束原本不可控的行為。接下來我們就看看，指標治理的有那些方法論？以及這些方法是如何設計成系統，也就是我們說的——數據指標中心。

05 如何建立指標體系

1、首先定義指標并歸集到對應的主題域

指標的本質是量化了的目標，比如常見的例子：

①我們要把用戶的盤子做大，那對應的量化指標就是已注冊用戶數；

②我們要統計今天的銷售額，那對應的量化指標就是總支付金額；

③我們要衡量一次活動的效果，那對應的量化指標就是下單率。

從上面的例子我們可以看到，我們比較常用的幾個類型的指標就是，存量型指標（已注冊用戶數）、事務型指標（支付金額）、轉化型指標（下單率），其它還有比例型、統計型、排名型等，這些比較不常用，就不在此贅述了。

這些不同類型的指標，分散在我們產品中的不同功能模塊中，所以為了更好地規范與管理，我們需要將這些指標也按照主題域的方式歸集起來。主題域在“倉庫模型中心”進行創建與定義，在這里只需要將對應的指標劃歸到對應的主題域就行了。

2、然后是拆分原子指標與派生指標

先來看看原子指標跟派生指標這兩個概念具體是什么？

①原子指標：是事實表中，某一個字段的統計值（sum、count、max、min、avg），如下單用戶數，下單金額等；

②派生指標：是基于原子指標，進行維度組合后產生的指標，如近1天商城下單用戶數，本周商城黃金會員下單金額等。

原子指標無業務意義，它只是預定義的代碼片段而已。業務中用到的指標基本都是派生指標。

3、接著定義原子指標與派生指標的生產邏輯

在本章的開頭有提到這樣一句話：“將指標的組成部分解耦拆分開來，并在邏輯表中進行規范性的定義”，這個解耦跟定義的過程，就是把一個派生指標拆解成原子指標、時間周期、限定維度、聚合粒度，然后再重新拼裝，生成新的派生指標的過程：

在上面這個例子中可以這樣來理解：

①統計周期是這個原子指標進行統計運算的時間范圍，在這里是本周；

②聚合粒度是指標的主體，即按照哪個維度來來進行聚合，這里是黃金會員；

③限定維度是限制原子指標的計算范圍，這里限定在商城，即只計算商城相關的數據；

④原子指標則是預定義的某個字段計算規則。在這里是下單金額的累加。

4、最后通過指標管理平臺對指標進行規范生產

（1）規范化指標命名

命名規范對于后期大量的指標管理來說非常重要，因為當指標多起來的時候，你要找一個指標經常需要用到檢索功能，而檢索的前提是你對指標有一些前置的認知。這就需要我們對指標的命名進行規范化。

指標命名規范有三個重點：

①簡潔明了，易懂：最好是只要看到指標名，不需要看注釋就可以知道它的意思，歸屬等；

②格式統一：每個指標的格式都是一樣的，通過組合不同模塊的命名拼湊起來；

③生成統一：原子指標與繼承自它的派生指標的規范是一致的。

以商城相關的指標為例：

①所有業務下單跟支付指標，默認以主單為統計口徑，不用帶“主單”相關字眼，如商城下單次數；當統計口徑為“子單”時則需要在命名中標出，如：商城子單下單次數；

②所有與人相關指標默認以“注冊用戶”為統計實體，不需要帶“用戶”相關字眼，如訪問次數；當統計主體為“游客”時則需要在命名中標出，如：游客訪問次數；

③無指定業務范圍的指標默認為平臺指標，不需要帶“平臺”相關字眼，如近30天支付人數。如果有限定業務范圍，則需要加上業務名稱，如：商城-近30天支付人數；

④無指定時間周期的指標默認為“近1天”（但需要保存小時粒度，便于后續下鉆），不需要帶“時間”相關字眼，如注冊人數。如果有限定時間范圍，則需要加上時間周期：如：近7天注冊人數。

完整的命名的規范為：商城（業務板塊）+用戶（實體）+近7天（統計周期）+新增（業務動作）+子單（類型）+單日（間隔周期）+平均（統計運算規則）+支付金額（原子指標），如：商城-用戶近7天新增子單單日平均支付金額（沒有的部位可留空，如：商城-匯總支付金額）。

⑵規范化統計口徑

當指標主體為實體（名詞）：游客、用戶、商品等，則只需定義單位為“人/個” 即可。如：游客人數、用戶人數、商品個數。

當指標為業務動作（動詞）：如點擊、支付、下單等，單位除定義為“次數” 外，還需考慮跟這個動作關聯的實體的單位，如“商品”時需要定義多一個單位“筆數”；為“用戶”時則需要定義多一個“人數”等；所以一個下單動作的指標，會有多個不同的統計口徑：下單次數，下單人數，下單筆數，下單金額……

在定義指標名時需要詳細列出，避免出現“下單數”這樣模糊的指標。

⑶規范化指標等級

我們都知道，隨著公司的發展，產品在不斷地進行迭代，功能的增刪與業務的變化勢必也影響著指標的發展，一些舊的指標被不斷更新或廢棄，而新的指標也不斷增加。這時對指標的管理也成了一個問題，哪些指標由誰開發？后續誰來維護……

一個比較好的解決方案就是對指標進行等級劃分，可以劃分為兩個等級：

①一級指標：即原子指標與小部分全平臺的核心指標，從各業務部門收集需求后，統一由數據中臺來產出，有一套完整規范的開發流程：需求-評審-排期-開發-測試-驗收-上線。所有維護管理工作都由中臺負責；

②二級指標：即派生指標，由各業務部門自定通過指標中心生成，沒有嚴格的開發流程，各業務部門根據需要自行創建，但需要遵守命名規范。所有維護管理工作由部門內部負責。

06 業務合作與職責邊界

指標中心建成后，還需要將在整個數據分析過程中各個角色的職責邊界理清楚。公司在追求業務商業價值最大化的過程中，會涉及到多個部門間的合作。

• 業務產品經理：
  負責協調研發、測試、設計等部門，從實際業務需求出發，上線產品；
• 數據開發工程師：
  根據數據產品經理的需求，按模型、按主題等去加工業務數據；
• 數據分析師：
  建立體系的分析框架評估業務狀態，定位業務問題，指導業務的發展；
• 數據產品經理：
  負責協調數據開發同學將業務數據模塊化和體系化，同時將業務分析框架產品化，提升數據賦能的效率；
• 運營：
  根據業務方向，通過短期的激勵活動，引導用戶認識到產品的長期價值；

在實際的工作中，涉及的部門會更多，比如還會有算法部門、研發部門、用戶研究部門等等，這里就不一一展開跟大家講了。

具體的合作過程：首先是業務產研團隊基于實際需求，上線產品，當業務數據被收集上來以后，會同步到數據倉庫，數據開發工程師根據數據產品經理的需求對數據進行加工處理，數據分析師會全面有邏輯的去拆解和分析業務，并同數據產品經理一起合作把分析框架沉淀在數據產品上。數據分析師、數據產品經理和數據開發工程師一起搭建了整個業務的數據體系，然后對外輸出：評估業務狀態、數據支持運營活動、分析產品迭代效果等等。