說一個東西重要，肯定要講為什么，不然絕對是要被拿著刀追幾條街的。
那么，數據分析為什么重要呢？至少有以下好處：
相比“似乎”、“好像”，能夠更加客觀的呈現真實現狀；
相比“我以為”、“我覺得”，數據的改變是對產品”改變”做出的最直觀、最無聲的投票，數據可以佐證“改變”是否正確、恰當以及效果如何；
相比所謂的“經驗”、“年紀”、“職位”，數據能夠排除掉這些太不可控的“主觀”的影響/壓力，作為另一個相對客觀的決策依據；
說的更加大白話一些的，那就是：
你剛接手個新業務，搞不清現狀，小伙伴也東一嘴西一嘴的講的碎碎的，你可以看數據；
如果你想做某個需求，人家不給你做，你可以甩數據給他看，證明需求的必要性；
如果你不想做某個需求，但人家硬要你做，你還是可以甩數據，證明需求無意義或者效果不理想；
如果你做了需求不知道要不要繼續迭代下去，你還是可以看數據，去看用戶的無聲投票如何；
數據是產品、運營、技術日常裝備中必不可少的矛和盾。至于什么時候是矛，什么時候是盾，那就看不同場合不同情況了。
// 補充：數據分析輔助決策，但并不是決策的唯一要素。我并不鼓吹數據分析天下第一，請注意，合理使用才是王道。
數據的最大天坑
數據分析，字面意思，數據分析由兩個部分組成：一是數據，二是分析，看起來跟廢話一樣，但卻也是絕大多數人都忽略的。
大多數人在講到數據分析的時候，更加注重的是分析，而并不是數據本身，這就造成了 數據分析最大的誤區：不關心數據怎么來，使勁兒做無用功 。
舉個簡單的例子唄？
在App的新版本上，產品經理新加了個子頻道。版本上了一段時間數據穩定后，產品經理從數據發現，哎喲，這個子頻道很吊炸天啊，點擊率、登錄比等數據同比甩其他子頻道N條街啊，恩，說明這個子頻道用戶很需要呀，以后要接著往這個方向上做。
看似，產品經理好像做了正確決策吧？
然而，oh，no，不幸的消息來了！
程序員在數據埋點的時候不小心埋錯了，他把另一個熱門子頻道的數據和這個新頻道埋在了一起，數據計算的是這兩個頻道的總和！（抱歉，程序員又一次實力背鍋，之后會為你們正名）
因為錯誤的數據，得出了錯誤的分析結果，并且還做了后續錯誤方向的工作，這在日常中其實并不少見，雖然真的很蠢。
有效數據分析的前提，是對正確的數據做分析。
分析的最大天坑
數據怎么來的，是基礎。得來的數據怎么分析，是進階。光有數據不分析，假把式，還糟蹋了人家的SQL。
這就引來了一個重要問題： 為什么要分析？
用基本的分析去了解現狀以及趨勢；
用針對的分析去驗證或者踢翻自己的想法；
看似很簡單，實際做起來卻一點兒都不簡單。又要舉個常見例子唄：
新版本發布了一段時間，數據也穩定了，產品經理讓實習生A、B、C分別做一份用戶對新版本各項修改內容的數據分析反饋報告。
實習生A：這個簡單啊，數據組的同學一定有數據，拿過來就是了。
最后他把各種原始數據表發給了產品經理；
產品經理內心獨白：X，我要你有個啥用？
實習生B：這個工作，數據同學說不定已經做了，直接找他問就好了嘛。
最后他把數據挖掘童鞋的口述內容寫成了報告發給了產品經理；
產品經理內心獨白：雖然比之前的那個好，但依舊X，你自己的腦子呢？
實習生C：這個報告不是那么好寫的，至少得：
看下新增、優化、影響了哪些地方做重點觀察；
圍繞著這些地方，分別列好目標和可能的猜想；
找數據挖掘童鞋聊并且記錄根據他的角度數據處于什么樣的情況，還得記得拿原始數據；
自己再做一次針對性的數據分析工作；
得出一些結論，保留一些疑惑等；
最后他把根據以上步驟得出的觀點做成了報告發給了產品經理，同時附帶了原始數據的各種變形計算；
產品經理內心獨白：這個上道，可以的可以的。
實習生A、B其實都屬于沒有搞清楚為什么要分析，分析的目的到底是什么。沒有想清楚這一環節，自然給到的分析結果也沒什么用了。
分析目的是指南針，只有方向對了，后續的各種分析方法以及分析結果才有意義。
上文舉的例子，其實一部分說明了數據分析過程中除了以上兩大坑之外的一些其他小坑坑，下面也來簡單列一列：
1. 小團隊的數據正確性很難被保證
這個就是上文舉例的時候我說會為開發同學正名的部分。大公司暫且不說，畢竟，光是數據支持團隊就比人家小公司一整個團隊的人還要多了。
小公司往往沒有資源去組建自己的數據團隊，這個時候就要使用各種第三方的統計軟件來做數據埋點。然而，各個統計軟件又有各自的問題：
GA ：需要翻墻，數據會計漏；
百度 ：額，不說了；
友盟 ：統計大的數據ok，但是在細致的用戶行為方面就比較菜了，代碼埋點也是個坑，數據也不圖表化！（好久前用的，可能現在已經慢慢有圖表了吧？）；
fabric ：和友盟其實差不多，但是強在程序報錯上，另外數據圖表化做的也是很炫酷，但，還是坑爹的代碼埋點；
growing io/諸葛io ：強于細致的用戶行為數據分析，同時宣稱可以無代碼埋點。然而無代碼埋點又是另一個不亞于代碼埋點的大坑，必須符合他的框架寫法才行，不然數據統計不上或者出錯。然而，框架寫法又沒有明確的文本說明，開發也不一定能改掉自己的寫法。另外，細致的用戶行為數據分析，在實際分析操作上也是很蛋疼的；
完蛋，扯遠了，這塊如果感興趣，可以專門搞篇文章寫寫。想說的是，代碼埋點會產生很多問題，例如：
可能因為不同程序員的頁面代碼寫法不同，計算結果不同；
可能因為埋點過程中沒有溝通好，出現理解偏差，計算結果不同；
可能因為開發不小心埋錯點，計算結果不同；
可能因為版本迭代修改了某個地方，導致計算結果不同；
非常多可能性，導致埋點錯誤，從而導致數據錯誤。每次看移動端數據，都要ios和android端一起對著看，誰能懂？特么的跟偵探一樣樣的。
2. 存在已久并不代表一定正確
這個存在已有，不僅是指數據，同樣也指分析結果。
某個數據存在已有，所有人都對Ta沒有質疑，這就能說明這個數據沒錯了么？
其實不一定哦，也許這個數據從未被人注意過，也有可能大家都把質疑數據的正確性這個前提給忽略掉了。
所以，如果在分析的過程中發現，數據的橫向對比或者縱向對比，結果存在一定的違背，那么這個時候就要注意了。
至于分析結果的存在已久嘛，沒啥好說的，產品功能、產品運營手法都有可能導致數據的大變動，分析時段自然要比較新鮮才有用。
3. 數據條件很重要
數據條件是什么意思？說白了就是放在數據這兩字前的定語，即：什么樣的數據。（這是定語還是形容詞，傻傻搞不清）
舉個例子：
極度活躍用戶、一般活躍用戶、不活躍用戶、沉默用戶、流失用戶。在用戶之前的字就是數據條件。
為啥說數據條件很重要呢？原因在于不同條件的數據在各項指標上可能都會差異非常大，而無法用簡單的均值來做概括。例如極度活躍用戶在活躍天數、活躍時長、日活躍次數、留存率等上都會甩掉其他用戶好幾個級別。
當然，更為日常的情況是，在和數據同學溝通的時候，一定要先確保大家的溝通前提處在同一條件下，不然很可能出現的情況是：拿到的數據是正確的，但是條件是偏差的。
4. 第一手分析很重要
很多小伙伴喜歡偷懶，覺得有數據挖掘同學分析數據就可以了，但其實并不是這樣的。
其一：除了數據本身是客觀的之外，對數據做的任何處理都是主觀的，不管是用模型還是各種數據之間的變形計算，都是主觀的，差別在于主觀的程度多少而已，每個人都會站在自己的背景知識去處理數據，如何保證別人的和自己相同呢？
其二：在分析數據的過程中，一般來說，各種橫縱向對比，是可以發現一些自己之前沒有注意過的結論的。而這點，別人幫你分析的過程中，一般這些信息無形中就不見了。
5. 分析具有聯動性
絕大多數情況下，單獨看某一個數據，一般意義不那么大，或者說達不到更好的效率。
舉些例子：
評價某模塊做的好不好，只看絕對uv，而不同時看模塊登錄比，介是耍流氓；
評價內容做的好不好，只看生產的絕對量，而不同時看不同類型內容的分別用戶uv占比/生產量，介也是耍流氓；
聯動的看數據，才能更加綜合的去判斷。
本文轉載自網絡，版權歸原作者所有！文章轉載請保留網址：http://waterplane.cn/news/industry/1898.html
