你會不會正在做無意義的數據分析？

并沒有符合你的預期，活躍度？

假設活躍度的口徑，是用戶當天用過登錄app的記錄

問題1、登錄app的用戶真的就算是活躍了嗎？

問題2、后臺記錄的登錄條件上是否有限制？push頁進來的也算登錄嗎，還是一定要首頁進來的？

問題3、統計量下的活躍用戶真的是有價值的客戶，可以為后續的轉化提供基礎，沒有噪聲用戶的嗎？

一、關于預警指標初認識

1、常用的用戶數據指標有哪些？

理解“日活/月活度數據指標”-使用場景

到底活躍對我們意味著什么？

活躍用戶，是相對于“流失用戶”的一個概念，是指那些會時不時地光顧下app，并為app業務帶來一些價值的用戶。

活躍用戶是一個公司講故事的資本。針對的是小型的，有融資需求的公司，如果一個公司有百萬以上的日活用戶，即使沒有盈利，依然會受到投資人的青睞，變現是小事，有沒有用戶使用才是大事?，F在產品的變現方式已經很成熟，有百萬用戶的產品通過接入廣告，也可以獲得一些收益。

在用戶活躍分析的時候，不是為了逼用戶天天來戳一下，而是為付費、或者其他轉化提供穩定的支持，那么選擇活躍度指標時需要考量公司的業務目標。

理解“日活/月活度數據指標”-日和月的定義

日：一般我們指一個自然日，即0:00–24:00

月：上個月的1號0點-當月最后一天的23點59分

月活躍用戶的計算邏輯是什么？

A、每一天的活躍用戶的累加（或者取平均值）

B、這個月所有活躍用戶去重的總數

理解“日活/月活度數據指標”--活躍的定義

活躍度的幾種口徑

A、檢測到用戶的登錄信息（一些強登錄的app，例如網銀、網游）

B、指定多個頁面的埋點數據上報

C、通過后臺帶用戶信息或者用戶ip的請求信息（無賬號APP）

D、停留指定頁面超過一定時長

理解“用戶日活/月活度數據指標”--活躍的定義

理解“增量數據指標”--新增用戶的使用場景

對“新增用戶”的定義實際上是通過用戶新增的后續行為進行一個簡單的用戶分層，滿足當前運營階段的“關鍵指標”的用戶作為有效新增用戶，也是后續運營的重點用戶。

在定義好“新增用戶”的指標后，拉新行為也就并不是只看重下載和打開，而是圍繞核心指標進行優化，例如以注冊為指標，需要通過觀察用戶的注冊行為路徑優化注冊流程體驗。

理解“增量數據指標”--新增用戶的定義

在目前的“新增用戶”的定義中，總的來說，可以分為兩種方式：

一種方式為一段時間內打開應用的新用戶數量，這是廣義的新增用戶。

另一種方式為一段時間內產生過“關鍵行為”的新用戶數量，比如：注冊賬號，激活賬戶，而對于增長黑客而言，則更關注第二種“新增用戶”。

理解“留存率”--留存率的使用場景

用戶留存率是驗證產品用戶吸引力很重要的指標。通?？梢岳糜脩袅舸媛逝c競品進行對比，衡量應用對用戶的吸引力。對于某一個相對成熟版本的應用，如果用戶留存率有明顯變化，則說明用戶質量有明顯變化，很可能是因為推廣渠道質量的變化所引起的。

理解“增量數據指標”--新增用戶的使用場景

對“新增用戶”的定義實際上是通過用戶新增的后續行為進行一個簡單的用戶分層，滿足當前運營階段的“關鍵指標”的用戶作為有效新增用戶，也是后續運營的重點用戶。

在定義好“新增用戶”的指標后，拉新行為也就并不是只看重下載和打開，而是圍繞核心指標進行優化，例如以注冊為指標，需要通過觀察用戶的注冊行為路徑優化注冊流程體驗。

理解“增量數據指標”--新增用戶的定義

在目前的“新增用戶”的定義中，總的來說，可以分為兩種方式：

一種方式為一段時間內打開應用的新用戶數量，這是廣義的新增用戶。

另一種方式為一段時間內產生過“關鍵行為”的新用戶數量，比如：注冊賬號，激活賬戶，而對于增長黑客而言，則更關注第二種“新增用戶”。

理解“留存率”--留存率的使用場景

用戶留存率是驗證產品用戶吸引力很重要的指標。通?？梢岳糜脩袅舸媛逝c競品進行對比，衡量應用對用戶的吸引力。對于某一個相對成熟版本的應用，如果用戶留存率有明顯變化，則說明用戶質量有明顯變化，很可能是因為推廣渠道質量的變化所引起的。

理解“留存率”--留存率的含義

留存指的是：一批新增用戶中，在指定的時間段內，沒有卸載的用戶（app場景）。

新增賬號第X日：某日新增的賬號中，在新增日后第X日有登錄行為記為留存

新增賬號X日內：某日新增的賬號中，在新增日后的X日內有登錄行為記為留存

活躍賬號第X日：某日活躍的賬號中，在新增日后第X日有登錄行為記為留存

活躍賬號X日內：某日活躍的賬號中，在新增日后的X日內有登錄行為記為留存

其他的基礎指標的定義

2、哪些指標需要做指標預警

A.指標跟業務掛鉤?？梢宰鲋笜说淖兞亢芏?，但是可以拿來做預警的卻不多，選擇直接跟指標掛鉤的。例如電商，直接就是銷售量，接口就是調用次數，產品就是環節轉化，運營就是用戶增長量

B.避免預警指標過剩，造成指標預警不重視，你設定報警的指標，一定是要真的很嚴重，你才能推送的那種，不要設置不嚴重的，但是造成郵件泛濫，沒人理會預警就得不償失了。

C.預警指標需要做重要性排序，先實現會經常出現異常導致你經常加班分析的指標，先實現在業務層面的重要指標，預警指標推送時間不要擠在一起，不然你同時接受多個預警，你不會仔細去看，而且要是都是異常的話，一下子那么多異常出來，你會心慌，那么分析思路就不那么清晰了。

3、指標預警的大類

接口類的數據指標預警（主要用于it部門監控接口或者平臺功能穩定），模型準確率

產品類指標的數據指標預警（主要是產品部門用于監控產品功能的轉化，產品的訪問之類的）

運營類指標的數據預警（主要是運營部門用于監控用戶的信息，例如用戶的激增，或者用戶的大幅度訪問下降。）

二、指標構建方法

1、比率占比法

其實就是看各個區間的占比是否跟之前的比較接近，但是這里需要注意的是，不要把“之前”拉的太長，一般是最近7天或者最近3天就可以了。那么這個時段之前的占比（或數據量），這個占比有以下幾種方法可以參考：

A.就是計算過去幾天的每個時段的平均占比（或數據量）。

B.過去7天，按照距離的時間越長，那么權重變少，例如最近往前推一天是0.5，最近往前推二天是0.3，這樣子的權重計算。

C.就是只用過去一天的數據做對比，但是這個不太實際，不過也要看你的業務是怎樣的。

2、統計方法

A.時間序列分析。數據量在時間序列上是可以有規律可以遵循的，所以可以利用時間序列分析的方法，預測當天的數據量，若實際與預測的數據量作差值，相差太多則觸發指標預警推送。（這種方法不推薦，在理論上可以過得去，但是實際的運用其實相對復雜并且效果也不一定好）

B.相關系數計算。第一點的占比法中，需要每個時段都去計算差別，產生的指標就會多，一旦這種數據量的類型多起來，就會很復雜，所以可以將這些占比列成一個向量，計算今天與之前的數據量組成的向量的相關系數的大小，當太小的時候，主動觸發預警。

3、差值&定值法

這個方法是最簡單的，這個在模型監控中常用到，其實就是將原先的模型效果與現在的模型效果做比較，或者直接計算模型KS后者auc值看是否低于某值，則預警，但是這里注意的是，這種模型的預警一般沒辦法以天為周期計算，因為模型的y值往往是有滯后性的。

4、孤立點檢測

對比以上幾個在單一維度上的方法，孤立點檢測是基于多維度建立的向量來觀察異常數據點的方法。

三、指標預警的方式

指標預警的方式-釘釘機器人&企業微信機器人通知

釘釘機器人還有企業微信機器人都設置了群機器人的功能，大部分的開發會拿來檢測任務是否正常運行，或者定時任務是否完成運行的提醒，所以你也可以拿來作為你的指標預警推送，網上都有響應的教程可以作為參考，寫python即可實現。

釘釘機器人詳細介紹鏈接：

https://developers.dingtalk.com/document/app/custom-robot-access

企業微信機器人：

https://work.weixin.qq.com/api/doc/90000/90136/91770

指標預警的方式-郵件通知

當公司沒有第一點的軟件，或者機器不能鏈接外網的時候，可以借助郵件推送的方式，利用python中的smtplib包實現。

指標預警的方式-平臺推送

到了特地為每個分析師都開發了這個預警平臺或者自研的bi平臺可以滿足預警推送的功能化，也可以通過平臺推送，這個話可能涉及的東西相對多一些，如果你會寫接口，借助django框架寫接口之后吐給前端去幫你展示也是可以的。

五、指標預警平臺