很多同學被嫌棄：做的數據分析，沒深度。到底啥是分析深度？怎么才能做出深度？話不多說，直接上場景。

問題場景：某物流企業，負責管司機的調度中心，會給每個未上線司機標注原因，標注格式如下：

備注：實際原因還有很多，這里僅做舉例

現領導要求：分析司機未上線情況。

問：該怎么分析？

一、0級深度做法

• 3月6日，共1000司機，上線900，上線率90%
• 3月7日，共1010司機，上線875，上線率87%
• 3月8日，共1050司機，上線850，上線率83%

上線率連續2天下降，建議搞高

不上線的理由TOP3為：

不點評了，大家自行吐槽。

二、1級深度做法

上線代表的是運力，不同線路運力需求不同，因此可以結合需求，解讀上線數據：

• A線路本月訂單暴漲，但司機上線率在下降，需保障運力。
• B線路本月訂單減少，司機上線率在下降，可調撥該批司機運力。
• C線路為季節性需求，預計下個月就沒有了，關注該批司機運力分配。

點評：終于知道把上線情況和業務需求聯系起來了。這樣能解讀出：司機上線/不上線，到底有啥意義；重點線路需要保障，零散線路釋放出運力要能調配開，這是基本常識。

同理，還可以對司機生命周期做分類，結合司機表現，解讀上線數據。

• 新手期司機：上線變差，是否意味著最近開發新司機質量下降
• 穩定期司機：上線變差，是否意味著平臺運作出問題，老司機流失

注意，以上這些計算，需要衍生指標，比如：

• 線路訂單量：最近一周內訂單數、貨運噸位
• 線路訂單變化：最近N周內訂單走勢
• 司機生命周期：從注冊到當前時長
• 司機行車里程：最近一周行車里程
• 司機缺勤頻率：最近一周無出車天數

這些數據不見得在一個表里能體現，因此得從各個數據源找數據組合分析。

這么做看起來比0級有深度了不少，但沒有解決一個核心問題：“到底司機不上線是啥原因？”，特別是“請假”比例這么高，到底是司機不想干，還是沒需求，還是平臺出了問題。

三、2級深度做法

注意，1級深度的核心問題，在于：未上線原因給的亂七八糟。

• 什么叫：雙十二過了？
• 什么叫：累
• 請假和累是不是有重疊
• 到其他線？那他該在其他線上線?。?/li>

可能有些物流企業管理較規范，但這家物流企業調動真的不咋樣。這種敷衍了事的回復看了讓人摸不著頭腦，根本沒法用。

但是要如何規范起來呢？如果平地一聲雷，甩一套新模板出去，不但培訓需要時間，而且和現有的數據對不上，很有可能制造新的數據垃圾；因此更好的做法是，先基于現有分類，梳理出邏輯，再培訓，提升規范度。

分類就要用到MECE法，實現MECE的最好辦法是：二分類。從示例反饋來看，可以用三層分類邏輯。

第一層二分類邏輯，最好用：線路問題/個人問題來區分（如下圖）。

這樣分類含義很直觀：線路問題跟司機沒關系，有些中小客戶，就是季節性/臨時性有需求（比如雙十一、雙十二）需要企業這邊開發客戶/分配好線路。司機的問題，再做進一步細分。

第二層分類邏輯，可以拆是否車壞了。車壞了是鐵定沒法運的，此時不但要登記原因，還得登記車輛損壞情況或預計修好時間；如果車輛嚴重損壞，可能直接導致司機退出，或者長時間運力缺失，這個情況對于新運力開發很重要。至于司機個人問題，再做細分。

第三層分類邏輯，可以看司機是否投訴平臺。比如平臺扣錢太多，這是個規則問題，平臺方也不可能因為一個司機的抱怨就改規則；但是，對投訴類問題要先掌握情況。這樣才能持續監控，發現更深入的問題。

至于沒有投訴情況下，司機個人問題，另行處理：

為啥司機個人問題要另行處理？因為個人問題很有可能沒實話。拉貨的司機不是辦公室文質彬彬的小白領，沒心情一句句細講心路歷程。

一句：“累”背后，可能有多重含義：

• 個人心累，不想干司機了
• 在你這干得累，不想在你這當司機了
• 線路跑得累，不想干這個線路的司機了

單純指望口頭問，很難理清楚這里邏輯。更不要說大部人連個“累”都懶得說，就是簡簡單單的不接電話/“請個假”。調度員每天對著幾十個司機，也沒空一個個談心，也不太指望調度員能把個人原因都整明白；所以這里可以簡單記錄原因，靠后續分析來做深。

綜合梳理完，現有歸類可以合并如下：

這樣能建立監控指標，觀察問題，也能加強對調度員的要求。

并且調度員需要關注的核心問題只有三個：

比起一次給30個選項的調查表，這樣抓關鍵行為的做法更容易讓調度員掌握，降低培訓成本，且后續數據也能和之前的對上，避免新數據垃圾產生。

然而，這樣做就夠深度了嘛？顯然沒有，這里遺留了好幾個問題。

四、3級深度做法

有了2級深度的分類，3級深度的分析思路就非常清楚了：

• 遺留問題1：線路到底是調度問題還是推廣問題
• 遺留問題2：司機投訴到底要不要受理
• 遺留問題3：司機缺勤到底是“累“還是”不想干“

這三個議題，都需要專題深度分析來解決，已經不是單純靠報表監控能搞掂的了。

比如問題1：想區分呢調度問題還是推廣問題，得首先對線路端打標簽，做分類。

比如：

• 線路本身需求不穩定
• 線路本身需求大幅度下降
• 線路本身難開，司機流失多

這些并不反映在調度表里，但是卻直接影響調度結果與司機上線，因此需要從線路需求表里，先分析清楚，這樣解釋調度的原因才容易說。

比如問題2：司機投訴到底要不要受理，這里可以分規模、內容、效果兩個角度來看。

• 規模：是否投訴量在加大，是否投訴集中在某些客戶，某些線路，某些時間段
• 內容：是否投訴集中在某些問題，特別是與薪資、扣款相關的
• 效果：是否投訴行為導致的影響在加劇，比如投訴后司機流失率在提升

這樣綜合分析，才方便運營評估：是否要響應投訴，看到投訴指標變化，也好理解這個指標對業務的影響程度。

比如問題3：司機到底是累還是不想干，得先看內部數據說話通過內部數據，能看出司機實際行車時間，把“累“字背后含義：真的累or賺不到錢區分出來，從而針對性分析；這樣做比追著司機刨根問底，更容易發現問題（如下圖）。

理論上，這里還有深入的空間，讀者們可以自行發揮哦。

五、小結

很長時間以來，人們把做數據分析的看成算命先生：我不說話，你丟幾個銅錢（敲幾下鍵盤）就天知地知，這是非常非常扯淡和錯誤的。

本質上看，數據分析對抗的是不確定性。因此需要大量的信息輸入，才能得出結論。阻礙數據分析由淺入深的最大問題，也是：沒！數！據！

并且如同上邊小案例所示：過分追求完美數據，不但會拖慢業務，增加成本，而且對內部員工和外部客戶體驗都很差——大家是來消費的，不是來被扒戶口本的。

所以，數據分析工作，始終伴隨著不完美的數據開展，在有限大的條件下，一步步導出結論，才是由淺入深的方法（如下圖）。

這里最重要的三個環節，就是：

• 結合業務含義，對描述統計初步解讀；
• 結合業務問題，形成分析框架；
• 結合業務策略，驗證判斷。

總之，就數輪數，可得不出啥有用結論。甚至有可能，數據越多，看得越糊涂。