本文由作者?董小礦?于社區(qū)發(fā)布

數(shù)據(jù)產(chǎn)品經(jīng)理的工作內(nèi)容有哪些？下文是根據(jù)自己在一家內(nèi)容服務(wù)公司的相關(guān)工作經(jīng)歷，總結(jié)出的有關(guān)數(shù)據(jù)產(chǎn)品經(jīng)理的工作思路、工作內(nèi)容。之前一篇文章介紹了我司數(shù)據(jù)體系搭建過程，見：埋點(diǎn)、數(shù)倉到中臺：數(shù)據(jù)體系的從0到1

為了區(qū)分?jǐn)?shù)據(jù)產(chǎn)品和數(shù)據(jù)產(chǎn)品經(jīng)理，下文會用數(shù)據(jù)產(chǎn)品和數(shù)據(jù)PM來區(qū)分。

本文較長，目錄如下：

數(shù)據(jù)PM的工作內(nèi)容：

1. 產(chǎn)生數(shù)據(jù)：

1.1 埋點(diǎn)指標(biāo)定義-事件表

1.2?埋點(diǎn)指標(biāo)定義-用戶表

1.3?埋點(diǎn)指標(biāo)定義-默認(rèn)屬性

1.4 埋點(diǎn)數(shù)據(jù)準(zhǔn)確上報監(jiān)控

?2. 獲取數(shù)據(jù)：

2.1 提需求取數(shù)

2.2 SQL查詢自助取數(shù)

2.3 可視化平臺取數(shù)和分析

2.4 自助報表取數(shù)

3. 數(shù)據(jù)產(chǎn)品：

?? ?? ? 3.1 基礎(chǔ)：數(shù)據(jù)倉庫

?? ?? ? 3.2?自助報表取數(shù)

?? ?? ? 3.3?自建可視化數(shù)據(jù)平臺

?? ?? ? 3.4 數(shù)倉Pro版：數(shù)據(jù)中臺

4. 推廣數(shù)據(jù)能力

4.1?指標(biāo)地圖

4.2?培訓(xùn)（工具+分析思路）

---

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

1

產(chǎn)生數(shù)據(jù)

1.1?埋點(diǎn)指標(biāo)定義-事件表

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

圖1：埋點(diǎn)指標(biāo)定義

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

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

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

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

圖2：運(yùn)營同事關(guān)注的字段

而開發(fā)同事關(guān)注的是下面這些字段：

圖3：開發(fā)同事關(guān)注的字段

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

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

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

舉一例，電商產(chǎn)品，商品詳情頁的事件變量怎么設(shè)計，見下圖：

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

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

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

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

圖5：舉例-商品詳情頁事件指標(biāo)設(shè)計

1.2 埋點(diǎn)指標(biāo)定義-用戶表

用戶表，顧名思義是記錄用戶信息、用戶屬性的表，通過用戶的唯一標(biāo)識（user_id）能夠?qū)⑹录砗陀脩舯韮蓮埍磉M(jìn)行關(guān)聯(lián)。事件與用戶實現(xiàn)關(guān)聯(lián)，事件表里一條條的數(shù)據(jù)記錄，就不會再是孤立的統(tǒng)計數(shù)字，而是能夠與具體的用戶產(chǎn)生關(guān)聯(lián)進(jìn)行分析，或者用行為來圈定用戶，給用戶設(shè)定分群和標(biāo)簽。

圖6：事件表和用戶表的關(guān)聯(lián)

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

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

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

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

圖7：用戶表維度舉例

1.3 埋點(diǎn)指標(biāo)定義-默認(rèn)屬性

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

圖8：默認(rèn)采集字段（部分）

1.4 埋點(diǎn)數(shù)據(jù)上報監(jiān)控

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

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

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

2

獲取數(shù)據(jù)

2.1 提需求取數(shù)

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

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

我給各部門數(shù)據(jù)對接人提需求時的要求：

圖9：提交數(shù)據(jù)需求的說明ppt截圖

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

2.2 SQL查詢自助取數(shù)

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

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

具備基本的SQL能力；

與數(shù)據(jù)組同事建設(shè)并維護(hù)數(shù)據(jù)庫字典表。

2.3 可視化平臺取數(shù)和分析

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

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

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

可視化平臺（自建/第三方）的優(yōu)勢在于：

1、使用者只需要關(guān)注使用層的數(shù)據(jù)，通過數(shù)據(jù)指標(biāo)字典（后面會講到）能夠快速找到自己想要的數(shù)據(jù)；

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

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

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

2.4 報表：定時報表&自助報表取數(shù)

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

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

3

數(shù)據(jù)產(chǎn)品

3.1 基礎(chǔ)：數(shù)據(jù)倉庫

從獲取到數(shù)據(jù)到產(chǎn)出應(yīng)用層的數(shù)據(jù)產(chǎn)品，我認(rèn)為數(shù)據(jù)倉庫是關(guān)鍵。穩(wěn)健的數(shù)倉是一個發(fā)力穩(wěn)定的炮火（數(shù)據(jù)）輸出，它像是整個數(shù)據(jù)產(chǎn)品化的中臺：隔絕源數(shù)據(jù)和數(shù)據(jù)產(chǎn)品，通過ETL整理好源數(shù)據(jù)、將按主題處理好的數(shù)據(jù)表提供給各數(shù)據(jù)產(chǎn)品應(yīng)用。

圖10：數(shù)據(jù)倉庫是數(shù)據(jù)產(chǎn)品的“中臺”

穩(wěn)健的數(shù)倉的效用在于：

1、整合企業(yè)內(nèi)各端、各業(yè)務(wù)線的數(shù)據(jù)，統(tǒng)一管理，實現(xiàn)數(shù)據(jù)打通，避免重復(fù)造輪子；

2、為數(shù)據(jù)產(chǎn)品做基礎(chǔ)，即使是實時數(shù)據(jù)的處理，相比于直接讀數(shù)據(jù)庫，從數(shù)倉消費(fèi)數(shù)據(jù)更穩(wěn)定、安全；

3、（一定程度上）解決業(yè)務(wù)同事對數(shù)據(jù)處理的依賴，所需數(shù)據(jù)直接從數(shù)倉獲取，釋放生產(chǎn)力。

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

3.2?自助報表取數(shù)工具

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

3.3?自建可視化數(shù)據(jù)平臺

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

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

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

圖11：某第三方數(shù)據(jù)平臺的首頁界面

3.4 數(shù)倉Pro版：數(shù)據(jù)中臺

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

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

4

推廣數(shù)據(jù)能力

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

4.1?指標(biāo)地圖和數(shù)倉表地圖

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

因此在數(shù)據(jù)指標(biāo)表的第一個sheet，設(shè)計了一個數(shù)據(jù)指標(biāo)地圖，將不同功能模塊的數(shù)據(jù)指標(biāo)進(jìn)行了拆解和說明，運(yùn)營同事找數(shù)據(jù)指標(biāo)之前，先打開指標(biāo)地圖大概定位，然后再去對應(yīng)的sheet表中尋找對應(yīng)指標(biāo)的細(xì)節(jié)定義和可下鉆的維度信息。

圖12?數(shù)據(jù)指標(biāo)地圖

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

4.2?培訓(xùn)（工具使用+分析思路）

在了解了平臺有哪些指標(biāo)和數(shù)據(jù)后，下一步就是對工具使用的培訓(xùn)，和分析思路的培訓(xùn)了。

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

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

圖13 兩家數(shù)據(jù)平臺分析模型

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

5

總結(jié)

數(shù)據(jù)PM工作的核心是讓數(shù)據(jù)為公司業(yè)務(wù)產(chǎn)生價值。

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

在不斷完善數(shù)據(jù)豐富度、準(zhǔn)確度、使用度的過程中，希望你也能發(fā)現(xiàn)數(shù)據(jù)之美。

Life's short, I love excel.

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

點(diǎn)個“在看”吧

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。