作為產(chǎn)品經(jīng)理，關(guān)注數(shù)據(jù)是一項基本工作。工作里常常會出現(xiàn)關(guān)注的指標(biāo)或數(shù)據(jù)出現(xiàn)波動，或者在分析某個功能時發(fā)現(xiàn)難以理解的數(shù)據(jù)的情況，這時候我們需要去分析數(shù)據(jù)波動的原因，而我也和大家分享一下我的分析思路。

1. 確認(rèn)數(shù)據(jù)源準(zhǔn)確性

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

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

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

一般有以下幾個常見的因素會導(dǎo)致數(shù)據(jù)源準(zhǔn)確性問題：

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

2. 維度下鉆分析

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

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

比如說我們通過新/老用戶區(qū)分分析發(fā)現(xiàn)新用戶進入該頁面UV出現(xiàn)了顯著下降，而老用戶較為穩(wěn)定，則可以猜測是新用戶的引導(dǎo)方面出現(xiàn)了問題。

3. 抓住重要節(jié)點

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

無論是維度下鉆或是抓住重要節(jié)點，本質(zhì)上其實是通過對比找到問題。不同時間段的縱向?qū)Ρ?，不同用戶群體的對比，同業(yè)務(wù)線不同產(chǎn)品數(shù)據(jù)對比，都是我們快速定位數(shù)據(jù)問題的利器。

4. 持續(xù)性緩慢變化

最難的一種數(shù)據(jù)問題是緩慢變化的數(shù)據(jù)，即數(shù)據(jù)沒變化沒有明顯的時間節(jié)點。這種問題是最難定位的。出現(xiàn)這種情況時，需要考慮一些隨著時間改變會逐漸優(yōu)化/惡化的因素。

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

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

5. 不要想當(dāng)然，不放過任何細(xì)節(jié)

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

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

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

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

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

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

本文由 @kakarotto 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議