做有用的數據分析，從做好 MVP 開始

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

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

數據分析的 MVP 是什麼

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

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

這套方法在數據分析領域非常好使！因爲它能解決數據分析的核心難題：做了半天，沒有屁用。

數據分析背後的《統計學》《數學》《運籌學》《博弈論》《機器學習》… 各種理論多了去了，因此極易引發自嗨。

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

“我早知道了！”

“你做的有啥用！”

“你做的咋落地！”

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

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

1.0 版本 MVP

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

這時候咋辦？

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

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

2.0 版本 MVP

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

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

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

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

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

至於和本階段無關的指標，可以大膽做減法，丟了再說。

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

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

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

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

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

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

3.0 版本 MVP

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

注意：這裏已經不僅僅是數據的範疇了。

數據只能打標籤，列指標；但話術、語氣、時機把握是需要培訓 / 業務部門提供的。因此在此階段做 MVP 的時候，可以直接向業務部門明確：是否只輸出數據就能滿足需求？如果不能，趁早拉其他部門一起幹活，不要自己埋頭別憋數據。

4.0 版本 MVP

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

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

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

這樣，又涉及到：

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

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

MVP 測試的廣泛應用

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

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

比如：

這些只要提前虛擬個數據，做個圖確認下需求，就能解決。

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

爲什麼要推 MVP 方法

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

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

相比之下：

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/ofGFlNh8tHOp47_cpgI0ow

猜你喜歡