編輯導(dǎo)讀：書寫數(shù)據(jù)需求文檔是在產(chǎn)品工作中經(jīng)常遇到的一項(xiàng)任務(wù)，看似簡(jiǎn)單的文檔背后也有值得注意的地方。本文將從四個(gè)方面進(jìn)行分析，希望對(duì)你有幫助。

DRD（Data Raquirements Document）顧名思義同PRD一樣，作為同研發(fā)團(tuán)隊(duì)溝通的一種憑借。便于管理當(dāng)前數(shù)據(jù)埋點(diǎn)的狀態(tài)和歷史迭代邏輯的追述。也是建設(shè)公司良好數(shù)據(jù)體系管理的基礎(chǔ)，那么如何寫一份高質(zhì)量的DRD文檔呢？

首先，要明確數(shù)據(jù)需求。只有從業(yè)務(wù)本身實(shí)際需求出發(fā)，才能夠采集滿足業(yè)務(wù)所需要的真實(shí)數(shù)據(jù)。是想了解整個(gè)用戶瀏覽頁(yè)面內(nèi)容的情況？還是想了解某個(gè)功能整體使用情況？只有需求清晰明確了，才能夠合理設(shè)計(jì)埋點(diǎn)采集方案定義埋點(diǎn)指標(biāo)。

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

下面結(jié)合具體實(shí)例來(lái)說(shuō)一下寫好一份DRD文檔分幾步。

一、明確需求定義指標(biāo)

通過(guò)需求拆分出核心的數(shù)據(jù)指標(biāo)。定義指標(biāo)前要了解產(chǎn)品的結(jié)構(gòu)、用戶行為來(lái)明確分析的范圍。

實(shí)例：

數(shù)據(jù)需求：通過(guò)埋點(diǎn)采集用戶行為，分析用戶使用情況和選擇偏好及流失原因。

指標(biāo)類別：

• 常用報(bào)表指標(biāo)：新增、日活、啟動(dòng)、周活、月活及注冊(cè)數(shù)據(jù)、會(huì)員數(shù)據(jù)、使用時(shí)長(zhǎng)、留存、系統(tǒng)穩(wěn)定性。這些通常為日常關(guān)心的核心數(shù)據(jù)指標(biāo)可以做到報(bào)表里供日常觀察的指標(biāo)。
• 營(yíng)銷指標(biāo)：營(yíng)銷banner曝光、點(diǎn)擊及各個(gè)營(yíng)銷位的點(diǎn)擊排行、展示排行、業(yè)務(wù)轉(zhuǎn)化等營(yíng)銷板塊的數(shù)據(jù)指標(biāo)。
• 用戶價(jià)值指標(biāo)：新用戶的次日留存、7日留存、月留存、成本、用戶的產(chǎn)品生命周期模型。
• 運(yùn)營(yíng)指標(biāo)：會(huì)員和活動(dòng)任務(wù)的熱度、業(yè)務(wù)轉(zhuǎn)化、會(huì)員新增、累計(jì)、續(xù)費(fèi)等指標(biāo)。
• 產(chǎn)品功能指標(biāo)：導(dǎo)航欄、按鈕點(diǎn)擊、功能入口的點(diǎn)擊和轉(zhuǎn)化等指標(biāo)。

通過(guò)指標(biāo)常用的類別確定我們需要分析的數(shù)據(jù)指標(biāo)，就可以進(jìn)行埋點(diǎn)事件設(shè)計(jì)了。

二、事件設(shè)計(jì)

主要會(huì)從兩個(gè)方面去進(jìn)行事件設(shè)計(jì)一個(gè)鎖定是核心要分析的頁(yè)面所產(chǎn)生的行為，一個(gè)是鎖定核心功能產(chǎn)生的行為。

頁(yè)面事件：鎖定要分析的頁(yè)面和頁(yè)面上的內(nèi)容以及在這些內(nèi)容和頁(yè)面上產(chǎn)生的點(diǎn)擊、瀏覽等行為。

功能事件：鎖定要分析的功能比如：搜索、登錄、注冊(cè)、購(gòu)買、會(huì)員付費(fèi)、簽到、掃一掃等，這些功能的入口、點(diǎn)擊和完成行為。

三、屬性設(shè)計(jì)

每個(gè)事件都有對(duì)應(yīng)的事件屬性來(lái)說(shuō)明該事件具體分析的維度。屬性可分為通用屬性和具體屬性。通用屬性如：版本、設(shè)備、網(wǎng)絡(luò)、IP等。具體屬性如：各事件的來(lái)源、各頁(yè)面加載時(shí)長(zhǎng)、各內(nèi)容的位置、各內(nèi)容的ID等。

埋點(diǎn)時(shí)需要進(jìn)行采集這些事件的參數(shù)和屬性用來(lái)分析。事件屬性維度的拆解可以依照4W1H（who、when、what、where、how）的方法去進(jìn)行思考避免遺漏，這里就不在多說(shuō)了，多多練習(xí)就好了。

通常的頁(yè)面時(shí)間的屬性參數(shù)會(huì)涉及到事件的來(lái)源位置、頁(yè)面曝光時(shí)長(zhǎng)、頁(yè)面上曝光的內(nèi)容、內(nèi)容ID、內(nèi)容類型、有無(wú)圖片等。

功能按鈕點(diǎn)擊的事件屬性設(shè)計(jì)時(shí)，一般只需要監(jiān)控按鈕點(diǎn)擊數(shù)即可，不需要進(jìn)行其他背后的屬性說(shuō)明，例如掃一掃、廣告圖片點(diǎn)擊等。也有的時(shí)候可以把按鈕所屬的頁(yè)面作為一個(gè)事件，把各個(gè)按鈕名稱作為參數(shù)，去設(shè)計(jì)埋點(diǎn)方案。

事件的采集就是在確定產(chǎn)品范圍內(nèi)找到用戶的點(diǎn)擊、曝光、完成等系列行為，最后針對(duì)各個(gè)行為進(jìn)行屬性和參數(shù)的細(xì)分說(shuō)明。這樣一份高質(zhì)量的數(shù)據(jù)文檔就完成了一大半。

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

四、完善文檔細(xì)節(jié)

正如本文開(kāi)頭說(shuō)的，DRD是作為同技術(shù)研發(fā)溝通的一種憑借。是為了便于管理當(dāng)前數(shù)據(jù)埋點(diǎn)的狀態(tài)和歷史迭代邏輯追述。那么就不可少了對(duì)文檔一些細(xì)節(jié)說(shuō)的備注，上線時(shí)間點(diǎn)，當(dāng)前埋點(diǎn)時(shí)的狀態(tài)，便于后續(xù)追溯。

所以一份完整的DRD具有的維度有：事件名、英文名、事件說(shuō)明、事件屬性名、事件屬性英文名、屬性值類型、屬性說(shuō)明、當(dāng)前狀態(tài)是否在線、埋點(diǎn)的形式是前端采集還是后端采集、及上線的版本記錄及當(dāng)時(shí)狀態(tài)的備注說(shuō)明，這樣一份完整的DRD就完成了！

本文由 @云杉小主 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議