作為數據産品經理，對統計埋點一定不陌生，每個版本多少都會涉及到部分統計需求。如何做好産品上線前數據指标的統計埋點，以及産品上線後的版本分析報告？本文筆者将會給結合自身工作經驗，給大家總結一些具體思路和方法。

　　明确定位與工作重心

　　數據産品經理是讓數據産生價值（決策、增長、收入）的設計者、實現者和推行者。如何理解這樣的定位呢？

　　首先，最基礎的是要熟悉數據工具平台與産品業務，其次，要學會逐步建立産品完整的數據指标體系，最後，是能夠通過數據分析解讀驅動業務發展。

　　具體拆解來看，主要包含：

　　（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），我們自己可以去整理當前産品功能結構圖、核心業務流程圖或用戶使用路徑圖。

　　如圖為美圖秀秀v6.9.6版本-美化功能用戶使用路徑圖（參考）。通過梳理，主要目的是對産品的功能結構、核心業務流程及信息框架有清晰的認知，幫助我們更好的進行數據相關工作。

　　（2）設計統計事件及數據埋點規範

　　做好了準備工作，接下來最主要的就是進行統計事件的設計和給出數據采集埋點方案。本文暫不讨論接入第三方統計sdk的方式進行埋點的相關内容。統計事件的設計，就是做到針對某個具體頁面，定義當前頁面中用戶的點擊或其他觸發行為并準确上報，從而提取數據進行分析，主要從用戶行為角度出發。

　　比如頁面中出現的某個按鈕，想知道用戶是否點擊該按鈕或點擊的頻次，統計事件就要記錄用戶點擊該按鈕的行為數據（消息數/設備數）。

　　如何通過用戶行為找到統計事件的對應關系？

　　用戶行為：分析用戶行為，找到該行為相關的信息；事件定義：根據相關信息，定義該行為對應的事件及參數。 說明一下，在版本叠代的過程中，新版本的事件無需全部重新埋點。

　　曆史已有的統計事件隻要有涉及到的，可列入測試check事件，版本新增的統計事件列入本期統計項。最終可彙總一份整體的數據統計事件庫，每次隻需在曆史已有的内容裡新增或修改補充當前新版本的統計項，也方便我們進行長期叠代與維護。通過用戶行為找到統計事件的對應關系後，即可整理出我們最重要的統計埋點文檔。

　　統計埋點文檔主要包含：

　　更新說明（文檔更新時間、更新内容記錄）本期統計項（新增/修改的統計事件list）本期check事件（新增/修改的統計事件check 可能影響到的統計事件check）後台全部展示事件（整體的數據統計事件庫） #舉個例子#

　　産品功能：美化圖片主功能中，新增馬賽克

　　用戶行為：用戶在美圖秀秀首頁點擊“美化圖片”按鈕-點擊“馬賽克”功能-選擇素材使用-保存

　　用戶行為與統計事件的對應關系（參考）：

　　統計文檔，本期統計項sheet表（參考）：

　　（3）需求研發測試跟進及校驗數據統計項

　　根據我們輸出的統計文檔，統計文檔中“統計規則”的描述，就要求清晰定義該統計事件采集的節點和上報邏輯，需要及時和開發跟進溝通；而統計文檔中“本期統計check事件”則需要詳細和測試進行核對。通常，公司優秀的開發和測試也可以更好的協助我們，對事件統計的規則做優化調整，提高數據存儲及讀取的效率。

　　# 上線後：版本分析思路

　　（4）數據指标上報監測及數據提取、可視化操作

　　學會使用公司提供的數據平台産品及工具，幫助業務或數據負責人更快速高效的獲取數據。在我們進行版本叠代的過程中，數據指标體系的日益完善會幫助我們更好的開展數據分析。

　　數據後台支持産品新增活躍留存、自定義事件等數據指标的快速提取，也可以自主配置。同時，平台上直觀、友好的項目數據可視化設計也能提升我們的分析效率，更快驅動業務發展。

　　（5）數據跟蹤與分析解讀、抽象業務痛點

　　數據分析的最終價值體現在能夠通過數據發現問題，抽象出業務痛點和需求。并不是項目中的每個人都能給出專業全面的分析及結論。數據産品則需要長期跟蹤産品核心數據指标以及産品叠代功能數據指标，産出版本叠代數據報告、以及其他階段性的數據報告。

　　版本分析報告的主要思路是：

　　基礎指标上線前後變化趨勢（大盤新增活躍留存波動）功能指标上線前後變化趨勢版本主要更新點數據主要數據結論及優化建議

　　寫在最後

　　數據統計埋點工作的基礎還是在于對業務的深度理解。我們要做的不僅是完成一個數據指标的上報，更重要的是通過不同緯度的數據指标，更加全面具體的去分析業務情況。

　　本文闡述的内容僅作為個人工作的總結和沉澱，如有疑問，歡迎與我讨論交流。感謝閱讀~

　　本文由 @Sherily◡̈ 原創發布于人人都是産品經理，未經許可，禁止轉載。

　　題圖來自Unsplash，基于CC0協議。

　　,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!