很久之前，你我都曾經做過物理題。記得那時老師經常嘮叨，「先認真審題，理解題意，然後再想方法，最後再落筆去做」；「審題啊！審題啊！說過幾遍怎麼就是不聽，尋思鷹呢？」

理解當年老師的良苦用心，歷經磨難，你我也都順利結束了學業，不必再審題、不必再做題、不必再考試。然而，人生不如意十之八九，你我又再次走上了數據分析的道路。
轉換為現在的視角。我們做數據分析的目的，是為了解決問題，換個詞，是為了有用啊。那麼你做的分析，有用嗎，怎樣做的分析才有用呢？
直接將分析結果利用，轉換為價值的，是業務。或許按照這樣的路線來做分析，更有用。
先審題（理解業務，做為方向）
思考方法（分析思路，設計分析方案）
下筆（選擇分析技術，開始分析）。
可見，套路是和我們當年做題一樣的吧，可是，當年的物理題也做過了不少，多苦多累我們都熬過去了，為什麼到了數據分析這裡，還是很多問題呢？私以為，做題是一個人的事，而現在做分析，變成了一個組織的事，銜接出了問題。

做數據分析可能出現的失敗場景：

分析結果就是錯的
分析結果是對的，然而並沒有什麼卵用，結果產生不了價值
根據分析結果，可以給出建議方向，但是很空洞，無法落地
分析結果對、建議方向也對、也有落地的方案，但是業務就是不執行

第一種場景比較少見、而後面的幾種場景卻是做數據分析的經常會碰到。舉個栗子。

場景a：
公司在6月18號跟著天貓一起搞了個618大促，結束後業務找到老王，說：「老王啊，我們活動做完了，給我做個數據分析，讓我看看活動效果怎麼樣？」
老王接到任務開始收集數據、處理數據、做模型、畫報表。最終出來結論：「我們本次活動期間，環比上周末uv增長了150%，綜合轉化率提高了27%，訂單量增長了110%，銷售額增長了85%。其中台北市訂單佔比最高，達到了27%。。。。」
業務：「你要說明什麼，是想告訴我活動真好，明年還搞618大促嗎？」
此時，老王只能期待他一臉懵逼的表情來萌翻業務了。

場景b：
業務：「老王，感覺公司的綜合轉化率有點低，你給我做個分析，看看是什麼問題」
向來以行動力強，技術水平高的老王，結合大量的訪問數據、用戶數據、訂單數據，採用聚類分析演算法、主成分分析、相關行分析等挖掘手段。成功的發現，年齡段在40歲以上的男性群體，綜合轉化率超高，平均達到47%，所以建議業務，制定拉新策略，提高這一用戶群體的訪問量。整體的轉化率就可以上來了。
業務：「但是這群人，平時很少上網啊」。
老王再次懵逼。

場景c：
老王：「我做了一個用戶流失預警模型，發現有a類行為特徵用戶在註冊後30天左右流失概率最大，有b類行為特徵的用戶在40天左右流失概率最大，有c類行為特徵的用戶在50天左右流失概率最大，那麼我們只需要做一個精準的關懷，針對不同行為特徵的用戶，在不同的時間點，推送廣告、或者發放優惠券，就能夠有效的降低流失率」。
業務：「老王，你說的很對，但是我們公司小，實現這樣的精準投放成本太高了，我們現在每天忙成狗，核心的內容體驗還沒做好，你的建議後面再考慮吧，辛苦了。。。」

老王他已經很努力了，但是分析結果確不盡如人意。

我們常常見到數據分析師抱怨：我的工作不夠重視，他們要數據的時候就讓我提取一下，最多做個簡單的加工；業務做決策都不看數據，全憑經驗來；業務開會，討論方案從來不叫上我，不參考我們的意見。
同時，也能聽到業務方的抱怨：數據部門提供的結果，都不是我想要的；數據部門太天真，提供的方案太多漏洞；數據部門的人都不懂業務，拿著點數據就能來指導我們嗎？
我想，這裡就是業務與分析之間的銜接出了問題。業務不相信數據，當一個分析結果與他的設想不同時，首先就是懷疑數據，他所做的數據分析，僅僅是為了驗證自己的觀點。

數據分析師和業務人員邁出一小步，是公司的一大步

見過數據分析做的比較好的公司，一個是BI系統經理是產品經理出身，懂業務、懂產品、懂運營，所以他帶隊做的分析專案自然貼合業務需求。還有一個是，公司將數據化運營提升到了很高的高度，培養公司業務具有數據意識，了解數據分析的思路，認同數據分析的價值，知道如何利用分析結果。
可以是數據分析師向業務多走一步，也可以是業務人員向數據多走一步，使得兩方面有一定的重疊，做好這個銜接，數據分析可能就會更有用。嗯，你們邁出的這一小步，就是你們公司的一大步。
一方面，培養全公司業務的數據意識，是需要時間並且有難度的。另一方面，作為一個數據分析師，也應該更多的了解業務，這樣才能把「業務的需求」轉化為數據需求，再進一步把分析結果轉化為有意義、可落地、可產生價值的方案。同時也能反過來完善自己的知識體系，提升自身的業務理解能力和數據分析能力。

問題來了，怎樣去了解業務呢，只能說，世上無捷徑，除非你改行。能想到的方法，就是交流交流再交流，當業務需要分析一個活動效果的時候，多問一句，你關心哪些指標？哪些參數會影響一個活動的成效？當業務要分析轉化率的時候，多問一句，影響轉化率的因素有哪些，有哪些方法可以提高轉化率。都是一個公司的，沒事請業務吃頓飯，沒有什麼是一頓飯解決不了的，如果有，那就兩頓，吃著吃著，不僅你懂了業務，業務也懂你了。

交流，聽起來很簡單，做起來是最難的，尤其大部分數據分析師都是數學、統計學、計算機等這種理工科出身。會有人期待一個更簡單的方法。例如：數據部門只做技術，分析全都交給業務部門如何，我們買BI系統工具，讓業務實現自主分析。你說用bi系統來節省工作量降低時間成本我信，你給bi這麼艱巨的任務，且不說bi工具的分析能力有限，無法實現深度分析和挖掘，業務部門的數據意識上去了嗎？沒有統籌，各個業務部門的分析結果相互衝突怎麼辦呢？業務部門的分析結果不客觀，對於公司來說，是最好的嗎？

所以，對於一整個數據分析體系而言，工具和技術只是輔助，業務和思路才是核心和重點。

談到技術，再進入到第二個銜接點。
網際網路公司一直處於技術的前沿，技術可能都不是問題（如果跟一個網際網路公司說你技術不行，就希望他們公司程序員加班太多打人的力氣都變小了吧），更多的可能是對技術的選擇。

私以為網際網路行業的數據分析需求可以大體上分為三類：
業務常規需求，主要是輔助業務日常工作用
指標監控與數據呈現類，為管理和決策提供支持，也為後面的針對性的挖掘分析提供入口
有主題有針對性的挖掘分析，為運營、產品的改善提供數據依據，具有一定的驅動價值
對於第1類和第2類需求，有用開源報表的、有用商用報表的、有用bi軟體的、有寫echart的也有用excel的。對於第三類需求，有用sas的、spss、python的、r的甚至有用c++的。

要說哪一類技術或工具才是最好的呢，我相信沒有，如何選擇，更多的是要結合業務場景，有時是多種工具同時使用，才是最佳的。如何才能做好這一點，我想就是要有清晰的分析思路，和熟練的分析技能（對各種工具的了解）。也就是打通第二個銜接點。

對於很多分析師來說，這一點要比第一個銜接點容易的多。但是我再多說一點的是，分析手段的選擇，不僅要考慮分析實現的可行性，也要考慮分析成本，主要的就是時間成本。R語言現在大量應用於網際網路公司，我想也是因為它提供大量的統計函數和演算法，降低了數據分析成本的原因，當然，少不了它開源的巨大優勢。
同樣，對於第1類和第2類需求，選擇實現方案，也要考慮成本。相比較來說，這兩類需求的實現難度更低，相信對於任何公司來說，也都是並非核心技術。有堅持用excel的，也有堅持碼程式碼的。當然，具體怎樣選擇也要結合業務場景，但是綜合起來看，如果有方法一天就實現，就盡量不要花兩天時間去開發。例如一個好的報表工具例如finereport，相比於開源report或者echart來說，還是節約一定的時間成本的，省下的程序員，還能打掃打掃衛生啊,哈哈。

以上是我對網際網路行業中數據分析業務的一些淺薄的看法，如有不當的地方，歡迎批評指正和交流。

原創文章，轉載請私信作者
作者：帆軟網際網路行業高級顧問 王佳東

喜歡這篇文章嗎？歡迎分享按讚，給予我們支持和鼓勵！