客户视角度量指标 · 操盘手年鉴

解决什么问题

团队在内部视角下自然倾向于衡量内部事件（登录数、点击数），而非客户视角的价值交付。指标过多导致无法聚焦，指标命名混乱导致团队缺乏共鸣。

核心内容

原则

指标应是从客户视角衡量的价值数值化表达
检验标准：如果你的 dashboard 意外泄露给客户，他们会为你正在衡量这些东西感到高兴
指标数量必须极少——你无法对 1000 个指标保持足够的关注和理解深度
定量指标与定性反馈（推文、客户视频）是平等的一对，缺一不可

北极星指标选取方法（以 Stripe Atlas 为例）

回到根本问题：客户为什么会推荐我们？
找到推荐的必要条件：Atlas 的场景下，如果客户在注册过程中提交了 support ticket，他们几乎不可能推荐给朋友
定义指标："零 support ticket 完成注册的公司占比"——从首次页面加载到注册完成 + 政府审批 + 额外 2 周缓冲期，全程无 ticket
基准数据：起步时仅 15%，18 个月后提升至 85%，与市场份额增长曲线形状一致
分解为战术 KR：由工程师认领具体子问题（如"风险审核时长"），每月逐步优化

"用户糟糕的一天"诊断指标

头脑风暴哪些事件会让用户有糟糕体验（404、支付延迟、被拒超过 10 次等）
每个事件触发时发出一条 log line
用堆叠柱状图展示各原因的频率
团队成员可随时往图上加新的"糟糕一天"原因
按优先级逐步消灭，不只是最小化

指标卫生习惯

命名要有情感：叫 "companies with zero support" 而非数据库字段名
小数位数：只保留有意义的位数
统一 X 轴：dashboard 上所有图表用相同时间轴
必须放在固定可发现的 URL 上：禁止用截图/邮件/一次性查询传递指标
一个新指标需要"生活"数周才能信任——前几周往往会发现计数错误
dashboard 使用频率是团队是否对齐、是否客户导向的强预测因子

防止指标产生 perverse incentive

不只看一个指标，但只优化一个
战术层面用具体 KR 约束手段（如"提高审核速度"而非"减少 ticket"），不允许投机取巧的手段自然存在
达到目标后可以主动放下该战术

适用边界

B2B 场景下效果最佳（Jeff 明确说他对 B2C 直觉较少）
"零 support ticket"这类指标需要与 GTM 策略对齐——Atlas 的 GTM 就是口碑推荐，所以这个指标直接驱动增长；如果你的 GTM 是广告投放，需要不同的北极星
需要团队有权限在 dashboard 系统中创建和维护指标

关键引述 · 原话

"If you accidentally leaked your dashboard to them, your customer would be ecstatic to learn that that's what you were measuring the whole time." — Jeff Weinstein

— Jeff Weinstein

关联卡片

与 Study Group 互补——指标告诉你"哪里有问题"，Study Group 让你"感受问题有多严重"。与 friction log 同属 Stripe 客户导向工具体系。