起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從0到1搭建業務指標追蹤平臺
編輯導語：數據指標的異常波動分析是很多人經常會碰到的小麻煩，但這個數據指標卻關系著高層策略方向制定，業務日常的運營等方面的工作，所以一個體系化的流程和監控機制就顯得很有必要了。本篇文章中，作者詳細地講解了該搭建業務指標追蹤平臺，一起來看看吧！
一、為什么要做
數據指標的異常波動分析是數據同學經常會碰到的case，也是業務同學經常會提的分析需求。數據指標的異常追蹤，特別是核心關鍵北極星指標，關系到高層策略方向制定，業務日常的運營，可以說在時效性和準確性上非常關鍵。
業務指標的監控需要業務同學和數據同學緊密配合，但在日常的數據運營過程中，業務變化是直接導致數據異動的重要原因，經常會發現業務變化對數據同事來說存在滯后，不對稱的情況，導致數據排查異常耗費較長時間。
業務指標監控，如果沒有一個體系化的流程和監控機制，會讓參與各方都會感覺“人在囧途”，具體情況，基于互聯網金融業務場景，我們來逐個分析下：
1. 產品運營團隊
新上線了個優化的小版本，數據同學卻抱怨沒提前通知他們，數據出了異常排查時間長。
這周做了個拉新活動，原本以為新注冊用戶數會大增，沒想到帶來了一大批垃圾注冊用戶。
流量太大，放款資金承接不住，我要經常修改流控開關，一動數據就會異常報警，也不知道到底是什么原因。
2. 風控團隊
入催率升高了，到底是用戶質量變差了，還是用戶還款還不進來了，每次排查都要一兩天。
三方征信源 數據認證天天報警，也不知道對我風控通過率到底有沒影響，怎么快速排查？
3. 支付和財務團隊
還款失敗率升高了，找技術排查還是找數據排查，誰能最快給我定位原因？
是支付渠道出問題，還是資方那邊出問題？
問題定位到了，都過了一兩天了，對外溝通還要時間，用戶投訴不斷……
4. 數據團隊
指標動不動就預警，業務到底發生了什么？
為什么我總是最后一個知道真相？
數據異常，是數據問題還是業務問題？
能不能配合的默契點啊，數據業務多互通有無啊… 你們做了啥怎么不提前知會數據部？
真是人在囧途，每個團隊都覺得自己人在囧途！
二、做什么
那到底是人出了問題，還是流程問題、工具問題？
基于以上異動定位的場景，根本原因還是流程和工具建設不到位，導致效率低下，相互抱怨。
這里面本質上的問題是 信息不對稱，沒有將常見的異常歸因流程沉淀下來。單單從流程上來說，業務根本沒有義務將日常的產品迭代和業務活動及運營策略都提前告訴數據團隊，那是否就證明數據團隊只能被動的從數據上了解真相呢？
這里我們先不討論流程問題，更多的去討論如何利用數據去提前發現真相，及時幫助業務歸因復盤。
那該如何優化？
三、怎么做
先，我們要梳理下信貸業務的指標體系。
信貸業務主流程鏈路節點和核心指標構建如下：
其次，根據業務方關注的細化流程來看。
具體到業務部門，比如產品部門最關注的就是節點轉化率。
前端環節涉及到的節點：注冊——實名——計算額度——發起申請——審核通過——放款。
對于各個節點的轉化率，漏斗情況，是產品同學每天都要關注的數據。
再次，抽象出一些通用的異常歸因指標體系，可下鉆定位。
比如，像風控好產品團隊都會關注的入催率指標，在風控平穩期（沒有大規模上線優化策略時期），當入催率指標下降時，我們發現大部分原因是由于用戶還款通道出問題，導致用戶想還卻還不進來，進一步下探，我們就需要下鉆到還款失敗率，再到進一步定位失敗原因，我們需要下探到還款失敗原因（按資方和按渠道維度），到此，我們大概率能看出是哪個資方的哪條還款渠道出了問題，接下來給到支付團隊去緊急修復或者去做外部溝通。
關鍵指標我們梳理出來了，那采用何種方法去監控異常？
首先，我們要考慮的是 如何定義異常。有對比才會有異常，如何定義對比的基線？
一般來說，有如下幾種比較方法：
1. 同比環比法
計算同比與環比，就是一種與自己的過去比較的方式。
通過和過去的自己比較，可以明確的知道，當前的指標處于什么樣的水平上。并且能知道這個指標變化的趨勢是向好的，還是向差的。
結合實際的業務場景，指標上升、下降、持續保持波動沒有變化或大幅波動等，都能夠稱之為某種程度上的問題。常見的比如 日環比，周同比等。
同比和環比法要指明時間周期，是日/周/月/季度/年，一般會幾個周期節點都看?？蓞⒖既缦略O計：
2. 擬合預測法
擬合預測法是對歷史數據進行擬合（線性，非線性）后，對于指標的趨勢變化進行刻畫，來判斷后續的數據點和擬合曲線的偏離程度。如果偏離程度超過某個預定閾值，則可以判斷為異常，常見的擬合方法有線性擬合、對數擬合等，如下是線性擬合的例子：
3. 標準差法
可以采用比較變化幅度與歷史數據標準差的方式，對于指標的變化幅度進行更為精準的刻畫，來設計預警機制。當我們談論到離散程度、變異性時，可以理解為數據的波動大小。
標準差（Standard Deviation） ，是離均差平方的算術平均數的算術平方根，用σ表示，衡量數據的波動大小。
可以參考著名的6-Sigma管理法，6σ管理法是一種統計評估法,核心是追求零缺陷生產，“σ”是希臘文的一個字母，在統計學上用來表示標準偏差值，用以描述總體中的個體離均值的偏離程度。閾值的設定為σ，2σ，3σ，可以根據具體業務場景來考慮使用。
4. 移動平均法
移動平均是一種分析時間序列的常用工具，它可過濾高頻噪聲和檢測異常點。根據計算方法的不同，常用的移動平均算法包括簡單移動平均、加權移動平均、指數移動平均。假設移動平均的時間窗口為T，有一個時間序列：
從上面的公式容易看出可以用歷史的值的均值作為當前值的預測值，在序列取值隨時間波動較小的場景中，上述移動均值與該時刻的真實值的差值超過一定閾值則判定該時間的值異常。
同時段移動平均法，比如采用過去7天/30天的平均值作為基線，這個更適合細化到分鐘段級別的異常判斷，比如每5分鐘一個點，對比過去一周內同時段的7日平均值，上下浮動20%為異常等。
這里面的另外一個難點，在于如何定閾值 ？可以根據業務經驗，也可以依據歷史數據分析來調整，還可以基于機器學習模型來判斷，我覺得什么方法不重要，能達到目的且成本最低的方法才是最合適的。
基于我們要監控準實時的指標，時效細化到每5分鐘，我們采取了移動平均法。當日 VS. 近7日同時段平均。
舉個例子，T日9點-10點的注冊用戶數，對比的基線指標是：sum（T-7到T-1日 每天的9點-10點的注冊用戶數）/ 7
最后，我們通過實時的BI產品來達到監控以上指標的目的，數據產品形式部分如下：
有了實時指標監控的數據產品，只能幫我們快速發現異常，有些場景還是需要人工接入定位異常原因并做跟進解決，同時還需要同步給相關干系人。
這一塊流程，我們還是采用線下的文檔跟蹤方式，需要定位到 時間，責任人，異常分類，異常描述，數據建議，業務反饋，是否關閉，截圖。具體形式可以舉例如下：
實時業務指標跟蹤平臺上線后 效果如何呢？ 我們選取了其中一個 異常歸因的case，在上線前和上線后，定位時效提升了數倍，舉例如下：
四、優化方向
以上是筆者在互金領域的實踐總結，但是數據指標監控體系的建立的一般方法論卻是適用于各行各業。筆者思考后，依然覺得有四點可以優化的方向，具體總結如下：
1. 接入更多業務歸因分析場景
比如客服和催收團隊特別關注的 接通率，平均接通時長等。
2. 業務自助選擇需要的指標來監控
這需要建立一個全面的指標體系，同時提供給業務自助監控的工具，業務自主選擇指標，判斷邏輯，閾值，發送人等。
3. 智能化的閾值預警
現在的閾值更多的是靠人工來調整，是否可以探索出一種方法，能自動學習歷史經驗來調整閾值。這是個長期的過程，還是需要人工不斷的反哺，前期采用人工+機器結合的方式。
4. 指標異常定位追蹤全線上流程記錄
目前的追蹤方式 是數據產品同學人工記錄整個case追蹤流程，采取郵件形式跟蹤問題解決進度。是否可以形成一個追蹤的閉環，比如異常case發送后，由指標負責人自己跟蹤并將結果線上反饋到系統，同時能自動通知所有干系人，包括關閉后也能通知。
理想的是如下閉環流程全部實現線上化：
指標選擇 —— 異常定義 —— 閾值調整 —— 異常預警 —— 告知干系人 —— 異常排查 —— 結果跟蹤 —— Case 關閉。
實現以上流程的閉環，則代表數據驅動從 人找數據思維轉變到 數據找人的思維。
本文由 @乘風隨行 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
小白的我看著還是有點懵的，不太懂。我還需要慢慢學習！
作者提到的方法很是實用，為啥感覺每次遇到就想不起來用了呢
溫故統計學，可以知新
作者大大在實踐總結很到位啊，數據指標監控體系的建立的一般方法論卻是適用于各行各業的，所以我果斷抄作業了！
歡迎指正