那麼，今天我們來捋清楚思路，以“某APP的日活有所下降”，該如何著手分析呢？

實際上因為資料來源出問題，導致的指標異常非常非常多，所以在開始著手分析前，必須首先確認資料的真實性。經常會遇到伺服器異常、資料後臺統計出現錯誤、在資料報表上出現異常值。所以，遇到問題第一順位先確認資料沒有錯，找資料統計相關的產品和開發確認下資料的真實性。

第二步：瞭解清楚資料指標（app日活）具體業務情況和異常情況。明確以下問題：

①明確日活究竟下跌了多少？持續的時間是多久？

②相比昨天、上週都分別跌了多少？（同比、環比）

④引起日活下跌的因素有哪些？這些因素分別對日活的影響程度有多大？

⑤與這些因素相關的運營以及產品部門對日活的影響程度有多大？

⑥這些部門是不是會因為產品迭代或者運營策略得到改變影響日活？

⑦確認日活下跌對整體產品業務線的KPI影響程度?

⑨以前日活下跌後，都採取過哪些措施？

清楚了資料指標（APP日活）的具體情況，有了輕重緩急的判斷，下一步就可以進行指標的拆解，再縮小懷疑範圍，建立分析假設。而建立假設，有助於去偽存真的進行驗證，進一步逼近真實原因。

第三步：將資料指標進行拆解。如：日活=新增使用者+老使用者留存+流失使用者迴流，二級指標拆解如下

②可拆解老使用者留存渠道：華為、vivo應用商店等

④可拆解新老使用者使用者的地區：天津、北京等

⑤可拆解新老使用者使用版本：新老版本

⑥可拆解新老使用者活躍時間：節假日、週期性等

⑦可拆解流失使用者：自然迴流， 回訪干預迴流等

可分別計算每個維度下不同的活躍使用者數。透過這種方法定位到導致哪個區域或者渠道的日活下降的使用者群體是誰，以及定位原因有了大致範圍。比如定位是新使用者問題，我們需要再把新使用者日活按渠道進行拆分：新使用者=渠道1+渠道2+渠道3+其他渠道；透過渠道拆分，我們會發現是具體哪個渠道效果發生的問題。那麼，繼續下一步我們要根據實際業務進一步做假設，具體情況具體分析。

第四步：異常範圍定位後，要根據業務進一步做假設，實際具體情況具體分析。具體分析可以採用“內部-外部”事件因素考慮。

▶內部-外部事件在一定時間內同時發生可能很多種，主要關注資料指標的起點、拐點、終點。

資料指標起點：資料指標剛下跌時，發生了什麼事件；往往起點事件是問題發生的直接原因。

資料指標拐點：在指標持續下跌過程中，是否某個事件的出現，讓問題變得更嚴重，或者開始轉暖。拐點意味著，這是可以透過運營手段改善指標的。

資料指標終點：當某個事件結束後，指標恢復正常。或當開始某個事件後，指標下跌結束。終點事件的兩種形態，代表著兩種改善指標的方法：等問題自己過去，或者主動出擊解決問題

▶內部事件因素分為獲取使用者（渠道轉化率降低、渠道平臺的問題等）、滿足使用者需求（新功能變更等引起某類使用者不滿）、促活運營手段（簽到等提活手段沒達成目標、產品自然使用週期低導致上次獲得的大量使用者短期內不需要再使用等）、內部功能和運營策略調整（產品、運營、技術在資料異常時間點附近做了什麼策略調整）。

▶外部事件因素採用PEST分析（宏觀經濟環境分析），政治（政策影響）、經濟（短期內主要是競爭環境，如對競爭對手的活動）、社會（輿論壓力、使用者生活方式變化、消費心理變化、價值觀變化等偏好變化）、技術（創新解決方案的出現、分銷渠道變化等）。

我們遵循短期變化找內因，長期異動找外因。在條件允許範圍內，再結合自身業務經驗確定幾個最可能的原因假設，給這些假設排資料驗證的優先順序，逐一排查，深入分析，比如本次指標下跌是因為新功能不符合預期不給力、渠道投放力度不夠、競品太厲害、版本更新大bug、流失嚴重等。

第五步：預測未來是否還會下跌？應該採取什麼方式避免下跌？與業務溝通反饋分析結論，探討後續方案的執行。再針對原因解決問題，制定最佳化策略。最後，我們要預測影響到什麼時間。並運營、產品溝通反饋分析結論，探討後續方案的執行。

以上，就是梳理的“資料指標出現異常波動時，該如何著手資料異常分析？”的思路框架，現在總結一下。

第二步：瞭解清楚資料指標具體業務情況和異常情況

第三步：將資料指標進行拆解。

第四步：異常範圍定位後，要根據業務進一步做假設，實際具體情況具體分析。

第五步：預測未來是否還會下跌？應該採取什麼方式避免下跌？與業務溝通反饋分析結論，探討後續方案的執行。再針對原因解決問題，制定最佳化策略。

總之，在實際業務中，資料異常的影響原因可能是多方面的，有的時候也需要建立統計分析模型來做一些定量分析。可能要花幾天的時間去不斷排查問題。

所以我們需要在平時工作中多留意資料變化，隨著對業務的熟悉和資料敏感度的提升，針對資料異常分析我們也會越來越熟練，更快的找到問題所在。