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

07-17

人人都是產品經理是中國最大最活躍的產品經理學習、交流、分享社區。集媒體、社區、招聘 、教育、社群活動為一體,全方位服務產品經理。本文由人人都是產品經理社區 專欄作傢 @kevin(微信公眾號:Kevin 改變世界的點滴) 原創發佈。轉載請聯系人人都是產品經理。

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

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

一 . 常見數據的獲取

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

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

使用第三方數據平臺

自己搭建數據平臺

沒有數據平臺,用 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 流,或者隻是在社區中滿無目的的瀏覽社區數據。

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

二 . 我分析數據時,常用的4種方法

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

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

1. 需求確定數據獲取

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

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

2. 數據平臺

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

數據采集字段

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

如:

訂單數據與訪問量數據

FEED 動態梳理與用戶性別數據

關註一些跨緯度的數據,有助於產品經理能夠瞭解一些細致的需求。比如類似 UGC 訪問量與性別有關系?舉報用戶大多在 B 模塊中使用類似功能比較多。

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

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

其中的一個社區 FEED 迭代案例

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

社區中用戶的發帖數統計

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

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

從數據平臺中拉去用戶 A 在產品中的消費數據、用戶 B 在產品中的消費數據,這裡是消費數據(ARPU),和 1 類似;

從數據平臺中拉去用戶 A 分享的次數數據以及分享的渠道(微信、微博、QQ)每一個渠道的具體數目,用戶 B 的分享次數數據和分享渠道數據,和 1 類似。

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

按照運營的分發為:業務盈利數據,和用戶 TRACKING 數據。

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

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

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

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

最後

不得不承認,在如今互聯網以流量、用戶為首的產品理念正在整個傳統企業以及互聯網企業形成一種趨勢。

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

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

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

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

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

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

精彩圖片
文章評論 相關閱讀
© 2016 看看新聞 http://www.kankannews.cc/