數(shù)據(jù)分析流程這么長，產(chǎn)品經(jīng)理如何一人搞定?

我2002年入行，那個時候還沒有“產(chǎn)品經(jīng)理”這個詞，我的主要工作是為業(yè)務(wù)部門跑數(shù)據(jù)并且制作報表， 就是傳說中“跑數(shù)據(jù)”、“做報表”的那個苦逼數(shù)據(jù)倉庫工程師。

2007年之前我一直在為制造型企業(yè)建數(shù)據(jù)倉庫，直到去了美國的之后，才開始進入到互聯(lián)網(wǎng)，服務(wù)過兩家公司，Linkedin 4年和 eBay 3年多。天天和產(chǎn)品經(jīng)理、數(shù)據(jù)分析師在一起，幫助他們準(zhǔn)備需要的數(shù)據(jù)、分析產(chǎn)品和用戶，最后把分析的結(jié)果做到產(chǎn)品里面去。走上了數(shù)據(jù)采集 – 處理 – 清洗 – 展現(xiàn) – 分析 – 數(shù)據(jù)產(chǎn)品的道路。

一個互聯(lián)網(wǎng)公司要做好 Growth，就要做好產(chǎn)品體驗。想要做好產(chǎn)品體驗，產(chǎn)品經(jīng)理第一需要的就是數(shù)據(jù)分析支持，有了數(shù)據(jù)才能開始Growth Hacker…此處省去10000字關(guān)于 Growth Hacker。

1.產(chǎn)品經(jīng)理關(guān)注的是用戶體驗

對于產(chǎn)品經(jīng)理而言，他們關(guān)心的是什么呢?產(chǎn)品經(jīng)理對網(wǎng)站或者是 APP 的 UI 、UX 是最熟悉的，因為他們參與了其中的設(shè)計：用戶應(yīng)該怎么交互，有哪些交互上面不方便的地方，每一級菜單 用戶交互的流程，交互上的死角和邊界;然后是設(shè)計，UI 是不是夠簡潔，美觀，吸引人?哪些鏈接需要加強用戶關(guān)注度，哪些鏈接需要減低用戶的關(guān)注度。總而言之，都是為了用戶體驗，好的用戶體驗才能帶來用戶活躍，提高增長。

比如網(wǎng)頁端( APP 端同理)：

2.分析師的報表為產(chǎn)品經(jīng)理提供數(shù)據(jù)支持

一個合格的數(shù)據(jù)分析師要能夠制作可視化的報表，能夠用不同的圖形表達分析的結(jié)果。比如下面的可視化報表：

分析師構(gòu)建報表的數(shù)據(jù)從哪里來呢?在數(shù)據(jù)庫。

數(shù)據(jù)庫里面有成百上千種表，一個合格的數(shù)據(jù)分析師首要的是知道數(shù)據(jù)在哪里?存在哪些表里面：

“哪里有頁面瀏覽的表，哪里有搜索的表，哪里有廣告的展現(xiàn)，點擊的表，哪里有手機用戶事件的表，哪里有用戶屬性的表，這些表每個字段對應(yīng)了哪些維度和指標(biāo)，哪里有宏觀的已經(jīng)計算好的指標(biāo)，哪里有微觀的詳細的用戶事件，還有很多過濾條件等等?！?/span>

對于一個剛?cè)肼毜姆治鰩?，即使是有專人帶的情況下，也是需要一定的時間才能成長的，不然很可能提供了錯誤的數(shù)據(jù)， 導(dǎo)致了錯誤的決策。

如下圖是數(shù)據(jù)分析師們熟悉的數(shù)據(jù)庫結(jié)構(gòu)，可以幫助他們迅速的找到表的定義和字段的定義：

數(shù)據(jù)工程師設(shè)計并構(gòu)建了上面的數(shù)據(jù)庫模型，同時他們也要負(fù)責(zé)源源不斷的把數(shù)據(jù)插入到這些數(shù)據(jù)庫的表中，這些數(shù)據(jù)可以存在數(shù)據(jù)庫里面，也可以存在 Hadoop 的數(shù)據(jù)集群中。

3.依賴專職數(shù)據(jù)工程師的繁瑣流程

可是數(shù)據(jù)庫里面存了所有我們能夠支持數(shù)據(jù)分析師的數(shù)據(jù)嗎? 當(dāng)分析師在數(shù)據(jù)庫里面找不到數(shù)據(jù)的時候， 就需要數(shù)據(jù)工程師需要從各種地方重新調(diào)取(此處省略關(guān)于實時數(shù)據(jù)流，Hadoop 集群，ETL，數(shù)據(jù)聚合等等關(guān)于技術(shù)的10000字)。

總之如果要得到?jīng)]有事先收集的用戶行為事件數(shù)據(jù)，就要在前端的代碼里面埋事件代碼，也就是在用戶事件產(chǎn)生的源頭埋點，才能在服務(wù)端得到相應(yīng)的日志數(shù)據(jù)。

在技術(shù)上 Linkedin 為互聯(lián)網(wǎng)日志做出了貢獻，開源了 Kafka。什么是 kafka?就是可以非常實時的接受客戶端發(fā)過來的實時事件數(shù)據(jù)并生成日志數(shù)據(jù)，然后發(fā)送到后端服務(wù)器上。比如騰訊，今日頭條，新浪等等互聯(lián)網(wǎng)公司都用 Kafka 收集日志的。

日志是這個樣子的：

以上的這些都是數(shù)據(jù)，不同的人看到的角度是不同的。如下圖：

從工程的角度出發(fā)，數(shù)據(jù)處理的順序是這樣的：

第一步：先埋點

第二步：收集日志

第三步：建立數(shù)據(jù)庫

第四步：分析數(shù)據(jù)

第五步：得出產(chǎn)品經(jīng)理要的分析結(jié)果

4.產(chǎn)品經(jīng)理借助數(shù)據(jù)分析工具可獨立完成

看起來這個鏈條很長，但是GrowingIO可以把它縮短，如何縮短?在一開始就從產(chǎn)品經(jīng)理的角度來看這個問題。

從產(chǎn)品經(jīng)理的角度出發(fā)，數(shù)據(jù)處理的順序是這樣的：

第一步：產(chǎn)品經(jīng)理直接圈選，看數(shù)據(jù)結(jié)果。

在保存了用戶事件之后，還可以自由的創(chuàng)造看板。如下圖

產(chǎn)品經(jīng)理和數(shù)據(jù)分析師可以在很短的時間能創(chuàng)建出看板，從事件的定義到產(chǎn)生分析結(jié)果，只要短短幾秒鐘，而且還追溯了過去7天的歷史數(shù)據(jù)。

不僅僅如此，GrowingIO 還提供用戶分群、用戶細查、事件留存和數(shù)據(jù)下載等高級功能。

我們現(xiàn)在通過云端軟件服務(wù)形式，制作了一個簡單容易上手的系統(tǒng)，可以讓初創(chuàng)公司快速地，低成本地獲得只有大公司才玩得起的實時大數(shù)據(jù)分析系統(tǒng)。