編輯導語：數(shù)據指標的異常波動分析是很多人經常會碰到的小麻煩，但這個數(shù)據指標卻關系著高層策略方向制定，業(yè)務日常的運營等方面的工作，所以一個體系化的流程和監(jiān)控機制就顯得很有必要了。本篇文章中，作者詳細地講解了該搭建業(yè)務指標追蹤平臺，一起來看看吧！

一、為什么要做

數(shù)據指標的異常波動分析是數(shù)據同學經常會碰到的case，也是業(yè)務同學經常會提的分析需求。數(shù)據指標的異常追蹤，特別是核心關鍵北極星指標，關系到高層策略方向制定，業(yè)務日常的運營，可以說在時效性和準確性上非常關鍵。

業(yè)務指標的監(jiān)控需要業(yè)務同學和數(shù)據同學緊密配合，但在日常的數(shù)據運營過程中，業(yè)務變化是直接導致數(shù)據異動的重要原因，經常會發(fā)現(xiàn)業(yè)務變化對數(shù)據同事來說存在滯后，不對稱的情況，導致數(shù)據排查異常耗費較長時間。

業(yè)務指標監(jiān)控，如果沒有一個體系化的流程和監(jiān)控機制，會讓參與各方都會感覺“人在囧途”，具體情況，基于互聯(lián)網金融業(yè)務場景，我們來逐個分析下：

1. 產品運營團隊

新上線了個優(yōu)化的小版本，數(shù)據同學卻抱怨沒提前通知他們，數(shù)據出了異常排查時間長。

這周做了個拉新活動，原本以為新注冊用戶數(shù)會大增，沒想到帶來了一大批垃圾注冊用戶。

流量太大，放款資金承接不住，我要經常修改流控開關，一動數(shù)據就會異常報警，也不知道到底是什么原因。

2. 風控團隊

入催率升高了，到底是用戶質量變差了，還是用戶還款還不進來了，每次排查都要一兩天。

三方征信源 數(shù)據認證天天報警，也不知道對我風控通過率到底有沒影響，怎么快速排查？

3. 支付和財務團隊

還款失敗率升高了，找技術排查還是找數(shù)據排查，誰能最快給我定位原因？

是支付渠道出問題，還是資方那邊出問題？

問題定位到了，都過了一兩天了，對外溝通還要時間，用戶投訴不斷……

4. 數(shù)據團隊

指標動不動就預警，業(yè)務到底發(fā)生了什么？

為什么我總是最后一個知道真相？

數(shù)據異常，是數(shù)據問題還是業(yè)務問題？

能不能配合的默契點啊，數(shù)據業(yè)務多互通有無啊… 你們做了啥怎么不提前知會數(shù)據部？

真是人在囧途，每個團隊都覺得自己人在囧途！

二、做什么

那到底是人出了問題，還是流程問題、工具問題？

基于以上異動定位的場景，根本原因還是流程和工具建設不到位，導致效率低下，相互抱怨。

這里面本質上的問題是 信息不對稱，沒有將常見的異常歸因流程沉淀下來。單單從流程上來說，業(yè)務根本沒有義務將日常的產品迭代和業(yè)務活動及運營策略都提前告訴數(shù)據團隊，那是否就證明數(shù)據團隊只能被動的從數(shù)據上了解真相呢？

這里我們先不討論流程問題，更多的去討論如何利用數(shù)據去提前發(fā)現(xiàn)真相，及時幫助業(yè)務歸因復盤。

那該如何優(yōu)化？

三、怎么做

先，我們要梳理下信貸業(yè)務的指標體系。

信貸業(yè)務主流程鏈路節(jié)點和核心指標構建如下：

其次，根據業(yè)務方關注的細化流程來看。

具體到業(yè)務部門，比如產品部門最關注的就是節(jié)點轉化率。

前端環(huán)節(jié)涉及到的節(jié)點：注冊——實名——計算額度——發(fā)起申請——審核通過——放款。

對于各個節(jié)點的轉化率，漏斗情況，是產品同學每天都要關注的數(shù)據。

再次，抽象出一些通用的異常歸因指標體系，可下鉆定位。

比如，像風控好產品團隊都會關注的入催率指標，在風控平穩(wěn)期（沒有大規(guī)模上線優(yōu)化策略時期），當入催率指標下降時，我們發(fā)現(xiàn)大部分原因是由于用戶還款通道出問題，導致用戶想還卻還不進來，進一步下探，我們就需要下鉆到還款失敗率，再到進一步定位失敗原因，我們需要下探到還款失敗原因（按資方和按渠道維度），到此，我們大概率能看出是哪個資方的哪條還款渠道出了問題，接下來給到支付團隊去緊急修復或者去做外部溝通。

關鍵指標我們梳理出來了，那采用何種方法去監(jiān)控異常？

首先，我們要考慮的是 如何定義異常。有對比才會有異常，如何定義對比的基線？

一般來說，有如下幾種比較方法：

1. 同比環(huán)比法

計算同比與環(huán)比，就是一種與自己的過去比較的方式。

通過和過去的自己比較，可以明確的知道，當前的指標處于什么樣的水平上。并且能知道這個指標變化的趨勢是向好的，還是向差的。

結合實際的業(yè)務場景，指標上升、下降、持續(xù)保持波動沒有變化或大幅波動等，都能夠稱之為某種程度上的問題。常見的比如 日環(huán)比，周同比等。

同比和環(huán)比法要指明時間周期，是日/周/月/季度/年，一般會幾個周期節(jié)點都看。可參考如下設計：

2. 擬合預測法

擬合預測法是對歷史數(shù)據進行擬合（線性，非線性）后，對于指標的趨勢變化進行刻畫，來判斷后續(xù)的數(shù)據點和擬合曲線的偏離程度。如果偏離程度超過某個預定閾值，則可以判斷為異常，常見的擬合方法有線性擬合、對數(shù)擬合等，如下是線性擬合的例子：

3. 標準差法

可以采用比較變化幅度與歷史數(shù)據標準差的方式，對于指標的變化幅度進行更為精準的刻畫，來設計預警機制。當我們談論到離散程度、變異性時，可以理解為數(shù)據的波動大小。

標準差（Standard Deviation） ，是離均差平方的算術平均數(shù)的算術平方根，用σ表示，衡量數(shù)據的波動大小。

可以參考著名的6-Sigma管理法，6σ管理法是一種統(tǒng)計評估法,核心是追求零缺陷生產，“σ”是希臘文的一個字母，在統(tǒng)計學上用來表示標準偏差值，用以描述總體中的個體離均值的偏離程度。閾值的設定為σ，2σ，3σ，可以根據具體業(yè)務場景來考慮使用。

4. 移動平均法

移動平均是一種分析時間序列的常用工具，它可過濾高頻噪聲和檢測異常點。根據計算方法的不同，常用的移動平均算法包括簡單移動平均、加權移動平均、指數(shù)移動平均。假設移動平均的時間窗口為T，有一個時間序列：

從上面的公式容易看出可以用歷史的值的均值作為當前值的預測值，在序列取值隨時間波動較小的場景中，上述移動均值與該時刻的真實值的差值超過一定閾值則判定該時間的值異常。

同時段移動平均法，比如采用過去7天/30天的平均值作為基線，這個更適合細化到分鐘段級別的異常判斷，比如每5分鐘一個點，對比過去一周內同時段的7日平均值，上下浮動20%為異常等。

這里面的另外一個難點，在于如何定閾值 ？可以根據業(yè)務經驗，也可以依據歷史數(shù)據分析來調整，還可以基于機器學習模型來判斷，我覺得什么方法不重要，能達到目的且成本最低的方法才是最合適的。

基于我們要監(jiān)控準實時的指標，時效細化到每5分鐘，我們采取了移動平均法。當日 VS. 近7日同時段平均。

舉個例子，T日9點-10點的注冊用戶數(shù)，對比的基線指標是：sum（T-7到T-1日 每天的9點-10點的注冊用戶數(shù)）/ 7

最后，我們通過實時的BI產品來達到監(jiān)控以上指標的目的，數(shù)據產品形式部分如下：

有了實時指標監(jiān)控的數(shù)據產品，只能幫我們快速發(fā)現(xiàn)異常，有些場景還是需要人工接入定位異常原因并做跟進解決，同時還需要同步給相關干系人。

這一塊流程，我們還是采用線下的文檔跟蹤方式，需要定位到 時間，責任人，異常分類，異常描述，數(shù)據建議，業(yè)務反饋，是否關閉，截圖。具體形式可以舉例如下：

實時業(yè)務指標跟蹤平臺上線后 效果如何呢？ 我們選取了其中一個 異常歸因的case，在上線前和上線后，定位時效提升了數(shù)倍，舉例如下：

四、優(yōu)化方向

以上是筆者在互金領域的實踐總結，但是數(shù)據指標監(jiān)控體系的建立的一般方法論卻是適用于各行各業(yè)。筆者思考后，依然覺得有四點可以優(yōu)化的方向，具體總結如下：

1. 接入更多業(yè)務歸因分析場景

比如客服和催收團隊特別關注的 接通率，平均接通時長等。

2. 業(yè)務自助選擇需要的指標來監(jiān)控

這需要建立一個全面的指標體系，同時提供給業(yè)務自助監(jiān)控的工具，業(yè)務自主選擇指標，判斷邏輯，閾值，發(fā)送人等。

3. 智能化的閾值預警

現(xiàn)在的閾值更多的是靠人工來調整，是否可以探索出一種方法，能自動學習歷史經驗來調整閾值。這是個長期的過程，還是需要人工不斷的反哺，前期采用人工+機器結合的方式。

4. 指標異常定位追蹤全線上流程記錄

目前的追蹤方式 是數(shù)據產品同學人工記錄整個case追蹤流程，采取郵件形式跟蹤問題解決進度。是否可以形成一個追蹤的閉環(huán)，比如異常case發(fā)送后，由指標負責人自己跟蹤并將結果線上反饋到系統(tǒng)，同時能自動通知所有干系人，包括關閉后也能通知。

理想的是如下閉環(huán)流程全部實現(xiàn)線上化：

指標選擇 —— 異常定義 —— 閾值調整 —— 異常預警 —— 告知干系人 —— 異常排查 —— 結果跟蹤 —— Case 關閉。

實現(xiàn)以上流程的閉環(huán)，則代表數(shù)據驅動從 人找數(shù)據思維轉變到 數(shù)據找人的思維。

本文由 @乘風隨行 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載。

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