题目重点：区分个人贡献、模型指标、产品使用与客户结果，给指标定义、基线、时间窗和上线监控路径。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 用本人实际项目回答，所有指标、基线和归因都需可核；训练表格只是选择指标的方法。
- 把‘客户使用’解释为有资格使用功能的用户/组织的实际采纳行为，定义需与产品团队核对。
解题路线
- 重大成就用目标、本人决策、对照基线、观察窗口、结果和局限讲述；模型离线 AUC/accuracy 只是中间证据，不能替代用户价值。
- 定义客户采用漏斗：有资格访问→激活→首次成功→重复使用→关键任务完成；各阶段固定身份去重、时间区间和事件版本，并按客户/端/地区分组。
- 监控时同时看成功率、延迟、错误与数据新鲜度，避免采用率升高却质量下降；低流量客户用计数和案例，避免对极小样本读过度精确的百分比。
- 报告因果边界：上线同期的市场活动、季节性和客户规模变化会混淆趋势；能实验则实验，不能则用审慎对照与定性反馈。
手动走一遍
训练指标卡：周活跃客户组织数=该周至少完成一次核心任务的已开通组织数；激活率=开通后 14 天内首次完成任务的组织/同期新开通组织。上线前后比较需保持事件口径一致，并标出被排除的内部测试组织。
规模与取舍
事件摄入量随用户数×每用户事件数增长；按天预聚合可降 dashboard 查询成本，但迟到事件需要回填。题目未明确客户量或埋点系统，不填固定架构参数。
易错点与追问
容易失分的边界
- 只说模型指标变好，就称客户采用增加。
- 没有分母、时区或事件定义的 KPI。
- 把团队成果全部归为自己的重大成就。
- 小样本百分比的大幅波动被当显著变化。
- 未核对埋点丢失或内部流量。
继续深挖
- 如果 KPI 上升但客户投诉也上升，如何诊断？
- 怎样证明成果来自你的改动？
- 何时采用 cohort 而非总量？
- 研究工作如何映射到产品指标？
