實現數據驅動的三道鴻溝

過去一年，一直希望能做出一套在滴滴能夠有效落地的數據驅動解決方案，進展並沒有多順利。其中反覆，不禁讓人想起：夫夷以近，則游者眾；險以遠，則至者少。而世之奇偉、瑰怪，非常之觀，常在於險遠。遂有此文。即使不能至，心嚮往之

1.利用數據自證的心態與數據驅動產生業務洞察之間存在鴻溝

我在一篇知乎的招聘貼中寫到過：數據驅動在大部分公司的遭遇是一樣的：大家說的是A，心裡想的是B，做的是C，最後復盤包裝的是D。因此大部分數據分析師的成長環境非常險惡，最終能夠修成正果的寥寥無幾。利用數據自證是一個心魔，很多時候我們只是意識不到而已或者打臉周期過長。一個小的例子是：過去十年的行業分析師在分析速食麵市場時都是對比日本和韓國的市場佔有率來說明中國市場還有很大空間。但是最近幾年的中國大陸的速食麵市場極速萎縮將數據自證的缺陷暴露無遺，想拿一個數據佐證自己的觀點太容易了。但觀點能歷經市場考驗為真，太難。

解決方案：退後一步審視思考過程；跳出盒子，懷疑一切；針對當前的一個業務痛點針對解決；承認數據驅不動的時候存在；部分時候簡單分析，快速決策

1.1 退後一步審視思考過程：最近《思考，快與慢》在滴滴非常火，這本書給我最強烈的一個感受是：人的思維局限實在太大了，加上信息噪音和各種誤導，我們需要很努力才能避免決策滑入思維陷阱。人在噪音中過活，有限時間和有限信息下決策，做一個正確的決策非常難。退後一步看看我們的思考原點和推演的過程有沒有問題可能不一定奏效，但一定是一個必要的姿勢。反覆地自問也能提高自己的直覺思維能力

1.2 跳出盒子，懷疑一切：我的同事最近做了一個關於**司機的數據分析，整體的結論是滴滴應該增加**司機的比例，構築一定競爭壁壘的同時也能優化我們的核心指標。論證過程按下不表。但是這個分析的思辨意義是很大的，從產品策略到運營策略，我們過去都太向**司機傾斜了。現在跳出一個不同的聲音本身就是好的。我們可能思考的結果是錯的，但是思考的過程一定是對的。

1.3 針對當前的一個業務痛點針對解決（這裡引用我一個分析師朋友的觀點）：

要通過數據分析來驅動業務發展，單純的採用概念介紹，遠景規劃，引用成功案例等手段效果不大。這就好像隔靴搔癢，不管力度多大都與現狀隔著一層，大有與我無關的感覺。最直接也是最有效的方式莫過於找到當前的業務痛點並針對性的解決，也就是所說的一擊立威。這樣不但可以直接體驗數據分析對業務的促進作用，更重要的是這種切身體會能帶來長遠的影響，讓未來的數據分析工作事倍功半。

1.4 承認數據驅不動的場景存在：

滴滴原來非常優秀的一個數據分析師lpc珠玉在前

長期來看，數據驅動一個基於貝葉斯法則不斷展開迭代的過程。貝葉斯法則的文字描述方式：後驗認知=先驗認知*校正因子。

比較理想的工作方式是我們在邏輯層面上對業務已經有了相當的積累，這些積累構成我們的先驗認知，然後通過數據分析、A/B testing等方式獲取更多的信息和數據，構成我們對特定問題認知的校正因子，將兩者結合起來得出我們的後驗認知。而這個後驗認知又構成下一次分析或者實驗的先驗認知，這樣就可以不斷的迭代下去。

在這樣一個迭代的框架裡面，不宜使用數據決策的場景是：如果我們沒有先驗認知，寄希望於通過校正因子來直接認識世界，很可能會陷入被數據誤導、用數據說謊的境地。這時候，可能需要先去補課，獲得更多的先驗認知，而不是被數據牽著鼻子走。

總結來說，先驗認知是優秀的數據科學家，產品人，戰略專家，公司高管必須要有的系統一，這裡不應該做任何試圖繞過認知，讓數據直接告訴我們應該怎麼做的美夢。利用經驗來決策本身就是人類能力中最有優勢的一部分。不應該在大數據時代就完全束之高閣。

1.5 讓系統一歸系統一，系統二歸系統二：

很多時候，without data或者少量依賴簡單數據分析不失為一個很好的決策方式。但判斷力非常關鍵：什麼時候應該簡單分析，move fast，什麼時候應該深入分析，審慎再審慎？這考驗了每一個數據科學家和產品人。

2.業務部門對數據的理解與數據部門對需求的理解存在鴻溝

業務部門無法了解數據的獲取、處理、計算整個流程，從而對數據的含義和用處產生了自己的理解，會跟真實情況有所偏差

數據部門無法真正了解業務需求，不清楚數據到底用於何處。甚至不太清楚了解一部分數據需求的前因後果，加上業務方立等可取的緊急程度，沒有時間給分析師充分思考的餘地。分析師往往無法提供最優或最有效的數據，或者是淪為數據自證，與數據驅動南轅北轍。

解決方案：建立業務部門與數據部門間的四重介面，包括：

2.1 規範的需求流程：需求一般由業務部門提起，通過數據部門對數據的獲取和計算將結果返回給業務部門，這個流程中

業務部門不僅要提供數據的規則，同時應該對獲取數據的目的、指標的定義、用處和價值做出詳細的描述；而數據部門不僅要給出最終數據，同時需要對指標的獲取途徑、計算方法作出解釋，最終的目的都是為了使雙方在理解上能夠達成一致詳細的文檔、合理的數據展現，而最重要的還是能夠銜接起業務和數據之間的人。

2.2 詳細的數據文檔：除了PM團隊熟悉的產品需求文檔，在滴滴實際的工作中其實還需要詳盡的數據需求文檔和數據解釋文檔，需要白紙黑字將規範需求流程中提到的這些關鍵點記錄下來，能經得起後續的反覆查閱。

2.3 信達雅的數據展現：其實就是一個原則：讓每個人看到自己想看的數據，並能直觀地理解這些數據。無論是自動郵件，數易（滴滴數據產品）、tableau還是其他展現方式，每個指標都應該能夠有途徑去直接查看到第二個介面提到的數據解釋文檔，而數據應該以最直觀的方式展現出來以方便理解，以信達雅的標準來催生業務洞見。

2.4 橫跨業務與數據的銜接者：這一類人的組織關係放在哪裡並不關鍵，可以是數據科學家，也可以是戰略專家，數據產品經理，甚至是公司高管自己。對這類人員會有較寬的技術棧要求。他應該對公司產品的戰略目標、業務流程十分熟悉，同時對數據的獲取途徑、計算方法也了如指掌，或許不需要涉及高技術難度的數據ETL處理、組織和優化，但必須具備自己去計算和獲取各類數據的能力。在四重介面里，這一重介面無疑是最重要和關鍵的。橫跨數據和業務的複合型人才，本身就會成為市場的寵兒。

3.數據即時查詢的效率與海量數據的處理建模存在鴻溝

如何在提供足夠豐富的指標的前提下保證數據的展現、獲取和查詢的效率能夠滿足數據需求方的要求？如果提供的指標不夠，或者數據的粒度不夠細，就無法滿足日常數據監控和分析需要，分析師也需要反覆提供即時查詢的結果，埋葬在需求的海洋；相反，如果每天計算和統計的指標過多或者數據分得太細，那麼顯然會增加伺服器運算的負荷，同時在數據查詢上的響應能力也會相應的下降，同時對於決策制定者來說，過多的指標產生了數據嘔吐（《精益數據分析》），往往並不能很好地輔助決策。

解決方案：把握核心數據，建立合理的多維模型

3.1 核心數據：簡單說就是網站的目標、KPIs等，這些數據是從高層到執行層都在時刻關注的數據，所以最優先的原則就是保證這些數據的查詢效率和及時響應。最簡單的做法就是這些指標獨立統計，不放入多維模型，只做每天的簡單聚合存入一張寬表中直接供報表展現。同時數據分析能夠在這張寬表直接進行深度的數據分析，找出業務癥結，而不需要再去寫sql跑數，反覆要去核對數據口徑，做無用功。這一層工作可以閉環在數倉部門，如果數據分析團隊有餘力也可以閉環到分析團隊。最不好的結果是互相推諉，報表歸報表，分析歸分析。大家自說自話。

3.2 建立合理的多維模型：業務方起初會漫無邊際地提各種需求，可能會有上百個指標，但一旦統計出來之後很少會有人真正去使用和分析這些指標，了解多維模型的人會知道：在多維模型中增加一個維或維的層次加深一層，對於立方的數據是以乘積方式遞增的，比如增加一個100條記錄的維相當於立方的數據乘以100，或者時間維的粒度從天到小時，相當於數據量是原先的24倍，這個對於那些本身數據量就非常龐大的多維模型而言本身就是一場災難。所以建立多維模型時的原則是提供實際應用中需要的維和指標，同時把握好各個維的層次粒度。好的多維模型永無止境。

關於數據驅動，一切都讓人想起Ben Horowitz的《The hard thing about hard things》：解決這些難題，沒有任何公式和套路可以使用。該踩的坑都會踩的，站起來拍拍土繼續前行就很好。