4. 案例背景说明

本章正式进入课程案例，通过一个完整的模拟业务场景，展示如何将RICE框架应用于A/B测试结果分析。所有后续章节的操作步骤、计算模型与置信度提升方法均基于本案例展开。请仔细阅读并理解以下背景信息。

4.1 适用场景

• 场景类型：SaaS产品内核心功能模块改版的效果验证，适用于功能迭代、UI调整、新机制上线前的灰度实验。
• 决策痛点：原始A/B测试仅呈现统计显著性(p值)，团队无法判断该改动是否值得投入工程资源、是否具有长期商业潜力、该改动与其他待办任务相比优先级如何。
• 适用时机：已完成首次A/B测试并产出结果，但需要进一步量化ROI、对齐业务目标以做出推进/回滚/优化决策的阶段。

4.2 前置条件

1. 已完成至少一轮A/B测试实验，获得基础统计结论（p值与置信区间）。
2. 已定义清晰的核心业务指标与辅助观测指标。
3. 已有完整的实验埋点日志与数据库记录，支持二次计算。
4. 已有明确的业务目标，如提升转化率、提高用户留存或增加单用户收入。

4.3 业务场景描述

某B2B SaaS平台（“智汇文档”）的“企业协作空间”模块近期上线了一个新功能——“智能任务看板”。该功能允许用户在文档内直接创建、分配和追踪任务，并自动同步至日历。产品经理希望通过A/B测试验证“智能任务看板”能否提升用户周活跃度（WAU）与付费转化率。

4.3.1 原始A/B测试设计

4.3.2 观测指标与数据来源

原始实验共设定三个核心指标，数据来源于后端事件日志与支付系统。

4.3.3 其他辅助数据样本

为支撑RICE计算中的置信度维度，还需收集以下辅助数据：

• 用户反馈NPS数据：实验周期内两组用户分别提交的净推荐值评分（1-10分），用于评估用户对改版的主观感受。
• 任务完成率：已创建任务中，标注为“已完成”的比例，用于评估功能粘性。
• 单用户平均使用时长：活跃用户日均使用“智能任务看板”功能的秒数。

4.4 输入输出物

4.5 责任边界

• 数据工程师：提供符合规范的数据集，确保分组信息与事件日志可交叉追溯。
• 产品经理：对业务目标（如WAU、F2P）负责，主导RICE评分中的Impact与Confidence打分。
• 数据分析师：计算原始指标，提供辅助数据（如NPS、使用时长），并作为RICE框架的评审专家。
• 实验负责人：最终确认RICE评分结果并给出推进/回滚/优化建议。

4.6 异常处理

• 数据不完整：若实验期间某天埋点日志缺失超过5%，须标记该天数据为“不可信”，并从计算中剔除。
• 样本偏斜：检查两组在“企业规模”（员工数）与“使用年限”上的分布，若出现显著差异(KS检验p<0.05)，需做分层校正后再计算指标。
• 实验提前终止：若实验组用户大面积报告功能严重Bug导致无法正常使用，应立即终止实验并回滚至旧版，本案例视为无效实验。

4.7 案例流程框架

下图为案例“智能任务看板”从业务场景识别到核心指标落地的整体流程框架，后续章节将基于图中的每一个环节展开细节。

4.8 验收标准

在进入第5章——RICE评分详解之前，请确认本章已完成以下验收：

• 我理解了“智能任务看板”的业务场景与原始A/B测试设计细节。
• 我能准确说出三个核心观测指标（WAU、TCR、F2P）及其原始实验结果。
• 我掌握了本章提供的输入输出物清单，能够在自己工作中复现类似数据准备。
• 我理解了案例中原始结论的决策困境——局部显著但全局目标模糊。