如何透過分析“活躍資料”，最佳化業務增長策略？
使用者活躍資料是運營每天必看的資料之一，當用戶被引進來，如何提升使用者活躍是運營必須思考和解決的一個問題。對使用者的活躍資料進行分析，也有益於最佳化業務增長策略，提高產品業務線的整體盈利能力。
“使用者活躍資料”是常見的資料指標，更是很多產品業務線的核心指標。當用戶“引流”效果穩定的情況下，就需要考慮“截流”的問題，使用者多久活躍一次，使用者第一次使用體驗如何，如何提升使用者活躍，怎麼讓使用者留下來（重複使用）等等。
而分析活躍資料，不是為了讓使用者每天來走個過場，掙點廣告費的，而是獲悉產品業務線的健康程度，提升付費轉化率、老客戶轉介紹等提供穩定的資料支援，實現對優質使用者進行分層運營，重點維護，且不斷最佳化以及調整業務增長策略。
然而，從本質上看，所謂的網際網路產品講使用者活躍，就像線下門店讓新老顧客到店一樣。所以，“使用者活躍資料”的影響因素太多，必須抓大放小，聚焦執行策略，更不能空談活躍，不重視轉化，促活和留存相輔相成的。透過內容、品牌、活動等各個方面的運營策略，將使用者活躍資料提升，從而提高產品業務線的整體盈利能力。
那麼，首先來看一下“活躍”的定義。（以網際網路產品為例）
下載量、新增註冊使用者等指標有很明確的指向以及定義，但“活躍使用者”可針對不同目標、不同產品生命週期、不同業務，有不同定義。比如：
……
而“活躍”合適定義標準則需要我們深刻理解使用者和業務場景，根據自身產品業務線的特徵及目標、發展階段、產品生命週期、產品屬性等作為參考，不斷調研迭代、校準資料。
接下來，02 來看一下“活躍資料”都有哪些分析維度呢？
首先，來拆解一下“活躍使用者”。
活躍使用者=新增使用者 老使用者留存 迴流使用者－流失使用者
新增使用者以及迴流使用者的數量要大於流失使用者的增加量，才能保持活躍使用者持續上升。如下圖，好比一個大水池，我們會不停的往裡灌水，但水池也會漏水，如果漏水速度太大，那麼水池就幹了。當新使用者下降可能因為市場競爭激烈、產品功能改版、投放費用減少等導致拉新乏力，流失使用者加大可能因運營策略調整、產品功能下線等因素。
然後，還需要我們繼續思考：
……
最後，還要考慮分析以下維度：
現在，我們來梳理一下如何分析“活躍資料”，最佳化業務增長策略？
透過活躍資料的走勢情況，瞭解到活躍使用者的規律。市場政策的變化，節假日、電商節等節日，常見的運營策略調整都能引發活躍資料變化。找到一些明顯的規律後，根據未來要發生的時間，預計指標波動情況，及時調整運營策略。
如下圖，可看出活躍使用者數在週末以及十一節假日呈階梯式下降，有對應事件發生以及對應波動形態，可見具有周期性規律，在週末時可調整營銷活動等運營策略，使增長趨勢平穩，但要綜合考慮產品屬性和使用者屬性。
注：為某考勤類APP十月份活躍資料趨勢圖，已做資料脫敏處理。
透過DUA同比/環比/佔比觀察，出現階梯式、持續性、非規律性等活躍波動為異常。但不是所有的異常波動都值得排查，但是要記錄發生時間，觀察走勢，當問題出現惡化時容易溯源。這就是為什麼要建立資料監控體系。
如下圖，可看出活躍使用者數在10月22日到10月24日紅框區域出現活躍異常波動，首先要了解日活究竟跌了多少，其次透過透過DUA同比/環比/佔比觀察，跌幅是否在合理的範圍，最後確定為非規律性異常。
注：為某考勤類APP十月份活躍資料趨勢圖，已做資料脫敏處理。
一般情況下，活躍資料的異常往往與事件有關，比如季節性促銷，沉默使用者喚醒以及影響活動，新功能上線等等。因此在挖掘異常原因時，可以分別對新老使用者進行觀察。對新使用者的行為路徑的各個環節的轉化進行梳理，對老使用者標籤化管理，實現不同觸達，發現問題，進而可刺激老使用者轉介紹。
透過判斷問題輕重緩急，對緊急重要的問題，找到問題的源頭，及時調整業務增長的活動以及運營策略，以提升活躍資料，預防使用者大規模流失。
最佳化完善使用者成長體系（會員體系），提升使用者活躍度，使使用者有歸屬感，不斷的最佳化使用者激勵體系，讓使用者想用我們的產品，提升活躍度。
最佳化產品功能以及流程，比如註冊流最佳化，減少一個環節，可能提升5%以上的轉化率。可利用AB測試來做驗證，不斷的最佳化產品功能等方面。
借用朋友所說的話：“從活躍使用者資料出發，制定增長策略，要注意活躍使用者內的新增、老使用者留存、迴流、流失，各個部分的比重，比重較大的部分適當的傾斜資源，比重較小的部分視成本決定取捨。”
總體來講，活躍使用者資料是業務增長形成轉介紹以及裂變的基礎，從活躍使用者資料中，針對不同使用者制定不同的營銷、推送等增長策略，實現使用者分層管理，且不斷的最佳化業務增長策略 。
另外值得注意的是，朋友如是說“要結合產品生命週期的特性，來制定活躍提升策略，例如產品生命週期較短的產品，活躍策略應側重減少流失，反之，則應側重提高留存率。”
作者：木兮，資料運營小白；公眾號：木木自由
本文由@木兮擎天＠ 原創釋出於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議