明確定位與工作重心
數據產品經理是讓數據產生價值（決策、增長、收入）的設計者、實現者和推行者。如何理解這樣的定位呢？
首先，最基礎的是要熟悉數據工具平臺與產品業務，其次，要學會逐步建立產品完整的數據指標體系，最後，是能夠通過數據分析解讀驅動業務發展。
具體拆解來看，主要包含：
（1）數據層面
源數據層：數據源的採集、埋點（客戶端訪問日誌、服務端業務數據庫表、sdk等）
數據加工層：結合業務，對收集到的數據進行加工、清洗（join）等操作
數據倉庫層：依賴結構化規範的數據表，建設和維護數據倉庫
數據應用層：規劃與設計數據指標體系（構建核心指標框架；產品、運營等指標建設）
數據訪問層：結合平臺及應用產品，支撐業務方數據需求（如：統計平臺、數據可視化平臺、資源調度平臺、渠道後臺、用戶畫像平臺、abtest平臺等）
（2）產品層面
明確產品形態及定位，熟知業務功能（數據異動跟蹤分析、數據解讀與答疑）
數據驅動產品發展規劃（版本迭代、數據反饋推進）。
根據基礎數據體系，數據產品的工作基本上需要涵蓋從數據源到最終數據應用、訪問層的各個環節。做好產品上線前數據指標的統計埋點工作，以及產品上線後的版本分析，側重點主要在於：數據應用層面（規劃和設計項目核心指標，滿足各業務方的數據需求）；數據訪問層面（做好數據分析與解讀，對上線數據進行監測以及效果分析）對數據源的處理、數據加工及數據倉庫，本文暫不展開說明。
熟悉業務邏輯與流程
1. 工作流程
數據統計埋點工作流程說明
step1：梳理產品需求
作為數據產品經理，在版本迭代階段，主要是從數據的角度出發去思考業務需求和問題點。
在產品需求文檔的梳理過程中，可以就之前版本發現的問題參與需求的收集與討論。通過數據論證，提出相關的優化改進方案或建議，給出更加合理的產品規劃和需求優先級。
step2：產品需求評審
產品需求文檔一般包含：
文檔說明（功能優先級、修改歷史）
需求分析（需求背景、需求價值或、預期目標、數據參考）
結構流程（業務流程和產品框架）
原型交互（客戶端邏輯、服務端邏輯）
數據埋點
業務產品經理主導當前版本的功能規劃及需求輸出。數據產品經理則主要是負責數據埋點部分，需要我們全程參與需求文檔的評審，理解產品功能結構和開發實現邏輯。
ps：由於各公司逐步重視 “通過數據驅動業務決策”。數據相關工作，部分公司會將其單獨拆解出來，作為數據產品經理或數據分析師的主要職責。
step3：分析產品邏輯
當產品需求文檔完成最終評審，意味著當前版本需求不會再做大的改動。此時就需要開始分析產品邏輯，理解產品核心目標和當下主要的問題點。
除了需要弄明白產品承載了哪些重要的信息和功能，以及這些信息和功能的想要達到的需求目標。還要通過深入的分析，挖掘各業務方重點關注的數據指標是什麼，確立產品的第一關鍵指標。（即分析是在什麼樣的場景下要解決什麼業務問題，為了解決這個業務問題，要通過什麼樣的數據指標衡量），項目中不同的角色關注的問題不同，我們可以更好地給出他們最想看的數據。
產品（功能點擊量、使用率、功能留存、核心路徑轉化、改版效果、用戶行為等）
運營（用戶新增、活躍、流失、付費轉化、分享等）
渠道（渠道新增、落地頁pv/uv、渠道轉化、渠道留存率、ROI等）
step4：統計需求評審
統計需評階段，主要是進行統計事件的設計和給出數據採集埋點方案。一般情況下，在做統計需求評審時，可以優先梳理產品功能結構圖，將產品的功能模塊及跳轉流程梳理出來，想清楚上游入口和下游出口是什麼。這樣做的目的也是在進行更加合理的數據指標體系的設計，以及避免埋點的重複。
ps：由於項目迭代節奏較快，推行敏捷開發（“小步快跑模式”），有時統計需求評審會和產品需求評審同時進行，就需要和業務產品保持緊密的信息對接。
step5：跟進需求開發
當產品和統計需求評審完成後，接下來會進入需求研發階段。在開發實現產品功能需求時需要我們高頻溝通，這樣做的目的是為了保證數據採集的質量及數據分析的準確性。
step6：功能驗收核對
除了產品功能的核對，數據層面主要核對內容是：
數據上報節點或時機是否準確
數據採集的結果是否真實有效/重複上報
新增/修改的統計項是否會影響到其他功能的上報規則
step7：上線數據監測
發版後，隨著版本覆蓋率的提升數據會逐漸起勢。一般情況下，需要密切監測上線前3d的數據情況，並在3d後給出一份初步的數據波動趨勢分析文檔，主要目的是：發現是否存在統計上報異常的數據指標，產品功能若出現較大問題，也要及時關注可能會影響到的統計點。根據問題緊急程度，採取發緊急修復包或其他方式解決。
step8：數據分析總結
上線後若不存在什麼問題。即可輸出當前新版本的數據分析報告，主要用於向項目組成員同步該版本的數據分析結論和迭代優化建議，建議在發版2周後再拉取數據指標進行分析總結。因為時間越短，覆蓋率越低，數據量級小，就不太能夠說明問題。
2. 細節規範
# 上線前：數據統計埋點
（1）理解產品需求文檔與業務目標
在上線前做好數據統計埋點工作，最重要的就是需要理解項目產品和業務體系。梳理產品需求、參與產品需求評審、分析產品邏輯的工作必不可少。
如何更好地理解呢？
除了深入溝通理解產品需求文檔（prd），我們自己可以去整理當前產品功能結構圖、核心業務流程圖或用戶使用路徑圖。
（2）設計統計事件及數據埋點規範
做好了準備工作，接下來最主要的就是進行統計事件的設計和給出數據採集埋點方案。本文暫不討論接入第三方統計sdk的方式進行埋點的相關內容。統計事件的設計，就是做到針對某個具體頁面，定義當前頁面中用戶的點擊或其他觸發行為並準確上報，從而提取數據進行分析，主要從用戶行為角度出發。
比如頁面中出現的某個按鈕，想知道用戶是否點擊該按鈕或點擊的頻次，統計事件就要記錄用戶點擊該按鈕的行為數據（消息數/設備數）。
如何通過用戶行為找到統計事件的對應關係？
用戶行為：分析用戶行為，找到該行為相關的信息；
事件定義：根據相關信息，定義該行為對應的事件及參數。
說明一下，在版本迭代的過程中，新版本的事件無需全部重新埋點。
歷史已有的統計事件只要有涉及到的，可列入測試check事件，版本新增的統計事件列入本期統計項。最終可彙總一份整體的數據統計事件庫，每次只需在歷史已有的內容裡新增或修改補充當前新版本的統計項，也方便我們進行長期迭代與維護。通過用戶行為找到統計事件的對應關係後，即可整理出我們最重要的統計埋點文檔。
統計埋點文檔主要包含：
更新說明（文檔更新時間、更新內容記錄）
本期統計項（新增/修改的統計事件list）
本期check事件（新增/修改的統計事件check+可能影響到的統計事件check）
後臺全部展示事件（整體的數據統計事件庫）
#舉個例子#
產品功能：美化圖片主功能中，新增馬賽克
用戶行為：用戶在美圖秀秀首頁點擊“美化圖片”按鈕-點擊“馬賽克”功能-選擇素材使用-保存
用戶行為與統計事件的對應關係（參考）：
3）需求研發測試跟進及校驗數據統計項
根據我們輸出的統計文檔，統計文檔中“統計規則”的描述，就要求清晰定義該統計事件採集的節點和上報邏輯，需要及時和開發跟進溝通；而統計文檔中“本期統計check事件”則需要詳細和測試進行核對。通常，公司優秀的開發和測試也可以更好的協助我們，對事件統計的規則做優化調整，提高數據存儲及讀取的效率。
# 上線後：版本分析思路
（4）數據指標上報監測及數據提取、可視化操作
學會使用公司提供的數據平臺產品及工具，幫助業務或數據負責人更快速高效的獲取數據。在我們進行版本迭代的過程中，數據指標體系的日益完善會幫助我們更好的開展數據分析。
數據後臺支持產品新增活躍留存、自定義事件等數據指標的快速提取，也可以自主配置。同時，平臺上直觀、友好的項目數據可視化設計也能提升我們的分析效率，更快驅動業務發展。
（5）數據跟蹤與分析解讀、抽象業務痛點
數據分析的最終價值體現在能夠通過數據發現問題，抽象出業務痛點和需求。並不是項目中的每個人都能給出專業全面的分析及結論。數據產品則需要長期跟蹤產品核心數據指標以及產品迭代功能數據指標，產出版本迭代數據報告、以及其他階段性的數據報告。
版本分析報告的主要思路是：
基礎指標上線前後變化趨勢（大盤新增活躍留存波動）
功能指標上線前後變化趨勢
版本主要更新點數據
主要數據結論及優化建議
寫在最後
數據統計埋點工作的基礎還是在於對業務的深度理解。我們要做的不僅是完成一個數據指標的上報，更重要的是通過不同緯度的數據指標，更加全面具體的去分析業務情況。
CIO之家 www.ciozj.com 微信公眾號:imciow
閱讀更多 CIO之家 的文章
