3、金融数据基础：用户画像数据、行为数据、产品数据的采集与预处理
金融推荐系统区别于通用推荐系统的核心在于：其数据基础具有强金融属性——用户资产状况敏感、行为稀疏且噪声大、产品维度复杂且伴随风险约束。本章围绕三类核心数据源（用户画像、行为日志、产品主数据），系统讲解其采集范围、埋点规范、预处理链路与质量校验方法，为后续特征工程与召回排序模型提供可靠的数据底座。
3.1 用户画像数据：从KYC到动态资产视图
3.1.1 核心原理与数据范围
用户画像是推荐系统的“静态骨架”，决定了推荐的基本边界与合规底线。金融用户画像不仅包含通用的人口统计属性，更核心的是资产状况与风险承受能力。画像数据通常来自多个内部系统：CRM系统存储基础客户信息，核心银行系统记录资产余额，KYC（Know Your Customer）流程采集风险测评结果，客户经理维护补充标签。
| 画像维度 | 典型字段 | 更新频率 | 采集方式 |
|---|---|---|---|
| 人口统计 | 年龄、性别、职业、学历、城市 | 低频（月/季） | CRM同步、注册表单 |
| 资产状况 | AUM、持仓市值、可用余额、理财持有 | 高频（日/实时） | 核心系统接口、数仓同步 |
| 风险偏好 | 风险测评等级（R1-R5）、投资经验年限 | 低频（年/触发时） | KYC问卷、APP测评 |
| 收入与流动性 | 月均收入、代发工资、可投资资产 | 月/季 | 代发系统、客户经理录入 |
| 生命周期 | 年龄分层、婚育状态、职业阶段 | 季/年 | 模型推断+人工维护 |
3.1.2 采集与预处理要点
画像数据采集的关键在于多源ID-Mapping：同一用户在不同系统中可能使用不同标识（身份证号、手机号、客户号、设备ID），需要通过统一客户主数据（MDM）进行关联。预处理阶段重点关注：
- 缺失值处理：风险测评缺失时，不能简单填充“中等风险”，应标记为“未测评”并限制推荐高风险产品；收入缺失可用代发工资或消费水平推断。
- 异常值检测：AUM字段出现负数或超过阈值（如10亿）时，需结合数据来源判断是测试账号、对公账户还是数据错误。
- 时效性权重：资产数据是强时效特征，3个月前的AUM对当前推荐参考价值极低，需按时间衰减或只保留最近快照。
3.1.3 实战场景：新客冷启动画像构建
某城商行APP新注册用户小王，25岁，填写了职业为“互联网工程师”，但未完成风险测评。系统画像构建流程如下：
- 基础属性：从注册信息获取年龄、性别、城市，通过职业映射库推断收入区间（互联网工程师→20k-40k/月）。
- 资产初始化：调用核心系统接口，获取开户后首次入金金额（假设5万元），标记为“初始AUM”。
- 风险等级推断：因未做测评，采用“保守默认”策略，暂定R2等级，限制推荐R3以上产品。
- 行为补充：观察首周行为，若频繁浏览股票基金频道，则触发“风险测评提醒”，并在测评完成后更新画像。
该案例说明画像数据是动态演进的，推荐系统需要建立画像置信度机制——数据越新、来源越直接，置信度越高。
3.2 行为数据：埋点规范与日志治理
3.2.1 行为数据的价值与挑战
行为数据是推荐系统中最能反映用户实时意图的信号。金融行为数据相比电商行为数据更为稀疏——用户可能一个月只登录几次，每次浏览3-5个产品页面，交易行为更是低频。这种稀疏性要求采集端尽可能完整记录每一次交互，同时预处理阶段需要更强的聚合与平滑策略。
3.2.2 埋点体系设计
金融APP的埋点需要覆盖以下关键事件类型：
| 事件类型 | 事件名称 | 关键属性 | 触发时机 |
|---|---|---|---|
| 曝光 | product_expose | 产品ID、推荐位ID、位置序号 | 产品卡片进入屏幕可视区域 |
| 浏览 | product_view | 产品ID、停留时长、来源页面 | 进入产品详情页 |
| 点击 | product_click | 产品ID、推荐位ID、位置序号 | 点击产品卡片或按钮 |
| 加自选 | product_favorite | 产品ID、操作类型（加/删） | 点击自选按钮 |
| 交易 | trade_order | 产品ID、金额、交易类型（申购/赎回） | 交易提交成功 |
| 搜索 | search_action | 关键词、搜索结果数、点击位置 | 搜索执行及结果点击 |
3.2.3 预处理核心操作
- 会话切分：以30分钟无操作为界，将行为流切分为会话（Session），会话级特征（如会话内浏览产品数）比单次事件更有意义。
- 去重与过滤：同一用户1秒内重复点击同一产品只保留一次；过滤爬虫和测试流量（通过IP、设备ID、行为频率识别）。
- 缺失与异常处理：曝光事件缺少产品ID时丢弃；停留时长超过1小时视为异常，截断为最大值或置为缺失。
- 行为权重设计：不同行为对用户兴趣的反映强度不同，预处理阶段可赋予权重：交易（1.0）> 加自选（0.7）> 详情浏览（0.5）> 曝光点击（0.3）> 纯曝光（0.1）。
3.2.4 案例：行为日志质量排障
某基金公司推荐系统上线后，发现“点击率”异常偏高（从5%升至25%），但“申购转化率”反而下降。排查过程：
- 初步检查：查看埋点日志，发现点击事件量级正常，但曝光事件量级下降60%。
- 根因定位：对比版本记录，发现前端改版后曝光事件改为“手动上报”，部分低端机型因性能问题未触发曝光上报。
- 修复方案：恢复自动曝光检测，并增加服务端兜底曝光日志（当推荐位渲染时由服务端记录）。
- 结果对比：修复后点击率回落至6%，申购转化率恢复至正常水平。
该案例说明：曝光数据缺失会导致点击率虚高，预处理阶段必须校验曝光量与点击量的比例关系（正常范围通常在2%-10%之间）。
3.3 产品数据：多源异构的标准化处理
3.3.1 产品数据的复杂性与统一建模
金融产品数据是推荐系统的“候选池”，其复杂性远超普通商品：同一产品在不同系统中可能有不同代码（TA代码、行情代码、内部代码）；产品属性维度差异大（货币基金无期限，定期理财有封闭期，保险产品有缴费年限）；收益率口径多样（七日年化、万份收益、业绩比较基准、成立以来年化）。
3.3.2 产品数据预处理流程
| 步骤 | 操作内容 | 示例 |
|---|---|---|
| 1. 主数据对齐 | 统一产品ID映射，合并多源产品信息 | 将TA代码与行情代码关联到统一product_id |
| 2. 属性标准化 | 统一收益率口径、期限单位、风险等级编码 | 所有收益率统一为“年化收益率%”，期限统一为“天” |
| 3. 缺失值处理 | 产品风险等级缺失时，根据投资范围推断 | 货基默认R1，混合型基金默认R3 |
| 4. 时效性处理 | 区分“实时收益率”与“历史收益率序列” | 实时收益率用于排序，历史序列用于波动率计算 |
| 5. 标签生成 | 构造产品标签：稳健型/进取型、短期/长期、低费率/高费率 | 根据风险等级+期限+类型生成多维度标签 |
3.3.3 产品数据质量校验规则
- 收益率合理性：货币基金七日年化超过5%或低于0.5%时触发告警；权益类基金日涨跌幅超过10%需校验是否分红或拆分。
- 风险等级一致性：产品风险等级与底层资产类型必须匹配（如纯债基金不应标记为R5）。
- 可售状态校验：已下架、已售罄、暂停申购的产品必须从候选池中剔除，否则推荐系统会推荐“不可购买”的产品。
3.3.4 实战：理财产品标准化案例
某银行代销的理财产品来自3家基金公司、2家理财子公司，产品数据格式各异：
- 基金公司A：收益率字段为“近1年收益率”，缺失“成立以来收益率”
- 理财子公司B：收益率字段为“业绩比较基准”，且为区间值（3.0%-4.5%）
- 基金公司C：期限字段为“持有期≥30天”，非标准天数
预处理方案：统一将收益率转换为“年化收益率%”，区间值取中位数；期限字段解析为最小持有天数（30天）；缺失的成立以来收益率用近1年收益率填充并标记来源。最终形成统一产品宽表，供推荐排序模型直接使用。
3.4 三类数据的融合与质量保障
3.4.1 数据融合策略
三类数据在推荐系统中需要融合使用，常见融合方式包括：
- 用户-产品交叉特征：用户风险等级与产品风险等级的匹配度、用户资产规模与产品起购金额的匹配度。
- 行为-画像联合特征：用户画像中的“偏好品类”与行为数据中的“实际浏览品类”的一致性。
- 产品-行为聚合特征：产品近7日浏览人数、购买转化率、复购率等群体行为指标。
3.4.2 数据质量监控体系
| 监控指标 | 正常范围 | 告警阈值 | 处理方式 |
|---|---|---|---|
| 曝光-点击率 | 2%-10% | >15% 或 <0.5% | 检查埋点、检查推荐位是否被遮挡 |
| 画像覆盖率 | >90% | <80% | 检查ID-Mapping、检查KYC流程 |
| 产品数据完整率 | >95% | <90% | 检查上游产品系统接口 |
| 数据延迟 | <5分钟 | >30分钟 | 检查Kafka消费链路 |
3.4.3 常见误区与复盘
误区二：忽略行为数据的“位置偏差”。推荐位第1位和第10位的点击率天然不同，预处理时需记录位置信息，训练时做位置消偏。
误区三：产品数据只关注收益率，忽略风险等级和流动性约束。推荐系统必须将“合适的产品推荐给合适的人”作为硬约束，而非仅追求收益最大化。
总结复盘：金融推荐系统的数据基础建设，核心在于建立“用户-行为-产品”三张表的稳定、合规、低延迟的数据管道。用户画像提供边界约束，行为数据反映实时意图，产品数据定义候选空间。预处理阶段的质量把控直接决定上层特征工程和模型效果的上限。建议团队建立每日数据质量巡检机制，将关键指标（覆盖率、完整率、时效性）纳入监控看板，确保数据问题在影响推荐效果前被及时发现。