前言

上一篇文章中，我們介紹了為什么要關注數據，在本文中我將分享具體如何做。

關注宏觀和細節

大多數人都能做到關注宏觀的數據，拿互聯網產品來說，日活，月活，流失率，NPS（凈推薦值），這些都是宏觀的數據。宏觀數據能夠反映出產品的整體狀況，是值得長期關注的。

但是在宏觀之外，我們還應該關注一些細節的數據。拿日活來說，我們可以再進一步進行分析，比如：

日活中新用戶所占的比例

日活中 iOS 和 Android 的各自占比

日活中大家集中活躍的時間段

日活中用戶的會話（Session）次數分布，時長分布

日活中用戶平均使用你的產品核心功能的次數

當你把數據拿放大鏡看得更細的時候，你可能就會發現一些問題。帶著這些問題，你進一步分析，就可以找到更多信息。

舉一個我們創業產品小猿搜題的例子，我們發現日活中的用戶，有相當一部分用戶只是注冊了，但是并沒有使用我們產品的核心功能，于是我們擔心會不會有一些付費推廣渠道「刷量」。

所以，我們將新增用戶中不活躍的比例按渠道來劃分。通過這樣的劃分，我們很容易找到那些效果差的渠道，從而選擇更有效的推廣渠道。

關注原始數據

原始數據是什么？就是那些不是通過別的數據計算出來的，不能被分割的數據。這些數據是最最真實的，而其它通過計算出來的數據，因為進行了二次加工，所以不一定能夠完全反映出產品的問題。

再舉一個小猿搜題的例子，我們為了研究 NPS 給我們打零分的用戶。把這些用戶的搜索數據、操作記錄都抽樣出來，一個用戶一個用戶看，然后進行分類整理。最終我們發現這里面小學生用戶占比很高，從而調整了產品的策略，在內容和算法上對小學生進行了兼顧。

關注原始數據除了能改進產品外，還能在技術上提高代碼的質量。我們曾經遇到過一個很難復雜的 Bug，在我們的測試機中都無法復現，但是我們通過分析相關用戶的操作記錄，找到了具體崩潰的操作方法。

雖然該操作方法不能在我們自己的機器上復現 Bug，但是我們卻能找到相關的關鍵代碼。通過一些針對這些代碼的討論，我們就找到了 Bug 的原因。現在回想起來，如果沒有這些原始數據，要修復這個 Bug 就要困難很多了。

關于面試

其實不光做產品要看「原始數據」，面試一個人也是。我在面試的時候，會選一個候選人簡歷上的事情，進行深入了解。我會讓他提供詳細相關工作的數據和事例。通過這些「原始數據」，我能夠更加方便地「還原他真實的工作場景」，從而對他的工作質量作出盡量客觀的評價。

舉個例子，有一個產品實習生候選人在簡歷上寫他運營了一個微信公眾號，「粉絲逾千，單日粉絲增量 200 以上，數篇文章閱讀量超過 3000」。但是在面試中，詳細追問這些數字，我們才發現他說的「逾千」是指 1000，而「單日粉絲增量 200 以上」是指的最高的一天，其它信息也都是有夸大的成分。

還有一次，我面試一個技術候選人，這個候選人說他有代碼潔癖，覺得前公司的代碼「很亂，受不了」。但是我讓他具體舉幾個例子的時候，他卻很難說出實際的例子。還有候選人說他喜歡看技術書，但是卻無法說出他印象最深的一本技術書以及其中的部分觀點。

通過了解細節，我們就可以揭開簡歷中光鮮描述的外衣，了解到事情背后的細節，這對我們評價候選人至關重要。

數據可視化

數據可視化是指將原本枯燥的數據，用折線圖、餅圖、柱狀圖等方式呈現出來，它可以使我們更容易發現數據的規律，也更容易發現數據的異常。

在小猿搜題項目中，數據可視化多次給我們帶來巨大的幫助，包括：

了解數據的特點：我們將小猿搜題的 QPS 按每小時為頻率畫出成一條折線圖，所以我們很容易知道我們服務器高峰期的時間段以及訪問量。

發現服務異常：我們將服務器搜索的失敗率占比畫出成一個餅圖，有一天，這個餅圖中顯示出失敗率突然變高了。同時，每日的 NPS 分數突然也變低了很多。我們借此發現了新擴容的一臺服務器故障。因為那臺服務器是新加的，所以運維忘記了增加監控，如果沒有數據可視化的幫助，這個故障可能會持續更長時間。

監控核心質量：我們將小猿搜題的一些核心指標畫成折線圖，然后大家都努力讓核心指標更優。

發現惡意攻擊：一些重要指標，我們都會可視化出來，這樣當這些數據指標變化時，我們就會進一步分析原因，從中我們還發現了一些競爭對手惡意的攻擊行為。

數據可視化工具

我們當然不可能所有的數據可視化都是自己手工用 Excel、Numbers 之類的工具來生成。所以，我們開發了一個數據可視化的平臺，我們把它叫做 flyboard。

flyboard 提供了各種數據可視化的方式，包括數字，折線圖，餅圖，環形圖，柱狀圖等。如下圖所示：

我們將所有的原始數據都歸集到分布式存儲Hbase中，然后通過配置一些定時的計算任務，就可以以幾乎實時地方式，看到產品的各項可視化指標。

這些指標，有宏觀的，也有一些比較細分的，如果我們對某項指標的數值有疑問，我們就會進一步寫一些分析腳本，來從 Hbase 中計算一些數據進行檢查。

在猿題庫公司，我們的三個產品（猿題庫、小猿搜題、猿輔導）的辦公區域，都掛著一個巨大的顯示器，這個顯示器除了用于 Scrum 的每日站會同步進度外，平時都用 flyboard 顯示著產品的各項核心數據。

悄悄告訴你一個秘密，我們的 flyboard 可視化平臺是開源的，項目地址是：https://github.com/yuantiku/flyboard，在 Github 上你可以下載到完整的代碼，我們也附有完整的安裝使用說明文檔。如果你還沒有使用任何數據可視化工具，歡迎嘗試一下 flyboard。

學習寫 SQL

由于有Hadoop、Hbase、Hive的存在，產品經理也可以通過一些簡單的 SQL 語句，就可以生成MapReduce任務，進行分布式的數據分析運算。

所以數據分析最最常用的辦法就是寫 SQL。在很多公司，產品經理都在這方面能力比較欠缺，這使得產品經理在需要數據時，需要向技術提需求。技術會根據自己的工作排期。這樣一來一回，一般一個簡單的數據分析都需要一天時間。

這樣的低效率的方式，會扼殺產品經理的一些數據分析需求，特別是那種需要探索式發現的數據分析工作。因為這種工作需要不停地根據數據分析的結果，調整各種策略來寫嘗試的 SQL。

所以在猿題庫，我們希望產品經理都能有基本的數據分析能力，一些簡單的 SQL 都是需要自己能夠寫的。當然，一些特別復雜的 SQL，產品經理可能還是需要向技術同事咨詢。

具體如何寫 SQL，市面上已經有非常多的相關書籍了，我在這里就不再展開介紹了。

數據查看和分析一定要方便

如果你仔細觀察就會發現，很多革命性的產品就只是讓某件事情更方便了一點點。智能手機其實只是讓你上網更方便了一點，但是這種方便使得人們從以前有「離線和在線」的狀態，變成了永久在線。于是，移動互聯網誕生了，本質上來說，移動互聯網就是一種人們永久在線的網絡，但是就是這么一點點的方便，使得很多行業被完全顛覆。

而數據分析也是一樣，我們應該盡量讓數據觸手可得，這樣我們才能將數據分析的效率最大化，一定程度上的效率提升就會產生質變，使得我們專注于數據做更多事情。

我們之前移動端統計用 Flurry，但是 Flurry 在中國實在太慢了，即使掛上國外的 VPN 也很慢！如果產品經理每次登錄 Flurry 要 10 秒鐘的話，那么他就可能將注意力臨時轉移到別的事情上，然后就可能忘記本來要看的數據。

為了讓數據觸手可得，我們放棄了對 Flurry 的使用，我們自己開發了日志收集平臺，然后自己寫日志計算程序，將一些核心指標全部自己計算在 flyboard 上，我們也另外開發了一套數據分析平臺，實現 Flurry 中的類似功能。現在，我們已經能夠非常舒服地分析數據了。

所以，如果你的公司不能很方便的查看和分析數據，那么一定要想辦法改進，這些數據就像人的神經系統一樣，傳遞著產品的健康數據，重視這些數據，才能夠做好產品。

總結

總結一下本文中的觀點：

重視宏觀數據和細節

關注原始數據

數據可視化

學會用 SQL

數據查看和分析一定要方便

作者：唐巧? 自由轉載-非商用-非衍生-保持署名 |Creative Commons BY-NC-ND 3.0

http://blog.devtang.com/blog/2015/09/03/how-to-monitor-data/