如何寫一份高質量的數據需求文檔？

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

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

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

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

一、明確需求定義指標

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

實例：

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

指標類別：

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

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

二、事件設計

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

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

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

三、屬性設計

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

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

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

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

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

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

四、完善文檔細節

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

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

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

題圖來自Unsplash，基於CC0協議