編輯導讀：書寫數據需求文檔是在産品工作中經常遇到的一項任務，看似簡單的文檔背後也有值得注意的地方。本文将從四個方面進行分析，希望對你有幫助。

DRD（Data Raquirements Document）顧名思義同PRD一樣，作為同研發團隊溝通的一種憑借。便于管理當前數據埋點的狀态和曆史叠代邏輯的追述。也是建設公司良好數據體系管理的基礎，那麼如何寫一份高質量的DRD文檔呢？

首先，要明确數據需求。隻有從業務本身實際需求出發，才能夠采集滿足業務所需要的真實數據。是想了解整個用戶浏覽頁面内容的情況？還是想了解某個功能整體使用情況？隻有需求清晰明确了，才能夠合理設計埋點采集方案定義埋點指标。

數據是判斷你工作目标是否達成的關鍵依據，是服務于每一次叠代上線後的效果衡量。通常指标定義好之後，圍繞着定義好的一些指标進行事件和屬性設計就可以着手寫DRD文檔了。

下面結合具體實例來說一下寫好一份DRD文檔分幾步。

通過需求拆分出核心的數據指标。定義指标前要了解産品的結構、用戶行為來明确分析的範圍。

實例：

數據需求：通過埋點采集用戶行為，分析用戶使用情況和選擇偏好及流失原因。

指标類别：

• 常用報表指标：新增、日活、啟動、周活、月活及注冊數據、會員數據、使用時長、留存、系統穩定性。這些通常為日常關心的核心數據指标可以做到報表裡供日常觀察的指标。
• 營銷指标：營銷banner曝光、點擊及各個營銷位的點擊排行、展示排行、業務轉化等營銷闆塊的數據指标。
• 用戶價值指标：新用戶的次日留存、7日留存、月留存、成本、用戶的産品生命周期模型。
• 運營指标：會員和活動任務的熱度、業務轉化、會員新增、累計、續費等指标。
• 産品功能指标：導航欄、按鈕點擊、功能入口的點擊和轉化等指标。

通過指标常用的類别确定我們需要分析的數據指标，就可以進行埋點事件設計了。

主要會從兩個方面去進行事件設計一個鎖定是核心要分析的頁面所産生的行為，一個是鎖定核心功能産生的行為。

頁面事件：鎖定要分析的頁面和頁面上的内容以及在這些内容和頁面上産生的點擊、浏覽等行為。

功能事件：鎖定要分析的功能比如：搜索、登錄、注冊、購買、會員付費、簽到、掃一掃等，這些功能的入口、點擊和完成行為。

每個事件都有對應的事件屬性來說明該事件具體分析的維度。屬性可分為通用屬性和具體屬性。通用屬性如：版本、設備、網絡、IP等。具體屬性如：各事件的來源、各頁面加載時長、各内容的位置、各内容的ID等。

埋點時需要進行采集這些事件的參數和屬性用來分析。事件屬性維度的拆解可以依照4W1H（who、when、what、where、how）的方法去進行思考避免遺漏，這裡就不在多說了，多多練習就好了。

通常的頁面時間的屬性參數會涉及到事件的來源位置、頁面曝光時長、頁面上曝光的内容、内容ID、内容類型、有無圖片等。

功能按鈕點擊的事件屬性設計時，一般隻需要監控按鈕點擊數即可，不需要進行其他背後的屬性說明，例如掃一掃、廣告圖片點擊等。也有的時候可以把按鈕所屬的頁面作為一個事件，把各個按鈕名稱作為參數，去設計埋點方案。

事件的采集就是在确定産品範圍内找到用戶的點擊、曝光、完成等系列行為，最後針對各個行為進行屬性和參數的細分說明。這樣一份高質量的數據文檔就完成了一大半。

這裡值得注意的一點就是時刻清晰明确做數據埋點的目的是什麼然後通過場景化思考進行方案設計，這樣有效避免數據遺漏或複雜而無用造成的低效數據埋點方案。這一方法論不僅适用于埋點方案設計時也适用于在其他所有地方和場景中做産品方案設計時，值得大家牢記。

正如本文開頭說的，DRD是作為同技術研發溝通的一種憑借。是為了便于管理當前數據埋點的狀态和曆史叠代邏輯追述。那麼就不可少了對文檔一些細節說的備注，上線時間點，當前埋點時的狀态，便于後續追溯。

所以一份完整的DRD具有的維度有：事件名、英文名、事件說明、事件屬性名、事件屬性英文名、屬性值類型、屬性說明、當前狀态是否在線、埋點的形式是前端采集還是後端采集、及上線的版本記錄及當時狀态的備注說明，這樣一份完整的DRD就完成了！

本文由 @雲杉小主 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議