作為產品經理，關注數據是一項基本工作。工作里常常會出現關注的指標或數據出現波動，或者在分析某個功能時發現難以理解的數據的情況，這時候我們需要去分析數據波動的原因，而我也和大家分享一下我的分析思路。

1. 確認數據源準確性

很多時候數據的問題僅僅是數據的問題。如果遇到一個數據波動或異常我們無法簡單地分析出原因時，可能就要想想是不是數據源出了問題。

數據源可能是我們的業務數據庫，如商品價格、銷售額這些數據；也可能來自用戶行為，如用戶的點擊、瀏覽等事件，這些數據源都極有可能出現問題，例如業務數據庫同步出現問題，用戶行為的采集、上報不準確等等。

有時候我們一股腦地從產品角度去分析，最后確實數據本身的問題，會做很多無用功。所以遇到一時間分析不出原因的問題，首先要考慮是不是數據源出現問題。這時候就得聯系公司的數據產品經理、前后端行為上報方、大數據的研發確認。

一般有以下幾個常見的因素會導致數據源準確性問題：

• 前端上報的事件與產品的定義不符：例如有的頁面可能會預加載，從產品的角度看，預加載是技術的處理方式，不能算是用戶的行為。但是前端往往會將預加載的事件不做區分地上報，導致數據與預期不符。
• 服務器重構/技術優化：服務器的工程師們不時會進行技術優化，這部分優化產品常常是難以感知的，同時又容易造成數據波動。例如有一次我司的Push發送量突然大增，定位問題發現是技術大大們對發送Push的服務器進行了優化，優化后目標用戶量不變，單位時間發送量（QPS）提高，導致原本在規定時段內（如20:00~22:00）沒有發完的push現在可以全量發完了。
• 大數據統計邏輯：產品使用的數據往往不是底層數據，而是大數據組研發們在底層數據基礎上進行的聚合，在這個過程中，就有可能出現定義不一致的情況。這類問題建議先與數據產品經理溝通，根據我的經驗，除非產品經理對數據側比較了解，否則直接與數據組的研發溝通，溝通效率會比較低。

2. 維度下鉆分析

要探索一個指標異常的原因，一個十分重要的工具就是維度下鉆。通過從不同維度和不同力度的下鉆，我們能夠一步一步接近問題的本質。

例如一個頁面的UV占比不斷的下跌，我們就可以從新/老用戶、頁面各個入口流量、頁面各板塊點擊等維度下鉆進行分析，定位問題。

比如說我們通過新/老用戶區分分析發現新用戶進入該頁面UV出現了顯著下降，而老用戶較為穩定，則可以猜測是新用戶的引導方面出現了問題。

3. 抓住重要節點

第三點其實也屬于第二點的一種情況，是從時間的維度去分析問題——數據通常都是會在一個時間點開始發生變動，這時候我們就得去研究這個時間點發生了什么事，是上線了新版本，還是調整了數值，或者有什么活動開始了。

無論是維度下鉆或是抓住重要節點，本質上其實是通過對比找到問題。不同時間段的縱向對比，不同用戶群體的對比，同業務線不同產品數據對比，都是我們快速定位數據問題的利器。

4. 持續性緩慢變化

最難的一種數據問題是緩慢變化的數據，即數據沒變化沒有明顯的時間節點。這種問題是最難定位的。出現這種情況時，需要考慮一些隨著時間改變會逐漸優化/惡化的因素。

例如我們公司有一次出現了一個指標長達3個月的緩慢小幅下降，大概每一周下降0.5個點，大家抓破腦袋研究很久以后，終于找到原因：我們使用了數美的一款異常用戶攔截產品，這款產品自身會根據大數據不斷優化，提高攔截準確性，攔截率會隨時間緩慢提升，從而導致我們相關指標的不斷下降。

所以這種異常會跟一些會隨時間緩慢變化的因素相關，例如推薦算法的不斷學習，用戶習慣的緩慢改變等等。

5. 不要想當然，不放過任何細節

有時候原因就在眼前，只是我們想當然地覺得不可能是它，于是視而不見。

有一次我們的產品新增留存突然下降4%左右，這算是一個非常嚴重的問題了。老板緊急召集各負責人分析人，在經過八仙過海各顯神通的集思廣益后，排除了各種原因，發現數據變化的時間點與新版本發布有關。最終找到問題所在是新包內容比舊包增加了30mb左右，用戶更新內容時會在更新頁面多等待數十秒，因為增加的這幾十秒導致敏感的新用戶流失了4%左右。

在一開始，所有人都想當然地覺得這30M的體積不會造成如此大的影響，產品團隊在排除掉幾乎所有可能的因素，才在最后定位到這個問題。

新用戶是最敏感的用戶群體，任何等待、崩潰、體驗不佳都可能導致用戶留存下降。

針對這個問題，我們升級了更新策略，使用靜默更新，即玩家進入app后如果有l更新資源，則原生就開始靜默下載新內容。同時豐富更新頁面的內容，使玩家在更新頁面不那么枯燥，降低退出率。

作者：kakarotto；公眾號：原住民的自修室

本文由 @kakarotto 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議