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

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

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

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

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

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

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

2. 維度下鉆分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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