作產品一般都離不開用戶活躍度分析，但是這個“度”我們應該如何把握呢？它是單純的一串數(shù)據(jù)或者數(shù)字嗎？我們該怎么去拆解它？

因為用戶相關的話題很多，為了便于大家閱讀，這里把各種話題做一個歸類如下圖，這樣看著清楚一些。今天我們來系統(tǒng)的分享一下：用戶活躍這個話題。

01 用戶活躍常見問題

1. 到底啥叫活躍，口徑不統(tǒng)一

用戶注冊、付費是很明確的動作，一般不會認錯，但“活躍”到底是個啥，往往眾說紛紜，比如：

• 登錄成功就算活躍？
• 登錄了點擊幾下算活躍？
• 登錄完成一個特殊動作？

當然，針對不同目標、不同業(yè)務，可以有不同定義。但使用這些定義的前提是口徑統(tǒng)一，各個部門得達成共識：有XXX行為的就算活躍了。

而最常見的問題，就是不但沒統(tǒng)一口徑，而且還不斷發(fā)明新名詞，搞得歷史數(shù)據(jù)前后對不上。最后開起會來雞同鴨講。

2. 陷入細節(jié)，糾結每一天波動

看過活躍率、活躍人數(shù)指標的同學都知道，這玩意日常波動太多了，幾乎大事小事都會對活躍率產生影響。

有時間分析活躍率下跌的報告還沒交，丫自己就漲回來了。結果每天糾結于“為啥又高了/低了1%！”累死自己，還沒找到病根。

3. 孤立看問題，砸錢搞活躍

雖然活躍率為啥跌不一定清楚，但是怎么搞活躍率，那套路可太清楚了。登錄7天簽到送福利、30天連續(xù)簽到送福利、登錄就抽獎最高888、種樹20天送一袋獼猴桃……

于是，往往還沒找到病因，短期拉指標的措施已經懟上去了。

結果按下葫蘆浮起瓢。活躍率做高了，轉化率跌了，轉化率做起來了，費用燒干了……

注冊、活躍、付費這些指標從來都不能割裂開看，就像我們評論人的身材，是三圍一起報。要不然，你想要一個36D的女朋友，推薦個36-48-52身材的你要不要？不但得要，還得幸福哦。

02 用戶活躍分析核心問題

陳老師總是舉例，做數(shù)據(jù)的不懂業(yè)務會導致各種問題。可在用戶活躍分析中，恰恰是做業(yè)務的不懂數(shù)據(jù)，才導致上述亂象。

運營沒有深入思考過活躍指標的含義，也沒有分析過活躍指標與注冊、付費、轉化關聯(lián)。只是單純因為“這是我的KPI”，就產生：“KPI指標下跌綜合癥”：不等分析清楚就急不可耐的下手了，最后總是治標不治本，還折騰人。

想破局，先解決一個核心問題：到底活躍對我們意味著什么？

除了類似陰陽師、DOTA傳奇這種很肝的游戲以外，其他的大量互聯(lián)網(wǎng)應用，真的需要用戶天天守在這？除了微信這種超級應用，真的有另一個應用是用戶無可替代每天一看的？（如下圖所示）

從本質上看，互聯(lián)網(wǎng)應用講用戶活躍，就像傳統(tǒng)企業(yè)講顧客到店一樣。

• 活躍是一切的基礎，必須關注；
• 不能空活躍不轉化，得聯(lián)起來看；
• 影響因素太多，必須抓大放小，聚焦行動

在講用戶流失分析的時候，我們說過：流失分析的目的不是消滅流失率，而是把流失控制在可控范圍內。在用戶活躍分析的時候，道理類似：做活躍分析，不是為了逼用戶天天來戳一下，而是為付費、轉介紹提供穩(wěn)定的支持。

03 用戶活躍分析基本思路

1. 定標準：目前業(yè)務需要什么樣新增、活躍、付費結構
2. 找規(guī)律：常規(guī)的活躍走勢，該是什么樣
3. 查異常：區(qū)分常規(guī)變化、異常變化
4. 追原因：對異常變化進行追蹤，分析
5. 定計劃：根據(jù)問題輕重緩急，制定應對

最重要的當然是定標準。作為業(yè)務方，心理要有判斷：我需要多少活躍用戶，需要多少活躍率；并且不能割裂看一個指標，要關注AARRR的整體形態(tài)。

1. 定標準的常用辦法

定標準主要參考三點：

1. 業(yè)務特征：不同業(yè)務，本身需要的活躍用戶數(shù)和活躍率就不一樣。
2. 發(fā)展階段：一般新上線更傾向于聚集人（做大DAU），到一定程度才做付費轉化。
3. 競爭策略：策略不同，意味著對活躍、付費的要求不同。

比如最基礎的三大策略（如下圖所示）：

請注意，競爭策略才是定標準的核心。比如傳統(tǒng)觀點認為金融服務是低頻業(yè)務，可做金融APP時，完全可以把財經新聞、理財教育、本地吃喝攻略、電影信息這些和消費有關的東西做進去，把一個低頻應用做成高頻應用。

因此，一般同類業(yè)務特征和發(fā)展階段只是參考。更重要的，是業(yè)務內心的聲音：“我們要做成一款XXX的應用，相比之市場上的產品，我的目標是XXX”。

這就要求，運營需要有自身業(yè)務判斷能力，能對自己的方向有清晰的認識。數(shù)據(jù)分析師只是輔助作用，提供比如業(yè)務特征、發(fā)展階段、競品數(shù)據(jù)以作參考。

這也是為什么陳老師會吐槽，活躍問題是“亂自上做”，確實有很多公司的運營沒啥想法，就知道機械完成KPI，只要數(shù)據(jù)達標就行。數(shù)據(jù)不達標，就試圖把鍋甩給數(shù)據(jù)分析師沒洞察、對手刷量了、我們費用不夠。這樣標準都不清晰，更沒法談后邊的分析了。

2. 找規(guī)律的常用辦法

規(guī)律包含三類

1. 政策規(guī)律。政策發(fā)布以后，產生的巨大反響。
2. 自然規(guī)律。全年1-12月，本身就包含了很多影響活躍的因素（如下圖所示）
3. 運營規(guī)律。常見的運營事故（商品缺貨、系統(tǒng)宕機、宣傳誤導……）運營措施（抽獎、簽到、互動游戲）都能引發(fā)活躍數(shù)據(jù)變化。

這些具體的政策、事件、運營動作，才是指標變化的本質原因。因此在分析之前，應該先大量收集內外部事件，拿著事件思考問題。而不是就數(shù)論數(shù)，說“因為過去三天漲，所以今天漲”“因為之前周五漲、所以這個周五漲”之類毫無邏輯的話。

找到一些明顯的規(guī)律后，可以用來做定性預測，根據(jù)未來要發(fā)生的時間，預計指標波動變化，也可以用來做解釋。比如發(fā)生指標波動的時候，如果有對應事件發(fā)生+對應波動形態(tài)，那八成就是規(guī)律性變化。

這樣做，可以節(jié)省大量分析時間，而不是做了一堆分析，還被吐槽為：“我早知道了”“它就是這樣的呀”。

3. 查異常的常用辦法

遭遇異常，要關注：

1. 幅度：單日波動是否足夠大
2. 持續(xù)性：是否有持續(xù)增大、持續(xù)回落的走勢
3. 規(guī)律性：是否是有規(guī)律的、計劃內的波動
4. 關聯(lián)性：關聯(lián)的注冊、付費指標是否同樣波動

注意，不是所有的波動都值得追擊，大幅度、持續(xù)性、非規(guī)律、波及其他指標的優(yōu)先處理。偶爾的波動一下很正常，但是要記錄發(fā)生時間，觀察走勢，當問題出現(xiàn)惡化時容易溯源。這樣做，不用讓數(shù)據(jù)分析師陷入無休無止的糾結里，更容易找到真正的異常問題。

4. 追原因的常用辦法

確認是異常波動，常見的形態(tài)有三種

1. 事件型：一次性的，大幅度下跌
2. 持續(xù)型：從某一節(jié)點開始，持續(xù)下跌
3. 系統(tǒng)型：自身波動小，但始終比競品差

先判斷是哪一型的問題再追原因。追原因的難度是：事件型》系統(tǒng)型》持續(xù)型的。一次發(fā)生的事件最容易查到源頭。

系統(tǒng)型差異，可以通過競品分析得到答案。持續(xù)性問題反而最糾結，有可能過著過著自己沒了，有可能是一次重大事件的余波，也有可能是深層次的問題。

需要注意，我們常說DAU=DNU+DOU（日活躍用戶=每日新用戶+每日活躍老用戶，一般新注冊用戶都直接計入活躍）往往系統(tǒng)型問題會影響DNU，在用戶注冊后T+1，T+2…T+N的時間內沒有做好引導，導致用戶不活躍甚至流失。

DOU往往與事件有關，比如季節(jié)性促銷，沉默用戶喚醒，新品上市等等。因此在追蹤原因時，可以分頭觀察。對新人關注注冊到首次付費流程，對老人打標簽，關注老人對活動的響應（如下圖所示）

5. 定計劃的常用辦法

然而并沒有這一部分，這一部分是運營的范疇，是一個業(yè)務動作，不在本篇的討論范疇。定計劃主要看運營的業(yè)務能力。作為數(shù)據(jù)分析，可以提供的支持是：

1. 判斷問題輕重緩急
2. 對緊急重要的問題，提示問題源頭
3. 對過往改善問題的方法，提供ROI分析結果支持
4. 等著運營提想法，做臨時性支持

總結

最后再強調一句：好方法是設計出來的，不是算出來的?？繑?shù)據(jù)分析只能評估過往的方法好壞，最多再預測下用戶對XX產品響應率，不能再多了。真正做好落地，還是得靠運營自己多練內功才行。

從頭看完，我們會發(fā)現(xiàn)：數(shù)據(jù)分析方法一點不神秘，更多的是：

• 大量的、細致的收集事件
• 用數(shù)據(jù)描述、評估、總結事件
• 用邏輯推演事件的影響，用數(shù)據(jù)驗證假設。

這是個很枯燥的體力活，卻是出成績的關鍵。脫離了這些細節(jié)，任何 “思維方法”“底層邏輯”“核心法則”都沒法起效。只有算命大師才是搖搖銅錢天知地知，做數(shù)據(jù)分析的人，其實和搬磚工沒啥區(qū)別。

作者：接地氣的陳老師，微信公眾號：接地氣學堂。十年資歷的數(shù)據(jù)分析師，擁有多個行業(yè)的CRM經驗。

本文由 @接地氣的陳老師 原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議