法诉|互联网法诉业务数据体系建立

编辑导语：在实际工作中，数据分析师会遇到多种类型的数据体系，而不单单是业务数据的监控体系。作者就其目前的部门体系的搭建，分享互联网法诉业务数据体系该如何建立，一起来看看吧。

今年从零开始参与了部门整体体系的搭建，一直忙到9月份才有喘息的机会，也想分享一下在业务数据体系搭建的经验。
之前看到的很多数据体系搭建的分享都是业务数据监控体系搭建，其实在部门实际操作中会涉及多类型的数据体系，而不仅仅是业务数据监控体系。以我们部门现在在做的逾期资产处置来看，很多数据的收集是线下数据汇总以及清洗，和能够通过线上的用户日志的数据收集清洗逻辑完全不同。
在通常的业务部门中，有大量的数据是在线下通过EXCEL报表的形式交互的，这种业务形式下整体数据的体系会因为人为、操作的因素导致体系相对不是那么清晰，加上大部分公司的模式都是业务追着数据跑，跑着跑着数据工作的压力就特别大，慢慢的数据组就全成了工具人了。

目前我们部门的架构简单分为三个组别，材料组是对目前现有的可诉讼证据材料进行甄别、组织全量诉讼材料，渠道组主要对接外部可委托在各地法院进行诉讼的渠道。
因为所有的数据都是在线下交互的，且完全没有系统支持，所有的数据逻辑只能靠人工在线下进行整理。
以实际业务及工作需求为核心拆分现有的数据需求：

每一个工作业务步骤下都存在大量记录的数据，因此就需要内部将所有的数据体系按数据的统一维度进行计算，也需要确定每个工作节点的数据回传时间和数据回传质量以及数据检查项
根据业务的流程，可以大致推导数据的流转方向：

由于数据交互的节点下有多人、多渠道参与，不同的同事在数据传递和数据回收的处理方式不尽相同，就需要建立标准的数据较验处理规定和模板。
【法诉|互联网法诉业务数据体系建立】为了让每个数据环节的数据处理情况一致，确保实际操作的数据和分析的数据按统一的维度拆分，就需要从一个整体的角度出发去核准数据的处理标准和时间：
以分案为例，案件筛选目前有几个需要严格核准的标准，如用户有多笔欠款，则以合计欠款金额为实际欠款金额，该用户下的所有订单合并，以实际用户案件的维度去考虑诉讼范围。

如上图所展示的，就算是同个用户在不同的订单下借款的金额、借款时间、借款用途与逾期天数等数据是不完全一致的，需要根据用户的不同订单下的订单特征归纳出完善且可用的用户特征。
但由于实际起诉后用户还款不一定能完成按照起诉的总额归还，由于公司数仓底层仍是按照订单作为主键的维度建库，部分归还的情况下会需要将用户的还款按不同的订单和不同的金额填充规则（具体根据借款合同约定。
例如按最早一期欠款的罚息、利息、本金的顺序进行冲账）因此会在推出案件的前期明确同个用户下多笔订单的主次关系。
此外，需要对所有后期需要分析的字段的当前状态进行留存，这就需要对系统内所有业务相关字段的含义和更新逻辑有所了解，数仓通常会保留订单的当前状态，举个例子，用户目前的逾期状态是全部逾期（即所有账期均未还满），当执行院强制执行后有部分还款，但不足以抵扣全部欠款，用户该笔订单的逾期状态会从全部逾期转变为部分逾期。