76 lines
5.8 KiB
Markdown
76 lines
5.8 KiB
Markdown
# 试点指标采集与 Phase 2 决策方案
|
||
|
||
> 日期：2026-08-02
|
||
> 适用：3～5 家独立宠物洗护单店
|
||
> 样本闸门：约 200 次完整服务
|
||
> 状态：指标口径冻结；等待真实试点数据
|
||
|
||
## 1. 决策目的
|
||
|
||
这轮试点不证明“功能很多”，只验证三件事：门店是否能连续履约、报告是否真的到达宠主、回访是否能形成可归因的再次预约。在样本闸门满足前，不进入支付、库存、储值、复杂会员、多门店组织、订单系统或泛 AI。
|
||
|
||
“完整服务”定义为同店一笔 Appointment 产生唯一 `service_completed` 事实。当前该事实只在进行中的预约成功提交唯一 Report 并转为 `done` 时产生，因此不能由页面点击或手工报表补记。
|
||
|
||
## 2. 样本与时间边界
|
||
|
||
- 试点门店：3～5 家已完成开通、实际提供洗护服务的独立单店。
|
||
- 观察期：建议 4～8 周；所有日报/周报统一使用 Asia/Shanghai，时间窗口为 `[from, to)`。
|
||
- 总样本闸门：全店合计 `complete_service_count ≥ 200`。
|
||
- 分布闸门：每家进入结论的门店至少 25 次完整服务，避免单店数据支配判断。
|
||
- 质量闸门：31 项 production preflight 全为 0；指标查询的四项可靠性反例全为 0。
|
||
- 第 50 次完整服务做一次口径复核，只允许修正采集缺陷；不得为了达标追溯篡改既有事件或更换分母。
|
||
|
||
## 3. 指标字典
|
||
|
||
| 指标 | 计算 | 用途 |
|
||
|------|------|------|
|
||
| 完整服务数 | 去重 `service_completed.aggregateId` | 200 次样本主闸门 |
|
||
| 履约闭环率 | 完整服务 / `service_started` | 店员能否顺畅完成服务与报告 |
|
||
| 报告确认发送率 | 同窗提交后形成 `report_sent` 的报告 / 同窗 `report_submitted` 报告 | 报告是否真正进入传播动作 |
|
||
| 24h 内发送率 | 提交后 24h 内首次 `report_sent` / 已完整观察 24h 的提交 cohort | 值班流程是否及时；窗口末 24h 的新报告暂不进分母 |
|
||
| 报告打开率 | 同窗确认发送后去重打开的报告 / 同窗已确认发送报告 | 宠主是否收到并愿意打开；员工预览或发送前打开不计 |
|
||
| 打开→留资率 | 打开后产生留资的去重报告 / 已打开报告 | 下次服务提醒是否有价值；按报告而非线索条数，避免多人手机号放大 |
|
||
| 留资→再次预约率 | 同窗留资中形成 `rebook_created` 的 source lead / 同窗 `lead_submitted` | 回访商业闭环；只认 FollowUpTask 关联的真实 Appointment |
|
||
| 到期回访按时完成率 | due_date 后两天结束前完成 / 已完成任务 | 员工是否真正执行队列 |
|
||
| 回访平均联系次数 | AVG attempt_count | 联系成本与任务设计负担 |
|
||
| 无效联系方式率 | invalid_contact / 已终结任务 | 留资质量与输入校验 |
|
||
| 退订数 | canceled + unsubscribed | 尊重宠主意愿并观察打扰风险 |
|
||
|
||
比率在分母为 0 时返回 NULL，不展示 0%，避免把“没有样本”误解为“表现为零”。所有漏斗按门店分别看，再做全店汇总；不公布跨店客户级明细。
|
||
|
||
## 4. 决策观察带
|
||
|
||
以下是试点判断带，不是对外承诺；第 50 次样本只做一次合理性复核：
|
||
|
||
| 信号 | 健康观察带 | 需要访谈/修复 |
|
||
|------|------------|---------------|
|
||
| 履约闭环率 | ≥ 90% | 低于 90%：查开始服务时机、报告填写负担、异常中断 |
|
||
| 24h 内报告发送率 | ≥ 85% | 低于 85%：查工作台提醒、交接班与发送确认理解 |
|
||
| 报告打开率 | ≥ 60% | 低于 60%：查发送渠道、链接可达性、宠主认知 |
|
||
| 到期回访按时完成率 | ≥ 80% | 低于 80%：查领取机制、日期建议与人员负荷 |
|
||
| 归因完整性 | 100% | 任一伪 rebook 或事件缺失即停止使用该指标 |
|
||
|
||
留资率和再次预约率先作为探索性指标，不在首批样本设置硬成功线；需结合服务周期、门店客群和观察窗口解释。定量指标之外，每店每周访谈一次老板或值班员工，记录：最费时间步骤、最常绕开的步骤、误解文案、失败后的人工补救和是否愿意继续使用。
|
||
|
||
## 5. 采集与输出
|
||
|
||
事实源：`t_business_event`、`t_follow_up_task`，门店配置/开通状态只用于筛选试点范围。只读查询：`backend/db/queries/pilot_metrics.sql`。查询默认 `@pilot_store_ids='0'`，不会返回全部门店；执行人必须显式填写本轮 3～5 个门店内部 ID，并让所有查询共用同一个 `[from,to)`。
|
||
|
||
执行规则：
|
||
|
||
1. 只在只读账号或只读副本执行，不把数据库凭据写入仓库或命令历史。
|
||
2. 先固定 `@pilot_from/@pilot_to/@pilot_store_ids`；不得使用 `NULL` 或空字符串扩大到全库。保存门店 ID 集合、查询脚本 commit、数据库快照时间和结果文件 SHA-256。
|
||
3. 日报只观察系统异常、积压和隐私退订；周报才讨论转化，避免小样本日波动驱动功能变更。
|
||
4. 输出仅含门店内部 ID、计数、比率和时间，不导出手机号、宠物名、员工名、token、openid/unionid、IP、备注或媒体 URL。
|
||
5. 每周结果关联当周应用四仓 commit 与是否发生迁移/事故；指标口径变更必须新建版本，不覆盖历史结果。
|
||
|
||
## 6. Phase 2 结论模板
|
||
|
||
达到样本闸门后只允许形成三种结论：
|
||
|
||
- `Continue`：核心履约、发送、打开和回访执行均稳定，3 家以上门店愿意继续，进入商业化小实验设计。
|
||
- `Iterate Core`：门店持续使用但一项核心流程明显掉队；只修预约→报告→发送→回访内核，再补 50 次样本。
|
||
- `Stop/Redesign`：两家以上门店无法持续完成核心流程，或数据/隐私可靠性无法保证；停止扩功能，重新验证问题与操作流程。
|
||
|
||
即使结论为 Continue，下一阶段也先验证付费意愿与服务边界，不直接建设全套会员/收银/库存。
|