產品日活下降分析思路
轉載：https://mp.weixin.qq.com/s/A9reSWkOEMf5qScniXbUHg
案例：
一款信息流APP平時日活穩定在79w-80w之間，但是在6月13日起突然掉到了78.8w，到6月15日已經掉到78.5w，這時產品負責人着急了，讓你儘快排查一下數據下跌的原因。這樣的問題對大多數人來說還是比較頭疼的，因爲對於80w量級的產品，一兩萬並不是一個非常大的波動，但原因還是要排查。拿到這個問題，會覺得不知道從哪點着手開始分析？沒關係，我們把常用套路捋清楚了，然後回頭再看這個案例。
核心點：先做數據異常原因的假設，後用數據驗證假設
不建議大家第一步先自己對着數據去拆，影響日活數據的因素很多，不可能把所有維度逐一拆解對比，容易浪費時間卻沒有任何有價值的發現。
做數據異常原因分析的核心就是結合以往經驗及各種信息，找出最有可能的原因假設，通過數據的拆分進行多維度分析來驗證假設，定位問題所在。過程中可能會在原假設基礎上建立新的假設或者是調整原來假設，直到定位原因。
第一步：確認數據真實性
在開始着手分析前，建議先確認數據的真實性。我們經常會遇到數據服務、數據上報、數據統計上的BUG，在數據報表上就會出現異常值。所以，找數據流相關的產品和研發確認下數據的真實性吧。
第二步：根據幾個常見維度初步拆分數據
計算影響係數：每一項數據都要和以往正常值做對比，算出影響係數。
影響係數=(今日量-昨日量)/(今日總量-昨日總量)
影響係數越大，說明此處就是主要的下降點
以上是幾種常見的初步拆分維度，通過初步拆分，定位原因大致範圍。
第三步：異常範圍定位後，進一步做假設
針對初步定位的影響範圍，進行進一步的排查。分三個維度來做假設，建議針對數據異常問題專門建一個羣，拉上相應的產品、技術、運營人員一起，瞭解數據異常時間點附近做了什麼產品、運營、技術側調整。
綜合考慮以往數據異常原因、產品運營技術側調整、初步定位的影響範圍最可能由什麼原因造成，再結合自身業務經驗確定幾個最可能的原因假設，給這些假設排數據驗證的優先級，逐一排查。
最後：細分假設，確立原因
除了上述，可以細分分析的維度實在太多，邏輯上說核心點在於一個假設得到驗證後，在這個假設爲真的基礎上，進行更細維度的數據拆分。我們需要記住這種分析方式，當猜測是某種原因造成數據異常時，只要找到該原因所代表的細分對立面做對比，就可以證明或證僞我們的猜測，直到最後找到真正原因。
案例分析
以上就是核心數據異常的分析套路，是不是剛纔拿到問題還不知道從哪開始分析，現在覺得其實有很多點可以去着手？讓我們回到剛纔的案例吧。根據上述套路，首先我們拆分新老用戶活躍量，如下圖（老用戶左軸、新用戶右軸）：
發現老用戶日活較平穩，但是新用戶自6月13日下降嚴重，於是計算新老用戶影響係數：
老用戶影響係數=(77.89-78)/(78.8-79.5)=0.16
新用戶影響係數=(0.98-1.5)/(78.8-79.5)=0.84
新用戶影響係數0.84，說明DAU下降是出在新用戶身上，明確範圍後進一部細分，新用戶由什麼構成？
新用戶=渠道1+渠道2+渠道3+其他渠道 ，於是我們把新用戶日活按渠道進行拆分：
通過渠道拆分，我們發現渠道3自6月13日起新用戶下降嚴重，於是我們把問題定位在渠道3，應該是渠道3的渠道效果發生問題。聯繫渠道3的負責人一起定位具體原因，渠道線索量降低？渠道轉化率降低？渠道平臺的問題？找出原因後，再針對原因解決問題，制定渠道優化策略。
最後要說的
至此本篇文章已到尾聲，詳細敘述了核心數據異常的分析套路以及講了一個易於大家理解的小案例，相信大家下次再遇到這類問題，至少有一個明確的着手點。還有一些想對大家說的是：
爲了方便大家理解，這個小案例的數據是我虛構的，問題定位過程也比較簡單。但是在實際業務中，數據異常的影響原因可能是多方面的（本篇只講到了一些內部因素，外部環境和競對其實也會影響核心數據），有的時候也需要建立統計分析模型來做一些定量分析。可能要花幾天的時間去不斷排查問題，這個過程繁瑣且枯燥，假設驗證失敗可能會有挫敗感，或許忙活了很久但是最後並沒有找出原因。其實這是很正常的事情，數據異常分析甚至對於一個資深數據分析師都是一個令人頭疼的問題。所以我們需要在平時工作中多留意數據變化，隨着對業務的熟悉和數據敏感度的提升，針對數據異常分析我們也會越來越熟練，更快找到問題所在。
原文鏈接：https://mp.weixin.qq.com/s/A9reSWkOEMf5qScniXbUHg