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

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

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

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

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

一、明確需求定義指標

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

實例：

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

指標類別：

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

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

二、事件設計

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

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

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

三、屬性設計

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

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

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

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

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

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

四、完善文檔細節

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

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

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

題圖來自Unsplash，基于CC0協議