效果归因与项目验收

1. 验收需要三层判断

验收会不是把功能清单逐项打勾后宣布“项目成功”。系统能力、真实使用和业务结果应分开核对：系统层看任务评估与运行要求是否达标；行为层看使用者是否采用、动作是否完成；业务层看事先约定的结果指标及其解释。

三层之间有关联，但不存在自动推导。任务准确率高，不代表员工愿意用；采用率高，不代表带来增量收益；收入上涨，也不证明系统没有严重安全问题。验收材料应让委员会同时看到已完成项、未完成项和证据边界。

2. 效果分析先检查数据成熟度

本课目标涉及 30 天复购，刚收到券的会员不应立即被记作“未复购”。券发出、核销、交易、退款可能发生在不同时间，数据也可能延迟到达。分析前应冻结数据截止时间、纳入批次、完整观察窗、退款处理和身份映射版本。

对实验组和对照组分别检查样本构成：门店、渠道、首购时间、历史购买、促销参与等是否明显不同。不要在结果出来后随意删掉“不好看”的门店。如果事先定义了排除规则，应保留排除人数与理由；若后来发现数据问题，需要透明地报告调整前后结果。

3. 对照设计与差分法

条件允许时，事先设计随机分组通常比事后选择“看起来差不多”的人群更容易支持因果解释，但仍需处理执行偏差、样本量和干扰。无法随机时，可以使用对照方法分析，但必须说明选择依据和假设。

差分中的差分（DiD）比较实验组的前后变化与对照组的前后变化。它试图扣除共同变化，不会自动消除所有差异。关键假设包括没有处理时两组趋势具有可比性，以及没有只影响其中一组的同期冲击。只有一个基线时间点，无法充分检验平行趋势；如果有多期数据，应检查趋势、安慰剂结果和敏感性。

treated_before, treated_after = 0.20, 0.28
control_before, control_after = 0.18, 0.23
did = (treated_after - treated_before) - (control_after - control_before)
print(round(did * 100, 2))  # 3.0 个百分点；这里只验证算术

这四个百分比不能用于计算置信区间，也不能证明真实因果收益。还需要样本数量、分组方式、多期数据和适当的统计方法；存在门店聚类或重复观察时，误差估计也需要相应处理。参阅 世界银行 DIME 的 DiD 说明 ↗和只有基线数据时的局限 ↗。真实商业结算所用分析应由适当专业人员复核。

4. 如何处理核销延迟、污染与执行差异

若实验组收到建议却没有执行，应区分“被分配到策略”的效果与“实际执行者”的表现。只挑执行成功的人分析，可能引入选择偏差。跨店购买、共享优惠、同一人员同时接触两种活动，也可能造成组间污染。

对于核销延迟，可以事先规定观察窗和成熟批次，同时报告尚未成熟的批次；不要为了赶验收把所有待观察人群记成失败，也不要只报告最早成功的几个样本。对无法控制的同期促销、价格或门店变化，应在结果解释中列出，而不是用“模型贡献”覆盖。

5. 结果约定与商业风险

结果约定需要回答四个问题：交付什么结果、用什么数据测量、双方各自负责什么、出现分歧怎样核对。本课把这份教学文档称为 Outcome-Level Agreement（结果约定）；这是课程使用的名称，不是标准合同格式，也不同于 IT 服务管理中的 Operational Level Agreement。

一份教学版结果约定至少包含结果指标、基线、数据权利、测量周期、归因方法、双方依赖、排除项、争议处理和复查安排。它不能把所有结果责任都交给模型供应方，也不能让服务方只要系统上线就不再关心采用。

阅读 RaaS 结果服务案例，将“按结果付费”拆成指标、基线、执行、归因和结算五项工作。合成试点复购率提升 8 个百分点，对照提升 5 个百分点，差分为 3 个百分点；仍需检查分组、趋势与同期活动，不能只凭差值认定因果。

提交一张可重算结算表，分别列增量收入、毛利、补贴、退货、人工与系统成本，并记录客户未执行的动作。比较固定费、里程碑与混合结果费如何分配风险。实际合同、价格与结算安排需专业复核。

6. 验收材料怎样组织

建议按“范围与原始目标 → 交付版本 → 系统证据 → 使用证据 → 业务分析 → 未达项 → 后续安排”组织。每个结论能链接到测试、数据或记录，避免只有截图。附录放完整评估和口径，主汇报先解释最重要的差异与决定。

委员会可能提出：财务希望降低尾款；业务负责人希望承诺下一阶段增长；IT 要求补充长期运维。分别回应范围履行、效果边界和未来服务，不把三件事混成一次口头妥协。合理的新要求可以形成后续阶段，不应静默变成本期既有义务。

7. 结果不显著时如何汇报

可以准确地说：“本期已完成范围内的系统和使用验证；观察期内业务差异尚不足以支持明确的增量收益结论。当前主要限制是样本与观察窗。建议延长验证，并保持写动作在已验证范围内。”随后给出成本、周期和停止条件，让对方可以做决定。

不要将“不显著”说成“一定没有效果”，也不要用几个成功故事覆盖总体不确定性。解释清楚什么已经被证明、什么尚未证明，本身就是 FDE 的商业判断能力。

8. 必做作业、思考与验收

必做：运行合成效果分析脚本；提交样本、口径、观察窗、对照和局限说明；完成三层验收材料及一份可用于委员会汇报的结构稿。系统评估和业务归因应分别有证据入口。

思考：若系统层通过、用户采用良好，但短期业务结果不明确，你建议验收、继续试点还是暂停扩展？根据事先范围、证据和风险说明，不给所有项目同一个答案。

进阶：设计一份混合结果费用的教学方案，列出不能由服务方独立控制的条件，以及数据争议和客户未执行时的处理方式。

验收要求：未把前后差异全部归因于 Agent；百分点和百分比正确；未成熟样本与零分母有处理；系统、安全和商业证据未混用；未达项没有被删除；下一步有清楚的验证与停止条件。