這篇文章一共會分為四個部分進行講解。

1. 認識資料 通過這部分我們可以知道什麼是資料，資料與產品之間的關係等。

2. 獲取資料 這裡我們可以瞭解到一些資料指標的含義，獲取資料的常用工具以及常見網站的核心資料指標的確立。

3. 分析資料 這部分我們可以瞭解到一些基本資料分析的方法，以及使用資料時需要注意的事項。

4. 利用資料 這裡我們可以知道在做產品的時候，使用資料的一些場景和利用資料驅動產品的思維方式。

一、認識資料

1.1 什麼是資料？

簡單來說資料是一種量化事物的手段，就像身高、體重、三圍一樣，它們都是一個數字指標，代表了事物現實存在的客觀情況。 資料最大的特徵就是客觀性，無論我們是否觸碰它，它就在那裡。在面對海量資料的時候，身為產品經理的我們要更像一個「求知者」，如果我們希望在資料中找到答案，我們更應該帶著一個「求證」的態度去讀取，去分析，去解讀。

1.2 資料與產品的關係

資料可以用來幫助我們驗證產品假設是否正確，也可以幫助我們發現產品的問題。

通常情況下，一個完整的資料需求包括：

1. 功能設計方案
2. 功能目的和目標
3. 功能上線後需要跟蹤的資料指標

這裡舉個例子說明下，網站註冊流程功能的資料統計需求：

1. 註冊流程的完整方案設計文件
2. 做這個功能的意義：讓所有新使用者快速完成註冊流程，並正確提供所需要的個人資訊
3. 所需指標及定義。圍繞2中的目標，設計所需要的資料指標，思考哪些資料指標，可以描述目標完成情況；比如：每一個註冊環節的使用者跳出率，每一個註冊填寫欄位的出錯率，各類註冊錯誤的出現頻次分佈等。

二、獲取資料

2.1 網站的資料指標與分析工具

2.1.1 資料獲取工具

免費的網站排名工具：Alexa、中國網站排名、網路媒體排名 免費的網站檢測工具：Google Analytics、百度統計、CNZZ網站分析

2.1.2 關鍵指標

• 訪問量 訪問量就是 一段時間的訪問量就是這段時間的內的會話次數。 什麼是會話，如下圖：

  什麼是會話

• 訪客數 也稱獨立訪客數（UV），就是訪問網站的人數。

  如何識別一個使用者？

  在網站分析系統中，會依據使用者的瀏覽器，裝置型號等資訊為使用者分配一個編號，這個編號稱為Cookie。訪客數就是訪問網站的Cookie數。如果同一個人換了瀏覽器或者裝置訪問網站，那麼它的Cookie也發生了變化。

• 瀏覽量 常被稱為PV（PageViews），就是瀏覽頁面的數量。

• 頁面停留時長 訪客一次訪問在某個頁面的停留時間。 計算方法：頁面停留時長 = 這個頁面的總停留時長 / 這個頁面的訪問量

• 網站停留時長 訪客一次會話的時間長度 計算方法：網站停留時長 = 網站的總停留時長 / 網站的訪問量

• 跳出率 網站的所有會話中，來到網站之後沒有任何動作就離開的比例。 計算方法：跳出率 = 只訪問了落地頁面的訪問量 / 總訪問量

• 退出率 無論從哪個頁面進入網站，最終從這個頁面退出的比例。 計算方法：退出率 = 從一個頁面的退出次數 / 總訪問量

• 轉化率 計算方法：轉換率 = 達成某種目標的訪問量 / 總訪問量

2.1.3 對網站的巨集觀分析

網站的資料有很多，我們可以通過先對網站進行巨集觀的分析對網站有個大體的把握，避免一上來就陷入資料的細節中，通常我們可以通過回答以下幾個問題來大體的瞭解網站：

1. 有多少訪客訪問網站，訪問深度怎麼樣？ 檢視「受眾群體」概覽頁來了解網站的訪客數和訪問深度。

2. 這些訪客從哪裡來，以及效果怎麼樣？ 檢視「流量獲取」的概覽頁來了解網站的流量從哪裡來。 一般有：引薦網站、直接進入、自然搜尋、付費搜尋、付費流量廣告

3. 訪客在網站上做了什麼？ 檢視流量最大的著陸頁的相關資料，著重優化，降低跳出率； 檢視流量最大的頁面的相關資料，並與預期相比，發現差異； 檢視頁面點選熱圖； 檢視主要流程的轉化漏斗。

2.2 移動應用類資料指標

2.2.1 資料獲取工具

2.2.2 關鍵指標

• 使用者獲取
  • 下載量
  • 安裝啟用量
  • 啟用率
  • 新增使用者數
  • 使用者獲取成本
• 使用者活躍與參與
  • 數量指標
    • 日活躍使用者數
    • 月活躍使用者數
  • 質量指標
    • 活躍係數 它等於：活躍使用者數 / 月活躍使用者數
    • 平均使用時長
    • 功能使用率 使用某功能的使用者數佔活躍使用者數的比例
• 使用者留存率
  • 次日留存率
  • 7日留存率
  • 30日留存率
• 使用者轉化
  • 付費使用者比例 付費使用者佔免費使用者的比例，建議將付費使用者和免費使用者區別對待，因為他們在行為上差異挺大的。
  • 首次付費時間 使用者啟用多久後才會開始付費。
  • 使用者平均每月營收 一個月的收入除以月活躍使用者數
  • 付費使用者平均每月營收 一個月的收入除以月付費使用者數
• 獲取收入
  • 收入金額
  • 付費人數

2.2.3 版本迭代時，如何利用以上指標去評估版本迭代的效果？

注：在利用指標去評估版本迭代的效果時，儘量使用新使用者的資料，因為老使用者會存在忠誠度等因素影響資料。

我們在評估新版本的迭代的效果時，可以看以下幾個資料指標

1. 新使用者的留存率 新版本釋出後，新版本釋出前14天內的新使用者次日留存率。 留存資料整體提高，表明移動端版本迭代的效果較好。

2. 核心功能的使用率 同比：舊版本釋出後14天 環比：新版本釋出前14天 通過同比和環比14天的資料觀察核心功能的使用率是否有提升。

3. 新功能的使用率，繼續使用率和新功能的核心貢獻 在新的版本中，增加了功能A

   1. 需要檢視功能A的使用率
   2. 功能A的繼續使用率
   3. 功能A的核心貢獻：使用過功能A的聽歌人數比例 - 未使用過功能A的聽歌人數比例

通過觀察以上指標基本上就可以大概的判斷這個版本改版的效果了。

2.3 電商類資料指標

2.3.1 關鍵指標名詞解釋

• 銷售額 這裡是指電商網站的收入，這是電商網站最重要的指標。由於移動網際網路的崛起，這裡還需要統計下移動端佔比。

• 購買客戶數（按照賬號去重計算）

  • 老客戶數 當天之前就購買過商品的使用者數，表示網站的粘性
  • 新客戶數 統計當天首次購買的使用者數，表示網站客戶增長速率

• 客單價 每個客戶購買的金額，等於銷售額/購買客戶數

• 購買轉化率 訪客中購買了商品的比例，等於購買客戶數/訪客數

• UV 訪客數，來到網店的人數

• 詳情頁UV 訪問商品詳情頁的人數

• 訂單數 訂單數關係到支付壓力和倉庫發貨的任務量

• 妥投及時率 妥投到客戶的訂單中，按照約定時間妥投的比例，它是個非常重要的使用者體驗指標。現在京東的一個很好的優勢就在於它的物流。

• 重點商品缺貨率 爆款缺貨的比例。有時候使用者想購買的物品缺貨，容易導致客戶的流失。

2.3.2 如何將銷售額和其他的資料關聯起來，輔助我們去發現問題？

我們前面說到，銷售額是電商網站中最關鍵的指標，沒有之一。 銷售額 = UV 轉化率 客單價 那我們接下來一個一個的分析這三個因素

1. 流量變化的因素

分析流量的變化就需要從流量的來源上來入手。

分析思路大致是，先按照終端細分，先看下PC端、App端、Wap端分別變化了多少，然後在細分對應的終端流量是從哪裡來的。PC端和Wap端可以細分到媒體，App端又分Android端和iOS端，Android端可以從渠道包中來區分來源，iOS端可以用一些跟蹤工具或者IDFA來跟蹤。 具體可以看下圖：

2. 客單價變化的原因 下面我們來看下客單價的公式

客單價 = 人均購買件數 * 件單價

• 人均購買件數是指每個客戶購買幾件商品，這個指標也經常用來衡量關聯銷售的效果，也就是關聯銷售效果越好，人均購買件數就會越多。
• 件單價是指商品的平均價格，等於銷售額除以銷售量，這個指標用來衡量網站上的商品價格高低。

客單價的變化經常會與促銷活動有關係。如下圖：

3.轉換率增長因素 - 轉化漏斗 正所謂一圖勝千言，看下面這張圖大家應該就可以明白了。

2.3 UGC 類資料指標

首先解釋下什麼是UGC，UGC就是以使用者創造內容為主的應用，比如部落格，微博，朋友圈等 UGC產品的關鍵指標就是「使用者參與度」 使用者參與度指標

• 訪客數
• 停留時長
• 產出內容（比如：點贊、評論、發表文章等） 不同的產品關注的產出內容關鍵點也不一樣，比如： 微博關注的是轉發微博、發表微博； 朋友圈關注的是朋友圈發表狀態； 部落格關注的是發表的部落格數。

舉個例子： 輕部落格的參與度指標

• 活躍使用者規模

  • 訪客數 訪問網站或者開啟App的人數，等於web端訪客數+移動端訪客數
  • 登入訪客數及佔比 登入的訪客數以及佔總訪客的比例

• 留存以及訪問深度

  • 沉默使用者數及佔比 超過7天未訪問的賬號數佔總賬號的比例
  • 平均停留市場 總停留時長除以訪客數

• 核心功能使用情況

  • 點贊訪客數及佔比 點讚的訪客 / 登入訪客數
  • 推薦訪客數及佔比 點選推薦的訪客 / 登入訪客數
  • 分享訪客數及佔比 點選分享的訪客 / 登入訪客數
  • 創作訪客數及佔比 創作訪客數 / 登入訪客數
  • 文字、圖片、音樂、視訊創作訪客數及佔比

另外UGC產品還特別依賴於優質內容的產出，那如何去篩選優質內容了？

首先我們要對優質內容建一個評分模型，比如微博的優質內容模型為：

熱度 = 轉發 + 評論 + 點贊

然後可以對各個指標定義下所佔比例，這樣就可以憑藉熱度這個指標去篩選優質內容了。

三、分析資料

3.1 基本分析方法

3.1.1 橫向對比

橫向對比就是和自己對比。

舉個例子，改版的App釋出後，想看下改版後的效果，這個時候就需要用到橫向對比了，和上一個版本進行對比。

3.1.2 縱向對比

縱向對比就是和競品對比。

舉個例子，微信支付和支付寶在除夕這天的一些資料對比（資料純屬虛構）：

3.1.3 象限分析

象限法指根據資料中的（質量、數量等）的兩個重要屬性作為分析的依據，進行分類分析。

比如對App的渠道分析，我們可以用「質量」和「數量」兩個維度來進行，如下圖：

3.1.4 交叉分析

交叉分析的主要作用就是從多個維度細分資料，它的作用主要是從中發現最為相關的維度來探索資料變化的原因。

舉個例子，統計一款App的新增使用者數，我們採取交叉分析法，把終端、時間和渠道三個維度結合到一起，如下圖：

3.2 AARRR資料分析框架

AARRR是Acquisition、Activation、Retention、Revenue、Refer，這個五個單詞的縮寫，分別對應這一款移動應用生命週期中的5個重要環節，具體模型如下圖：

那產品經理應該可以利用AARRR模型來做什麼了？

它提供很好的精細化資料分析思路，能夠將整個是資料鏈打通，而不會僅限於某個具體的指標。

下面我們舉個具體的例子來說明：

某App通過渠道A引入了100000個使用者，單個使用者成本為3元。 通過渠道B引入了50000個使用者，單個使用者成本為10元。

如果我們不通過AARRR模型來分析，這樣就很簡單的判斷是渠道A效果會更好，但是我們如果通過AARRR模型來看。

渠道A的AARRR模型：

渠道B的AARRR模型

通過上面兩張圖我們可以看出其實是渠道B的效果會更好一些的。

3.3 邏輯拆解分層框架

什麼是邏輯拆解分層框架？

對於一個產品來說，它的資料指標非常的多，對於產品經理來說，我們不可能時時關注每個指標，通知我們需要重點關注最核心的指標。

舉個例子來說：

1. 對於網易考拉海購來說，最重要的指標就是銷售額
2. 對於夢幻西遊這個遊戲來說，最重要的指標就是ARPU（使用者平均收入）
3. 對於網易新聞Web端的，最重要的指標就是UV（網站訪問人數） 當我們關注核心指標的變化時，是什麼原因導致這些核心指標的變化了？我們需要怎樣去解釋這些變動了？

這裡我們舉個電商的例子，電商的核心指標是銷售量，我們對銷售量這個指標進行邏輯分層，得到下面這張圖：

得到這張圖後，我們通過分析銷售量的指標的變化，就可以更精確的去定位是什麼原因的導致的了。

3.4 漏斗模型分析框架

漏斗模型，就是從起點到終點有多個環節，每個環節都會產生使用者流失，依次遞減，每一步都會有一個轉化率。

比如很典型的商品購買流程：

我們通過這張圖就可以很清楚的知道使用者在哪個步驟流失的最多，然後我們就可以針對該步驟進行優化。

3.5 使用資料時需要注意的事項

3.5.1 資料圖形的欺騙

我們先來看下下面這兩張圖：

這兩張圖其實表達的資料是一樣的，但是看第一張圖會感覺活躍使用者增長趨勢比第二張圖好很多。

那怎麼避免這種問題了，答案是給這套曲線增加一個公式，用公式來表現曲線的斜率。

3.5.2 資料抽取樣本的問題

舉個現實生活中的例子：

在2008年奧運會上，姚明的三分投籃命中率為100%，科比的三分投籃命中率為32%。

那麼我們是不是說姚明的三分投籃命中率要比科比高了？ 顯示不能這麼說，因為那屆奧運會，姚明只投了一個三分，科比投了53個三分。

決定樣本量大小的因素有：

1. 總體大小
2. 總體內部差異程度。

所以在抽取樣本的時候，儘可能的多覆蓋，儘可能的找差異程度大的使用者。

3.5.3 資料被平均

這裡先舉個例子說明下：

對於一個新推廣的的網站：

網站平均訪問時長：55秒；使用者平均訪問頁面2.16個。

這個是不是就可以說明使用者主動瀏覽其他頁面，但是我們這時候看下頁面瀏覽和訪問時長的分佈圖：

這個時候你就會發現你被平均數帶到坑裡去了。

那麼問題來了，什麼時候平均數可以代表整體的情況了？

答案是當資料為正態分佈時，就可以用平均數代表整體的情況了。 當資料的分佈為長尾分佈時，我們可以選取資料比較集中的部分進行分析。

3.5.4 辛普森悖論

當人們嘗試探究兩種變數(比如新生錄取率與性別)是否具有相關性的時候，會分別對之進行分組研究。然而，在分組比較中都佔優勢的一方，在總評中有時反而是失勢的一方。

下面舉個具體的例子來說明下：

當產品經理看到上面這組資料時，是不是就可以決定要先從電腦版開始開發了？

我們接下來再看另一組資料：

從這組資料來看是不是和上面那組資料得到的結論完全相反了。

3.5.5 忽略沉默使用者

使用者迫切需要的需求 != 產品的核心需求

有時候我們所聽到的需求，或許只是少部分使用者迫切需求，而大部分使用者並不在乎。

舉個微信的例子：

很多使用者都反饋說為什麼不給訊息加個訊息狀態，這樣我就可以知道對 方有沒有看我的訊息了。說實話剛開始看到這個需求的時候，我就想到了陌陌和WhatsApp，他們都做了訊息的狀態功能。然後就想當然的覺得微信其實也應該加一個。

後來我看到這樣Allenzhang的回答：

如果我們針對需求一個人去滿足，你可能獲取了這部分使用者，但是得罪了另外一部分使用者。有人就挺不喜歡把我的已讀狀態暴露給別人，你想這樣的話，如果你的上級找你，你看了然後你又不回，就很麻煩。 我們要給人撒謊的機會，我們說人性是什麼？給他撒謊的機會，說我沒有看到。你看簡訊不太準確，我們經常會說，你那個簡訊丟了，我們沒有看到。如果我們把人都像機器一樣約束起來不一定是好事。

我們為什麼不做已送達的狀態？因為我們覺得未來的系統是絕對可靠的，我們有這個信心，肯定會送達，除非他關機了，我們不會再專門做一個是不是已送達，只有不自信的系統才會做這樣一個狀態。而且你每發一個訊息還有個已送達或者傳送中，那很醜陋的，多了一個東西在那裡。所以這也是一種態度。對於這種使用者要什麼就給什麼，其實這是考驗產品經理水準的東西，因為我滿足需求很容易，但是你怎麼找到理由拒絕他，或者說找到什麼方式實現它這個非常難。

微信對人性的把握太精準了。

所以說很多時候我們要站在更高的角度去考慮問題，不能聽到使用者的聲音的時候就立馬做出決策，而忽略了產品大部分目標使用者的核心需求。

3.5.6 過分依賴資料

我們觀察我們生活中的很多的偉大的產品都不是通過分析資料得出了。比如，當年汽車誕生的時候，我們通過分析馬車的相關資料，只能得出使用者需要一匹更快的馬車。

所以說，產品經理還需要把自己的理性思維和感性思維更好的結合在一起。

3.5.7 錯判因果關係

什麼是因果關係？

就是A的發生，導致了B的發生。比如醉酒駕駛導致交通事故，那麼醉酒就是交通事故的原因之一。

什麼是相關關係？

就是A和B兩件事情的出現，都是出自同一個原因，資料上顯示火鍋消費高峰期和冰淇淋消費低谷期總是同一個階段出現，而這兩件事情都有同樣一個原因，即天氣變冷，氣溫下降。

有時候我們在分析資料時常常把相關關係錯判為因果關係。

這裡我們舉幾個現實生活中的例子：

1. 吸菸真的是短命的原因嗎？
2. 玩網遊讓學生成績變差？
3. 打籃球讓人長高？

所以說，我們在面對資料的時候要時刻保持獨立思考的狀態，要多問幾個為什麼，要多好奇心 。

四、利用資料

4.1 資料應用的場景

4.1.1 需求層面

需求一般有兩個來源，一個是使用者層面，一個是公司層面，資料在面對這兩個方面的需求所起到的作用是不一樣的，下面我們分別看下這兩個層的需求來源。

1. 使用者層面。 一般來說使用者層面的需求一般來自普通使用者或者產品經理自身。這個時候資料主要是用來「去偽存真」。

   有時候使用者會基於自身層面提出很多需求，但是這些需求都非常的主觀，我們這時候就可能需要利用資料來驗證這些需求了。

   比如說，有時候一個使用者說，你們這個網頁打不開啊！產品經理就是個垃圾。

   這個時候我們可以自己使用下，看下問題是否能復現，如果不能的話。再看下這個頁面的退出率是否存在異常，如果沒有，這個問題也可能是網路、裝置等原因引起的。

2. 公司層面 面對高層需求，從資料入手，驗證觀點，並提供合理化建議。

   高層的需求通常是基於公司戰略目標提出來的，這個目標可能會與使用者體驗有一些衝突，這個時候產品經理就可以利用資料來驗證並提供合理化建立。

4.1.1 產品設計階段

1. 設計前 通過資料分析發現問題，確定行之有效的量化標準。

   比如：網站首頁的改版，可以看到各個模組的點選率，轉化率等。看下是否需要調整模組的位置。

2. 設計中 輔助決策，判斷思路

   比如：我們在購物網站中，優惠券的有效時間設定多長比較合適了？1小時？12小時？1天？3天？

   這個時候其實就可以利用資料來分析下使用者之前使用優惠券的時間分佈圖，最後確定時間的長度。另外還可以使用A/B Test來測試。

3. 設計後 這個階段主要是資料來驗證方案是否符合預期。

4.2 資料驅動產品的方法

資料驅動產品最重要的保持資料驅動產品的思維方式（具體見下圖），可以看出，利用資料，產品可以不斷的進行優化。

4.3 如何培養資料分析的能力

首先我們有一個好奇的心，保持自己的求知慾望。這些是引領我們前進的內在動力。我們在生活中就可以發現很多資料，如果我們有足夠好奇心的話，其實可以發現很多有趣的問題的。

比如，分析在春節時候的自己朋友圈轉發文章的閱讀數、點贊數等一些資料。你會發現哪些文章的轉發率高，自己朋友圈的一些特徵等。

其次我們要有正確的資料驅動產品的思維方式。

然後我們要非常熟悉我們所在產品的業務，我們要重視資料，儲存對資料的敏感程度。