導讀：數據其實有很多用法，譬如定位異常問題、譬如尋找新的增長點，我們今天主要就是聊聊如何使用數據定位業務問題這個話題，希望對大家有個啟發。

產品經理在工作中大概會有三個場景需要定位異常問題：單日數據出現大幅波動，數據出現趨勢性下降，版本迭代之后數據未達預期。，我們一個個聊。

一、單日數據出現大幅波動

這個最常見，產品經理每天都需要看數據，恰恰數據每天都是波動的，這就意味著這里面有很多時候都是發生了產品經理不知道的事情，產品經理必須要從數據這個儀表盤里去尋找到波動的部分，并給出合理的解釋，從而確定是不是存在問題。

但也不是數據一波動產品經理就需要去排查，從我們的經驗來說數據一直都是波動的，它會有一個常規的波動范圍值，因業務類型和業務的發展階段不同而不同，所以只要不超出這個波動值就可以不用刻意去排查。

我先講一講這個波動值的問題，對于初創型的企業來說，業務量不大，所以波動就可能很大，我們一般是建議量級不過百的就趕緊去搞增長，量級這么小任何波動都是正常的，根本不存在分析的必要，偶然性很大的。如果量級不過千的那就先可以先根據歷史數據設一個值，但是也不要太關心這個，日常搞增長才是重點。

OK，說回這個數據波動需要排查的問題。

我們以簡化的電商業務為例，譬如說今天早上起來一看，發現昨天的成交額下降了，最近兩周的數據基本是1000萬左右，昨天下降到了800萬，出現了單日的大幅下降，這個時候就要排查了。

那怎么排查呢？

你根據業務鏈路從前往后看也行，從后往前看也行，我們分別可以講一下。

先說從前往后看。你就需要先去看新用戶注冊人數和老用戶登錄人數有沒有下降，沒有問題就去看商品詳情頁的瀏覽量有沒有下降，沒有問題再去看訂單生成量有沒有問題，沒有問題再去看訂單支付量有沒有問題。

這中間可能會有問題，譬如新增用戶少了，那可能是渠道來的用戶少了，也可能是用戶注冊頁面出了問題，這就需要具體去看，需要產品經理對這個出問題的原因有一個大概的認知。譬如訂單生成量減少了，就說明訂單模塊可能出現了問題。

也可能業務鏈路是沒有問題，這個時候就需要去看客單價的問題，因為訂單量沒有下降，成交額下降那就是客單價下降了，這就需要去看是不是出現了商品價格錯誤的問題，就要去看哪些商品價格出現了變化，從這些商品里面找異常。

有的時候如果沒有辦法知道哪些商品改過價格的話，那就非常麻煩，可能就需要一點點看了，從低價產品區開始看。

總的來說可以從單量和客單價兩個維度去看，根據拆解公式去看就行。

前面我們說的是從1000萬下降到了800萬，如果出現了從1000提高到了1300萬，這也是異常波動，需要去排查原因，并不是說提高就不需排查。

當然如果是提高的話就先去看市場推廣是不是買了更多的量或者運營是不是搞了大活動，然后再看業務鏈路。一般來說都是買量多了或者搞了活動。

還有一種情況是最麻煩的，那就是你一看業務鏈路每個環節都出現了下降，但是每個環節都下降不大，到了最終環節就出現了大幅度的下降。

這個真的是非常難受，雖然極少出現這種情況，但是一旦出現就很頭痛，你無法馬上采取措施，需要先看看后續是不是會持續出現這個問題，如果持續出現那就意味著不是一個局部的問題，而是出現了系統性的問題，就需要從獲客質量和商品推薦策略這些更復雜的維度去考察，需要花的時間和精力會多很多。

二、數據出現趨勢性下降

單日數據波動是最簡單的情況，是最容易分析的。如果出現了趨勢性下降就比較復雜了。

什么叫趨勢性下降？就是連續幾個月，每個月都小降一點，但是基本上月月降，半年搞不好就能下降30%，你從單月看降幅不大，但架不住連續下滑。

這種情況，一般來說老板就很著急上火了，都是錢啊。

趨勢性下降不會是業務鏈路的原因，一般來說需要從另一個角度去拆解。

我們還是以簡化的電商業務為例，GMV半年下降了20%，很大的降幅。

這個時候就需要去根據營收公式拆解了：

GMV=新用戶購買量×新用戶客單價+老用戶購買量×老用戶客單價=新用戶注冊人數×新用戶轉化率×(新用戶購買總金額/新用戶購買人數)+老用戶活躍人數×老用戶復購率×(老用戶購買總金額/老用戶購買人數)

從這個公式里面再去看問題是出在哪個部分，然后再去看是增加獲客量還是提示獲客質量還是激活老用戶，以及怎么提高轉化率的問題-這就涉及到各種算法推薦模型的優化；

總的來說趨勢性的下降如果產生則也意味著重新拉升回來也是緩慢的，但不是束手無策。

趨勢性下降的時候一般來說就是找原因和想對策，老板也知道下降了，他就想知道解決方案，所以這個時候的重點就是馬上做各種策略把數據拉回來。

三、版本迭代之后數據未達預期

最后一個也是最復雜的一個問題——版本迭代之后數據未達預期，這個就是最難定位了，有很多時候我們在設計方案的時候就很難說清楚提升的具體比例會是多少。

究其原因，就是我們在做版本迭代的時候就不一定有依據。有的時候是因為老板說要這么改，有的時候是競品這么改了所以這么改，有的時候是依據一些模糊的經驗和原則。

不管怎么樣，設計的時候就是模糊的，結果如何就也是無法預測的。

A/B test測試技術的出現在一定程度上規避了這個問題，在做灰度測試的時候如果數據不行就會代碼回滾。

但對于大量的小廠來說沒有條件做這個A/B test 測試，所以會出現版本迭代之后未達預期的情況。

這個時候其實非常尷尬，因為新版本已經上線了，但是數據沒有提升或者提升非常小。

原則上如果數據沒有出現下降就不回滾代碼，就在線上使用新版本就行。

最重要的是在做下次版本迭代計劃之前，盡可能的使用有數據依據的假設。

小廠的產品經理之所以在很多時候沒有一個可靠的方法論就是受限于平臺條件，無法使用更好的驗證技術。而靠經驗這個事情就永遠比不上靠技術驗證來的快。

四、最后

產品經理的主要工作就是發現問題和解決問題，所以一切可以依托和使用的工具和方法都必須用起來，而數據顯然是最直觀的工具，所以這是首先要用起來的。

當然光有數據不行，數據只是結果的呈現，怎么解釋這種結果就依賴于產品經理對業務的理解程度了，所以一個對于業務有著深刻理解的產品經理其實是非常有價值的，大家還是需要多花點時間在業務上。

希望我的分享對你有所啟發，謝謝。

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

題圖來自 pexels，基于 CC0 協議