作為產品經理,你每天會觀察哪些資料?

來源:互聯網
上載者:User

標籤:

作為產品經理,我們每天需要觀察哪些資料呢?本文和大家一起來扒一扒,希望對大家有所協助。

剛入行的時候不懂怎麼看資料,每天就是看著後台報表裡的 UV 、 PV 漲了一點點/跌了一點點,然後就沒有然後了。直到後來機緣巧合做了一段時間使用者增長,渠道相關的工作,才慢慢學會怎麼去看資料。

後來我反思為啥最早對著資料的時候整個人是懵的?想來想去最後覺得根本原因還是缺少了目標。不知道為什麼看資料的時候,所有資料都是一個個孤立的數字,後來開始帶著目標去看,去資料中找答案,慢慢就學著找資料之間的聯絡,找隱藏在資料表象下的資訊。

在我看來,所有具體的目標概括起來就是兩點:找問題找機會。找現在的產品有沒有隱藏的問題,找設計的邏輯是不是符合使用者行為,找有沒有潛在機會幫產品再上一個台階。

扯完目標進入正題,我平時經常需要關注資料大致有四類:

1. 產品的運營資料,包括 規模資料 和 品質資料

2. 產品核心情境的使用者行為資料

3. 新功能上線後的反饋資料

4. 行業資料

其中適合每天看的主要是運營資料核心情境的行為資料反饋資料是在某個新功能,或者為了驗證某種假設的實驗後研究的;行業資料則基本是按季度維度去看就可以了。

運營資料

最常規的資料是產品的運營資料,我習慣從規模和品質兩個角度去看:

· 規模資料主要是產品的一些資料指標,例如:新增使用者數,DAU (日活躍使用者數), MAU (月活躍使用者數), 電商產品的話就包括訂單、收入、等等。

· 品質指標則是反應產品業務健康程度的資料,例如:新增使用者的次日留存,使用者的啟動頻率和啟動時間長度,等等。

看這些資料首先要弄明白資料的定義方式,採集和計算過程。理解上的差異可能導致將一些不同資料做強行匹配,導致結論顯著的錯誤,尤其是面對不同產品,不同公司的資料時。

弄清楚了指標的定義,具體看資料的時候我習慣反覆使用 對比 和 分解 這兩種基本方法:

· 對比,是通過 橫比 和 縱比 的方式看資料,橫比就是和相似的產品比,和自己的經驗資料比(比如經驗裡面寒暑假是視頻的旺季,但是產品對應的資料確下跌了,這就需要進一步去找原因了);另一個縱比是在時間軸上過去的自己比。

· 分解,是按照不同的維度去分解資料,例如:可以從渠道的維度看,從地區維度看,通過不同的維度分解將對比的差異值逐級鎖定,方便尋找原因,做使用者增長的時候,我會關注不同類型的 Top 渠道。

使用對比/分解大法基本能養成較好的資料 sense 了,最後再說三個資料解讀中比較常見的錯誤:

1. 過度關注資料下跌的原因,而完全忽視上漲的原因,或完全歸因為業務的好轉。我在做瀏覽器的時候有個核心指標「人均搜尋數」,它是由 「總搜尋次數/搜尋使用者數」 計算得來的,所以人均搜尋數的增長,可能是總搜尋數增長,也可能是搜尋使用者數下跌了,是需要進一步分析的,簡單的認為上漲就是好、下跌就是差是有問題的。

2. 因果歸因錯誤,把相關關係錯認為因果關係,或者忽略了關鍵因素;例如: A 導致了 B 和 C 的發生,分析時卻忽略了 A ,直接認為 B 和 C存在因果關係。

3. 倖存者偏差,忽視了沉默的大多數,這是在看抽樣資料時很容易犯的一類錯誤,關於倖存者偏差的詳細定義大家可以翻翻百度百科。

使用者行為資料

還有一個建議每天看的是使用者行為的 log 資料,這個資料有點像「百度統計」裡面的漏鬥模型,但是他比漏鬥模型更加詳細一些,他不單單能說明使用者有沒有走到漏鬥當中,還可以進一步看到,使用者在漏鬥中的路徑,以及跳出使用者是如何跳出的。

使用者的行為資料都是一些生資料,資料量比較大,需要有一定的處理。

1、找產品的核心情境

不是所有使用者的行為日誌都去看,而是要找到影響使用者認知產品的核心情境,這裡可以借鑒( MOT , Moments of Truth )的概念,就是使用者和產品的服務發生接觸的點,這些點的體驗決定了使用者對於產品整體的評價。例如,做使用者新增的需要看新使用者進來之後找到自己想要的服務的路徑是什麼樣子的,是不是足夠簡短?有沒有遇到困難?

2、為使用者分類,找目標使用者

最好一次只看一類使用者,因為看使用者的行為資料是比較消耗精力的過程,不是每次都能有收穫的,需要不斷的看,不斷的挖掘。

所以在做新增的時候,我基本會以引流時設定的鉤子做分類,每次看其中一類使用者,例如通過今天只看通過視頻加速引流的使用者,看看這些使用者進來之後能不能快速的找到對應的視頻;過幾天看看通過資訊進來的使用者。

說完每天看到資料再簡單說兩句 反饋資料 和 行業資料 ,雖然這兩個資料不需要每天看,但在產品經理的工作中也是很有協助的。

新功能反饋資料

迭代是產品經理重要的工作手段,無論是灰階發布, AB test ,還是常規的發版都需要通過收集資料來驗證之前的假設,從而覺得是繼續最佳化,還是推到重來,迭代協助產品經理積累被驗證的認知。

 

看反饋資料最重要的是在設計的時候就想清楚,目標是什嗎?我認為這個新功能能夠起作用的邏輯是什嗎?我需要採集哪些資料來驗證?

最好的辦法就是把這些問題的答案,一條一條的寫下來,通過寫下來的方法可以保證我們事前就好一些細節的問題都考慮進去了,避免兩種常見的失誤。

· 過度採集資料,增加開發工作量;

· 採集資料不足,不能開展結論分析;

行業資料

最後說說行業資料,我習慣用行業資料來發覺新機會,行業資料能夠看到使用者移轉的一種大的趨勢,如果自己的產品能夠借上這種大勢,很可能就是一波比較大的突破。例如:2013年 WIFI 萬能鑰匙的興起;2014年視頻流量的增長;2015 年今日頭條和快手的使用者量崛起。

行業資料擷取比較依賴大平台,如果是在 BAT 這樣的大公司,有足夠大的使用者樣本,比較容易及時的看到這些資料。如果沒有這樣的條件,一方面可以依賴艾瑞等第三方的報告,另一方面就是要多關注各種排行版資料,例如:app store 、應用市場的榜單,微博的關鍵熱榜、百度指數等的變化。

總的來說就是要去想,使用者最近關注什嗎?這個東西和自己的業務有沒有聯絡,切忌不要強制聯絡。

看資料這種技能也是越練越熟,真有「資料 sense 」這種東西,經常看就會對資料更敏感,更容易探索資料中隱藏的資訊。

 

來源:人人都是產品經理

作為產品經理,你每天會觀察哪些資料?

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.