資料分析這點事

2022-04-19 12:26:19 字數 3818 閱讀 3525

**自:

先宣告一下,按照傳統的定義,我還真不是資料分析高手,各種關聯演算法,只會最簡單的一種(話說不少場合還算管用);各種挖掘技術,基本上一竅不通;各種牛逼的資料分析工具,除了最簡單的幾個免費統計平台之外,基本上乙個都不會用。所以,各種高手高高手請隨意bs,或自行忽略。這裡說點高手不說的。

從微博段子說起,微博上關於資料分析有兩個段子,我經常當作案例講,第乙個段子,說某投資商對某企業所屬行業有興趣,要做背景調查,甲是技術流,一周分析各種網上資料,四處尋找行業材料,天天熬夜,終於寫出乙份報告;乙是人脈流,和對方高管喝了次酒,請對方核心人員吃了頓飯,所有內幕資料全搞定,問誰的方法是對的;第二個段子,某電商發現競爭對手**店,周收入突然下降了30%,但是隔週後又自然恢復,中間毫無其他異常現象,於是老闆讓分析師分析,苦逼的分析師辛苦數日,做各種數學模型,總算找到勉強的理由自圓其說,老闆讀畢,雖說不能讓人信服,卻也沒有更合理的解釋,某日,見對手老闆,閒聊此事,「你們某段時間怎麼突然收入下降?」「嗨,別提了,丈母娘去世了,回家奔喪,公司放羊了。」老闆恍然大悟。

兩個段子,第乙個段子,微博上一邊倒的說,苦逼分析沒有人脈有用;第二個段子類似,一邊倒的認為,人脈的訊息比苦逼分析管用多了。但是我想說的是,這個解讀絕對是錯的!

我常訂閱一些著名分析師的微博,他們透露的資料往往是很有價值的(這是我訂閱的原因),但是他們的解讀通常是慘不忍睹的,這就是只看表象的惡果,而且隨便翻看一下他們的資料解讀,可以說他們的資料感和資料認知貧乏到可笑,甚至缺乏最基本的資料校核和考證的能力,他們拿到了某公司核心資料又怎樣?沒經歷過苦逼的分析,他們其實什麼都看不到。

第二個段子同理,如果不是持續有效的資料跟蹤,怎麼能得出下降30%的結論,這一資料結論與人脈得到的訊息相互驗證,才會得到完整真實的結果,否則僅僅是閒聊,你怎能知道對方企業管理對業績影響的範疇,苦逼的分析也許一時沒有人脈的訊息管用,但是你所得到的對資料的認知和積累,是人脈永遠不會給你的。

所以,再次強調,基本的資料跟蹤和日常的資料感養成,絕不是可以忽略和無視的。人脈情報可以成為資料解讀重要的資訊**,但是絕不能喧賓奪主,替代基本的資料分析工作。

作為公司或團隊負責人,怎麼培養員工的資料感,我其實也有乙個建議,平時可以搞一些小的競猜,比如團隊集體競猜新產品或產品改版上線後的日活躍使用者,或者pv數字,或者收入資料,等等;然後看誰的最準,一種是懲罰制,最不准的請最準的喝奶茶,吃冰淇淋;另一種不懲罰,最準的累計積分後公司可以發一些獎品鼓勵,這樣下去大家的資料感就會在日常培養起來,而且對團隊的氣氛培養也有幫助。

資料感之後,談資料分析的方法,我的建議是,不炫技,不苛求技術複雜度,最簡單的資料,所包含的資訊往往是最有價值的,而很多人恰恰這一步都沒做好,就總想著弄一堆挖掘演算法;資料的價值在於正確的解讀,而不是處理演算法的複雜度,切不可喧賓奪主。 大公司的kpi制度,往往會產生偏差,比如技術工程師的評定,要講究「技術複雜度」、「技術領先性」,直接導致簡單的事情沒人肯做,最基本的工作不認真做!所以往往是大公司的分析工程師,為了評高階工程師,非要簡單問題複雜化,四則運算就搞定的事情一定要弄一套詭異的演算法,最終非但浪費了資源,消耗了時間,而且往往由於工程師對業務理解的漠視,對應的產品人員又對演算法的陌生,導致了嚴重的理解歧義,從而出現各種誤讀。

下面說關鍵,資料解讀,正確的資料解讀,是所有資料分析工作最關鍵的一步,這一步錯了,前面的所有努力都是白搭,然後,往往很多人簡單的以為「資料會說話」,他們認為把資料處理完一擺就ok了,所以我看到很多知名分析師拿著正確的資料信口胡謅;而更有甚者,顯然是故意的行為,乙個非常非常著名的、口碑極佳的跨國企業,曾經就同乙份很酷的資料,在不同的場合下,為了市場公關的需求,做出不同的解讀;這簡直就是道德問題了。

資料解讀,不能是為了迎合誰,要遵循資料的本質,要遵循科學的邏輯,要有想象力(配合求證),可能有時候也需要依賴人脈關係所獲得的情報,(這個也有很多典型範例),這個具體再怎麼說可能我也說不清楚,說幾個反面例子也許更容易理解。

1、因果關聯錯誤,或忽略關鍵因素,a和b的資料高度相關,有人就片面認為a影響了b,或者b影響了a;但是,有時候真實原因是c同時影響了a和b,有時候c被忽略掉了。

2、忽略沉默的大多數,特別是網上投票,調查,極易產生這種偏差,參與者往往有一定的共同訴求,而未參與者往往才是主流使用者。

3、資料定義錯誤,或理解歧義,在技術與市場、產品人員溝通中產生資訊歧義,直接導致所處理的資料和所需求的資料有偏差,結果顯著不正確。

5、忽略前提;有些資料結論是基於某種前提,符合某種特定場景下得出的,但是解讀者有意或無意忽略前提,將結論擴大化,顯著誤讀。

6、忽略互動;在商業模式改造和產品改進,往往都會出這類問題,最簡單說,你遊戲中的道具降價,對收入的影響是增還是減?如果忽略互動,僅僅依賴於資料推算,當然是減,但是實際呢?做運營的都知道。

7、缺乏常識;如果對一些重要的紀念日,節日,或者網購節不了解,那去處理有關資料顯然就不知所云了。做行業報告更是如此,很難想像對行業不了解的人能做出怎樣的報告。

8、無視樣本偏差;我們通常做資料調研,是基於樣本資料,而取樣過程本身很難做到完全的公平和分散,樣本偏差要控制在合理範疇內,即便無法控制,在結論中也需要標註;這才是嚴謹的資料解讀,對樣本偏差視而不見,甚至為了某種宣傳目的刻意尋找偏差的樣本,都不可能做出好的資料結論。

那麼, 資料處理也多說一點,雖說是個技術活,但是有些不那麼技術的事情,也必須做到位才行;很多時候,我看到乙個資料,不符合我的預期,我第一反應,是了解資料**和處理邏輯,我們通常面對的資料,包括大量的干擾,噪音資料,以及一些識別上容易產生歧義甚至誤判的資料,這都是需要處理的,很多時候工程師只關心演算法層面、效率層面,不願意也不關心這些東西,所得出的資料結論失真度就非常高,越是大公司,這種情況越普遍;在我效力的巨頭公司時,這樣的範例非常多,處理方法其實很簡單,多看看源資料,對中間的噪音和干擾資料正確識別標註,對容易誤判的資料進行二次判定,全是苦力活,沒啥技術含量,但是這是必須的。

最後,很多人想知道我怎麼看資料,或者想問我,他們每天看很多資料,不知道怎麼去看,我其實有很簡單的三板斧,一學就會,一用就靈,對常見的資料場景,可解決絕大部分日常需求。 簡單說就是「對比,細分,溯源」 六字真言,沒了。

對比,資料放在那裡,是沒意義的,你說你遊戲周流失率80%,啥情況?不知道,你問我我也不知道。對比起來才知道。

一是橫比,你拿出50款遊戲來比,別人平均流失率90%,你80%,你遊戲還不錯勒,別人要平均流失65%,你80%,這就有問題了。

二是縱比,和自己時間軸比,你兩個月前1.0版本流失率90%,你現在80%,有進步麼,你要是兩個月前是50%,現在80%,好好反思嘍。

所以,我特別強調,在通常企業資料監控,顯示一大屏資料的介面上,對比特徵要最大體現,比如所有同比下降超過多少比例的一概紅色體現,所有上公升多少比例的一概綠色體現,公司運營狀況一目了然。

細分,資料出現對比異常,你當然想知道原因,那就需要細分了。

細分先分維度,再分粒度,什麼是維度?你按照時間去分,就是時間維度,按照地區去分,就是地區維度,按照來路去分,就是來路維度,按照受訪去分,就是受訪維度;你說今天**訪問量漲了5%,咋回事不知道,你細分一看,大部分網頁都沒漲,某個頻道某個活動頁漲了300%,這就清楚了,這就是細分最簡單的範例,其實很多領域都通用。 粒度是什麼,你時間維度,是按照天,還是按照小時?這就是粒度差異,你來路維度,是來路的**,還是來路的url,這就是粒度的差異;這樣可以將對比的差異值逐級鎖定,尋找原因。

溯源,有時候我對比,細分鎖定到具體維度,具體粒度了,依然沒有結論,怎麼辦,溯源,依據鎖定的這個維度和粒度作為搜尋條件,查詢所涉及的源日誌,源記錄,然後基於此分析和反思使用者的行為,往往會有驚人的發現,我們正是基於這一邏輯發現過產品的一些缺陷,而且你不斷通過這個方式分析資料,對使用者行為的理解也會逐步加深。

其實,這個話題還有很多延伸,比如,如何看乙個年輕人有沒有資料分析潛質;以及如何培養資料分析和產品分析人才,等等,不過,就這樣吧。今天說的不少了,我水平有限,吃飯的就這幾招,而且又老又笨,大家都會了我離下崗也不遠了,您就凑活看吧。

感謝諸多網友反饋提到的錯誤用詞,緯度修改為維度,特此標註。

還有這個人品大爆發,連續被名人推薦,受寵若驚,其實,這個,愧不敢當

資料分析這點事

看到這篇文章,完全對映出當今網際網路中存在的一些問題,不僅僅是在資料分析領域,深感無力,因為覺得寫的很樸實,所以轉於此.from 先宣告一下,按照傳統的定義,我還真不是資料分析高手,各種關聯演算法,只會最簡單的一種 話說不少場合還算管用 各種挖掘技術,基本上一竅不通 各種牛逼的資料分析工具,除了最簡...

需求分析和資料分析那些事。

需求分析和資料分析有什麼區別 1.概念不同 需求分析也稱為軟體需求分析 系統需求分析或需求分析工程等,是開發人員經過深入細緻的調研和分析,準確理解使用者和專案的功能 效能 可靠性等具體要求,將使用者非形式的需求表述轉化為完整的需求定義,從而確定系統必須做什麼的過程。需求分析是軟體計畫階段的重要活動,...

mount掛載這點事

一.作用 掛接目錄和檔案系統 二.mount的標準用法 mount t type device dir mount t 檔案系統型別 裝置名 掛載點 mount 192.168.86.5 share mnt三.mount的檢視 df h 可以來檢視對應裝置和目錄的掛載關係 mount命令直接回車,也...