第3章 实验数据采集规范
规范的数据采集是A/B实验结论可信的基石。本章定义从指标定义到标准清洗的完整SOP,确保每次实验的数据可复现、可审计、可直接用于优先级排序分析。
3.1 适用场景
- 实验上线后数据接入:实验已全量发布,需要规范采集用户行为、业务指标数据。
- 多数据源统一处理:客户端埋点、服务端日志、第三方SDK(如GA、Firebase)需要合并清洗。
- 大规模自动化校验:实验涉及百万级以上用户,必须通过脚本或ETL完成清洗,不能依赖人工。
- 团队协作审计:需要留下可回溯的清洗记录,支撑实验复盘、监管合规或数据再加工。
3.2 前置条件
| 条件 | 验收标准 | 负责人 |
|---|---|---|
| 实验已上线、埋点已部署 | 数据仓库中能看到原始事件表 | 工程开发 |
| 数据字典通过评审 | 指标名称、类型、业务含义已归档 | 数据科学家 |
| 数据源接入权限就绪 | 可以拉取指定时间范围的原始数据 | 数仓工程师 |
| 清洗逻辑ETL脚本已开发 | 脚本在测试环境运行无报错 | 数据工程师 |
| 数据质量基线已建立 | 历史无清洗记录的存量数据已标注 | QA |
3.3 操作步骤
数据采集规范遵循“定义→确认→清洗→异常→填充”五阶段流水线。下图展示完整流程,后续按步骤逐一拆解。
步骤一:指标定义表
适用场景:实验启动前,必须完成指标的结构化定义,确保团队对每个指标的理解一致。
| 字段 | 必填 | 示例 |
|---|---|---|
| 指标名称 | 是 | ctr_experiment |
| 数据类型 | 是 | float (0.0–1.0) |
| 业务含义 | 是 | 实验组点击次数 / 曝光次数 |
| 聚合粒度 | 是 | 用户级别 × 实验日 |
| 取值边界 | 是 | [0.0, 1.0] |
| 埋点事件ID | 是 | event_click / event_impression |
| 折算公式 | 否 | SUM(click) / COUNT(impression) |
步骤二:数据来源确认
- 操作:对照指标定义表,逐一确认每个字段的来源表名、分区字段、拉取SQL。
- 输出:
数据来源清单.csv,包含字段名、来源表、更新频率、最后确认时间。 - 异常:若某个指标找不到对应数据源,需在“记录材料”中标记并联系工程团队补齐埋点。
步骤三:清洗规则
清洗规则应覆盖常见数据质量问题,并使用参数化ETL脚本执行。
| 规则类别 | 规则说明 | 处理方式 |
|---|---|---|
| 重复数据 | 同一用户同一事件多次记录 | 保留第一条(按时间戳升序),其余剔除 |
| 格式修正 | 时间戳格式不一致(如“2024-01-01” vs “01/01/2024”) | 统一转换为ISO 8601 |
| 逻辑校验 | 点击数大于曝光数 | 剔除该条记录并标记 |
| 分组校验 | 实验分组标识(variant_id)不在字典中 | 标记为“未定义分组”,按缺失值处理 |
步骤四:异常值处理
异常值标准:以下条件之一即判定为异常——
- 数值超出3个标准差(基于实验前7天历史数据)
- 取值不在指标定义表的取值边界内
- 业务逻辑矛盾(如注册时间早于出生日期)
处理方式:
- 记录到
异常值处理记录表(字段:用户ID、指标名、异常值、判断依据、处理结果)。 - 默认剔除,但若剔除后样本量减少超过5%,需人工复核。
- 复核后仍保留的异常值必须在分析报告中注明。
步骤五:缺失值填充标准
| 缺失类型 | 判断方式 | 填充方法 |
|---|---|---|
| 随机缺失(MAR) | 缺失与观测值无关 | 中位数填充(连续变量)/ 众数填充(分类变量) |
| 非随机缺失(MNAR) | 缺失与未观测变量有关 | 标记为“-1”或“unknown”,不填充 |
| 结构缺失(如未曝光无点击) | 业务设计导致 | 填写0,但需记录原因 |
Tips:建议在填充前先做缺失比例分析。如果某一列的缺失比例超过20%,应重新审视数据来源或考虑删除该列,而非盲目填充。
3.4 输入输出物
| 类别 | 物名称 | 说明 |
|---|---|---|
| 输入 | 原始埋点日志 | 客户端/服务端原始日志,至少包括事件ID、用户ID、时间戳、实验分组、所有指标字段 |
| 数据字典 & 指标定义表 | 步骤一输出的结构化文档,作为清洗规则的唯一基准 | |
| 输出 | 清洗后数据集 | 已通过完整清洗流程的表,可直接用于A/B分析 |
| 异常值处理记录表 | 包含每个异常值的上下文和处理决策 | |
| 缺失值填充记录表 | 包含每列缺失比例、填充方法、填充值 |
3.5 责任边界
- 数据科学家:输出指标定义表、制定清洗规则与异常值/缺失值标准。
- 数据工程师:实现ETL脚本,执行清洗流程,生成输出表与记录表。
- 产品经理:确认指标业务含义,参与异常值复核决策。
- QA:对清洗前后数据进行抽样对比,验证流程正确性。
3.6 记录材料
每批次实验数据采集完成后,必须归档以下材料:
- 指标定义表(PDF/Excel,版本号+修订日期)
- 数据来源清单(含每个字段的拉取SQL或表路径)
- 清洗规则日志(每条规则的触发次数、被剔除/修正的记录数)
- 异常值处理记录(用户级明细,含处置理由)
- 缺失值填充标准报告(列级缺失比例、填充方法、填充值)
3.7 异常处理
| 异常场景 | 触发条件 | 处理方式 |
|---|---|---|
| 指标定义冲突 | 同一指标在字典中有多个不一致的定义 | 冻结当前批次,由数据科学家与PM在24小时内评审统一 |
| 数据源断连 | ETL脚本无法拉取某张表 | 自动重试3次(间隔10分钟),仍失败则标记并跳过该数据源 |
| 异常值比例超限 | 异常值 > 样本量5% | 暂停清洗,输出异常明细报告,由数据科学家确认是数据异常还是业务波动 |
| 缺失值比例超限 | 某列缺失 > 20% | 默认不填充该列,在报告中标红,由决策层决定是否剔除该列 |
| 清洗脚本报错 | ETL运行返回非零状态 | 回滚至清洗前状态,重跑上一批次检查点,修复脚本后重新执行 |
重点提醒:所有异常处理都必须保留
异常处理日志,包括时间、场景、处理人、处理结果。否则在实验复盘时,异常记录缺失会被视为流程不合规,直接影响优先级排序的可信度。
3.8 验收标准
- 完整性:清洗后的数据集与原数据集的记录数差异必须小于1%(剔除的无效记录需提供清单)。
- 一致性:随机抽取10%的清洗后数据,人工对比20个关键字段,一致率100%。
- 可追溯:每一条异常值或缺失记录都能在相应处理表中找到原因和决策。
- 可复现:将清洗脚本重新运行一次,输出结果与首次运行完全一致(增量数据影响除外)。
- 文档齐全:3.6节要求的5份记录材料全部归档且版本号匹配。
数据采集规范不是一次性工作。每轮实验启动前,都需要按本章SOP重新执行一次清洗流程,并对比上一次清洗的基线变化。持续积累清洗记录,可以帮助团队提前发现埋点退化、数据源变更等问题,减少对优先级排序的干扰。