起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識數據產品經理基礎技能：數據需求說明文檔怎么寫？
編輯導語：數據產品經理的本質是互聯網產品經理的一個細分領域，在產品的建立過程中，很多時候都需要各種數據作為支撐，以及對數據進行分析得出結論；本文作者分享了關于數據產品經理的基礎技能，我們一起來了解一下。
最近身邊有很多小伙伴轉行了數據產品經理，或者是在轉行的路上，大家咨詢較多的問題在于數據需求文檔怎么寫？用戶畫像需求文檔怎么寫？有沒有數據需求文檔（后續簡稱數據prd）的模板？
于是乎，我專門寫了這篇文章，來回答各位的問題。
01 是什么？
1. 數據產品經理是什么？
我們先聊一聊，數據產品經理是什么？數據產品經理與產品經理的區別？我們先來看一個小案例：
前陣聽神策CEO桑總講到神策2015年成立，他早先認為團隊并不需要數據產品經理，研發直接開發的數據能力十分強大，2015-17年間都是由他自己擔任數據產品經理/產品經理，他來掌控產品方向，推進產品迭代。
但在17年，桑總開始意識到神策的數據分析等技術能力已十分強大，但產品用戶體驗不佳，很多功能都是一些堆砌，缺乏產品的層次感。這時，他的態度開始轉變，他意識到僅靠自己和開發團隊來做難以給客戶帶來更好的產品體驗，需要招專業的、懂數據、懂產品的產品經理，來推進神策分析產品的進一步發展。
而這里的產品經理則是細分方向下的數據產品經理。
從上述案例可以看出什么呢？
一是數據產品經理，其實就是產品經理的角色，他承擔著產品規劃、產品設計、整體項目進度推進、產品運營推廣等責任。而要做好一款數據分析產品，數據產品經理需要具備產品的基礎能力，如溝通、協作等能力、prd撰寫、原型繪制等等能力。
二是數據產品經理跟產品經理又稍有不同，數據產品經理需要懂數據分析，懂一些數據庫語言，即sql語言，至少能把數據需求描述清楚。
數據產品經理=產品經理+數據分析，其能力要求80%產品經理，20%數據分析。
搞清楚數據產品經理是什么后，那我們來看看數據產品需求說明文檔是什么？數據產品需求說明文檔跟產品需求說明文檔的區別？
2. 數據產品需求說明文檔是什么？
數據產品需求說明文檔，是數據產品項目由概念化階段進入到圖紙化階段的最主要的一個文檔。這是對產品需求描述的描述，其內容包含需求背景、價值、產品架構、核心業務流程、功能需求說明、數據需求說明等。
總的來看數據產品需求說明文檔與產品需求說明文檔大體相同，而其差異點主要在于數據需求說明模塊。
數據產品需求說明文檔=產品需求說明文檔+數據需求說明文檔。
文檔面向的用戶群，決定了文檔應該寫哪些內容，寫的怎么樣。數據需求說明文檔使用對象主要為：數據分析師、數倉開發、算法、前后端、數據&功能測試、項目經理、交互設計師、運營等其他業務人員。
從這里的用戶群可以看出，與業務prd不同點在于，新增了數據分析師；數據prd的開發人員除了前后端開發外，還有數倉開發及算法；測試人員新增了數據測試，當然一般來說數據測試和功能測試都是一個人。
用戶對象有了新增，則文檔的內容勢必發生相應的變化，新增了一大模塊——數據需求的說明。
02 為什么需要數據prd？
prd撰寫是產品經理的基礎能力，而數據prd撰寫是數據產品經理的必備技能;數據prd是數據產品與研發、測試、設計等溝通的橋梁，要是需求描述不清楚，研發難以開發；prd出得不夠細致或全面，研發則容易漏需求，導致延期。
03 如何輸出一份高質量的數據prd？
數據prd在基礎規范上需達到以下2個要點：
1）全面：描述清楚why-what。在what層面要盡可能地細致，縱向考慮流程鏈路、橫向考慮各個細節功能點以及異常情況，還原用戶操作界面
2）可讀性強：書寫風格和內容清晰。書寫風格上有條理，讀者能按導航快速找到相應模塊，運用清晰的編號，分小模塊介紹；書寫內容上有邏輯，運用專業的書面語言，看圖說話，復雜問題最好通過舉例子方式說明
1. 數據prd包含哪些模塊？
一份數據prd的組成如下：
第一模塊：需求概述，講清楚需求背景及價值，解決為什么做這個需求的問題。
第二模塊：項目總覽，明確項目邊界及項目預期上線時間，避免后續砍需求或是加需求。
第三模塊：產品總覽，展示產品結構和全局說明，讓讀者較為清晰的從整體上接收此需求。
第四模塊：功能需求說明，介紹每個功能的使用場景/用戶故事，前置和后置條件，正常和異常處理。
第五模塊：數據需求說明，介紹本期的數據需求對應的邏輯，取數的表等。
第六模塊：運營計劃，列出后續的一些運營推廣計劃、相關人及時間點。
附錄：歷次溝通意見匯總，規范記錄每次需求變更及變更人，在一定程度上可以減少變更。
除第五模塊外，其他各模塊均為業務prd的基礎組成，產品經理同學對這些基本是輕車熟路，市面上相應的資料比較多，在這我就不展開介紹。草帽小子接下來主要聊聊數據需求怎么寫。
2. 數據需求分類
而要聊如何寫數據需求，就不得不從數據產品經理的工作內容聊起。數據產品經理工作內容上從下層數據采集到上層數據應用，可分為數據埋點方向、BI分析方向、用戶畫像方向。
對應的需求文檔分別為：
- 埋點數據需求文檔，偏向于埋點事件的描述說明。
- 指標數據需求文檔，偏向于對指標、維度、取數邏輯的說明。
- 標簽數據需求文檔，偏向于對標簽業務含義、取數邏輯的說明。
04 標簽數據說明文檔怎么寫？
索隆是負責用戶畫像平臺方向上的數據產品經理，其工作內容主要為標簽體系的搭建，用戶畫像平臺建設。
1. 標簽數據說明文檔總覽
標簽數據說明文檔包含：
1）標簽主題：標簽主題通常按對象劃分，例如電商中的對象有消費者、商家、商品等對象，不同主題對象下劃分的標簽類別不一；
2）標簽類別：標簽所屬的分類，如基礎信息；
3）標簽名稱：標簽中文名，如性別；
4）標簽值：標簽的枚舉值，如男、女。
5）數據類型：標簽可分為文本型標簽、數值型標簽。文本型標簽通常為文本類型的枚舉值，可用string表示；數值型標簽通常為數字類型，可用int表示，此項通常由開發人員填寫。
6）標簽含義：標簽的業務含義，這通常是業務人員比較關注的一欄。
7）標簽使用場景：標簽在什么場景下用，需業務人員在提出標簽需求時填寫清楚，沒有應用場景的標簽開發出來浪費人力物力，最終也是沒人用。
8）標簽計算邏輯：通常由數倉開發或是算法工程師填寫，從技術的角度說明清楚該標簽是如何一步步得出的。
9）依賴數據表和字段：針對事實或規則類標簽，產品經理可列出標簽所需的上游數據表及字段，方便開發人員寫邏輯。這就需要產品經理較為熟悉底層的數據表及業務字段，最好是聯合需求方一塊梳理，業務上表的狀態字段很多都難以區分，產品經理隨便寫上去，最終可能不是業務想要的結果。
總體來看，產品層面需要描繪業務語言，把標簽的業務含義、使用價值等說清楚；研發層面列出標簽的計算規則，增強標簽的置信度， 一期可先在線下維護起來，后續可以開發標簽管理系統，將標簽在系統中管起來。
其中業務價值及使用場景決定了是否要做該標簽，以及標簽如何定義。如，商家“累計簽約次數”標簽，其使用場景一在于：對于多次簽約的商家給予一定力度的優惠，提升一定的留存率。
統計“累計簽約次數”標簽是很簡單粗暴的方式，其好處在于營銷人員可靈活圈選“累計簽約次數>1、2、3…”的商家分群，且規則簡單。但其劣勢在于標簽值分段不直觀，容易給營銷人員造成困擾，到底是對“累計簽約次數>1還是2”的商家給予優惠呢？分別給予多少優惠？沒有明確的業務策略，以至于這個標簽開發出來沒人用。
因而產品經理需要進一步思考，基于這個場景，標簽是否還有其他更好的實現方案？
2. 標簽樹狀分級結構
劃分標簽的主題，以及標簽所屬的類別，簡而言之，也可以理解為劃分標簽的一級分類、二級分類。為什么要做這樣的劃分呢？
而索隆率先建設消費者畫像，初期做了十幾個標簽，如性別、年齡、所在城市、偏好等，最開始沒做分類。接下來索隆又豐富了消費行為類、偏好類標簽，做了上百個標簽。
為了讓營銷人員更快的找到對應的標簽，索隆將消費者標簽劃分了幾大分類，整個消費者體系的畫像雛形基本建設完成，營銷人員則可靈活的對這類群體進行精細化運營。
從營銷側來看，標簽樹狀分級的緣由在于幫助營銷人員，快速從成百上千個標簽中找到自己所需標簽；從管理側來看，標簽分級結構可拓展性強，方便管理標簽。
這時面向商家對營銷人員開始眼饞了，看著面向消費者側有如此個性化的服務，商家側也需要建設一份商家畫像，因而，索隆也開始著手搭建商家畫像體系。當然商家營銷關注的業務與消費者側并不一致，因而所建立的標簽體系也會有所不同，如建設商機行為、簽約行為等標簽。
從索隆建設標簽樹狀分級結構過程，可以看出：從營銷側來看，標簽樹狀分級的緣由在于幫助營銷人員，快速從成百上千個標簽中找到自己所需標簽；從管理側來看，標簽分級結構可拓展性強，方便管理標簽。
了解了做標簽分級的原因，建設初期要注意的是層級不必生搬硬套，劃分過細，需根據標簽建設實際情況來。如公司只有幾十個標簽，則劃分至二級足矣，過細反而累贅。
3. 標簽名稱和標簽值
用戶標簽，即對用戶某個維度屬性的描述。其標簽值具有高度概括、相互獨立以及可枚舉窮盡的特點。標簽由【標簽名稱】+【標簽值】組成，如性別：“男、女”。
例如，在職場視角，你被貼上如責任心強、積極上進、技術型產品等標簽；在整個社會視角，你被貼上如白領、高收入人群、IT互聯網、宅女等標簽。這里的“高收入人群”即是文檔中標簽值的概念。
按標簽值類型的不同，可將標簽分為兩種類型：數值型標簽、文本型標簽。
- 數值型標簽：標簽值為數字，跟指標一致，標簽命名通常由【時間】+【用戶行為】+【統計方式】組成，如，近30天購買次數：0、1、2、3…10+。
- 文本型標簽：標簽值為文本，也稱為字符串，標簽命名無特定方式，注重簡約直觀，如，用戶價值：高價值、中價值、低價值。
05 小結
整篇文章草帽小子介紹產品經理與數據產品經理、業務prd與數據prd；相信你可以認識到數據產品經理其實就是產品經理的角色，其承擔著產品規劃、產品設計、整體項目進度推進、產品運營推廣等責任。
因而與數據產品經理相對應數據prd與業務prd整體結構相同，都包含需求概述、項目總覽、產品總覽、功能需求說明、運營計劃等常規模塊，數據prd額外增加數據類需求的詳細說明。
而數據類需求整體來看的要點是，盡可能寫清楚數據的計算規則、來龍去脈。把庫表字段、取值范圍等說明清楚。工作做到細致到位，這樣才能更好的保障數據的質量。想了解更多的朋友，也歡迎加入“數據產品交流群”進行交流。
整體來看，產品基本功打好了，寫數據prd并不難。建議從業務產品轉數據產品的朋友，可學一些簡單的SQL，這樣基礎的數據可以取來分析；建議數據開發/數據分析師轉數據產品的朋友，可以學習產品方法論，不忘業務導向。
#專欄作家#
草帽小子，公眾號：一個數據人的自留地，人人都是產品經理專欄作家?！洞髷祿嵺`之路：數據中臺+數據分析+產品應用》書籍作者，專注用戶畫像領域。
本文原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
有個問題？prd里告訴開發取數據的表是哪個？這個有必要嗎？開發應該比產品更了解數據表或者數據存放在哪個表里吧？
我這邊一般表述清楚需求和畫好原型圖就行了，后端數據庫表那些我不管的。也有的公司的PM直接拿著數據庫的表和研發吵，加個接口又不難啥的巴拉巴拉
數據分析轉數據產品有什么建議嗎
指標的可以介紹下不