如今，互聯網中的數據倉庫 ， 已不單單是數據開發工程師的責任，隨著業務的發展和細分 ， 對產品經理提出了更高的要求 。
開發工程師往往不能夠第一時間深入理解業務，或者說理解的不夠透徹，完全交給數倉工程師開發的數據倉庫，不但時間過長（需要理解時間成本） ， 而且不能很好的支持業務 。這就需要數據產品經理參與數倉的開發中 。不但要參與數據的建模和邏輯的梳理，還要做好數據的管理和規劃 。
本文不討論數據建模的過程，只聊聊在數據的管理和規劃中 ， 數據產品經理應承擔的工作內容和職責 。
一、數據的源頭-生產端互聯網公司，往往依托用戶的行為，來搭建用戶的相關行為模型進行分析，所以關于用戶行為上報的數據 ， 是最基礎的數據也是最重要的數據 。只有合理、規范的上報 ， 數據才會產生價值 。那么如何做好埋點，并且怎樣管理好埋點呢？
1.如何做好埋點簡單來說：需要的數據進行埋點，以交互為底、業務價值為依據、時間為起點、需求為最終目標進行埋點的設計 。
文章插圖
任何交互的元素都要考慮是否需要進行埋點
業務價值為依據
考慮這個交互是否有實際的業務意義，來判斷是否需要埋點
時間為起點
記錄此處事件的真實發生時間
需求為最終目標
需求就是’誰對什么做了什么‘
2.埋點管理一個埋點對應一個標識，通常一款產品包含數百個埋點，也會隨著業務和產品的變化，埋點需要增刪修改等，所以對埋點管理也是一個重要的步驟 。
埋點管理的內容大致包含如下：
文章插圖
1）埋點、埋點含義、觸發場景埋點文檔中必須寫出埋點上報時機 ， 同時描述準確；
2）參數、參數名稱、參數值類型參數里記錄的是針對埋點行為，所包含的信息，埋點行為不同，對應的信息也不同，所以不能作為公共字段記錄在數據表中 ， 會以json形式，記錄在字段中 ， 分析時需要使用具體的信息，可通過函數解析出來（get_json_object） 。
3）元信息、備注信息備注信息的意義就是解釋說明 ， 例如文檔中只記錄了物品和怪物的id，具體的名稱沒有記錄，是因為日志中存儲漢子易出現亂碼，僅記錄id即可達到分析需求，并且減少數據量 。
4）元編碼、編碼表同時，埋點文檔中 ， 除了第一頁sheet表中展示埋點文檔外，其后幾頁需要寫出含多個枚舉值參數的編碼表，方便數據人員進行分析對照 。
5）業務宣講埋點文檔設計完成后，即可提交至研發同學，進行宣講 。用戶行為分析是基于埋點完成 ， 其重要性不言而喻，所以后期埋點驗收也需要產品經理的參與，確保埋點的準確性 。
3.埋點方案
文章插圖
如圖 ， 目前業內幾種埋點方案類型的比較 。參考不同類型埋點的特點 ， 在具體的功能場景時，根據具體情況選擇對應方案，進行埋點方案的設計 。
二、數據字典所謂數據字典 ， 就是用來描述數據指標的一個公司內部的埋點規范 。它將數據定義、結構、數據類型、數據邏輯、數據源等進行了一個匯總的文檔 。那么它的生產與管理過程是怎樣的呢？
文章插圖
1.字典收集收集環節是需要對數據字典進行一個詳細的定義 。需要知曉在業務分析中，數據的使用方關注哪些數據指標、歸因包含哪些維度 。單純的從業務產品去思考，會存在缺失，通過與產品/運營同學的交流，可以使字典的內容更加完善 。
2.標準建設主要包含兩步，新標準的制定和舊標準的修改 。新標準除了收集業務方的需求和建議外，還要參考一下業內最新的標準，這樣可以滿足業內的特定需要 。
3.標準更新如果舊標準與現有業務存在沖突，那么就需要積極的與舊標準的業務方溝通，進行因地制宜的協同與調整 。
三、業務數據管理業務數據是企業運營各個環節的共用實體，連接企業的各個系統，如果存在業務數據不一致，上有無法對接運營系統，下游無法進行數據分析和整合，各個系統間的數據無法進行關聯，對企業的運營支持就很有限 。
那么如何做好這些業務數據的管理呢？
文章插圖
各個部門主責自己的業務數據，編碼數據與主數據一致
數據定義明確
數據屬性定義、標準、規范等統一維護
維護流程統一
各個部門在申請新的產品時，按照統一申請流程進行填寫或修改 ， 流程由數據產品經理統一負責編寫與更新
數據共享及時
雖然業務數據不常變化，但是如有變化，實時性非常高，主要主動告知下游的變化情況
數據狀態可控
數據的增加、修改、刪除、凍結等 ， 需要數據產品經理對數據的版本進行管理
數據屬性完備
每款產品，每個數據的屬性描述 ， 進行統一的梳理
文章插圖
埋點全鏈路協同流程
寫在最后【DPM在數倉建設中的作用 dpm是什么意思】以上就是數據產品經理在數倉開發過程中，對數倉的工作內容和職責 ， 主要是集中在數據管理這里，這是一項非常繁瑣且重要和有挑戰性的工作 。如果中間的歧義產生較多，那么就會反饋到業務上來，當進行更深層的業務邏輯分析時，會產生更嚴重的問題 。