編輯導語：數據分析可以指導業務的推進，不過在分析過程中，並非所有數據都需要攬括，數據也不能實現無限精細。那麼作為新手，你知道如何利用數據分析，推動業務決策、指導業務優化嗎？本篇文章里，作者結合個人工作經驗，總結了利用數據指導業務優化的思路，一起來看一下。

作者結合個人的數據工作經歷，初步整理了一些如何讓數據最終能夠指導業務優化的思路，歡迎交流。

一、雞生蛋還是蛋生雞——數據指標與數據源

由數據源確定數據分析指標還是由數據分析需求樹立數據指標，開發數據源以獲取對應的數據？理論上是後者，不能被已有的數據範圍所限制，應當以業務目標和數據分析目的產生數據需求，再由需求對照需要那些數據作為支持。

但也要考慮數據獲取的客觀條件。實際情況中，往往受當前技術所限，一些數據儘管粗在分析需求，但數據短期內無法實現採集。這時候可能就需要考慮轉換數據分析的思路，適當選擇繞道而行。

順帶一提，使用數據的時候，需要對於數據的準確性進行核驗。一些時候，如果要使用的數據源被證明足夠可靠，經過驗證或者已經被使用成熟，我們可以跳過對於數據源的核驗或者稍加核驗，對數據進行使用。

但如果數據的獲取不穩定（常見於監控性質的數據，涉及數據的採集、數據的存儲等，這裡面大有說法），明確數據誤差的來源，以及誤差的可接受度。

例如獲取機房的伺服器數量，數據就是相對可信的，接口被廣泛運用。但涉及到帶寬、監控、流量之類的，往往就要挖掘到數據源那一側，包括數據是怎麼採集的、存儲方法等。

例如在帶寬利用率的數據中，當時的技術條件是：每5分鐘就會採集一個數據點，但是超過七天之後，數據點只會每天保留一個。這樣，對於每天精確的帶寬利用變化趨勢數據圖表就無法實現了。這種就是數據影響到功能的情況。

再例如，算機房流量，可以通過計算每台機器的網卡流量並求和，也可以直接取出口交換機的流量數據，後者相對更精確，因為前者會包含了機房內機器之間互相通信的數據流量。

但是在統計機房內某個業務的流量占比的這個場景下，只能採用第一種算法，第二種算法中交換機無法區分業務的流量，而且該業務之間的數據傳輸不大，可以忽略誤差，因此可以採用第一種誤差較大的方法。

二、由心率到心電圖再到診斷書——數據的下鑽，數據能夠指導業務的優化，而不是僅僅顯示一個狀態

就像心率和心電圖一樣，心率僅僅能夠顯示狀態，非常簡單地判斷健康狀況，心率高一些也只能說明心臟跳得快一些。但是如果進行一些下鑽，心率隨時間的搏動情況，就可以判斷一些問題，例如心率不齊等、再進行下鑽，心電圖的層面，就能夠發現更多的問題了，例如癲癇之類的。

數據也是如此。我們有很多描述狀態的大顆粒度數據。但是能夠提供的信息卻非常單薄。這種是不利於問題的發現以及業務的優化的。也是初級發展階段的數據分析環境普遍存在的一個問題。

但是辯證來看，並不是所有數據都有下鑽成心電圖的必要，就像我們的手環，只要能夠提供心率即可，不必要展示到心電圖的程度，而我們生病或者體檢的時候才會需要心電圖。有些數據，我們只需要獲取大致的狀態即可，不必非要執著於刨根問底。

說到底，其實還是根據數據的消費需求來看，是需要詳細的拆分的細顆粒度數據，還是只需要粗顆粒度的，感知大致狀態的數據即可。

三、從診斷書到治療方案——對於有需要的數據，將數據與真實的業務優化、業務行為結合起來

數據到現實業務是一個無限接近的過程，我們希望得到的就是能夠最大程度上地直接作用於業務決策或者業務行為。

當然這裡面也有一個度在裡面，數據不可能無限精細，這樣就會造成大量的數據冗餘，最好能夠「點到為止」。

例如在提供機器年限、過保相關的數據時，我選擇將最精細的數據提供到單個機器的編號為止，並設計了導出功能（理論上做跳轉功能會更加直接，但是評估後沒做），用戶在點擊過保機器的數據後，可以詳細得到具體有哪些機器過保，並可以下載機器型號，方便他們後續進行進一步的操作。

本文由 @星若雨 原創發布於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議