业务指标与交付范围

1. 从“提升复购”到可执行的项目目标

北极星指标是帮助团队保持方向的核心结果指标，不是把复杂业务压成一个数字。选择时至少检查三点：是否有稳定可复算的数据；项目是否可能影响它；变化后能否指导下一步行动。若销售额同时受价格、门店、促销、季节和渠道影响，只报销售额上涨不能证明 Agent 有效。

在本课合成项目中，可以把“完成完整观察窗的新会员 30 天复购率”作为候选结果指标，把“有证据的建议采纳率”和“有效执行率”作为过程指标。它们分别回答业务是否改善、建议是否被使用、动作是否完成，不能互相代替。最终是否采用这组指标，要经过业务与财务共同确认。

2. 指标契约必须回答的八个问题

先处理右截尾问题：如果某会员昨天才首购，今天没有复购并不能说明其 30 天内不会复购。把这些人提前放入分母会低估指标，也会让不同时间点无法比较。跨店购买是否算复购、首购是集团首购还是本店首购，同样会改变结论。

3. 将口径写成可以执行的计算

先用极小样本手工推演，再用 SQL 或 Python 重算。下例是教学查询，假设 valid_orders 已完成身份映射、去重、有效订单筛选和业务时区归一；一行是一笔有效订单，order_day 使用 YYYY-MM-DD。它计算集团范围的首次购买口径，不等同于下载包现有的门店范围口径。执行前必须选择一种口径并写入契约。

WITH first_purchase AS (
  SELECT member_id, MIN(order_day) AS first_day
  FROM valid_orders
  GROUP BY member_id
), eligible AS (
  SELECT * FROM first_purchase
  WHERE julianday(:as_of) - julianday(first_day) >= 30
), scored AS (
  SELECT e.member_id,
    EXISTS (
      SELECT 1 FROM valid_orders o
      WHERE o.member_id = e.member_id
        AND o.order_day > e.first_day
        AND julianday(o.order_day) - julianday(e.first_day) <= 30
        AND o.order_day <= :as_of
    ) AS repeated
  FROM eligible e
)
SELECT COUNT(*) AS denominator, SUM(repeated) AS numerator,
       1.0 * SUM(repeated) / NULLIF(COUNT(*), 0) AS rate
FROM scored;

这段日期级示例将同日加购排除在复购之外；若业务需要区分同日不同会话，应改为时间戳和会话级定义，不能直接沿用查询。无合格分母时结果应为空或明确“不可计算”，而不是伪造 0%。先写测试：第 29/30/31 天购买、首购未满 30 天、退款后重购、重复订单、跨店订单、同日两笔订单。

4. 范围取舍：先做什么、后做什么、不做什么

优先级需要把业务价值、技术可行性、交付成本和风险放在一起讨论，而不是按功能投票。可以先做 A 店的只读分析和建议，验证身份、口径和业务质量；执行动作需等连接器、权限、预算和评估条件具备后再增加。这样不是天然保守，而是把不同风险的能力放到可检查的里程碑中。

每个范围项都应能对应交付物和验收方法。“建设会员智能运营体系”无法直接验收；“在冻结样本上按契约重算指标，输出含证据和排除说明的人群建议”则可以。排除项同样重要，例如不进行跨租户查询、不自动更改价格、不承诺未经验证的收入提升、不接管现有支付系统。

若规则或一次查询已经能解决目标问题，应保留这个基线。后续增加 Agent 的理由，应来自它对模糊目标、澄清、工具选择和异常处理的增益，而不是为了满足技术名词清单。

5. SOW 如何支持交付，而不是只支持签字

SOW 是工作说明。真正有用的版本把目标、范围、交付物、里程碑、依赖、验收和变更连接起来。实际合同、付款和责任约定应由商务与法律专业人员复核；本课模板只是教学结构，不是可直接签署的法律文本。

付款节点和验收节点需要一致，但不能用付款压力逼迫夸大效果。若需要将费用与业务结果关联，必须另行定义归因、观察窗、共同责任和不可控因素，第 10 周会进一步展开。

6. 财务访谈与范围冻结演练

财务角色提出：“复购率涨了，但券成本和毛利怎么算？”这是本周必须解决的有效问题。将结果指标与经济性分开：复购变化、活动成本、核销成本、运营人工和系统运行费用都需要明确口径。券发出不等于券已核销，核销不等于增量交易，交易额也不等于利润。

用一个合成例子说明：100 名完整观察窗会员中 20 人复购，复购率为 20%；另一张表把 25 名观察窗不足者计入，结果是 16%。两张表不一定有人算错，而是分母不同。范围评审应冻结口径和数据截止日，同时保留旧口径作为对照。后续发现合理的新口径时，通过版本和回算说明变更，不能静默替换历史结果。

案例阅读可参照 OpenAI Frontier 公告中的企业部署线索 ↗。将公开提及的场景拆成业务决定、数据输入和衡量方式；未披露的经济收益、工期和团队投入应写“未知”，而不是为了让案例完整而填入推测。

7. 本周应形成怎样的交付包

提交一份指标契约、一段可运行查询或计算脚本、一组反例测试、一份范围说明和一次评审决定记录。指标文档与代码应使用同一个版本号，并互相链接。至少让一名未参与编写的人根据文档重算小样本；如果其需要不断问你“这里到底是什么意思”，说明口径还没有写完整。

评审会议不应只演示最终百分比。先给一个人的订单轨迹，说明为何进入分母、为何进入或不进入分子；再展示整体结果和排除记录；最后讨论这组指标能支持什么决定、尚不能支持什么因果结论。

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

必做：完成财务/核算角色访谈；提交指标契约及至少六类边界样本；实现一段指标计算；完成 SOW 教学草案，包含排除项、依赖和变更流程。

思考：客户坚持用一个更容易上涨、但与项目影响关系更弱的指标验收，你如何展示差异并提出兼顾商业目标与技术可验证性的组合？

进阶：为同一数据生成两个合法口径的对账报告，量化身份、观察窗和跨店规则各自造成的差异，不把“统一”理解为删除所有业务视角。

验收要求：公式与实现一致；零分母和时间边界有测试；业务、系统、采用指标未混用；范围中的每个承诺有验收方法；真实商业条款明确需要专业复核。没有获得一致意见的口径必须保留为未决项，不得标成已确认。