第4章 Reach数据采集方法：后台数据提取、用户调研、第三方报告、数据清洗规则
章前提示：Reach指标（触达/覆盖）的原始数据来源直接影响RICE优先级计算的客观性。本章聚焦四种主流采集方式及其清洗规范，确保数据“可溯源、可审计、可对比”。
4.1 适用场景
- 后台数据提取：产品已有完整埋点体系（DAU/MAU/曝光UV），需批量获取历史时段覆盖数据。
- 用户调研：新产品或未上线功能，需通过问卷/访谈估算目标人群中的触达比例。
- 第三方报告：行业基准对比、竞品覆盖度量（如Sensor Tower、App Annie、易观/QuestMobile）。
- 数据清洗规则：所有原始数据在进入RICE模型前必须经过统一清洗流程，消除离群、重复、时间窗口不匹配等问题。
4.2 前置条件
| 条件类别 | 具体要求 |
|---|---|
| 数据源授权 | 后台数据需有数据库/BI平台读取权限；调研需目标用户池名单及伦理审批 |
| 时间窗口定义 | 统一使用“近30日活跃/曝光”作为Reach基线，避免跨版本周期混用 |
| 清洗环境 | 至少一个可执行Python脚本或SQL引擎的工作站（如Jupyter Notebook、MySQL Workbench） |
| 标识符统一 | 用户ID、设备ID、Cookie等去重标识必须预先映射为统一匿名ID（如SparkID） |
4.3 操作步骤
- 后台数据提取
- 连接数据仓库（如Hive、ClickHouse），提取近30天表
dws_user_active_daily。 - 筛选出“曝光事件 ≥ 1”的用户，按功能模块聚合UV。
- 导出CSV：
reach_backend_yyyy-mm-dd.csv，字段包括功能ID、UV、日期。
- 连接数据仓库（如Hive、ClickHouse），提取近30天表
- 用户调研采集
- 设计选择题：“在过去30天内，您是否使用过XXX功能？”（四选一：用过≥1次/知道但未用/不知道/记不清）。
- 回收至少300份有效问卷（置信度95%，误差±5%），按用户分层加权。
- 输出
reach_survey_id_mapping.xlsx，含用户ID、覆盖标记（0/1）。
- 第三方报告
- 确认报告口径：是否为“月活跃用户覆盖百分比”？数据采集时间是否与内部窗口重叠？
- 手动转录或购买API获取覆盖数据，记录报告来源、版本、日期。
- 存储为
reach_3rd_provider_yyyy-mm-dd.json，按功能/场景分类。
- 数据清洗规则
- 去重：按用户ID去重，保留最早一条记录或最新一条（依场景定）。
- 异常值过滤：剔除 UV > 总用户数 或 > 行业CVR 3σ以外的样本。
- 时间对齐：将所有数据统一到“近30日滑动窗口”，补齐缺失日期（用前值填充或移动平均）。
- 转换格式：统一数值类型为整型(INT)，空值填0，异常文本标记为
NaN。
⚠ 常见踩坑点：后台数据与调研数据往往存在“渠道覆盖差”——后台统计的是所有设备，而调研只覆盖回答样本。务必在清洗阶段增加“信心因子”（置信度权重），不要直接合并相加。
4.4 输入输出物
| 环节 | 输入物 | 输出物 |
|---|---|---|
| 后台提取 | 数据仓库连接信息、提取SQL脚本 | reach_backend_raw.csv（含功能ID、UV、日期） |
| 用户调研 | 问卷链接、用户池ID列表 | reach_survey_cleaned.xlsx（含用户映射、覆盖标记） |
| 第三方报告 | 报告PDF/API响应、提取模板 | reach_3rd_provider_clean.json |
| 清洗规则 | 原始数据集、清洗规则配置文件（YAML） | reach_master_merged.parquet（标准格式主表） |
4.5 责任边界
- 数据工程组：完成后台数据提取并确保口径一致；提供清洗规则白皮书。
- 产品/市场组：设计并执行用户调研，保证样本无偏差；提供第三方报告原始文件。
- 分析/数据科学组：执行清洗规则，生成主表；记录每个环节的转换日志。
- RICE评估负责人：审核最终表，确认无数据污染；标记所有异常回退记录。
4.6 记录材料
- 数据血缘图：至少一张DAG图表，标明每个数据源→清洗节点→最终表。
- 清洗执行日志：每步操作时间、原始行数、剔除行数、异常描述。
- 版本快照：每次运行生成
reach_run_metadata.txt，记录参数与规则版本号。 - 调研原始应答：脱敏后的CSV文件，保留回答时间与渠道标记。
4.7 异常处理
| 异常场景 | 处理方式 |
|---|---|
| 后台数据缺失部分日期 | 先标记缺失日期，使用前7天平均值填充；填充量超过20%则标记为低可信，退回数据组 |
| 调研回收量低于300份 | 扩大投放渠道，若无法扩量则在清洗时增加“样本置信度惩罚系数”（0.5~0.8） |
| 第三方报告指标定义不一致 | 寻找同口径替代报告，或手动换算（如MAU→WAU需提供换算系数），并在记录中注明换算公式 |
| 清洗后UV总数与后台基础表偏差 >10% | 立即停止上游使用，检查去重逻辑和执行顺序，输出偏差分析报告 |
4.8 验收标准
- ✅ 四种数据源均有对应原始文件与清洗后文件，且命名符合规范。
- ✅ 清洗规则配置文件（YAML）版本号与运行日志匹配。
- ✅ 最终主表
reach_master_merged.parquet总行数 = 各源去重合并后记录数之和，且无重复用户ID。 - ✅ 任意两条来源的相同功能UV差异不超过 15%（调研数据需计算置信区间上限）。
- ✅ 所有异常处理记录已存档于
reach_exception_log.xlsx。
💡 实操建议：建议将清洗规则写成可复用的Python模块（如
reach_cleaner.py），接受YAML配置参数。首次运行需完整输出清洗前后对比报告，后续增量更新只需执行差异部分。