數據產品經理的工作內容有哪些？下文是根據自己在一家內容服務公司的相關工作經歷，總結出的有關數據產品經理的工作思路、工作內容。之前一篇文章介紹了我司數據體系搭建過程，不再重複，見：https://coffee.pmcaff.com/article/gaBwDw5Jkj 。
為了區分數據產品和數據產品經理，下文會用數據產品和數據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 培訓（工具+分析思路）
------正文分割線------
數據PM的工作內容
先做說明：工作內容分了前後五部分，有一定的、但並不絕對的順序關係，比如埋點設計和數據治理，是一個伴隨始終的工作，而數倉、數據產品建設，則屬於比較靠後順序的工作內容了。
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要保證自己是公司裡對數據指標（埋點設計）和工具最熟悉的人，這樣後面才能夠給其他小夥伴培訓工具的使用。
可視化平臺（自建/第三方）的優勢在於：
使用者只需要關注使用層的數據，通過數據指標字典（後面會講到）能夠快速找到自己想要的數據；
有現成的分析模型可用，如事件分析、漏斗分析、留存分析等，且可以保存成概覽，下次直接更新日期後查看即可；
可以在加上若干條件後，直接獲取源數據（相比於SQL取數，又更簡單了）。
這裡再次提到文檔的建設，數據PM可能會對接多部門多個人，如果自己不想陷入到各種溝通的汪洋大海，建議從最開始碰到需要自己解答的問題的時候，就記錄下來，到一定量級後就整理一番，將那些共性的問題做成通用的內部QA手冊，然後不斷完善這個手冊。
2.4 報表：定時報表&自助報表取數
如果前三步都做到了，基本上能滿足公司90%以上的數據需求了。除此外，有一些按週期更新，面向直接使用（如領導層、投資人看的報表），的場景，需要通過報表來實現。定時報表能解決週期取數的重複性工作，相比人工取數更穩定高效，可以用更復雜的取數邏輯，直接從數據庫中獲取數據，同時也存在著不夠靈活，不容易發現問題的缺點。
我司也只建設到定時報表階段，自助報表取數是在之前聽到一位中原銀行的數據總監分享的實踐。其核心是：在數據倉庫中離線處理好面向主題的各張表，表與表之間降低耦合度，同時表與表之間通過主鍵進行關聯，以實現個性化的拼表和並表。這塊內容我不熟悉，不展開。
3.數據產品
3.1 基礎：數據倉庫
從獲取到數據到產出應用層的數據產品，我認為數據倉庫是關鍵。穩健的數倉是一個發力穩定的炮火（數據）輸出，它像是整個數據產品化的中臺：隔絕源數據和數據產品，通過ETL整理好源數據、將按主題處理好的數據表提供給各數據產品應用。
圖10：數據倉庫是數據產品的“中臺”
穩健的數倉的效用在於：
整合企業內各端、各業務線的數據，統一管理，實現數據打通，避免重複造輪子；
為數據產品做基礎，即使是實時數據的處理，相比於直接讀數據庫，從數倉消費數據更穩定、安全；
（一定程度上）解決業務同事對數據處理的依賴，所需數據直接從數倉獲取，釋放生產力。
數倉建設的難點在於：一邊在修路（整合數據、規範數倉），一邊也在跑車（新業務不斷產生新的數據，業務端等不及整合）。這大概是所有信息技術公司的問題。對於數倉建設而言，先把業務形態穩定，且應用頻次最高的幾張表先在數倉中整理好，比如訂單表、註冊表和最基礎常用的用戶數據，如內容平臺對用戶閱讀行為的記錄表等。數倉建設先把低垂的果實採入囊中，提高運營同事、業務開發的工作效率，逐漸提高對數倉團隊的信任，後面再推別的需求會更容易些。
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也是能夠分析的，並且如果分析思路成為套路，可以把模型保存，下次更新數據就行了。工具可以指導分析思路、提高分析效率，但不是分析的瓶頸。
總結下：數據PM工作的核心是讓數據為公司業務產生價值。涉及到的工作內容包括：生產數據-管理數據-數據產品-推廣使用，過程中需要與大數據團隊、數據分析團隊進行比較密切的合作。如果貴司處於正在從業務思維往數據思維轉型，或者處於數據基礎能力建設階段，數據PM的大部分工作還是跟底層數據指標打交道，每天打開最多的工具軟件是excel。在不斷完善數據豐富度、準確度、使用度的過程中，希望你也能發現數據之美。
Life's short, I love excel.
閱讀更多 PMCAFF產品經理社區 的文章
