數據產品經理職責

① 如何面試數據產品經理

實事求是，不要浮誇

② 數據產品經理是做什麼的

近年來，隨著精益經營理念和數據操作的普及，數據產品的名稱越來越多。而數據產品經理的出現也引發人們的關注。

數據產品是什麼

簡單地說，數據是主要自動化輸出的產品形式。

我們就可以對它拆分細化。從用戶群體來區分，可以分為三類：

1.內部使用的數據產品，如自建的BI和推薦系統;

2.所有企業的商用數據產品，如 Google Analytics 和 GrowingIO；

3.用戶均可使用的 Google Trends 和淘寶指數等等。

結語

以上的環節就是數據產品經理區分其他產品經理的核心，也需要很高的要求。它需要豐富的產品設計經驗和深入的業務理解和數據分析。

③ 數據分析師和數據產品經理有什麼區別

CDA——數據分析師主要是在企業中扮演戰略參謀的角色，對企業各類運營、銷售、管理、專戰略等數據進行分析，可屬以有效的規避運營風險和提升成本利用率。
數據產品經理從事數據產品（企業數據平台、數據分析軟體等）的設計

④ 數據產品經理和普通產品經理的要求有什麼不同

你好，數據產品經理和普通產品經理的相同和不同點有這些：
相同點：都是產品經版理，都是一個產品的負責人，權工作職責基本都是一樣的；
不同點：數據產品注重的是數據情況，偏向於數據分析，而普通的產品經理主要負責一個產品，普通的產品經理也有可能負責自己產品的一些數據。

⑤ 軟體行業產品經理的崗位職責

1、制定戰略，關於軟體開發的創意，軟體開發之前的用戶調查和對於產品創意的分析和溝通。

⑥ 數據產品經理和數據分析師，產品經理有什麼區別

隨著科學技術的進步和數據時代的來臨，數據分析的能力范疇也進一步擴展，它需要將社會生活經驗、數據分析理論和現代計算機技術有機地結合在一起，才能發揮出數據分析的最大威力。

⑦ 數據產品經理和數據分析師有什麼區別核心競爭力分別是什麼

數據pm重產品設計，數據分析是數據pm的基本技能；工作職責是數據平台的搭建、數據策略制定等；
數據分析重分析，屬於後置性工作，工作職責是，通過數據結論，為產品、運營、市場提供數據支持。

⑧ 數據產品經理如何學習

1. 推薦環節
在推薦這個環節，最關鍵的問題就是如何推薦用戶感興趣的美食，只有把用戶感興趣的美食推薦給用戶，成單率才會高。

所以，在這個時候就會用大數據產品的智能推薦系列產品。

2. 接單製作環節
在接單製作的過程中，商家會面臨如何根據用戶的喜好來製作美食。

這時，我們可以通過用戶畫像，掌握用戶口味、喜好，用戶畫像系統會把用戶平時喜歡的常點的菜品做記錄，然後通過大數據分析來標記用戶，對此用戶喜歡的口味、菜品，我們都能清楚掌握。

3. 物流配送環節
在物流配送環節最典型的問題：如何在保證用戶體驗的同時，最大程度的提升配送效率。

這個時候就需要用到調度系統這種數據產品。

4. 優惠環節
優惠環節的關鍵問題是：如何用最少的這種優惠來刺激用戶，產生更多訂單。

這個時候我們常用到的是智能營銷類數據產品。

首先，在數據質量層，外賣會有數據質量監控系統、埋點系統來保證數據質量，確保提供准確，安全，穩定的高質量數據。
其次，在數據工具層會提供大數據分析平台，用戶行為分析平台，實現平台，用戶畫像平台等平台，提高內部人員獲取數據的效率，讓內部人員的決策更加科學。
最後，在數據應用層，也是大家在日常生活中經常接觸到的，那麼它會有智能調度、智能推薦、智能營銷這些數據產品。
融合真正的業務場景來驅動業務的發展，就是最上層的一個數據應用。

結合剛才的案例，大家可以思考一下什麼是數據產品？它有什麼作用？

帶著這個問題進一步往下看，首先數據產品的定義是應用場景+數據+產品化=數據產
從狹義上講，數據產品經理是負責實現數據產品工具，用它滿足特定的數據使用需求的一個崗位。

狹義的數據產品經理主要承擔的責任以及工作主要有三類：數據質量產品、數據工具產品、數據應用產品。

從廣義上講，數據產品經理不限於實現數據產品工具，還需要完成數據分析、運營等數據相關的工作，負責公司的數據服務。

廣義的數據產品經理主要承擔的工作和職責包括四類：

第一類是數據生產，例如寫一些生產數據的腳本、產出數據報表、維護數據生產流程；
第二類是數據提取，比如負責對業務提出的數據需求提取數據；
第三類是數據分析報告，例如日常的一種業務分析報告、日報，並形成業務結論；
第四類是數據運營，比如建設數據指標字典、運營指標字典和數據運營等等。

⑨ 優秀的數據產品經理需要掌握哪些技能

1.要極其熟悉公司業務及動向。
所以要了解公司的商業模式、戰略、以及業務流程、要考核的各種指標，以及指標背後的業務含義等。這一點，再了解都不夠。
2.要了解數據分析。
好的數據PD，即使不做數據PD，也應該是個數據分析師。數據PD的一大要務就是將數據分析做成可復制，可自動運轉的系統。雖然有數據分析師們圍繞在自己周圍，但是自己也要清楚業務的問題，分別要看什麼數據，或者當數據出現後，意味著業務出現了什麼問題或者會出現什麼問題。這一點，要向最好的數據分析師們看齊。
3. 要了解數據倉庫及商務智能。
這 兩個關鍵詞背後都是龐大的體系，恐怕我短短半年的轉崗時間太短，雖然能夠對別人講解一通商務智能產品的架構。嘴裡雖然會拋出若干個類似於匯總，鑽取，度 量，指標，維度，緩慢變化維，層次，屬性，儀表盤等等術語，但是也不支持多幾層的知識鑽取，遇到異常問題，也不知道該從什麼地方分析原因。幸而身邊有數據 倉庫的同事，可以多多學習。這一點，沒有天花板。
而商務智能，做為一門學科，起源於20世紀90年代，它的出發點是幫助用戶更好地獲取決策信息，最初商務智能的動機是為用戶提供自助式的信息獲取方式，這 樣，用戶就可以不用依賴於IT部門去獲取定製的報表。（引自《信息儀表盤》一書P41）。而如今，商務智能除了提供信息，更主要的是降低用戶獲取數據的門 檻，提升數據的實時性等方面。從降低用戶獲取數據的門檻一個方向，我們就可以做很多事情，比如如何設計信息儀表盤（designing of information dashboard）？如何讓數據以更親和的更直觀的方式展示（數據可視化）？如何能夠讓用戶離線訪問？如何能夠實現警戒數據的主動發送？這一點上，花多少功夫都不多。
4. 要精通數據產品開發流程。數據開發+產品開發。
數據PD的最終目的是要做數據產品。這里要拆開看，其一，數據產品本身也是在線可供用戶實現的產品，既然是產品，產品的整套研發思路和普通的產品沒有太大區別，用戶是誰，他們需求是什麼，滿足需求需要什麼featurelist，每個feature list的資源評估以及優先順序如何，產品的生命周期如何？這是產品開發。然後他是個數據產品，意味著這比普通的產品，多了更多的要求。在數據這個內核之外，它需要各種feature list，如訂閱，搜索，自定義，簡訊介面，郵件介面等。但是數據這個內核，也需要一套數據開發流程。
比如：
數據源——是否足夠，是否穩定
數據PD需要足夠了解目前的業務處理系統建設情況，以及數據源的積累程度，用以判斷數據產品的建設時間是否合適。不合適的時機會導致項目組的重復勞動和殘缺 的數據產品誕生。數據產品是用以支持監控，分析，決策的，而業務處理系統的定位在於提升工作效率，解放工作人員手腳。業務系統採集的數據未必滿足所有分析 需要。比如或許領導要分析大量攀升的退換貨的詳細原因，而業務系統目前並沒有要求用戶在申請退換貨的時候選擇原因或只有輸入而非標准化選項，負責退換貨出 力的員工也只有在excel里登記原因，而不是錄入到系統里。所以可能會導致需求方要看的數據提供不出來，那麼數據pd就有必要反向驅動數據源得以採集。
分析模型的設計—— 分析模型的好與不好，其實決定了數據產品的成敗。
在 項目中，可以由BI的數據分析師們擔綱此職責，也可以由數據PD擔綱，更多則由雙方一起確認，內容以數據分析師們為主，功能評估及優先順序、項目計劃和協 調、統籌以數據PD為主。所以數據PD要更加清楚數據分析師們所需要的需求是否能夠實現，背後的商業價值如何，並與數據開發、產品開發保持比數據分析師們 更加通暢的合作關系，能夠借力進行可行性和資源的評估。
有的時候，我們不是沒有數據，而是有了太多的數據，不知道怎麼去看。如果只是拋給用戶一堆數據，很難想像用戶會如何去解讀它。以前做交互設計的時候，我們流行一句話：把用戶當成傻瓜。
而數據平台，因為可能本身就要求有一定的使用門檻，所以想成不會互聯網的傻瓜不太現實，那麼我們就要想成「用戶是不懂數據的傻瓜」。他們或許也能通過一串串 數據體悟到什麼，但是如果是一條上升的退款率趨勢線，或許他們會體悟到更多——畢竟，上和下本身就是直觀的。然後再想一下，如果將這條線上加上一條警戒點 的線，他們會知道從什麼時候開始數據是異常的。再然後，就要設想，當他發現從7月12日數據上升後，想干什麼？他會不會想了解是哪個行業上升了？他會不會 想了解是那個渠道上升了？那麼，就要提供行業和渠道的選項或者對比給他。
再然後，當他過問了這個行業的負責人後，負責人想不想再了解是哪個供應商或者哪類商品上升了？那麼要如何將這些維度、層次都融合在一起，同時又能將用戶非常 方便地去用呢？分析模型的建設至關重要，也可以說，分析模型是前期需求分析的最有價值的產物。分析模型應該會包含幾點：
主題的劃分：
整塊分析會劃分成什麼主題，比如銷售可能會分成銷售走勢及構成分析，行業排名，商品排名等
度量及指標:
分析主題會涉及到的度量及指標的演算法、定義等（這通常會產生一份指標以及維度的定義及描述文檔）
維度：
要分別從什麼維度去看這些指標和度量，如時間，渠道，這些維度是要篩選還是要對比
鑽取：
這些維度本身有沒有層次，需要不需要進行鑽取，如渠道可鑽取到渠道類型，行業可鑽取到子行業，商品類目可鑽取到商品葉子類目等
輸出：
分析需要用何種圖表進行展現
數據的ETL開發
數據的清洗，轉換，裝載流程佔用了數據產品開發的大半資源，不規范的數據源會導致這一塊的資源更大程度的佔用。比如同樣是供應商編碼，系統之一稱為供應商編 碼，系統二命名為供貨商編碼，系統三命名為供應商ID，這三個系統同時是公司的系統，這種情況雖然想起來匪夷所思，但是現實情況卻也存在。雖然ETL開發 是DW開發工程師在做，但是作為數據PD，焉能對這些工作缺乏了解，對ETL工程師反饋的問題，缺乏認知，不理解對於項目的潛在風險是什麼？而且更多時 侯，當遇到數據不規范，不統一的問題，數據PD需要反向驅動業務系統進行數據規范性建設，無論是功能上，還是驅動直接的使用方——如負責錄入數據的行業小 二，建立一套錄入規范。這些工作看似和數據PD無關，我們大可以推脫說：那沒辦法，這是數據源的問題，不是我們功能的問題。但是，用戶是有權利選擇使用不 使用你的數據產品的，當數據產品提供的數據不值得信賴的話，無疑是自取滅亡。一旦用戶對數據不信任，再想挽留他們，是很難的。即使有很多「無能為力」的借 口,我們也不能坐觀其變。
前端交互與體驗的優化
雖然內容定義好了，但是那麼多度量、指標、維度、鑽取，如何劃分信息層級，如何劃分欄目，如何設計用戶的行為路徑？這些就不是數據分析師們的重要工作范疇。 而是交互設計師？鑒於很多數據產品項目可能會沒有交互設計師，所以數據PD應該對內容進行封裝，進行信息架構、頁面布局以及圖表各種功能設計。設計，然後 撰寫詳細的功能需求文檔，交付給產品開發，前端開發以及數據開發，以及前端展現開發四種類型的開發人員。
數據產品的功能描述文檔，除了產品開發部分，其他的就是在描述「內容」，即分析模型，除了主題、度量、維度、鑽取、篩選、輸出圖表類型，有些內容還需要詳細定義到「排序方式」 等等細節，這就case by case來看了。
環境，技術，工具
或許做一個普通的產品，你把需求描述清楚，與產品開發工程師確認好可行性，接受資源評估就OK了。但是數據產品，受制於所部署的環境，所選型的工具，如Oracle，IBM的Cogos，以及SQL Server。其他的產品我不知道怎麼樣，我們用的是Oracle BIEE。那麼作為數據PD，是否需要了解BIEE能夠提供的功能是哪些呢？看文檔，請教別人，不能知其不可而為之。另外，也需要逐漸摸透BIEE的壞脾氣，實現不了的功能，無法克服的難點等。這一點，也需要繼續了解，繼續學習。