第3章 · RICE评分数据准备清单
RICE评分的可靠性完全依赖输入数据的质量。本章定义实验平台、埋点系统、项目排期三大数据源的接入规范，以及数据清洗、缺失值处理、有效期管理的标准化操作，确保每次评分都基于一致、可追溯的数据基线。
适用场景
- 多项目并行评分：同时评估10个以上候选实验，需要统一的数据口径。
- 跨团队协作：数据工程师、产品经理、分析师分别负责不同数据源，需明确交接边界。
- 历史实验复盘：对已结束的A/B测试重新做RICE评分，依赖完整的数据快照与有效期标注。
- 评分结果争议仲裁：当RICE总分出现异常时，可通过数据准备清单回溯排查数据质量问题。
前置条件
环境与权限要求：以下三项必须全部满足方可进入数据准备流程。
| 条件 | 验收标准 | 负责人 |
|---|---|---|
| 实验平台（如LaunchDarkly / Optimizely） | 可导出最近30天实验元数据及分组统计数据 | 平台管理员 |
| 埋点系统（如Firebase / 神策） | 核心事件定义已发布至生产环境，数据延迟 < 15分钟 | 数据工程师 |
| 项目排期表 | 包含实验ID、计划上线日期、预计结束日期、迭代版本号 | 产品经理 |
操作步骤
本环节共4个步骤，每个步骤的输出物将直接作为下一步的输入。建议使用数据准备检查单逐项打勾，避免遗漏。
- 数据源接入 — 从三大系统拉取原始数据，统一存入临时工作区。
- 数据清洗 — 应用规则过滤异常记录、去重、格式标准化。
- 缺失值处理 — 对空字段执行丢弃、填充或标记策略，并记录处理日志。
- 有效期设定 — 标注每条数据的时间窗口与回溯期限，过期数据自动失效。
步骤一：数据源接入
按以下映射关系从各平台提取数据，字段名统一采用下划线命名法。
| 数据源 | 核心字段 | 拉取方式 | 频率 |
|---|---|---|---|
| 实验平台 | experiment_id, variant, user_count, conversion_count, start_time, end_time | API / 导出CSV | 每日一次 |
| 埋点系统 | event_name, distinct_id, event_time, properties (版本号、渠道) | SQL查询 / SDK回调 | 实时流 + 离线T+1 |
| 项目排期 | project_name, experiment_id, planned_start, planned_end, owner, stage | 飞书 / Jira / 在线表格 | 每周同步 |
常见陷阱：实验平台的
user_count 有时包含重复ID（用户跨设备登录），须在清洗阶段去重；埋点系统的事件时间戳务必确认时区（统一使用UTC+8）。
步骤二：数据清洗规则
所有数据在进入评分前必须通过以下4类清洗规则，未通过的记录进入异常数据池留待复核。
| 规则类别 | 规则说明 | 示例 |
|---|---|---|
| 格式统一 | 时间戳转为ISO 8601；数值字段去除千分位逗号；布尔值统一为0/1 | "1,234" → 1234 |
| 去重 | 按 experiment_id + variant + distinct_id 组合键去重，保留最早一条 | 组合键重复 → 删除后写入log |
| 范围校验 | conversion_rate ∈ [0,1]；user_count > 0；日期不晚于当前时间 | conversion_rate = 1.5 → 标记异常 |
| 逻辑校验 | 对照组与实验组人数比例符合实验设计（偏差 < 5%） | 分流比应为50:50，实际为80:20 → 告警 |
# 清洗规则配置示例（JSON）
{
"rules": [
{"type": "format", "field": "event_time", "action": "to_iso8601"},
{"type": "dedup", "keys": ["experiment_id", "variant", "distinct_id"], "strategy": "keep_first"},
{"type": "range", "field": "user_count", "min": 1, "max": 10000000},
{"type": "logic", "description": "分流比偏差 < 5%", "expression": "abs(control_n/total_n - 0.5) < 0.05"}
]
}步骤三：缺失值处理
按字段类型和缺失比例执行分级处理策略，所有操作须记录在缺失值处理日志中。
| 缺失字段 | 缺失比例 | 处理策略 | 影响评估 |
|---|---|---|---|
conversion_count | ≤ 2% | 用实验组平均值填充 | RICE置信度降低0.1 |
variant | ≤ 1% | 丢弃整行记录 | 不影响整体分布 |
planned_end | ≤ 5% | 标记为“待确认”，有效期暂按计划开始+14天计算 | 需人工复核 |
| 其他字段 | > 5% | 停止处理，告警通知数据负责人 | 暂不纳入评分 |
最佳实践：对于
conversion_count 缺失的场景，除了填充平均值，还应同时输出 “填充标记列”（is_imputed: true/false），方便后续敏感性分析时剔除填充数据做稳健性检验。
步骤四：数据有效期设定
每条数据必须携带明确的有效期窗口，过期数据在评分时自动权重归零。
- 基础有效期：
[experiment.start_time, experiment.end_time + 3天]（3天为数据回补缓冲期）。 - 回溯窗口：埋点事件的时间戳必须在实验运行期 ± 7天范围内，超出此范围的数据不参与计算。
- 排期变更：当项目排期表更新时，对应的
planned_end变化超过2天，该条数据有效期自动失效，需重新拉取。
# 有效期判定伪代码
if event_time < experiment.start_time - 7d:
mark_invalid(reason="事件早于回溯窗口")
elif event_time > experiment.end_time + 3d:
mark_invalid(reason="超出数据回补缓冲期")
else:
mark_valid(expire_at = experiment.end_time + 3d)输入输出物
| 类型 | 名称 | 格式 | 备注 |
|---|---|---|---|
| 输入 | 实验平台原始数据 | CSV / Parquet | 含分组统计与元信息 |
| 输入 | 埋点事件日志 | JSONL / 数仓表 | 每日分区 |
| 输入 | 项目排期表 | Google Sheets / 飞书表格 | 人工维护 |
| 输出 | 清洗后宽表 | Parquet + 数据字典 | 主键：experiment_id + distinct_id + variant |
| 输出 | 异常数据池 | CSV + 异常原因列 | 供人工复核 |
| 输出 | 缺失值处理日志 | JSONL + 统计摘要 | 每条记录包含原值、填充值、策略 |
责任边界
| 角色 | 职责 | 交付物 | 验收人 |
|---|---|---|---|
| 数据工程师 | 搭建数据管道，确保三大数据源按时汇聚至临时工作区 | 数据接入状态看板 | 产品经理 |
| 产品经理 | 维护项目排期表，保证experiment_id与实验平台一致 | 排期表最新版本 | 数据分析师 |
| 数据分析师 | 执行清洗规则、缺失值处理、有效期标注 | 清洗后宽表 + 处理日志 | 数据工程师 |
| 增长负责人 | 终验数据清单，确认可进入RICE评分环节 | 数据就绪签署单 | 项目组 |
记录材料
每次数据准备须归档以下材料，保存至实验结束后90天：
- 数据接入状态日志：记录各数据源拉取时间、行数、异常数。
- 清洗规则执行报告：每条规则的命中记录及处理结果。
- 缺失值处理日志：字段、缺失比例、处理策略、填充值。
- 有效期标注快照：含每条数据的
valid_from和valid_until。 - 异常数据池复核记录：人工复核结论及是否回补。
异常处理
异常分级响应机制：根据影响范围分为三级，对应不同处理时效。
| 异常等级 | 典型场景 | 处理措施 | 响应时限 |
|---|---|---|---|
| P0 | 三大数据源任一不可用超过4小时 | 立即发起on-call，切换离线备份，暂停评分 | 30分钟内 |
| P1 | 清洗规则发现 > 10% 数据被标记异常 | 通知数据工程师核查上游，暂不发布评分结果 | 2个工作日内 |
| P2 | 缺失值处理比例超过预设阈值（5%） | 自动告警至分析师，人工复核后补充或重跑 | 1个工作日内 |
验收标准
数据准备清单通过验收须同时满足以下条件：
- 完整性：清洗后宽表记录数与三大数据源原始记录数偏差 < 0.5%（剔除的异常记录须在日志中说明）。
- 一致性：随机抽取5%的实验ID，人工比对宽表数据与原始平台界面数据一致。
- 时效性：所有数据有效期标注正确，不存在过期数据参与评分的情况。
- 可追溯：缺失值处理日志中每条填充记录均可还原原始值，支持回滚。
- 签名确认：增长负责人已在数据就绪签署单上电子签名或确认已读。