本文抽象介紹了一個產品數據體系建設，以支持產品瞭解數據如何採集、計算與展現。
近期有師弟師妹不斷問到產品經理必備技能中，數據分析是怎麼回事？產品怎麼就有數據可以分析了？
簡單瞭解了下其產生問題的原因與訴求，將其問題拆分為二：
- 產品的數據體系如何建設？
- 如何進行數據分析？
關於問題2，網上已經有足夠豐富的資源進行學習與討論，這裡不再贅述，簡而言之根據運營或迭代的目的進行深度思考與結論沉澱。
以下內容僅針對問題1在產品數據體系思路層面進行介紹，主要面向平臺類產品策劃。不足之處請多包涵。
一、為何要建設數據分析體系？
任何一個產品的迭代與運營都需要數據進行指導，基於線上數據情況，可以更準確的支持策劃與運營同學做出有效決策。
二、數據分析體系包含哪些部分？
不同行業與不同公司對產品體系的定義與訴求不同，這裡僅以平臺類抽象舉例，包含：存儲格式、上報邏輯、計算邏輯與展現方式。
三、為什麼包含這些內容？
如果PM想監測一種數據，首先需要打開數據報表來查看（即展現方式），而數據報表的製作依賴要拿到這些數據(即上報邏輯)，這些數據上報後如何在後臺計算才可以支持報表快速展現(即計算邏輯)，這些數據均基於用戶行為觸發而生成，因此需要在用戶觸發某個行為時進行數據上報（即上報邏輯）。
最後，數據上報如果是雜亂無章的，則在進行數據提取時會遇到各種各樣複雜的問題，因此我們需要給數據上報定義一個格式，格式和開發約定好，以此格式為依據，開發進行後臺數據庫定義存儲(即存儲格式)。
四、每個內容詳細是什麼？ 存儲格式
即開發與產品同學約定好的數據上報格式，產品同學根據這個格式制定數據上報賬單，開發同學根據這個格式進行數據存儲，拿最簡單的數據格式舉例：
上報邏輯
約定好上報格式後，產品側根據自身目的定製上報賬單，舉例：
開發拿到此賬單後，根據“上報時機”進行數據上報，上報後數據直接存儲到後臺以構建的數據庫中，即完成數據採集。
其中，“頁面id”和“標記id”用於給每個上報分配其“唯一識別標識”，方便後面做出具處理。上報時機則根據自身產品進行定義，通常會有“點擊時”、“曝光時”和“停留時”幾類。
計算邏輯
通常，產品發佈後我們會拿到海量數據上報，如果不對這些數據進行過濾和計算，則後期提取時則耗時巨大。因此需要在數據存儲後對數據進行一次過濾，目的是剔除無效數據並加快數據提取速度。這裡涉及涉及到比較複雜的數據挖掘算法，每個公司都會搭建專門的數據研發團隊，不再贅述，僅用下圖簡單描述。
展現方式
通常情況下，數據經過一層處理存儲到過濾表後，依舊不是我們最終想要的數據，部分數據需要再處理一次並製作數據報表以支持後續快速查看，這裡涉及到兩個問題：
1，過濾表中的數據如何做成數據報表？
2，數據報表通常有哪些？
第1個問題，這裡就與之前的“數據賬單”有關，根據之前的數據賬單，構建數據處理邏輯，給到開發進行進一步開發，並根據你的目的繪製數據報表格式。拿上面的數據賬單舉例：
比方說，我想監測“每天點擊某個按鈕的性別分佈是怎樣的？”，那麼我需要給開發提需求，以“拓展字段1”為區分，開發數據報表，其中標記id為1，僅提取該標記下的數據。報表樣式如下：
之後開發即可瞭解如何進行報表開發，後面只需要等待開發完成，每日定時監測報表數據即可。其他類型的報表邏輯同上。
第2個問題，不同產品的報表區分維度不同，比較常用的有用戶數據與用戶行為類數據，如果是平臺類產品還應該包含內容類數據。
- 用戶數據：基於用戶生命週期的各項數據。
- 用戶行為數據：用戶在使用產品時各個頁面各個按鈕的操作記錄。
- 內容類數據：app內容用戶消費情況與流轉情況(新聞/商品/遊戲等均為內容)
五、總結
本文主要介紹一個產品的數據體系建設邏輯，主要包含：“存儲格式”、“上報邏輯”、“計算邏輯”和“展現方式”。多數內容抽象到1到2個點進行介紹，僅僅為對數據分析後臺建設感興趣的同學進行思路疏通。
另外，不同公司有不同的數據建設框架，市面上也有不少性價比較高的數據SDK可以直接拿來使用，但思路大同小異。
閱讀更多 極品科技 的文章
