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

2007年之前我一直在為制造型企業建數據倉庫，直到去了美國的之后，才開始進入到互聯網，服務過兩家公司，Linkedin 4年和 eBay 3年多。天天和產品經理、數據分析師在一起，幫助他們準備需要的數據、分析產品和用戶，***把分析的結果做到產品里面去。走上了數據采集 - 處理 - 清洗 - 展現 - 分析 - 數據產品的道路。

一個互聯網公司要做好 Growth，就要做好產品體驗。想要做好產品體驗，產品經理***需要的就是數據分析支持，有了數據才能開始Growth Hacker…此處省去10000字關于 Growth Hacker。

1.產品經理關注的是用戶體驗

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

比如網頁端( APP 端同理)：

在GrowingIO圈選以查看相關數據

2.分析師的報表為產品經理提供數據支持

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

GrowingIO一目了然的數據看板

分析師構建報表的數據從哪里來呢?在數據庫。

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

“哪里有頁面瀏覽的表，哪里有搜索的表，哪里有廣告的展現，點擊的表，哪里有手機用戶事件的表，哪里有用戶屬性的表，這些表每個字段對應了哪些維度和指標，哪里有宏觀的已經計算好的指標，哪里有微觀的詳細的用戶事件，還有很多過濾條件等等。”

對于一個剛入職的分析師，即使是有專人帶的情況下，也是需要一定的時間才能成長的，不然很可能提供了錯誤的數據，導致了錯誤的決策。

如下圖是數據分析師們熟悉的數據庫結構，可以幫助他們迅速的找到表的定義和字段的定義：

數據工程師設計并構建了上面的數據庫模型，同時他們也要負責源源不斷的把數據插入到這些數據庫的表中，這些數據可以存在數據庫里面，也可以存在 Hadoop 的數據集群中。

3.依賴專職數據工程師的繁瑣流程

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

總之如果要得到沒有事先收集的用戶行為事件數據，就要在前端的代碼里面埋事件代碼，也就是在用戶事件產生的源頭埋點，才能在服務端得到相應的日志數據。

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

日志是這個樣子的：

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

從工程的角度出發，數據處理的順序是這樣的：

• ***步：先埋點
• 第二步：收集日志
• 第三步：建立數據庫
• 第四步：分析數據
• 第五步：得出產品經理要的分析結果

4.產品經理借助數據分析工具可獨立完成

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

從產品經理的角度出發，數據處理的順序是這樣的：

***步：產品經理直接圈選，看數據結果。

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

產品經理和數據分析師可以在很短的時間能創建出看板，從事件的定義到產生分析結果，只要短短幾秒鐘，而且還追溯了過去7天的歷史數據。

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

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