數據產品經理門檻真的有那麼高？

作者：KEVIN

編輯：Juvae

我數據與產品經理的一些趣事

近期在負責公司的產品模塊迭代，在評審會議中與開發們PK自己的需求同時，也在糾結如何更快的去證明需求的可靠性？如何將產品設計的立腳點站穩？如何給予評審會議中的同事、LEADER一個不是拍腦袋的方案？

由此，合理的數據分析顯得尤為重要，如何去得到數據？如何將數據的分析結論應用於評審與需求設立中？相信不少朋友會有這樣迷惑的場景，數據在產品經理的心中門檻有時候變得很高，因為產品經理沒辦法拿到數據；有時候又很低，因為數據拿到了，但是卻無法用來證明自己的需求設立點。

01 常見數據的獲取

每一個產品都會有一款自己的管理端，這是產品完整的一個基礎。基於管理端管理者可以把控前端的內容、功能、甚至是邏輯。

關於產品數據的獲取，從大廠到小廠，數據的意識比數據的獲取更為重要。如果說數據的獲取是執行，那麼數據的意識便是驅動力。除開數據的意識，經過不同公司，每家公司的數據獲取都大同小異，但各有千秋。

• 使用第三方數據平台

• 自己搭建數據平台

• 沒有數據平台，用EXCEL等工具統計

• 沒有數據統計
  
  

以上這四種情況，基本覆蓋了目前各個產品經理所處的現狀，因此在不同的產品背景下，每個產品經理的數據分析能力也各有差別。

1.第三方數據平台

最為常見的是第三方數據平台使用，這也是中小型企業所最佳選擇；我截取了現階段國內數據平台的排名

【國內數據分析平台】

現在數據埋點的技術也和之前有大不相同，前段時間參加了 關於GROWING IO的數據分享，其推出的無埋點技術也是數據分析的一個亮點，產品經理或數據分析人員只需要創建相應的統計事件即可，（如果你問我什麼是事件，可以百度~）

【事件定義列表】

獲取的數據，我們可以通過數據平台的數據導出在EXCEL上進行分析，當然目前數據平台以友盟、TALKINGDATA等數據分享平台自己平台也有現成的漏斗分享模型，數據的導出其實就是為了滿足更多的數據分析需求。

有數據平台的產品團隊，其數據的獲取就變得很容易了。以下是我羅列出在UGC模塊中會存在的簡單數據獲取欄位

【數據獲取模版】

當產品經理定義好需要埋點的欄位或事件甚至是頁面，那麼接下來就是交驗數據的正確性以及數據的真假驗證。

2.自家搭建數據平台

相對於採用第三方數據平台的企業，其自家搭建的數據平台明顯是側重於數據的保護和更豐富的數據需求，但值得 一點需要注意的是，並不是自己搭建了數據平台其數據有效分析性一定是強於第三方的，數據分析平台最重要的功能我認為其是數據採集、輔助數據分析的平台，只有產品實戰中獲得數據分享的方法論和數據模型，才是數據的真正意義。

自家搭建數據平台的產品或企業，其理由有千萬種，但在常規情況下，國內常見的類似BAT等企業，其自家的數據平台是為了滿足自己複雜的數據需求、保護自己的數據安全。

但除開BAT一線互聯網公司，其中小型企業也有不少數自家建立數據平台，毫無疑問自家建立數據平台，是數據意識最強的產品企業，數據驅動增長，找出產品的正確迭代方向。

自家的數據搭建，首先需要PM進行數據的梳理，除開以上使用第三方數據平台需要建立數據的需要欄位、事件，還需要考慮數據平台的完整性

【數據平台的搭建】

自家搭建數據平台，尤其需要注重的是公司內部數據的採集完整，能否滿足後期數據的擴展。常見問題就是：1.0版本到2.0版本，2.0因為增加了新的功能，以前的數據平台要想能夠採集，就得再次開發。當然最重要的是再次開發需要大量修改，對模塊框架或數據採集邏輯進行修改等常見問題，是產品經理在搭建數據平台考慮的，這也就是途中的數據擴展性。

3.沒有數據平台，用EXCEL獲取

咋在目前從事產品快3年的路上，作為產品經理對於數據的追求和執著，打動我的是在產品工作中，一次工作會議上，我的領導親口傾述的一個同事的故事。

在公司沒有數據平台的時候，如何去獲取數據？如何得到數據？當時的產品負責人或產品經理，通過將用戶產生的信息列印出來，一張紙、一張紙的列印，最終人工數出來，並加以計算。

人工計算？用紙數?換成今天來看，這是多麼不可思議的事情，多麼浪費時間的事情。但這確確實實反映了作為產品經理，其獲取數據的執行的力不應該簡單建立在公司是否有數據平台、公司是否買了數據第三方平台等。

毫無疑問，在這種狀態下成長的產品經理，雖然其數據收集的成本或數據分析成本會比剛剛前面說的2種情況下困難許多。

其門檻無非需要麻煩開發通過資料庫直接將現有的數據進行調出，產品經理用EXCEL進行分析，簡歷相應的模型

【EXCEL分析模型】

上面我舉例了一個分析模型，其隨著數據的分析方向和數據採集的樣本數量多樣，其分析的方法和模型也會越來越複雜。

4.沒有數據統計

沒有數據統計並不是說一點都不看數據，而是沒有將數據進行一定規律的演算法、分析；這裡我舉個例子，以科技美學的社區為例

【科技美學社區】

社區所產生的FEED流，產品人員只是通過簡單的數目篩選，沒有規律的查看近期相應的FEED流，或者只是在社區中滿無目的的瀏覽社區數據。

這就是沒有數據統計的典型樣本，其產品經理獲取數據的方式只是拼著第一認知或當前的人工辨別去查看相應的數據，這一點毫無疑問也是目前數據與產品經理的常態之一。

02 我分析數據的常用方法論

既然上面說了4點關於數據的獲取情況，還是那個前提這裡我們拋開公司的數據意識，僅僅只說PM自己與數據的相關聯繫。

那麼對於我來說，我是如何通過數據去落地產品設計？這裡首先我的整個需求落地流程如下：

【數據分析流程】

1.需求確定數據獲取

需求的確定后，通常對於需求的收集與處理確定當前版本或當地周期會做的需求，尋找相應改動或迭代的模塊或功能需要的數據會存在那裡？數據平台如果有多個要區分，那PM需要提前區分相應的數據會在那一個數據平台，在那一個統計模塊？統計模塊的報表中所涉及的數據，需要那些欄位。

如：UGC社區FEED流演算法需求，我需要統計點贊、評論、動態數、用戶每天發動態的人數、評論數、舉報動態數，我需要統計以上數據來決定是否採用那種演算法？至於FEED流演算法，上周我的分享UGC與演算法|2017行業產品FEED流產品設計，我如何落地UGC信息流？在這裡可以進行學習。

2.數據平台

從想用的數據平台尋找剛剛確定的數據需求，並且查看當前數據是否有更多可用的？自己在需求整理的時候，數據是不是少了一些緯度的可能？這裡我給予幾個網上找的數據平台數據採集截圖

【數據採集欄位】

不管是第三方數據平台還是自家開發的數據平台，其數據採集的細度隨著當時採集的需求不同，其細度也不同。因此從數據平台中除了查看自己需要的數據外，還需要看下是否有一些其他數據的統計，不同數據之間的關聯。

如：訂單數據與訪問量數據、FEED動態梳理與用戶性別數據

關注一些垮緯度的數據，有助於產品經理能夠了解一些細緻的需求。比如類似UGC訪問量與性別有關係？舉報用戶大多在B模塊中使用類似功能比較多。

3.多個數據分析模型——以及我使用的數據分析模型

其實數據分析模型網上有一大堆理論，但每個產品經理其自己願意關注的數據、收集的數據整理之後無非都會形成一套自己的模型理論，誰的理論更有效是核心保障點，但初學者需要不斷調整自己的數據模型，針對相應的模塊建立相應的模型，最終提高有效的產品迭代方案。

這裡還是以UGC FEED流方向來為大家分享我的分析模型，選擇我曾經從事過的一個迭代案例來說明下我使用的模型所建的模型，以下是A用戶女性與B用戶男性在社區中的發帖數隨時間15天。

【社區中用戶的發帖數統計】

1.從數據中我們可以看到，其FEED流在周末幾乎沒有生成，在工作日中，其用戶活躍度A用戶的是B用戶的8-10倍左右，很明顯B用戶是少數用戶。

2.用戶的獲取與留存需要單獨從數據平台進行拉取，和上圖類類似，拉去A用戶的新增數據、B用戶的新增數據、A用戶的留存數據、B用戶的留存數據，這裡就涉及到新增、留存

3.從數據平台中拉去用戶A在產品中的消費數據、用戶B在產品中的消費數據，這裡是消費數據（ARPU），和1類似

4.從數據平台中拉去用戶A分享的次數數據以及分享的渠道（微信、微博、QQ）每一個渠道的具體數目，用戶B的分享次數數據和分享渠道數據，和1類似

以上的數據指標為：活躍度、新增、留存、分享、收益，按照目前網上的理論說明為：AARRR模型（海盜指標）

按照運營的分發為：業務盈利數據，和用戶TRACKING數據

4.通過數據結果落地需求

首先需要說明的是，需要以多個數據分析指標來考慮需求的落地，這裡我只簡單說明以用戶的活躍情況來確定需求落地的方案

其一：通過以上的數據分析，我們發現周末的用戶發帖數低，因此需要考慮增加一些推送或周末內容，提供用戶發帖的驅動力。A用戶比B用戶活躍度高，考慮B是男性，以及該模塊為社區模塊，以內容來沉澱、拉新用戶，因此需要增加男性用戶的內容，並且增加一些中性內容，以提高B用戶的活躍度。

其二：根據用戶的發帖數，我們可以看到整個社區的發帖數目目前A用戶是B用戶的10倍，因此產品定位從之前的中性定位會逐漸傾向於偏側A用戶，增加與A用戶相關的常用功能。當然其二需要多方緯度考慮評量，我這裡只是作為一個簡單需求落地點

03 數據與產品經理門檻那麼高？

不得不承認，在如今互聯網以流量、用戶為首的產品理念正在整個傳統企業以及互聯網企業形成一種趨勢。如何其做精細化運營？

每一個產品都有自己的獨特點和產品定位，產品經理不僅僅是需要將產品的原型、文檔寫好，我認為其對於數據的敏感應該來自於日常的訓練或學習。

當你正處於一個沒有數據環境的TEAM，或產品項目中，我認為最簡單的就是去使用一些數據分享工具，QQ群、微信公眾號都會有這樣的數據分析工具。雖然可能其涵蓋的指標不多，但是足夠養成數據習慣，讓你去總結自己的數據模型。

在日常評審中，採用數據的分析后，可以更合理的去落地相應的需求案例，不會以拍腦袋來決定，因為「XX競品都是這麼做的」來說服開發或LEADER。

當然這裡最後說的是，PM也應該通過數據來給予自己設定KPI，雖然一提KPI每個運營人員都是頭大。但不得不承認，一個產品是否好？或者是否在你的手裡經過好的迭代？數據是最有利的說話方式。

當前模塊的留存、MAU是設密碼情況，新版本的又是什麼情況？是產品經理典型的一種KPI

我認為，或許KPI就是檢驗一個PM的成功與否。