本文由作者?董小礦?于社區發布

數據產品經理的工作內容有哪些？下文是根據自己在一家內容服務公司的相關工作經歷，總結出的有關數據產品經理的工作思路、工作內容。之前一篇文章介紹了我司數據體系搭建過程，見：埋點、數倉到中臺：數據體系的從0到1

為了區分數據產品和數據產品經理，下文會用數據產品和數據PM來區分。

本文較長，目錄如下：

數據PM的工作內容：

1. 產生數據：

1.1 埋點指標定義-事件表

1.2?埋點指標定義-用戶表

1.3?埋點指標定義-默認屬性

1.4 埋點數據準確上報監控

?2. 獲取數據：

2.1 提需求取數

2.2 SQL查詢自助取數

2.3 可視化平臺取數和分析

2.4 自助報表取數

3. 數據產品：

?? ?? ? 3.1 基礎：數據倉庫

?? ?? ? 3.2?自助報表取數

?? ?? ? 3.3?自建可視化數據平臺

?? ?? ? 3.4 數倉Pro版：數據中臺

4. 推廣數據能力

4.1?指標地圖

4.2?培訓（工具+分析思路）

---

先做說明：工作內容分了前后五部分，有一定的、但并不絕對的順序關系，比如埋點設計和數據治理，是一個伴隨始終的工作，而數倉、數據產品建設，則屬于比較靠后順序的工作內容了。

1

產生數據

1.1?埋點指標定義-事件表

一款互聯網產品每天產生的數據是龐大雜亂的，全部都存下來會占據硬盤空間，而且，不加定義和標記的數據也很難使用。因此，在初期的數據建設階段，先要做的是定義想要的數據，告訴前端開發和后臺的同事，你想要的數據有哪些，定義這些數據的字段包括但不限于以下字段：

圖1：埋點指標定義

上圖是我目前管理我司平臺埋點的字段，分別解釋下：

埋點位置：我司平臺覆蓋了APP、Web和小程序平臺，其中有部分核心功能、頁面在三個平臺都有涉及（類似于電商平臺的商品詳情頁），分開管理會造成指標冗余，因此對于多平臺存在的核心指標，采用的是統一事件名定義，不同平臺觸發時，數據上報到同一個事件名上，通過平臺類型（platform_type）進行拆分；

功能模塊：對應埋點所屬的大功能板塊，如【電子書】功能模塊，會盡可能把屬于電子書的埋點事件放到該模塊進行管理。這里解釋下沒有向下拆解子功能模塊的原因：對于我司業務，區分度比較高，功能模塊+具體事件名就能夠快速定位到想要的指標了。這點因公司而異；

埋點事件：這個文檔我是同時要給開發和運營的同事看的（分開維護的成本太高），對于運營同事來說，他們要關注的字段是下面這些：

圖2：運營同事關注的字段

而開發同事關注的是下面這些字段：

圖3：開發同事關注的字段

因此針對同一個埋點，至少要考慮的是以上這些字段。（更大平臺的埋點字段會更多，歡迎交流）

其中，比較難處理的是【觸發時機】的準確定義和描述，舉個例子，某頁面的pv數據，觸發時機定義成加載和加載成功，會是完全不同的數據；又比如，首頁模塊（也有叫樓層）瀏覽，模塊長短不一，到何種深度會觸發對應模塊的瀏覽，需要定義時想清楚，與開發溝通實現細節，避免后期踩坑；

事件變量定義：用來定義事件的參數，也可以理解為事件維度（也有一些實踐是把事件表和維度表分別進行管理，我司實踐是把二表合二為一）。該字段決定了事件的顆粒度，直接影響到事件下鉆的顆粒度，對于數據PM來說，平臺不同位置的事件抽象后，盡可能提取出公用事件，然后通過事件變量進行區分，能減少：指標冗余、指標管理工作、培訓成本，以及使用者的學習成本。當然這里也并不完全執著于抽象公用性，對于數據PM和開發來說，指標約精簡越好，便于理解和管理，但可能對于運營同事來說，學習和使用成本高企，數據產生了但無法最大化應用側價值，那就得不償失，所以需要平衡。

舉一例，電商產品，商品詳情頁的事件變量怎么設計，見下圖：

圖4：商品詳情頁事件變量

這里你可能會有疑問，如果是傳一個【商品id】，其實也就可以通過【商品信息表】，把【商品名稱】、【品牌】、【一二級類目】給查出來了，為什么還需要傳？這里就涉及到指標管理與數據使用便捷性的權衡：如果不傳，在使用的時候免不了要跨表聯查，是比較影響使用效率的。在指標管理時常需要通過用空間換時間的方式，來保證數據能比較高效使用，最大化數據的價值。

其他說明：變量值類型，比較常見的有：int、float、boole、string、timestamp；埋點形式，對于自己研發的數據采集系統，一般前端埋點和服務端埋點可以了，如果外采第三方數據采集服務，可能還會有全埋點（詳細見上篇文章）；埋點版本和日志，則是幫助你和開發快速回憶這個點的前世今生。如果這篇文章你只記住一句話，我希望是：好好記錄指標備注及變更日志。這個工作能讓你后面少踩太多坑了。

以上，綜合下來，以電商商詳頁舉例，一個埋點事件最后的字段如下：

圖5：舉例-商品詳情頁事件指標設計

1.2 埋點指標定義-用戶表

用戶表，顧名思義是記錄用戶信息、用戶屬性的表，通過用戶的唯一標識（user_id）能夠將事件表和用戶表兩張表進行關聯。事件與用戶實現關聯，事件表里一條條的數據記錄，就不會再是孤立的統計數字，而是能夠與具體的用戶產生關聯進行分析，或者用行為來圈定用戶，給用戶設定分群和標簽。

圖6：事件表和用戶表的關聯

用戶表的自定義維度設計與業務關聯度最高，除了常規的用戶id、用戶昵稱、注冊時間、首次登陸APP時間等字段外，其他偏業務屬性字段需要一個比較全局的視角，不僅要與數據運營方溝通，而是要與公司每一個有分析訴求的部門進行溝通，采集他們的數據分析訴求，來提煉抽象出比較通用的用戶表。

如上面提到的，如果只是從事件表里把上報的數據聚合成統計數字或者圖標，是沒有很大意義的，還要能夠下鉆進行分析。事件表中變量字段的設計是為了從事件反映的用戶行為側進行下鉆，而用戶表的屬性字段則是基于從產生行為的用戶本身進行下鉆。

舉簡單一例：當日商品詳情頁的總瀏覽數據是上升的，但是總GMV確沒有明顯提高，從事件側分析，發現某類異業合作主推的單品商詳頁瀏覽數據上升，其他品類商詳頁沒有明確上升；從用戶側分析，該類單品新增流量主要來自于渠道A。從此得出的初步判斷是：1）單本對渠道A的用戶拉新效果明顯；2）但是該類用戶被吸引來了，卻沒有下單，很奇怪，需要確認投放落地頁與站內商品信息是否一致，尤其是價格；3）該類用戶對平臺其他商品的興趣不高。

說回用戶表的屬性字段設計，回到那句核心：采集共性訴求，提煉出通用、容易理解的用戶表。這個工作其實并不難，考驗的是數據PM溝通、提煉真實訴求，并整合成具體的需求的能力。以我司做內容服務的平臺舉例，用戶屬性表如下，基本覆蓋了通用的用戶群的分析：

圖7：用戶表維度舉例

1.3 埋點指標定義-默認屬性

除了前面提到的自定義事件和用戶屬性外，一般客戶端或者第三方數據采集SDK還會采集一些默認的屬性信息，這些可能不需要你單獨去定義，但數據PM需要去了解平臺獲取的默認字段有哪些。

圖8：默認采集字段（部分）

1.4 埋點數據上報監控

埋點的測試和異常檢測不同于前后端可見的功能，測試的時候很難完全模擬到實時的操作場景，出問題的時候大多是用的時候撈數據發現不對勁，然后進行 排查，嚴重點的，是發出去的數據報表，被大佬看到后來反問質疑。這樣的情況反復出現幾回，會對整個數據團隊十分不利，后期別團隊再拿數據分析的時候，發現分析出的結論跟預想的不太一致，首先不是檢討產品或運營層面的問題，會先來質疑數據，讓數據組來排查數據……

不了解數據流轉機制的，會默認前臺頁面產生的數據，都應該能夠被統計到，而數據從觸發-上報成功-解析入庫-統計更新這條鏈路上大量工作要做，而且有一些統計類數據的產生很依賴上游任務的效率和質量，導致數據監控是塊難啃的骨頭，其工作成果：要么能保證數據不出錯；要么能及時發現并糾正錯誤，不要讓錯誤數據進入到分析環節。前者實現難度高，數據血緣關系復雜，很難完全從源頭把控清楚，我司目前也是出于后者的監控水平，即及時發現問題處理，盡量不讓錯誤數據流出。

數據監控的工作成果很重要，但是工作過程往往不可見，存在感低，往往給與的重視程度不夠高。我司實踐并不夠完善，大數據組目前是通過異常任務報警來接收異常，每天有一個值班同事跟進處理的方式來“勉強度日”。

2

獲取數據

2.1 提需求取數

如果是初期的數據團隊，還沒有專門的數據分析部門的話，大概率數據PM會接各部門的數據需求。而在數據產品建設不夠完善時，只能由數據PM和大數據的小伙伴來處理各類大小不一的數據需求了。

提需求取數，大概是最簡單，也是效率最低的方式了。只要需求夠明確，梳理好后按優先級發給大數據組，按排期來做就是了。但問題也出在梳理需求上，有些數據需求方的數據敏感度不夠高，會出現先提了需求，拿到數據之后發現不是自己真正想要的數據，然后又提了一個追加需求，周而復始無窮盡也……作為數據PM，為了提高自己的工作效率，也為了讓大數據組的兄弟們不要整天忙于各種ETL，有必要明確數據需求的規范，要求需求部門想清楚自己的分析訴求，自己想要的數據是否具備證明或者推翻前期猜想的邏輯？

我給各部門數據對接人提需求時的要求：

圖9：提交數據需求的說明ppt截圖

其中，【期望時間】是大多數人都不太在意、卻是我認為最影響需求處理節奏的內容。提的時候不明確要的時間，只說了句【當然越快越好啦】，然后按正常排期處理后。需求方到了自己緊急要數據的節點了，或哭天喊地，或強硬要求，讓數據組同事臨時來處理。這種情況很影響已經規劃了的工作。

2.2 SQL查詢自助取數

按照接需求-處理需求的流程走一段時間后，會發現簡單的、重復性（可能只是改了時間段，或者提取對象從A改成B）的需求占據了多數以上，不用走數據組，只要能連數據庫，簡單改改參數，自助取數也是能夠實現的。初期我試過自己通過DBeaver這樣的工具連接數據庫取數，不光處理一些數據需求，我自己也能夠通過自助取數對我司數據庫的情況有了更深的了解。

SQL語言并不復雜，算是數據PM的通用技能之一。在寫完一長串SQL代碼，點擊Run的那一刻，還會有一些心流的期待。我在跟數據組同事溝通后確認，將幾個已經同步好了的離線表的查詢權限開放給運營同事，交給他們一些簡單卻很常用的數據提取語句，是能夠實現自助獲取，釋放一部分數據組的生產力。這中間除了基礎的SQL語言能力之外，更重要的是了解數據庫哪些表、哪些字段可用，把數據字段distinct出來后，能夠理解每一個值所代表的意思，因此，數據PM在這里的工作主要是兩部分：

具備基本的SQL能力；

與數據組同事建設并維護數據庫字典表。

2.3 可視化平臺取數和分析

通過SQL能夠解決獲得數據的問題，但是數據清洗、建立分析模型的工作還是要手動做，而且在沒有很好工具的前提下，清洗、建模的工作學習成本不低，而且會花費大量的時間，無法徹底實現讓數據使用者直接使用數據獲得結論的程度。

可視化的數據分析平臺是目前比較常見的解決方案，我本人沒有搭建數據可視化平臺經驗，而且我自己也不建議C輪之前的公司自己搞，建議外采接入，實現成本和學習成本都是低的。而且在與這類專業的數據服務商對接的過程中，學習到很多數據架構、分析思路層面的東西。

對接此類平臺，數據PM往往是第一批接觸平臺的用戶，從POC（Proof of Concept）開始，了解數據平臺如何打通設備和不同平臺的用戶信息、上報數據的機制、常規分析模型的用法等。數據PM要保證自己是公司里對數據指標（埋點設計）和工具最熟悉的人，這樣后面才能夠給其他小伙伴培訓工具的使用。

可視化平臺（自建/第三方）的優勢在于：

1、使用者只需要關注使用層的數據，通過數據指標字典（后面會講到）能夠快速找到自己想要的數據；

2、有現成的分析模型可用，如事件分析、漏斗分析、留存分析等，且可以保存成概覽，下次直接更新日期后查看即可；

3、可以在加上若干條件后，直接獲取源數據（相比于SQL取數，又更簡單了）。

這里再次提到文檔的建設，數據PM可能會對接多部門多個人，如果自己不想陷入到各種溝通的汪洋大海，建議從最開始碰到需要自己解答的問題的時候，就記錄下來，到一定量級后就整理一番，將那些共性的問題做成通用的內部QA手冊，然后不斷完善這個手冊。

2.4 報表：定時報表&自助報表取數

如果前三步都做到了，基本上能滿足公司90%以上的數據需求了。除此外，有一些按周期更新，面向直接使用（如領導層、投資人看的報表），的場景，需要通過報表來實現。定時報表能解決周期取數的重復性工作，相比人工取數更穩定高效，可以用更復雜的取數邏輯，直接從數據庫中獲取數據，同時也存在著不夠靈活，不容易發現問題的缺點。

我司也只建設到定時報表階段，自助報表取數是在之前聽到一位中原銀行的數據總監分享的實踐。其核心是：在數據倉庫中離線處理好面向主題的各張表，表與表之間降低耦合度，同時表與表之間通過主鍵進行關聯，以實現個性化的拼表和并表。這塊內容我不熟悉，不展開。

3

數據產品

3.1 基礎：數據倉庫

從獲取到數據到產出應用層的數據產品，我認為數據倉庫是關鍵。穩健的數倉是一個發力穩定的炮火（數據）輸出，它像是整個數據產品化的中臺：隔絕源數據和數據產品，通過ETL整理好源數據、將按主題處理好的數據表提供給各數據產品應用。

圖10：數據倉庫是數據產品的“中臺”

穩健的數倉的效用在于：

1、整合企業內各端、各業務線的數據，統一管理，實現數據打通，避免重復造輪子；

2、為數據產品做基礎，即使是實時數據的處理，相比于直接讀數據庫，從數倉消費數據更穩定、安全；

3、（一定程度上）解決業務同事對數據處理的依賴，所需數據直接從數倉獲取，釋放生產力。

數倉建設的難點在于：一邊在修路（整合數據、規范數倉），一邊也在跑車（新業務不斷產生新的數據，業務端等不及整合）。這大概是所有信息技術公司的問題。對于數倉建設而言，先把業務形態穩定，且應用頻次最高的幾張表先在數倉中整理好，比如訂單表、注冊表和最基礎常用的用戶數據，如內容平臺對用戶閱讀行為的記錄表等。數倉建設先把低垂的果實采入囊中，提高運營同事、業務開發的工作效率，逐漸提高對數倉團隊的信任，后面再推別的需求會更容易些。

3.2?自助報表取數工具

數倉建設到一定程度，基于基礎數據表和元表（對數據倉庫各表內容進行解釋的表），可以滿足自助取數的需求了。在上面有提到通過DBeaver、SSMS這類數據庫工具，直接連接數倉取數，需要取數同事具體基本的SQL能力，另一種是將數倉的表進一步主題化、解耦化后，讓使用人員通過一個前臺頁面，直接將所需要的的多張表通過主鍵關聯好后，下載到本地的是一張拼接好、計算好的報表。

3.3?自建可視化數據平臺

上一步仍然解決不了的問題是，表格數據的分析建模及可視化，分析的同事仍然需要自己處理數據，使用數據透視表等功能進行分析，效率不高。一個可視化的數據平臺能夠實現從獲取數據-分析數據-展示分析成果的閉環。據我了解到的較大體量的公司，到后期還是會選擇自建可視化平臺。

以某家第三方數據平臺的產品界面為例，作為SaaS平臺，提供給客戶的功能是相對固定的，客戶可以在指標層面上有創新，但是分析框架還是有所限制的（對于大多數客戶來說，這些通用分析框架已經足夠使用了）。如果業務復雜度高、體量大，且最關鍵的，有具體的需求和資源支持來做可視化平臺，最后都會走向自己建設的道路，可能會采購這類第三方平臺的SDK做數據采集工具。

自建平臺是大工程，除了開發資源，另一個就是評估有哪些業務指標和分析場景，即使是私有化部署的第三方數據平臺也無法滿足的。在最后評估ROI之后決定是否自建。對于大公司來說，很可能只是不想接第三方平臺而已，就選擇自己做了。（我司還沒有做過自建平臺，最早曾通過Superset這樣的開源平臺，做過簡版的儀表盤和自助查詢功能，后因組件支持度不夠，在接入某數據平臺后，逐步把指標遷移了過去）

圖11：某第三方數據平臺的首頁界面

3.4 數倉Pro版：數據中臺

從圖10也看到了，數據倉庫已經具有“中臺”層面的服務理念了：處于中間，隔絕上下的直接流動，但自身提供服務上下的能力。而數據中臺在我看來，是數據倉庫的Pro版：接入對象更完整、數據單元更主題、服務對象更多元，最終產生了話語權更重要的結果。

數據中臺的建設難點在于：如何處于與各業務線的關系？如果數據中臺無法解決業務側的問題，反而需要業務組同事參與接口開發；或者數據中臺建設速度趕不上業務的迭代速度；又或者數據中臺服務能力不穩定，常出bug等，是很難從容推進中臺項目的。中臺系統的建設一定需要得到公司高層認可和支持的，這樣去談業務整合才有討論的基礎，其次是在建設早期，先選擇那些具有杠桿性質的業務先做，所謂的杠桿業務，ta可能不是主流業務，但自身苦于沒有足夠資源做系統化，所以先去找這類業務，合作度會比較高，而且一旦整合成功了，能夠比較明顯提高其工作效率。以此成功案例作為杠桿，既是給中臺團隊以信心，也是作為敲門磚去整合其他業務。

4

推廣數據能力

以上，是從如何產生數據、如何管理數據層面的工作內容。再豐富的指標、再好用的工具，運營同事用不起來也是沒有價值的。數據PM除了定義數據和管理數據外，另一塊重要的工作是在公司內部推廣數據能力，真正讓數據為同事所用。從兩個方向來解決這個問題：讓同事知道有哪些數據指標并且快速找到；讓同事們能夠使用。

4.1?指標地圖和數倉表地圖

數據能力推廣的第一個難點，是讓平臺上有哪些數據讓大家知道。一個是在各平臺埋設的指標，我司采用excel的方式進行管理，問題是指標一多起來，找起來不太方便，對于定義者（我）來說自然很容易找到，但是對于使用者來說則不太友好。即使搜中文名稱，也會存在同一個地方，大家用不同的關鍵詞去搜索，比如：模塊、版塊、板塊。

因此在數據指標表的第一個sheet，設計了一個數據指標地圖，將不同功能模塊的數據指標進行了拆解和說明，運營同事找數據指標之前，先打開指標地圖大概定位，然后再去對應的sheet表中尋找對應指標的細節定義和可下鉆的維度信息。

圖12?數據指標地圖

另一塊就是數據倉庫的各種表的定義。從數倉里自助取數時，會有以下的問題：有哪些表、表格對應的是哪塊業務的數據、有哪些字段，字段的含義是什么？這個需要和大數據組一起來明確具體內容了，這個工作并不復雜，就是需要開個小會進行確認，并且約定好，新增表格時，及時更新對表格的解釋。

4.2?培訓（工具使用+分析思路）

在了解了平臺有哪些指標和數據后，下一步就是對工具使用的培訓，和分析思路的培訓了。

我司實踐是：數據PM偏向負責數據工具使用的培訓，數據分析團隊偏向負責分析思路培訓。另外，公司要求每個部門選出一個數據對接人，主要由ta來對接部門內的數據需求收集，簡單數據分析需求要能夠自行結局。因此要求ta需要比較深度了解指標和工具使用。這種方式的好處是，讓真正接觸業務的人，通過數據解決問題，或者提出值得用數據判斷的分析訴求。同時，也讓數據PM和分析團隊的精力不致過于分散，把優先培訓的對象放在對數據有興趣、有責任的數據對接人身上，而不是公司全員上。（人人都是分析師？推廣成本太高了）

我司前后接入過兩家數據服務平臺，會發現其工具的分析核心是相似的，其提供的分析模型也較為常用，基本上這幾個分析模型能用起來已經能解決大多數的分析問題了。

圖13 兩家數據平臺分析模型

如果沒有接入分析平臺，也沒有自建，也沒關系。對基礎數據進行清洗后，使用PowerBI、或者最基礎的Excel也是能夠分析的，并且如果分析思路成為套路，可以把模型保存，下次更新數據就行了。工具可以指導分析思路、提高分析效率，但不是分析的瓶頸。

5

總結

數據PM工作的核心是讓數據為公司業務產生價值。

涉及到的工作內容包括：生產數據-管理數據-數據產品-推廣使用，過程中需要與大數據團隊、數據分析團隊進行比較密切的合作。如果貴司處于正在從業務思維往數據思維轉型，或者處于數據基礎能力建設階段，數據PM的大部分工作還是跟底層數據指標打交道，每天打開最多的工具軟件是excel。

在不斷完善數據豐富度、準確度、使用度的過程中，希望你也能發現數據之美。

Life's short, I love excel.

------正文分割線------

點個“在看”吧

總結

以上是生活随笔為你收集整理的多表拆解 | 数据PM的工作内容的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。