API-as-a-Product 的话题谈了很多，但常被忽略的一点：当 API 成为你的产品，就必须把它当产品来经营。指标大致分三类——运营指标（性能与可靠性）、采纳指标（客户如何使用、用得多广）、产品指标（如何支撑业务目标）。下面这些指标横跨三类，正体现这种整体视角：一个高流失或低营收的 API，哪怕速度快、可用性 100%，也算不上好产品。
把 API 当产品经营，就得用产品指标衡量。本文编译自 Nordic APIs（2023-05-30），列出 TTFC、TTFV、流失率、月活、营收增长、可用性、错误率、每分钟请求数 8 个指标，覆盖运营、采纳与商业三类维度。
API-as-a-Product 的话题谈了很多，但常被忽略的一点：当 API 成为你的产品，就必须把它当产品来经营。指标大致分三类——运营指标（性能与可靠性）、采纳指标（客户如何使用、用得多广）、产品指标（如何支撑业务目标）。下面这些指标横跨三类，正体现这种整体视角：一个高流失或低营收的 API，哪怕速度快、可用性 100%，也算不上好产品。
Time To First Call（TTFC）衡量易用性。Ably 用「Time To Hello World」做基准：能在 30 分钟内跑通第一个示例、拿到 5/5 评分。TTFC 受部署复杂度影响，有些步骤（如 API key 审批）绕不开，但你可以把一切能省的都省掉。可关注：新用户发出第一个 GET example.api/user 拉取用户数据花了多久。
Time To First Value（TTFV）指客户第一次觉得「这东西有用」的时刻。难在如何度量——Insightly 举了图片缩放、短链等「即时价值」例子。对 API，可把 TTFV 近似为「开发者在真实应用里跑通一个可用集成」所花的时间。抓不到「顿悟时刻」，但这个估计已够好。
弃用、停更、注销账号——创始人们对这些近乎执念，因为留老用户远比拉新便宜。俗话说「拉新是虚荣，留存才是理性」。流失过高，原因可能是文档不足、价格、或没兑现营销承诺。你永远到不了 0 流失，但要搞清楚为什么走。
月活与流失是一体两面，监控独立用户数绝对值非常有必要。比如你上了分层定价，看到高用量就以为一切大好——但若用量都来自少数几个重度用户，按请求数或每千次请求计费反而更合适。例子：2021 年 Twilio 拥有超 25 万活跃用户、全年营收 28.4 亿美元，这类数据对测算获客成本与生命周期价值至关重要。
除了为融资快速扩张的产品，多数产品的目标是赚钱。理想情况下，无论服务更多客户还是提高用量，营收应逐月增长。增长停滞，可能因过度依赖少数重度用户、定价没算清扩展成本等。建模不同营收模型并紧密跟踪增长，才能确保 API 是值得投入的盈利业务。
可用性简单却常写进 SLA。100% 可用性是目标但几乎没人达到。但微小改进影响巨大：99.9% 与 99.999% 的年度差距，是 8 小时（一整个工作日）对比 5 分多钟。
知道错误频率能暴露生产问题或文档偏差，但只数错误数量意义不大——要数错误类型。比如大量「字段缺失」错误，往往说明文档写错了，可以立刻去修。一切始于 API 设计：从一开始就用好状态码，后续才好按状态码定位成因——从代码潦草、文档不佳到安全攻击都有可能。
知道 API 多久被调一次很有用，更重要的是发现波动与峰值：意外中断或成本飙升都藏在里面；监控请求率还能揪出暴力破解等可疑活动。更细地，按客户端统计请求数，是触发限流的依据，也能帮你识别值得定制企业版的重度用户。（*「分钟」可替换为小时/天/周/月。）
跟踪 API 指标的重要性怎么强调都不过分——前提是真去用它改进产品。这些指标无论 API 是否商业化都值得跟踪：任何一环不达标，都会拉低整个组织的形象。好消息是，许多 API 管理平台默认就提供分析能力。确定「跟踪什么、谁负责改进」，应该是全员工程，别让任何指标被遗漏。等你的团队（和外部干系人）开始用「能赚钱的产品」那套指标思考，API-as-a-Product 就顺了。