季度盘点会上，七个功能都标着"已交付"。有人问了一句"哪个真有人用"，会议室安静了——不是没人关心，而是这个问题在上线那天就没人被指派回答。发布单最后一项写的是"上线完成"，做完这一项，全员被拉去下一个需求，注意力在同一个小时撤走。
上线不是终点，是观测的起点。而"有没有用"只有在上线之前定义过，事后才查得出来；否则结论只能靠回忆和讲故事。
1. 上线那一刻，注意力就撤走了
| 阶段 | 谁在看 | 看什么 | 产出 |
|---|---|---|---|
| 上线前 7 天 | 研发、测试、运维 | 能不能发出去 | 发布单、回滚预案 |
| 上线当天 | 全员 | 有没有炸 | 值班记录、告警处置 |
| 上线后第 2 周 | 几乎无人 | 偶发用户投诉 | 无 |
| 上线后第 2 月 | 无 | 无 | 盘点时靠回忆 |
交付节奏奖励"发出"，不奖励"被用"：发布是可见事件，使用是缓慢分布。三件具体的事让注意力提前离场——需求单已关闭、人力已排进下一个项目、验收标准里没有使用指标。
把观测责任写回发布单，是最便宜的一次修补：
// release-checklist.yaml —— 最后一项不是"上线完成"，是"观测接管"
release:
feature_id: FEATURE_ID
owner_observe: ROLE_A // 上线后 30 天内对该功能的使用结论负责
observe_window: 30d
signals:
- feature_entered // 被调用
- feature_completed // 被完成
- feature_repeated_7d // 被重复使用
review_at: DAY_30
kill_criteria: KILL_RULE // 上线前就写，见第 6 节
没有 owner_observe 的功能，等于没有观测。
2. "有没有用"必须在上线前定义
定义要能落成证据，否则它只是形容词。三个问题足够：
// 定义三问 —— 由提出需求的人回答，研发不代答
1. 谁：具体角色 + 量级（不是"用户"，是"每月约 N 个 ROLE_A"）
2. 什么场景：现在他怎么做，成本多少（分钟/次、错误率/次）
3. 为什么换：不换的代价是什么，换掉之后哪一步变短
| 定义项 | 上线后可查的证据 | 常见缺口 |
|---|---|---|
| 谁 | 事件里的 identity 分群 | 埋点只记设备号，不记角色 |
| 什么场景 | 入口页 → 关键步骤 → 完成页漏斗 | 只有浏览量，没有步骤 |
| 换来什么好处 | 前后对照，或分群对照 | 全量上线，没有对照组 |
| 规模 | 30 日活跃使用者人数 | 只统计调用次数，不统计人数 |
事后补定义的通病是两个替换：把"调用次数"当"使用人数"，把"曝光"当"选择"。这两个替换在第 4 节会各造成一次误判。
3. 三个可观测层次：被调用、被完成、被重复使用
| 层次 | 回答的问题 | 怎么查 | 典型误读 |
|---|---|---|---|
| 被调用 | 有没有人来到入口 | 入口事件计数 | 入口挂在必经页 → 曝光当意愿 |
| 被完成 | 进来的人走完没有 | 漏斗：进入 → 关键步骤 → 完成 | 完成率低就断定功能差，忽略步骤本身有 bug |
| 被重复使用 | 用过的人会不会回来 | 同 identity 的 7/30 日再次使用 | 单次任务型功能天然低重复，被误判为失败 |
缺一层，结论就错位：只有第一层叫"有人点过"，只有前两层叫"能用"，三层齐了才叫"有用"。所以事件模型一开始就按三层定，别先上一堆计数再加 identity：
// 事件模型：同一 feature_id 串起来，identity 稳定可关联
{"event":"feature_entered","feature_id":"FEATURE_ID","identity":"UID","ts":"ISO8601","entry":"ENTRY_POINT"}
{"event":"feature_completed","feature_id":"FEATURE_ID","identity":"UID","ts":"ISO8601","duration_ms":0,"steps":0}
{"event":"feature_repeated","feature_id":"FEATURE_ID","identity":"UID","ts":"ISO8601","window_days":7}
// 三层一起看：进入人数、完成人数、7 日重复人数
select count(distinct identity) as entered,
count(distinct identity) filter (where event = 'feature_completed') as completed,
count(distinct identity) filter (where event = 'feature_repeated') as repeated_7d
from feature_events
where feature_id = 'FEATURE_ID' and ts >= now() - interval '30 day';
filter 语法按 PostgreSQL 核对；MySQL 用 count(distinct case when ... then identity end)。
4. 使用率的假象与"没人用"的三种解释
三个常见假象：曝光即使用（入口放在必经页面）、点击即价值（点开看一眼就走）、总量即覆盖（少数重度用户刷出高调用量）。判据只有一条：看人数分布，不看总次数。
"没人用"只有三种真实解释，对应三种完全不同的动作：
| 解释 | 判别信号 | 该做什么 |
|---|---|---|
| 没用（问题不真，或方案不解决问题） | 有曝光、有进入，完成率低或完成后不再来 | 回到第 2 节的三问，可能该下线 |
| 不知道（找不到、没被告知） | 目标人群进入率极低，同类入口进入正常 | 改入口与告知，不是改功能 |
| 有替代（现有做法够用） | 目标人群在用另一条路径完成同一目的 | 比较两条路径成本，可能该下线 |
// 分布查法：单用户占比过高 → 少数人刷量，不是覆盖面
select identity, count(*) as hits
from feature_events
where feature_id = 'FEATURE_ID' and event = 'feature_entered'
group by identity
order by hits desc
limit 100;
判断顺序很重要：先证明"不知道"不成立（入口和告知已到位），再讨论"没用"。顺序反了会把推广问题当产品问题，白改一版。
5. 反馈采集的偏差与仪表盘的失效
主动反馈几乎必然来自极端体验：特别顺的人不写，特别不顺的人写，中间大多数沉默。"没人提意见"既不是满意也不是不满意，是样本缺失。
| 渠道 | 采样偏差 | 能代表谁 |
|---|---|---|
| 应用内反馈按钮 | 只有愿意点的人，且情绪偏极端 | 极端体验者 |
| 客服工单 | 只有出问题且愿意找客服的人 | 阻塞型问题 |
| 问卷 | 愿填的人，问题由你设定 | 有观点的人 |
| 行为埋点 | 全量，但只记录"做了什么" | 全部使用者（不回答为什么） |
仪表盘没人看，通常不是配色问题，是它不回答任何问题。把标题从名词改成问句，读的人才会带着结论离开：
// 看板改造：每块图必须有一行结论，否则删掉
─── 旧：功能A · 日调用量
─── 新：功能A 有人在用吗？→ 30 日使用者 N 人，占目标人群 P%，趋势平
─── 旧：完成率曲线
─── 新：进来的人卡在哪？→ 第 2 步流失最高（X%），疑似 STEPS 校验
行为的"为什么"只能靠访谈补，且要按分层抽样：只找重度用户，会得到"这个功能很好用"的一致回答，然后什么都学不到。
6. 下线决策比上线更难，所以要提前写
上线有推动力（需求、排期、可见成果），下线只有阻力（沉没成本、谁提谁负责、怕被问"当初为什么做"）。唯一可行的办法是在上线前把 kill_criteria 写进发布单，让下线变成执行既定条件，而不是重新做一次判断。
| 手段 | 能回答 | 不能回答 |
|---|---|---|
| 灰度 | 新版本是否引入故障、错误率是否变化 | 这个功能是否值得存在 |
| A/B | 同一目标下两种方案哪个指标更好 | 指标本身选错时会给出精确的错误答案 |
| 分群使用率 | 谁在用、用得多深 | 不用的人为什么不用 |
| 访谈 | 动机与替代路径 | 规模（只能定性） |
// kill_criteria：写条件，不写态度
if 30 日使用者 < 目标人群 * THRESHOLD and 完成率 < RATE and 无合规要求:
下线，数据保留可读 90 天，入口改为说明页
elif 使用者达标 and 完成率低:
修 STEPS，观察 14 天，仍低则下线
else:
进入维护态，季度复核一次
四个度量够用：功能使用率分布（人数而非次数）、30 日留存（同 identity 回访）、反馈转化率（反馈数 / 使用者数）、上线后放弃率（进入未完成且 7 日未回）。这四个数到了季度盘点能直接回答"哪个有用"。
排错：盘点答不出"有没有用"的六种情形
| 现象 | 根因 | 处理 |
|---|---|---|
| 只有调用量，没有人数 | 埋点缺 identity | 补 identity 关联，历史数据只给趋势不给结论 |
| 完成率高得离谱（>95%） | 完成事件在入口就上报 | 核对上报位置，别在页面加载时算完成 |
| 使用率很高但业务指标没动 | 曝光被计为使用 | 拆成曝光、选择、完成三个事件 |
| 目标人群数说不清 | 定义没写量级 | 补人群口径，按 ROLE 维度统计 |
| 反馈全是负面 | 只有极端体验者会反馈 | 加分层抽样访谈，不据此定结论 |
| 灰度正常，上线后崩 | 灰度样本不覆盖真实入口分布 | 灰度按入口分群，不只按流量比例 |
边界：这些场景使用率本就不能当判据
| 场景 | 为什么不能作判据 | 替代判据 |
|---|---|---|
| 内部工具且强制使用 | 用不用不由使用者选 | 任务耗时、错误率、绕行路径成本 |
| 法规或合规要求的功能 | 存在本身即价值，与使用无关 | 合规检查通过率、审计缺陷数 |
| 用户量极小（低于噪声阈值） | 分布噪声大于信号 | 逐个访谈、任务观察 |
| 一年只用一次的任务型 | 重复率天然为 0 | 首次完成率、求助次数 |
| 平台与基础设施类 | 间接生效，没有直接入口 | 下游功能上线速度、故障率 |
自测
- 发布单上把"上线完成"换成哪一项，观测才有责任人？
- 为什么"有没有用"不能在上线后再定义？事后补定义最常见的两个替换是什么？
- 三个可观测层次分别回答什么问题，缺哪一层会把"能用"误报成"有用"？
- 使用率高而业务指标不动，第一个该怀疑的埋点错误是什么？
- 用 A/B 证明一个功能"有用"，什么情况下它给出的是精确的错误答案？
- 内部强制使用的工具，该拿什么替代使用率？