续期数据基础：核心字段、清洗与质量监控

做续期策略，第一关不是模型，不是算法，而是数据。我见过太多团队，模型跑得飞起，结果上线一看，宽限期字段是空的，缴费日格式乱成一锅粥。说白了，数据基础不牢，后面全是空中楼阁。

这一章，我们就来聊聊续期数据的三个核心问题：该拿哪些字段、怎么把脏数据洗干净、如何保证数据一直干净。

续期数据的核心字段

续期业务涉及的数据表通常有几十个字段，但真正关键的，其实就那么几个。我个人习惯把它们分成三类：保单标识、时间节点、产品属性。

数据清洗与预处理

拿到原始数据后，别急着建模。先花 30% 的时间做清洗，后面能省 70% 的麻烦。我一般按下面几步走：

第一步：缺失值处理

续期数据里，缺失值最常见的是宽限期截止日和缴费方式。为什么会这样？因为很多老系统的宽限期是写死在代码里的，没有落库。

我的处理原则：

• 关键时间字段缺失：根据险种和生效日推算。比如宽限期，大部分产品是 60 天，少数是 30 天。我会建一个宽限期规则表，按险种映射。
• 缴费方式缺失：看历史缴费记录。如果之前都是年缴，那大概率还是年缴。
• 投保人ID缺失：这属于严重数据质量问题，必须标记并反馈给上游系统。

第二步：格式标准化

日期格式是重灾区。有的系统用 2024-01-15，有的用 2024/01/15，还有用 20240115 的。我习惯统一转为 YYYY-MM-DD 字符串，同时校验合法性。

-- 一个简单的日期清洗示例（SQL）
UPDATE policy_table
SET due_date = STR_TO_DATE(due_date_raw, '%Y%m%d')
WHERE due_date_raw REGEXP '^[0-9]{8}$';

-- 标记非法日期
UPDATE policy_table
SET data_quality_flag = 'INVALID_DATE'
WHERE due_date IS NULL AND due_date_raw IS NOT NULL;

第三步：逻辑校验

字段之间是有约束关系的。我常用的校验规则：

• 缴费日不能早于保单生效日
• 宽限期截止日 = 缴费日 + 宽限期天数
• 已缴年期不能大于缴费年期
• 险种代码必须在产品目录中存在

数据质量监控体系

清洗是一次性的，监控才是长期的。我建议搭建一个三层监控体系，覆盖从数据产生到使用的全链路。

第一层：源端监控

在核心系统（保单系统、收付费系统）出口处做校验。比如：

• 每日新增保单的字段完整率
• 缴费日期的格式正确率
• 险种代码的合法率

第二层：加工层监控

在数据仓库或数据中台里，对清洗后的数据做质量检查。比如：

• 宽限期截止日与缴费日的差值分布是否合理
• 同一保单号在不同表中的记录数是否一致
• 关键字段的空值率是否超过阈值（比如 1%）

第三层：应用层监控

在续期策略系统里，对最终使用的数据做实时校验。比如：

• 跑批前检查当日待缴费保单的数据质量
• 如果某险种的宽限期字段空值率突然升高，自动告警并暂停策略执行

下面这张图，是我自己项目里用的数据质量监控框架，你可以参考一下：

监控指标与阈值

指标不能拍脑袋定。我一般先跑一个月的历史数据，看正常波动范围，然后取 P95 或 P99 作为告警阈值。下面是一些常用指标：

嗯，数据基础这块，说到底就是三个字：清、准、稳。字段要清，数据要准，监控要稳。把这三点做到位，后面的续期策略才能站得住脚。