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

2007年之前我一直在為制造型企業(yè)建數(shù)據(jù)倉庫，直到去了美國的之后，才開始進(jìn)入到互聯(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)品的道路。

一個(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 是不是夠簡潔，美觀，吸引人?哪些鏈接需要加強(qiáng)用戶關(guān)注度，哪些鏈接需要減低用戶的關(guān)注度。

總而言之，都是為了用戶體驗(yàn)，好的用戶體驗(yàn)才能帶來用戶活躍，提高增長。

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

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

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

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

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

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

對(duì)于一個(gè)剛?cè)肼毜姆治鰩煟词故怯袑Ｈ藥У那闆r下，也是需要一定的時(shí)間才能成長的，不然很可能提供了錯(cuò)誤的數(shù)據(jù)， 導(dǎo)致了錯(cuò)誤的決策。

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

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

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

可是數(shù)據(jù)庫里面存了所有我們能夠支持?jǐn)?shù)據(jù)分析師的數(shù)據(jù)嗎? 當(dāng)分析師在數(shù)據(jù)庫里面找不到數(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ā)過來的實(shí)時(shí)事件數(shù)據(jù)并生成日志數(shù)據(jù)，然后發(fā)送到后端服務(wù)器上。比如騰訊，今日頭條，新浪等等互聯(lián)網(wǎng)公司都用 Kafka 收集日志的。

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

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

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

第一步：先埋點(diǎn)

第二步：收集日志

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

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

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

作者： GrowingIO 聯(lián)合創(chuàng)始人吳繼業(yè)，原文發(fā)于微信公眾號(hào) GrowingIO 。

本文由 @吳繼業(yè) 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。