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

2007年之前我一直在為制造型企業(yè)建數(shù)據(jù)倉(cāng)庫(kù)，直到去了美國(guó)的之后，才開始進(jìn)入到互聯(lián)網(wǎng)，服務(wù)過(guò)兩家公司，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)品的道路。

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

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

對(duì)于產(chǎn)品經(jīng)理而言，他們關(guān)心的是什么呢?產(chǎn)品經(jīng)理對(duì)網(wǎng)站或者是 APP 的 UI 、UX 是最熟悉的，因?yàn)樗麄儏⑴c了其中的設(shè)計(jì)：用戶應(yīng)該怎么交互，有哪些交互上面不方便的地方，每一級(jí)菜單用戶交互的流程，交互上的死角和邊界;然后是設(shè)計(jì)，UI 是不是夠簡(jiǎn)潔，美觀，吸引人?哪些鏈接需要加強(qiáng)用戶關(guān)注度，哪些鏈接需要減低用戶的關(guān)注度?？偠灾际菫榱擞脩趔w驗(yàn)，好的用戶體驗(yàn)才能帶來(lái)用戶活躍，提高增長(zhǎng)。

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

在GrowingIO圈選以查看相關(guān)數(shù)據(jù)

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

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

GrowingIO一目了然的數(shù)據(jù)看板

分析師構(gòu)建報(bào)表的數(shù)據(jù)從哪里來(lái)呢?在數(shù)據(jù)庫(kù)。

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

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

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

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

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

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

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

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

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

日志是這個(gè)樣子的：

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

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

• ***步：先埋點(diǎn)
• 第二步：收集日志
• 第三步：建立數(shù)據(jù)庫(kù)
• 第四步：分析數(shù)據(jù)
• 第五步：得出產(chǎn)品經(jīng)理要的分析結(jié)果

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

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

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

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

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

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

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

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