數據分析,你逃不掉的幾大“坑”

9 評論 19913 瀏覽 86 收藏 13 分鐘

今天想寫的主題是:數據分析?,我一直覺得這屬于很多人不知道Ta有多重要、一部分人知道Ta重要但并不重視,只有極少數人真正在工作中重視Ta并且運用Ta。

說一個東西重要,肯定要講為什么,不然絕對是要被拿著刀追幾條街的。

那么,數據分析為什么重要呢?至少有以下好處:

  1. 相比“似乎”、“好像”,能夠更加客觀的呈現真實現狀;
  2. 相比“我以為”、“我覺得”,數據的改變是對產品”改變”做出的最直觀、最無聲的投票,數據可以佐證“改變”是否正確、恰當以及效果如何;
  3. 相比所謂的“經驗”、“年紀”、“職位”,數據能夠排除掉這些太不可控的“主觀”的影響/壓力,作為另一個相對客觀的決策依據;

說的更加大白話一些的,那就是:

  • 你剛接手個新業務,搞不清現狀,小伙伴也東一嘴西一嘴的講的碎碎的,你可以看數據;
  • 如果你想做某個需求,人家不給你做,你可以甩數據給他看,證明需求的必要性;
  • 如果你不想做某個需求,但人家硬要你做,你還是可以甩數據,證明需求無意義或者效果不理想;
  • 如果你做了需求不知道要不要繼續迭代下去,你還是可以看數據,去看用戶的無聲投票如何;

數據是產品、運營、技術日常裝備中必不可少的矛和盾。至于什么時候是矛,什么時候是盾,那就看不同場合不同情況了。

// 補充:數據分析輔助決策,但并不是決策的唯一要素。我并不鼓吹數據分析天下第一,請注意,合理使用才是王道。

數據的最大天坑

數據分析,字面意思,數據分析由兩個部分組成:一是數據,二是分析,看起來跟廢話一樣,但卻也是絕大多數人都忽略的。

大多數人在講到數據分析的時候,更加注重的是分析,而并不是數據本身,這就造成了數據分析最大的誤區:不關心數據怎么來,使勁兒做無用功

舉個簡單的例子唄?

在App的新版本上,產品經理新加了個子頻道。版本上了一段時間數據穩定后,產品經理從數據發現,哎喲,這個子頻道很吊炸天啊,點擊率、登錄比等數據同比甩其他子頻道N條街啊,恩,說明這個子頻道用戶很需要呀,以后要接著往這個方向上做。

看似,產品經理好像做了正確決策吧?

然而,oh,no,不幸的消息來了!

程序員在數據埋點的時候不小心埋錯了,他把另一個熱門子頻道的數據和這個新頻道埋在了一起,數據計算的是這兩個頻道的總和?。ū福绦騿T又一次實力背鍋,之后會為你們正名)

因為錯誤的數據,得出了錯誤的分析結果,并且還做了后續錯誤方向的工作,這在日常中其實并不少見,雖然真的很蠢。

有效數據分析的前提,是對正確的數據做分析。

分析的最大天坑

數據怎么來的,是基礎。得來的數據怎么分析,是進階。光有數據不分析,假把式,還糟蹋了人家的SQL。

這就引來了一個重要問題:為什么要分析?

  • 用基本的分析去了解現狀以及趨勢;
  • 用針對的分析去驗證或者踢翻自己的想法;

看似很簡單,實際做起來卻一點兒都不簡單。又要舉個常見例子唄:

新版本發布了一段時間,數據也穩定了,產品經理讓實習生A、B、C分別做一份用戶對新版本各項修改內容的數據分析反饋報告。

實習生A:這個簡單啊,數據組的同學一定有數據,拿過來就是了。

最后他把各種原始數據表發給了產品經理;

產品經理內心獨白:X,我要你有個啥用?

實習生B:這個工作,數據同學說不定已經做了,直接找他問就好了嘛。

最后他把數據挖掘童鞋的口述內容寫成了報告發給了產品經理;

產品經理內心獨白:雖然比之前的那個好,但依舊X,你自己的腦子呢?

實習生C:這個報告不是那么好寫的,至少得:

  1. 看下新增、優化、影響了哪些地方做重點觀察;
  2. 圍繞著這些地方,分別列好目標和可能的猜想;
  3. 找數據挖掘童鞋聊并且記錄根據他的角度數據處于什么樣的情況,還得記得拿原始數據;
  4. 自己再做一次針對性的數據分析工作;
  5. 得出一些結論,保留一些疑惑等;

最后他把根據以上步驟得出的觀點做成了報告發給了產品經理,同時附帶了原始數據的各種變形計算;

產品經理內心獨白:這個上道,可以的可以的。

實習生A、B其實都屬于沒有搞清楚為什么要分析,分析的目的到底是什么。沒有想清楚這一環節,自然給到的分析結果也沒什么用了。

分析目的是指南針,只有方向對了,后續的各種分析方法以及分析結果才有意義。

上文舉的例子,其實一部分說明了數據分析過程中除了以上兩大坑之外的一些其他小坑坑,下面也來簡單列一列:

1. 小團隊的數據正確性很難被保證

這個就是上文舉例的時候我說會為開發同學正名的部分。大公司暫且不說,畢竟,光是數據支持團隊就比人家小公司一整個團隊的人還要多了。

小公司往往沒有資源去組建自己的數據團隊,這個時候就要使用各種第三方的統計軟件來做數據埋點。然而,各個統計軟件又有各自的問題:

  • GA:需要翻墻,數據會計漏;
  • 百度:額,不說了;
  • 友盟:統計大的數據ok,但是在細致的用戶行為方面就比較菜了,代碼埋點也是個坑,數據也不圖表化!(好久前用的,可能現在已經慢慢有圖表了吧?);
  • fabric:和友盟其實差不多,但是強在程序報錯上,另外數據圖表化做的也是很炫酷,但,還是坑爹的代碼埋點;
  • growing io/諸葛io:強于細致的用戶行為數據分析,同時宣稱可以無代碼埋點。然而無代碼埋點又是另一個不亞于代碼埋點的大坑,必須符合他的框架寫法才行,不然數據統計不上或者出錯。然而,框架寫法又沒有明確的文本說明,開發也不一定能改掉自己的寫法。另外,細致的用戶行為數據分析,在實際分析操作上也是很蛋疼的;

完蛋,扯遠了,這塊如果感興趣,可以專門搞篇文章寫寫。想說的是,代碼埋點會產生很多問題,例如:

  • 可能因為不同程序員的頁面代碼寫法不同,計算結果不同;
  • 可能因為埋點過程中沒有溝通好,出現理解偏差,計算結果不同;
  • 可能因為開發不小心埋錯點,計算結果不同;
  • 可能因為版本迭代修改了某個地方,導致計算結果不同;

非常多可能性,導致埋點錯誤,從而導致數據錯誤。每次看移動端數據,都要ios和android端一起對著看,誰能懂?跟偵探一樣樣的。

2. 存在已久并不代表一定正

這個存在已有,不僅是指數據,同樣也指分析結果。

某個數據存在已有,所有人都對Ta沒有質疑,這就能說明這個數據沒錯了么?

其實不一定哦,也許這個數據從未被人注意過,也有可能大家都把質疑數據的正確性這個前提給忽略掉了。

所以,如果在分析的過程中發現,數據的橫向對比或者縱向對比,結果存在一定的違背,那么這個時候就要注意了。

至于分析結果的存在已久嘛,沒啥好說的,產品功能、產品運營手法都有可能導致數據的大變動,分析時段自然要比較新鮮才有用。

3. 數據條件很重要

數據條件是什么意思?說白了就是放在數據這兩字前的定語,即:什么樣的數據。(這是定語還是形容詞,傻傻搞不清)

舉個例子:

極度活躍用戶、一般活躍用戶、不活躍用戶、沉默用戶、流失用戶。在用戶之前的字就是數據條件。

為啥說數據條件很重要呢?原因在于不同條件的數據在各項指標上可能都會差異非常大,而無法用簡單的均值來做概括。例如極度活躍用戶在活躍天數、活躍時長、日活躍次數、留存率等上都會甩掉其他用戶好幾個級別。

當然,更為日常的情況是,在和數據同學溝通的時候,一定要先確保大家的溝通前提處在同一條件下,不然很可能出現的情況是:拿到的數據是正確的,但是條件是偏差的。

4. 第一手分析很重要

很多小伙伴喜歡偷懶,覺得有數據挖掘同學分析數據就可以了,但其實并不是這樣的。

其一:除了數據本身是客觀的之外,對數據做的任何處理都是主觀的,不管是用模型還是各種數據之間的變形計算,都是主觀的,差別在于主觀的程度多少而已,每個人都會站在自己的背景知識去處理數據,如何保證別人的和自己相同呢?

其二:在分析數據的過程中,一般來說,各種橫縱向對比,是可以發現一些自己之前沒有注意過的結論的。而這點,別人幫你分析的過程中,一般這些信息無形中就不見了。

5. 分析具有聯動性

絕大多數情況下,單獨看某一個數據,一般意義不那么大,或者說達不到更好的效率。

舉些例子:

  • 評價某模塊做的好不好,只看絕對uv,而不同時看模塊登錄比,介是耍流氓;
  • 評價內容做的好不好,只看生產的絕對量,而不同時看不同類型內容的分別用戶uv占比/生產量,介也是耍流氓;

聯動的看數據,才能更加綜合的去判斷。

感覺寫的差不多了,那就先這樣唄?雖然還有一些其他小坑,哎喲,以后再寫吧。再熬夜,感覺一周都要緩不過去了。

題圖來自 Unsplash ,基于 CC0 協議

#專欄作家#

瑤子,微信公眾號killifer,人人都是產品經理專欄作家。原選股寶首席打雜PM汪,現某廠打雜運營喵。從0到1分別做過產品和運營,相信懂業務懂人性的商人才可能是個好產品運營。

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 起點學院專門為0基礎的0-2歲互聯網人開設了《15天入門互聯網數據分析》班級哦~課程由數據思維+真實案例+實操相結合,提升你的數據分析能力!戳此了解>>http://996.pm/YNG4e

    來自廣東 回復
  2. 大神,第三方數據統計軟件TalkingData和易觀方舟怎么樣?

    來自山東 回復
  3. 啊,各種數據采集方式的優劣勢對比,評論竟然不能配圖。有需要的朋友可以私聊我或者加我微信hhhcccmmm

    來自北京 回復
    1. 另外,所有的分析產品都有一定的優劣,還沒見過有哪一款產品在整個數據分析鏈路上做到100分的。當然,我們也不會去苛求這件事,一般的分析童鞋都是取幾款數據平臺的各自長處一起使用的。

      針對我提出來的一些體驗問題,不需要太過介懷。

      來自浙江 回復
  4. 首先,關于作者文中提到的數據分析的第一大誤區,我個人表示贊同:不關心數據怎么來,使勁兒做無用功。確實,在做分析之前的上一層,一定是數據來源或者是采集的準確性,這也是我們服務客戶過程中在采集這塊兒著重強調的,比如采集時機的重要性,團隊內部的信息通暢。對于文中提到了諸葛io的部分,可能我會從以下兩個方面做些說明:
    一、關于采集
    諸葛io 主張代碼采集,(我們在市場層面從沒有主打過可以無代碼埋點)雖然我們今年也支持了全埋點、可視化埋點,但我們認為他有不同的應用場景,后兩者我們建議用在落地頁、或產品頁面體驗層面的衡量,這些頁面對數據偏統計需求,或者因為量太大加上開發資源緊張等等。更重要的一點是因為代碼埋點的準確程度、精細化程度以及對數據的二次可用性都要遠遠優于后兩者。
    關于目前的幾種數據采集方式的優劣勢如下圖:

    二、關于提到的代碼埋點的問題
    從文中羅列的幾個問題來看,其實都不是這項技術本身的問題,都可以通過內容溝通和協同解決。因為就目前看來,沒有比代碼埋點采集到的數據更準確了,以“注冊按鈕”點擊為例,通常我們判斷用戶注冊成功需要請求服務器,當服務器返回注冊成功的判斷時才會記為這個按鈕成功觸發了,而通過可視化埋點只能采集頁面元素的點擊情況,也就是不管你有沒有輸入手機號驗證碼,只要這個按鈕可點擊,用戶一但點擊,就會+1,如果通過這個按鈕的點擊情況確定注冊人數肯定會有誤差。但恰恰是代碼埋點的靈活性,你可以采集click,也可以等服務器判斷成功了再記,那這個過程中最大的問題就是需求提清楚,需求是采集click就行還是需要準確的注冊,直接影響這段代碼放哪兒。
    不能直接判斷準確與否,準確是建立在明確了某個數據是在什么樣的背景條件下來的就是準確的。
    在從需求到采集到測試到正式環境發版,我們有一套完整的團隊協作流程。這可以最大程度的避免文中提到的問題的發生。

    以上~

    來自北京 回復
    1. 抱歉,可能是我行文略有不當導致您產生了誤解,我可能需要解釋一下哈:

      1、針對埋點我列出了非常多的問題,但是并不代表我否認這個技術。誠如你所說,代碼埋點依舊是最精準的;

      2、雖然代碼埋點準確,但是我列的是人在使用這項技術的時候會出現的問題以及不容易被注意到的易產生數據錯誤的非技術原因。這個我認為依舊是非常有必要提醒相關的分析童鞋的。技術沒有對錯,但人的使用方法是有對錯、有使用性能問題的。指出認為因素,并不是說不要用,而是說要注意的用;

      3、針對諸葛io采集數據的技術問題,確實是我的行文使用的專有名詞不當,我文中所提到的“無代碼埋點”的意思基本等于你所說的“全埋點、可視化埋點”,想要表達的意思,也確實沒有明說,只是一筆帶過,意思就是區別于代碼埋點的另一種新的方式,可以達到基本不需要再讓程序員做一一的點對應埋點,而是可以加入一個sdk包引入相關的埋點資源,讓數據同學可以通過一定的界面去自行配置所要監測的位置,這樣的一種方法。這個方法確實有一定的優勢,但同時,我所說的問題也都存在。

      來自浙江 回復
  5. 觀點不錯,但后面扯得有點遠,最大的坑,不是在數據產生之后,而是需要什么地方出產數據,產品經理必須要明白各個埋點的作用,尤其在開始階段切忌大而泛,自己曾經就有痛苦的經歷,在第一版本已經提出了非常多的需求,雖然都很有用,但研發寫代碼都忙瘋了,還要照顧如此之多的埋點,真正上線的時候經常出現缺胳膊少腿的情況,經常是缺失了某項導致原來構想的全盤邏輯缺失。因此需要在各個版本首先明確核心的目標,逐步完善分步實施,用數據證明需要更多的數據,把大家的胃口都調動起來,整個數據分析工作才能更加有條不紊的展開

    來自廣東 回復
    1. 對的,這個其實也可以單總結一篇。我個人覺得吧,大而泛不是最大的坑點,而是大但數據鏈路不順,也就是在埋點之前,只是覺得說要埋點也不知道為什么,所以會出現各個點都埋,可能數據還丟失的情況。如果在一開始就想明白要驗證的用戶鏈路是怎么樣的,這鏈路上有哪些點,然后再去埋點,這樣就會稍稍避免一些問題。
      另外,區分優先級、把握粗細粒度確實是很大的坑點,這其實包含在文章中說的“分析的目的”,您說的很有道理,我周末就總結下這塊的內容,希望到時候可以再探討一下,嘻嘻~

      來自浙江 回復
  6. 沙發點贊。 ??

    來自北京 回復