前言

從《用戶行為分析-構建篇》到本篇已經是第三篇了，分別圍繞用戶行為分析的全流程講述了數據集構建-分析方法-異常修復這三趴，因為主講的內容會分布到不同的職能上，所以有些讀者群體們產生不了多少興趣，或者說工作上還沒有遇到諸如此類的問題還不太用的上，但是沒有關系，我依舊期望在你需要的時候，能夠在搜索結果或是收藏夾中出現它們的身影，為你提供一套標準可用的用戶行為分析指南。

往期干貨：

一、如何識別報表數據異常

為什么要留意報表中的數據異常？你聽我放屁：天災人禍你要渡過難關、潑天富貴你要想法接住、事在人為你要對比效果。簡言之幫助產品運營良性發展。

1. 識別與修復的重要性

數據報表會用作業務決策參考，不想被帶偏就要確保準確性，所以當我們完成報表搭建以后，先不考慮業務數據是否漂亮、是否有外界因素干擾，一定要先檢查從數據加工到報表建成的這個過程中是否有紕漏，如果這個過程沒有問題，數據依舊異常，則要進一步觀測數據采集階段是否有問題，只有當數據從采集到加工成報表都沒啥問題時，最后代入到業務場景中分析異常原因才有價值。

2. 在工作場景中的價值

作為一名非數據分析師，你可能是 PD、UE、UX、UI 等，但作為產研人員你不關注業務數據有些說不過去，而掌握不同程度的數據異常識別與修復能力，可以更便捷的滿足自身業務數據分析的需要。雖然張嘴提數據需求很快，但是需求什么時候落地你還得靜候佳音，所以通過自助分析減少對 BI 同學的依賴，加快響應何嘗不可；

好了，再聊回來如何識別異?！?/p>

3. 清晰業務背景與客觀規律

事實上要搞清楚你的數據報表有沒有問題，最簡單快捷的辦法就是了解業務與產品屬性后找客觀規律，因此數據不要揪著那么一兩天的看，也不要只停留在報表上找問題，最好是把數據的周期范圍拉長，以形成參考對比便于觀察趨勢變化，如果數據指標比較單一，不能構建趨勢或環比，那么你也可以結合業務流程、指標結構、行業標準等來看，看數據指標是否處于合理的水準。

如果上述的流程方法你一個字也沒看進去，那么請看這個例子：

如果當產品內部沒有主動的變量事件，外部也沒有明顯的被動事件影響，且數據指標還不符合客觀規律或業務預期，那么大概率報表搭建的過程中出了 Bug，準備找問題吧 hhhh

以下是針對業務背景與客觀規律的變量整理，一些常見的基本都概括了，在進行報表數據異常排查時可以參考；

通?？陀^規律是比較能夠反映出數據異常的，因為數據有一定的標準或規律可言，另外就是配合業務背景或行業狀況來解釋或預測數據的變動，這兩套數據異常識別方法，基本上可以用一套決策樹來概括；

4. 業務數據-多表對比驗證

用戶行為分析構建通常會單獨創建一套行為數據采集系統，這表明相關的數據表不止一套，一般還有業務后臺的數據、渠道投放數據等，這個時候我們就可以將相關的核心指標或大盤數據進行抽樣對比，如果數據對不上，那就代表數據報表搭建的有問題，一般業務后臺的接口數據是不會出錯的，遇到數據對不上就老老實實檢查報表或采集系統吧。

二、如何修復數據指標異常

一套用戶行為分析報表剛構建好之時，用戶行為指標異常無非就兩方面；
一方面就是用戶群中確實有異常的行為帶來了異常的數據或趨勢，這些是要結合業務營銷或外界因素來找原因了，但可以肯定的是異常數據是對的，沒有說謊，例如商品的優惠券配置錯了，給出了驚人的優惠，導致下單量數據與趨勢遠超以往，數據看起來是異常的，但卻是能找到對應異常原因的。

另一方面就是你的數據采集到計算加工出錯了，事實上這種情況也時有發生，常見于多個同事交叉作業、采集需求不完善、數據維護不規范、工作量較大出現紕漏、數據處理不熟練等。
那么接下來就好好跟大家嘮嘮數據報表構建完后，如何修復這些異常問題。

修復過程我結合我個人的習慣與過往經驗拆分成了六個部分，相較于專業的 BI 數字建模開發，可能還是有些差距的，但是也算夠用，起碼能夠自己 Hold 住大多問題，剩下的疑難雜癥再抱抱 BI 同事的大腿即可～

1. 定位數據異常

這是數據異常修復的首要工作，如何識別異常已經在上一趴聊過了，那么如何定位問題主要有兩個行動方向；

需要注意的是在數據驗證的過程中，采用相同條件的過濾或數據范圍，保證口徑的統一，那么當你找到數據異常發生在底層還是在中間加工層后，那么就進入下一步驟治理工作了。

2. 給數據打補丁

給數據打補丁就是加篩選條件，發現數據有異常后將異常的部分過濾掉即可，通過觀察這些異常數據的規律來界定一個數據有效的范圍或標準，然后在數據報表上添加數據過濾或判斷，通常數據或報表工具一定會具備這些功能，在前文有個清洗調研問卷的例子還有印象嗎？其實就是將無效的用戶反饋剔除即可；

你可能會好奇這些臟數據從哪里來的？

除了以上交互邏輯不完善導致用戶填入的數據外，還有一些可能是來自產品內部測試、腳本測試、數據爬蟲、灰產攻擊、數據采集 Bug 等，所以如果團隊內部有大量測試或腳本動作，一定開個名單把這些數據過濾掉，其他的則可以通過觀察產生異常數據的賬號、設備信息、MAC 地址、參數內容、IP 網絡等信息來找規律和數據規避，例如寫一個條件判斷的計算列，有效為 0 無效為 1，數據分析時過濾掉為 1 的即可；

3. 修正函數算法

在我的過往經歷中，指標度量的出錯通常有兩種情況，一個是你的函數能跑，但寫的不符合指標的預期，另一個是你計算過程中，引用了錯的字段參數，這兩種情況都會使得最終的指標度量不對。

如果你函數用的比較熟練，那么通常出錯的原因往往是用了不對的字段參數進行計算，如果你對業務數據不夠熟悉，或是業務數據的口徑不規范，都很容易出現這種問題，這種情況就需要你進行抽樣與數據試驗了。

字段參數口徑選用

最簡單辦法就是定位到存在有差異的數據源后，觀察具備相同屬性的字段參數那個更完整或更準確，例如一套數據集中有兩個字段參數可以視為用戶個體，但是進行列統計時兩個數據不相等，那么我們就要在原始數據集上進行排查，看看數據缺失的部分是否符合邏輯或是數據采集有漏洞，然后結合業務情景或數據詳情，來挑選出一個靠譜的字段參數用作業務指標度量計算，修復之后呢，也建議找個地方進行備注，特別是數據血緣比較復雜時，便于維護；

指標函數驗算

如果對各種函數的用法不熟悉，或是某個 BI 工具沒用采用傳統的 SQL 函數，導致你的指標度量計算出錯概率也是很大的，一般遇到這種情況，我都是先鎖定到一定范圍的數據，然后通過一些簡單的函數加人工算出指標值，然后找可行的函數來加工或調整出這個指標值，之后再隨機采樣驗證一下是否準確，如果遇到實在搞不定的數據運算或函數使用，那就問問 AI 大模型，或者平臺客服，反正我這邊 BI 平臺的語法群里的消息基本沒有停過～

4. 下鉆指標度量

此項是針對套娃式函數運算的指標場景，即當前的指標函數計算中，用到了其他計算列或是度量，但這些計算列或度量本身又是由其他計算列或度量構成，這就意味著引用的下游計算列或度量一旦有誤，上游指標全盤崩壞，這種情況也是排查和修護中比較惡心的，你得像剝洋蔥一樣一層一層的找問題，好在改完一個問題后，其他也能變回正常，此類問題修復可以參考以下決策樹；

5. 糾正數據采集

針對用戶行為數據采集，如果起初的埋點采集需求沒有寫清楚或開發驗證中有了遺漏，就會導致進行指標或用戶行為路徑分析時缺少關鍵數據或是數據對不上，這就是典型的數據采集事故，即上報完整性有問題、上報準確性有問題，如果產品迭代后，相關埋點沒有及時迭代更新也會出現諸如此類的問題。

你以為這種問題是少數？實際上很多時候開發者完成行為埋點開發后，業務方都沒有仔細測試驗證過，都是簡單看兩眼就好了沒問題了，然后在做數據報表或相關分析時，才開始查缺補漏找開發返工或補充，提過行為埋點需求的同學們，試問自己，每次埋點開發完后有仔細測試驗收過么？有的話，繼續保持！

6. 培訓和交流「交流中」

這一趴從企業流程管理或是個人發展學習都是有益的，特別是多個同學交叉作業的情景，無規范無維護后續越亂套我們越難受，讓改一套報表遇到點兒問題都要找半天，真的還不如新建一套報表來的舒服，所以數據采集加工、口徑統一、語法技巧等都是可以多交流的，甚至沉淀內部材料或分享都是不錯的。

就例如指標的函數加工，之前我為了輸出業務的期望指標，我寫了好幾套計算列才把結果套出來了，但是后來請教 BI 后，對方只用了兩套語法就把度量指標弄出來了，看完后我表示妙啊～

至于現在，基本的數據分析或報表構建我都能自助解決，完全不依賴數據相關的同事，同樣的數據需求，如果我有時間的話，別人的還在等數據同事那邊的排期，我這邊就開始了，人家開始時，我這邊已經結束了。

三、行為分析的延展應用

前文分享了如何進行基礎的用戶行為分析，實際上行為分析的妙用不止于此，如果這些行為數據妥善應用還能為業務帶來不少價值，如通過機器深度學習構建預測模型、更深入的偏好分析應用、異常或潛在威脅的行為監控等。

1. 異常行為監控

用戶行為異常分析可以幫助業務發現不正常的用戶行為，不同類型的異常行為對業務也會造成不同程度的威脅或負面影響，因此可以構建一套用戶行為監控系統（根據業務需要提需求或接入第三方服務即可，不是讓你寫代碼哈），根據不同類型的用戶行為定制相應的響應策略，這樣可以減少潛在的威脅以提升安全性或用戶行為規范性，通常來講這些異?？梢苑譃閮纱箢?；

一類是用戶不合規的行為，前者可以通過評估行為的惡劣程度來進行賬號警告、凍結等來處理。

另一類則是灰產攻擊，后者的容忍度相對會更低，一旦通過行為或其他數據確認后，就會進行攔截屏蔽或是相關賬號封禁處理。

至于這些異常如何識別，在第一部分的「清晰業務規律與客觀規律」或第二部分的「如何給數據打補丁」都有提過，基本上就是用戶行為異?；蛟O備屬性異常，那么在發現問題以后，最好就是將這些異常的特征記錄在案，并通過算法或一些自動化手段，融合到異常行為監控系統中，一旦發現符合特征的潛在威脅就提前告警或攔截屏蔽等，并且持續的優化迭代，以減少人工投入的成本。

2. 用戶偏好系統

相比于預測模型，用戶偏好系統大家肯定更熟悉一些，一般可以分成三個部分，即用戶畫像構建、用戶偏好分析、個性推薦系統，這里就不展開一個個聊了，其用途與構建的思路方法我用表格整理了一下可供參考，如果有興趣可以專門找一下相關的資料看看；

3. 行為預測模型

行為預測模型的本質是機器深度學習或 AI 相關的應用，說人話就是不定期的把業務數據整理好了喂個算法服務，然后算法根據數據產生一套預測結果，然后你把結果用于業務決策或定制化營銷上。

因為訓練模型需要一定成本，所以訓練前需要明確有業務上的需要，以及有合適的行為數據可用于加工后進行模型訓練，那么具體如何繼續模型訓練我就不展開了，很多人可能疑問這些行為預測模型具體有什么東西，能起到什么用途，對此整理了一下五點可供參考；

四、連續三篇全流程與決策樹總結

整個流程事件的步驟與決策方法概括；

感謝耐心閱讀，有疑問可留言或聯系交流，如果覺得寫的還行，就點贊關注一下吧，下次更新先通知你～