中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：在實際工作中，數據分析師會遇到多種類型的數據體系，而不單單是業務數據的監控體系。作者就其目前的部門體系的搭建，分享互聯網法訴業務數據體系該如何建立，一起來看看吧。

今年從零開始參與了部門整體體系的搭建，一直忙到9月份才有喘息的機會，也想分享一下在業務數據體系搭建的經驗。

之前看到的很多數據體系搭建的分享都是業務數據監控體系搭建，其實在部門實際操作中會涉及多類型的數據體系，而不僅僅是業務數據監控體系。以我們部門現在在做的逾期資產處置來看，很多數據的收集是線下數據匯總以及清洗，和能夠通過線上的用戶日志的數據收集清洗邏輯完全不同。

在通常的業務部門中，有大量的數據是在線下通過EXCEL報表的形式交互的，這種業務形式下整體數據的體系會因為人為、操作的因素導致體系相對不是那么清晰，加上大部分公司的模式都是業務追著數據跑，跑著跑著數據工作的壓力就特別大，慢慢的數據組就全成了工具人了。

目前我們部門的架構簡單分為三個組別，材料組是對目前現有的可訴訟證據材料進行甄別、組織全量訴訟材料，渠道組主要對接外部可委托在各地法院進行訴訟的渠道。

因為所有的數據都是在線下交互的，且完全沒有系統支持，所有的數據邏輯只能靠人工在線下進行整理。

以實際業務及工作需求為核心拆分現有的數據需求：

每一個工作業務步驟下都存在大量記錄的數據，因此就需要內部將所有的數據體系按數據的統一維度進行計算，也需要確定每個工作節點的數據回傳時間和數據回傳質量以及數據檢查項

根據業務的流程，可以大致推導數據的流轉方向：

由于數據交互的節點下有多人、多渠道參與，不同的同事在數據傳遞和數據回收的處理方式不盡相同，就需要建立標準的數據較驗處理規定和模板。

為了讓每個數據環節的數據處理情況一致，確保實際操作的數據和分析的數據按統一的維度拆分，就需要從一個整體的角度出發去核準數據的處理標準和時間：

以分案為例，案件篩選目前有幾個需要嚴格核準的標準，如用戶有多筆欠款，則以合計欠款金額為實際欠款金額，該用戶下的所有訂單合并，以實際用戶案件的維度去考慮訴訟范圍。

如上圖所展示的，就算是同個用戶在不同的訂單下借款的金額、借款時間、借款用途與逾期天數等數據是不完全一致的，需要根據用戶的不同訂單下的訂單特征歸納出完善且可用的用戶特征。

但由于實際起訴后用戶還款不一定能完成按照起訴的總額歸還，由于公司數倉底層仍是按照訂單作為主鍵的維度建庫，部分歸還的情況下會需要將用戶的還款按不同的訂單和不同的金額填充規則（具體根據借款合同約定。

例如按最早一期欠款的罰息、利息、本金的順序進行沖賬）因此會在推出案件的前期明確同個用戶下多筆訂單的主次關系。

此外，需要對所有后期需要分析的字段的當前狀態進行留存，這就需要對系統內所有業務相關字段的含義和更新邏輯有所了解，數倉通常會保留訂單的當前狀態，舉個例子，用戶目前的逾期狀態是全部逾期（即所有賬期均未還滿），當執行院強制執行后有部分還款，但不足以抵扣全部欠款，用戶該筆訂單的逾期狀態會從全部逾期轉變為部分逾期。

同樣地，因為有部分還款，逾期等級會下跌，這就需要本地留存部分的靜態數據，結合線上的動態數據去看，這就需要建立線下數據和線上數據的交互，將留存在線下的靜態數據在每一段周期內需要按一定的邏輯更新到線上數據庫內作為靜態數據留存下來；

這時候就需要建立一定的數據交互邏輯，本地數據按什么模板上傳，上傳的時間點，上傳的頻次，什么時候能夠在線上系統看到這部分靜態數據，這部分邏輯就需要和管理數倉的同事們溝通明確；

在完成分案之后，會對整體業務的進展進行跟進，這部分一般就由渠道運營的同事去推動；因為各個渠道對待案件的模式可能不盡相同，數據的處理方式也更不一致，舉個例子，有的渠道有自己的失聯修復的手段，有的渠道通過線下送達律師函的方式，有的由于合作法院的模式不一樣。

由于渠道特點和運營模式的特殊性，回傳的數據同樣具有特征性，這樣的數據是較難按統一的維度清洗的，需要給渠道設定合理的字段轉化代碼。

以渠道統計的可聯失聯數據為例，有部分渠道的失聯定義是聯系方式能正常接通但無法聯系到本人，還有一部分渠道將失聯界定為用戶的聯系方式已經完全失效，所有的這些非統一性的字段都需要整理歸納為統一字段含義。

因為所有有人為參與的過程一定會出現部分數據轉化存在問題的情況，最好能夠通過固定的字典表去核準：

以上的字段類型為目前部門部分業務字段名稱和類型展示，因為各類型字段需要渠道、業務方和數倉方面完全對齊字段含義，這樣才能減少數據工作人員在數據清洗方面的重復勞動，盡量簡化工作流程和數據清洗步驟；

當然，并不是所有的數據在收集的時刻就會完全與系統數據的類型和字段名稱完全一致，或者編碼形式完全統一（例如編碼形式為GBK/UTF-8）這就需要進行一步轉化，將收集的標準化字段利用字典表轉化為系統/數據庫可以讀取的數據統一留存，如果在這個步驟下是用數據組自己操作的話人為錯誤是一定無法避免的，最好是通過自動化的工具去完成數據的轉化。

可以通過Python利用pandas和EXCEL、CSV的包完成自動化的處理，之后導入本地數據庫通過表連接查詢用代碼的形式替換業務數據，完成轉化之后錄入系統；

不過，也不是所有的業務數據都能通過自動化工具去清洗，還有大量的業務數據空值由于不能簡單的根據特征數據填充，只能尋找歷史的情況去嘗試補充，這個情況是無法避免的；

數據清洗之后就可以慢慢增添分析的需求，分析指標建設這個已經有太多大佬分享過見解，我就不多說了。

在分析盤點體系的建設過程中一定會出現分析體系開始落后于業務進展的情況（尤其是從0-1的業務部門，業務的進展速度一定是超出實際工作流程建立速度的）。

這種情況下需要留出一定時間去梳理數據在業務流動過程，至于實際策略的產出，仍需要依托分析結果進行深入挖掘，這個以后找時間再分享吧~

作者：Logan_RRRC；公眾號： Logan的運營學習日記

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

題圖來自Unsplash，基于 CC0 協議