編輯導語：在BI系統里，經常會遇到風險告警的場景，在這一類場景中需要更加重視業務的管理以及產品流程，及時解決問題；對于這種數據決策類產品設計，我們應該怎么做？本文作者分享了關于BI系統里的數據賦能與業務決策，我們一起來了解一下。

01?什么是風險告警？

風險告警是一個我們在使用數據過程中會遇到的比較常見的場景。我們今天詳細說說這類場景如何進行數據決策產品設計。

1. 業務風險管理角度

從業務風險管理的角度上，一般將風險管理分為事前管理、事中管理、事后管理。

• 事前管理，目的是預防事情的發生；
• 事中管理，目的是及時介入，避免事情變得更糟糕；
• 事后管理，目的是縮小已發生的問題造成的影響面、降低影響程度。

從業務風險的角度，我們能夠理解風險告警的目的。

2. 產品角度

從產品角度上看在日常業務場景中，一般可以分為流程類風險、總量類風險。

• 流程類風險，是流程監控中常見的，比如事情應該做而沒有做、延遲做了、出現了不應該出現的事情（流程節點）。
• 總量類風險，是水平監控、質量監控中常見的，比如今天應該完成多少，沒有完成；平時正常水平多少，現在監控指標超過了正常水平相當比例。

從產品角度，我們能夠區分出我們遇到需求的是哪一類問題。

02 風險告警解決方案

知道了這兩種分類，能夠幫助我們在需求分析階段，很快的鎖定住我們的目標和大致的解決方案。

1. 一個例子

一家車聯網公司，最近想做一個用戶疲勞駕駛的風險告警，業務方設想的場景是，如果超過了交通法規規定的時間，就通過車聯網APP給用戶發出告警。

從風險管理的角度看，這個需求屬于是事后管理，因為業務希望是已經發生疲勞駕駛，發出提醒。

從產品角度看，這個需求屬于總量類風險（水平監控），當數據積累到一定值，發出告警，這個一定值，是交通法規規定的，所以是一個固定值。

弄清楚這兩點，我們的解決方案也大概有了個輪廓，采取策略方法，通過監控持續駕駛時長這個數據指標，當數據指標到達閾值時，觸發告警。那么，我們產品方案的核心就是要弄清楚持續駕駛時長這個數據指標的計算邏輯，這個和車聯網采集上來的數據是什么樣高度相關，數據指標邏輯選取是另一個話題，我們這里不展開了。

用這個例子向大家說明，一個數據相關的風險告警場景的需求分析大致是怎么做的。

表面上看，這個例子不太像BI系統干的活，更像是一個車聯網的應用場景。事實上，如果要在一個BI看板里面進行業務決策支持的應用，他要面對的需求場景和解決方案都會更復雜一些。

之前的文章里我們提過，BI系統做數據決策之所以是一個比較難的問題，是因為現實世界存在復雜性。

復雜性決定了在做數據賦能和業務決策相關的數據產品設計時，要避免『一刀切』的想法，避免『畢其功于一役』，避免設想自己的設計能夠『一次成功』，這是一個不斷調優的過程（如果是一名策略產品經理或者算法產品經理，應該能很好理解），調整好心態，我們開始吧。

2. 背景數據做風險告警的幾種方案

用數據來做風險告警，大概有這么幾種方案：

• 數據+策略/規則
• 數據+數據挖掘/機器學習
• 數據+知識圖譜

本文從產品角度，給大家介紹需求場景如何與這些解決方案相結合。

03 風險告警實例

下面來看一個數據安全審計的例子。

1. 背景

現在，平臺已經有了敏感字段管理，對于用戶的導出權限一般來說不做限制，但是會去監控用戶的導出操作與導出量行為，如果操作行為上看用戶的導出超過了正常業務需要，就屬于疑似異常導出，平臺要能識別這種異常并且發出風險告警。

這是一個我們通常會遇到的需求描述。表面上看，需求很明確，但仔細一琢磨，就會發現這個描述有很多模糊的地方。

這里面最大的需要明確的點，就是如何定義疑似異常導出的行為，即風險識別。

那么根據不同層次的需求，我們的解決辦法有相應的不同：

業務側說，我們有很明確需要監控的重點表，根據之前的業務case，當發生這些行為的時候（同一天內多次導出不同查詢條件的同一個表的數據；同一天內導出總數據量超過xxx條數）就是疑似異常導出。只要先識別出這些行為推送給我們，通過一些日志去判斷是否真的是異常就可以。

2. 明確需求

首先判斷，這是一個事后風險管控+總量類風險（水平監控）的需求，因為導出行為已經發生了；其次，我們判斷數據決策的要求水平，業務方對告警的精度要求不高，他們已經有了明確的通過實際案例積累下來的規則，

數據要做的是什么呢？幫助業務方在進行風險識別的時候提升效率、也就是篩選一個大面積的數據集，然后推送給業務人員進一步識別。

3. 設計解決方案

1）確定初步方案

需求到這個程度大致明確了，我們可以使用數據+策略的產品解決方案。即統計每個用戶對監控的表的單日導出次數，和每個用戶對監控的表的當日單出總量，兩者有一項超出閾值（或者同時發生時），將用戶信息及操作日志推送給指定的管理員用戶。

2）迭代

現在，來看一下迭代需求。

對接人反饋，第一期上線后，確實解決了大海撈針的問題，但是現在公司規模擴大了，數據量和數據分析人員增加，現在推送的疑似異常也多了很多，用戶已經分析審核不過來了，能不能把風險比較高的給我們，低風險的那些就先給這些用戶做一些告警提示。

業務對接人還提出來一些想法，比如按照導出次數大小或者按照數據量大小去分這個風險高低，低風險可以等審核人員有空的時候進行抽查。

首先通過判斷，這是一個迭代需求，需求還是事后風險管控+水平監控。

然后通過分析，這些新增的內容，是對于告警的精度要求提升了，說白了，就是要降燥。

業務方給的解決方案是：通過對識別出的異常進行分級，不同的級別對應不同的處理辦法。怎么判斷我們能不能按照業務提出這個解決方案去做呢？

我們從產品發展的角度分析一下：

這個解決方案進行了風險分級處理，不同級別風險，告警方式不同。這個思路肯定沒有問題。

3）分級的問題

在再進一步看，如何分級，用什么原則去分級呢？我們發現業務提供的這個分級的策略比較剛性，如果用一個固定的數據指標值，可能會有兩個問題：

• 導出數據量和次數與風險閾值的關系，是和表本身存儲的內容和數據量有關，也許不同的表閾值是不同的（意味著有巨大的維護規則的工作）。
• 隨著業務規模發展，存儲的數據量規模也會變化，即使同一個表，風險告警閾值很容易就會需要變更。

那么這個規則從擴展性來說，閾值不適合使用一個固定的值了，而是一個受到一些影響因素會發生變化的數。

經過一番需求分析，發現業務對接人提供的解決方案思路是ok的，但是細節還需要進一步去設計；那么這次產品迭代的目標是就是需要在數據監控的基礎上，動態的去進行風險分級。

有些小伙伴會說，這個時候該算法工程師上啦！應該讓算法同學出解決方案了。

我要說，這個時候其實產品的核心邏輯還沒思考清楚，算法同學接到需求，只會丟給你一個白眼好嘛！

4）梳理核心邏輯

怎么去梳理這個核心邏輯呢？

我的答案是，要去思考這件事情的本質是什么，抽象出來。我們要理解的事情是—風險告警推送給審核人員，他們到底在審核什么？

帶著這個問題和業務人員交流，溝通后發現，審核要找出用戶是不是真的出于不好的目的（比如盜取數據）導出數據。那么，我們風險識別，就是去能夠識別用戶行為的惡意程度，而風險的分級，就是惡意程度的分級。

現在，需求轉化成為了一個相對定量的，評估用戶在平臺進行數據導出或者查詢等一系列行為的惡意程度。惡意程度，如何量化？可以從結果去推導，用戶操作得到的數據結果整合后，如果這些內容流出，對公司造成損失程度。

把惡意程度和損失程度做了一個對等變換，如何看損失程度呢？通過和業務方調研了解到泄露出去的數據，包含的內容以及內容的組合，如果會推算出一些不公開的數據，或者通過單元數據加工可得到一些財務數據，這種就屬于損失比較高的了。

原來如此，不同損失程度其實和疑似泄露的數據集的特征有關系。這個數據集不一定是從有一個表導出的，也有可能是好幾個表數據組合的。和數據量明細也許不一定高相關（不同特征的權重是不一樣的）。

到了這一步，核心邏輯就整理出一個大概輪廓了：找到某個用戶一系列操作行為組合出的數據集的特征，與我們的目標值（損失程度較高的數據集）特征，他們的相似程度，相似度越高，風險越高。

5）明確詳細方案

現在，產品思路理清楚了，我們可以去和算法同學討論，使用什么樣數據挖掘/機器學習的算法能夠達成需求目標。當然，還會遇到算法同學提出的一些別的問題，需要共同討論再進一步得出更詳細的解決方案。

好了，這個例子對于需求分析說的比較詳細，通過對需求不斷抽絲剝繭，一步一步深入，最后得到一個解決方案。

未來會繼續對數據決策相關做探討。

作者用了一個虛擬的案例，或者說一個思想實驗，與實際上數據安全審計的類似場景會有不同的地方，但是解決問題的思路很值得學習和思考。

#專欄作家#

大鵬，公眾號：一個數據人的自留地。人人都是產品經理專欄作家，《數據產品經理修煉手冊》作者。

本文原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議。