數據支撐和數據分析?編輯導語：數據分析中的MVP就是在數據正式生産出來之前，提前進行檢驗，确認準确性，所以在數據分析領域中經常會使用這種方式，根據提前輸出的進行更改，保證後續的結果；本文作者分享了關于數據分析中的MVP方法，我們一起來了解一下，下面我們就來聊聊關于數據支撐和數據分析?接下來我們就一起去了解一下吧!

數據支撐和數據分析

編輯導語：數據分析中的MVP就是在數據正式生産出來之前，提前進行檢驗，确認準确性，所以在數據分析領域中經常會使用這種方式，根據提前輸出的進行更改，保證後續的結果；本文作者分享了關于數據分析中的MVP方法，我們一起來了解一下。

很多同學雄心勃勃想在工作中做出成績，這裡推薦數據分析的MVP方法，能為大家的工作保駕護航。

MVP（Minimum Viable Product）原本是應用于産品設計的方法，指在正式推出産品前，先推出一個版包含核心功能的簡單版本，測試用戶需求與反饋，從而快速判斷産品是否符合市場需求，做出調整。

數據分析的MVP方法，是在數據正式生産出來以前，先根據數據需求和使用場景，提供虛拟的數據結果，從而檢驗數據有效性，發現真正的數據需求。

這套方法在數據分析領域非常好使！因為它能解決數據分析的核心難題：做了半天，沒有屁用。數據分析背後的《統計學》《數學》《運籌學》《博弈論》《機器學習》…各種理論多了去了，因此極易引發自嗨。

做數據的自己嗨得不行，各種理論算的騰挪跌宕，到了用戶那裡：

一鍵三連，這項目就必敗無疑了。

數據分析的MVP方法，目的就是提前梳理清楚：數據如何對業務有用的邏輯，從而避免上述悲劇；而看似牛逼，實則然并卵的數據分析，在現實中多的很……

舉個簡單例子，比如互聯網平台-廣告銷售團隊提出：“要建立業務員用戶畫像，掌握每個業務員的性别、年齡、行為、轉化率，以提高業績”。

這時候咋辦？

如果用MVP思路，先不要急着去跑數，也不要急着列一大堆“用戶畫像标準指标”，而是直接拿着業務方提的最初的需求：“性别、年齡、行為、轉化率，以提高業績”直接給一個虛拟結果，然後确認：“如果我真的提供這些東西，你們真的能提高業績？”——讓他确認。

‍‍‍‍‍

至少隻基于這一句話來看，數據分析能輸出的結論是完全無用的。1.0版本的MVP測試不通過，要麼放棄這個需求，要麼繼續想想：該怎麼更好的抓用戶痛點。這樣把數據推向2.0版本。

進一步看，1.0版本的問題在于：沒有清晰目标。所謂畫像指标一大堆，到底看了要幹啥沒想清楚。如果聚集目标，比如：找到業績好的業務員。這樣就更清晰了一步。

這裡就需要引入更多分析，因為“好”“不好”本身就需要做分析：

在這個階段，做MVP時，可以直接把一些可預計的，很糾結的問題提前丢出來，和業務方一起提前思考應對方案；而不是等着跑了一大堆數據，自己悶頭計算好幾輪以後再讨論；越早讨論，越能提前刨累，避免無用功。

比如評價：“好/壞”中常見的多指标重疊問題（如下圖）。

比如業績表現不穩定問題（如下圖）：

至于和本階段無關的指标，可以大膽做減法，丢了再說。

有新的目标出來，再圍繞新的目标組織數據。避免不分青紅皂白，先撈一堆數再說的做法——數據分析師不能按時下班，都是被這些破事折騰的。

把這些梳理清楚，就有了2.0版本的MVP。（如下圖）

看起來，似乎已經比1.0版清晰了很多，删減了很多無效指标，聚焦到一個明确的目标上。

注意，這時候仍然還沒有跑任何數據，隻是基于經驗的虛拟，但是已經能把“早就知道了”的數據暴露出來，并且能過濾掉“其實沒啥用”的指标，并且把可能有歧義的地方以具體案例的形式具體讨論，從而極大規避問題。

但是注意，這還不是一個合格的MVP，因為知道誰好誰壞，又能怎樣？知道李四是真的好了，大家就能成為李四嗎？還是根本李四是不可複制的，我得找更多類似李四的人進來？

這些問題都沒有答案。所以此時還是無法直接得出：這數據就能提高業績。MVP測試不通過，繼續！

隻告訴誰好，誰不好是不能提升業績的。業績是一線做出來的，一線需要的是SOP，是彈藥，因此數據要進一步做，比如：

優秀标杆的數據指标（呼叫次數？時間分配？跟進機會？）

優秀标杆的目标客戶（是否特定客戶容易成功？）

優秀标杆的銷售技巧（用哪些話術？利用哪些物料/活動？）

注意，這裡已經不僅僅是數據的範疇了，數據隻能打标簽，列指标。但話術、語氣、時機把握是需要培訓/業務部門提供的；因此在此階段做MVP的時候，可以直接向業務部門明确：是否隻輸出數據就能滿足需求；如果不能，趁早拉其他部門一起幹活，不要自己埋頭别憋數據。

看起來3.0版本已經很厲害了。然而有個隐藏的BUG，就是别人有沒有可能學會。

注意，這個不可知，會極大的阻礙業務認可數據分析的結果——落地不見效，到底是因為數據分析結論錯了，還是執行沒到位？這個可得提前安排明白，不然事後背鍋分分鐘的事。

因此，還需要在現在版本基礎上，增加測試環節，檢驗到底有沒有用。

這樣，又涉及到：

選多大範圍進行測試

測試時間周期多長

如何排除節假日、活動等其他因素

測試結果認證标準

把這些想清楚了，就有4.0版本。

在這個階段，終于能将數據需求，指向一個業務期望的“提升業績”的結果了；并且最終結果有測試數據回收驗證，即使測試不成立，也有備用方案墊底；這時候可以放心大膽去跑數，跑出來一定有用。

注意，MVP測試，是緊密圍繞用戶需求的。

上邊的例子之所以做了好幾個版本，源頭上是因為用戶期望值高，指望直接見業績；如果用戶期望值不高，MVP測試可以很簡單。

比如：

用戶需求是：目前沒有數據→ 盡快提供數據

用戶需求是：目前數據太多→ 删掉無用指标

用戶需求是：目标數據太亂→ 重新整理邏輯

用戶需求是：不清楚問題在哪→ 輸出可量化的問題點

這些隻要提前虛拟個數據，做個圖确認下需求，就能解決。

稍微複雜一點的，比如用戶需求是：精準預測銷量，可能隻要梳理兩三步，就能更細化範圍，提升有用程度（如下圖）。

數據分析領域，一直有一個八爪魚派在流行，就是不管有沒有用，不管有沒邏輯，像一隻八爪魚一樣丢一大堆指标過來（如下圖）：

這種做法，張牙舞爪，看着厲害，可是實際上卻是項目失敗的根源；讓做數據的人誤以為工作就是做作業，不考慮實際效果，一味貪大求多，最後累得半死還不讨好。

相比之下：

多研究業務數據的基本形态；

多發現業務對數據實際需求；

多測試數據有用的點；

剔除無用的，空洞的，高大全的指标。

這樣才能更快的積累分析經驗，讓數據更好發揮作用。

#專欄作家#

接地氣的陳老師，接地氣學堂，人人都是産品經理專欄作家。資深咨詢顧問，在互聯網，金融，快消，零售，耐用，美容等15個行業有豐富數據相關經驗。

本文原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!