一款資訊流APP平時日活穩定在79w-80w之間，但是在6月13日起突然掉到了78.8w，到6月15日已經掉到78.5w，這時產品負責人著急了，讓你儘快排查一下資料下跌的原因。這樣的問題對大多數人來說還是比較頭疼的，因為對於80w量級的產品，一兩萬並不是一個非常大的波動，但原因還是要排查。

拿到這個問題，會覺得不知道從哪點著手開始分析？沒關係，我們把常用套路捋清楚了，然後回頭再看這個案例。

核心點：先做資料異常原因的假設，後用資料驗證假設。不建議大家第一步先自己對著資料去拆，影響日活資料的因素很多，不可能把所有維度逐一拆解對比，容易浪費時間卻沒有任何有價值的發現。做資料異常原因分析的核心就是結合以往經驗及各種資訊，找出最有可能的原因假設，透過資料的拆分進行多維度分析來驗證假設，定位問題所在。過程中可能會在原假設基礎上建立新的假設或者是調整原來假設，直到定位原因。

第一步：確認資料真實性在開始著手分析前，建議先確認資料的真實性。我們經常會遇到資料服務、資料上報、資料統計上的BUG，在資料報表上就會出現異常值。所以，找資料流相關的產品和研發確認下資料的真實性吧。

第二步：根據幾個常見維度初步拆分資料計算影響係數：每一項資料都要和以往正常值做對比，算出影響係數。

影響係數=(今日量-昨日量)/(今日總量-昨日總量)

影響係數越大，說明此處就是主要的下降點以上是幾種常見的初步拆分維度，透過初步拆分，定位原因大致範圍。

第三步：異常範圍定位後，進一步做假設針對初步定位的影響範圍，進行進一步的排查。

分三個維度來做假設，建議針對資料異常問題專門建一個群，拉上相應的產品、技術、運營人員一起，瞭解資料異常時間點附近做了什麼產品、運營、技術側調整。綜合考慮以往資料異常原因、產品運營技術側調整、初步定位的影響範圍最可能由什麼原因造成，再結合自身業務經驗確定幾個最可能的原因假設，給這些假設排資料驗證的優先順序，逐一排查。最後：細分假設，確立原因除了上述，可以細分分析的維度實在太多，邏輯上說核心點在於一個假設得到驗證後，在這個假設為真的基礎上，進行更細維度的資料拆分。

當猜測是某種原因造成資料異常時，只要找到該原因所代表的細分對立面做對比，就可以證明或證偽我們的猜測，直到最後找到真正原因。

新使用者=渠道1+渠道2+渠道3+其他渠道 ，於是我們把新使用者日活按渠道進行拆分：透過渠道拆分，我們發現渠道3自6月13日起新使用者下降嚴重，於是我們把問題定位在渠道3，應該是渠道3的渠道效果發生問題。聯絡渠道3的負責人一起定位具體原因，渠道線索量降低？渠道轉化率降低？渠道平臺的問題？找出原因後，再針對原因解決問題，制定渠道最佳化策略。最後要說的至此本篇文章已到尾聲，詳細敘述了核心資料異常的分析套路以及講了一個易於大家理解的小案例，相信大家下次再遇到這類問題，至少有一個明確的著手點。

還有一些想對大家說的是：為了方便大家理解，這個小案例的資料是我虛構的，問題定位過程也比較簡單。但是在實際業務中，資料異常的影響原因可能是多方面的（本篇只講到了一些內部因素，外部環境和競對其實也會影響核心資料），有的時候也需要建立統計分析模型來做一些定量分析。可能要花幾天的時間去不斷排查問題，這個過程繁瑣且枯燥，假設驗證失敗可能會有挫敗感，或許忙活了很久但是最後並沒有找出原因。其實這是很正常的事情，資料異常分析甚至對於一個資深資料分析師都是一個令人頭疼的問題。所以我們需要在平時工作中多留意資料變化，隨著對業務的熟悉和資料敏感度的提升，針對資料異常分析我們也會越來越熟練，更快找到問題所在。

先做資料透視（可以增加UGC數量、PVUV資料等維度），按照日期標記：產品更新、活動節點、事故/事件、競品動作等。