S2E1: 如何为 OpenAPI 的指标分类
作为一个好的 OpenAPI 业务同学,应该同时关注 OpenAPI 的基建指标和用户相关指标,从而更好的通过指标,数据驱动优化业务。
Hi,
一如昨天所说, S2E1,我们从指标开始聊起。
在正式去看一个个具体的指标和设计之前,我想先和你聊聊指标的分类。分类是一门艺术,好的分类可以帮助我们更好的理解世界。通过将对象进行分类,我可以快速给自己所面临的问题找到答案,这是我们的处事的方法和手段。
OpenAPI 作为一个业务,自然也有着其自己的业务指标和属性,通过这些业务指标,我们可以快速的了解到业务的属性和状态,从而规划在当前周期或下一个周期需要推进和执行的事情。
不过,由于 OpenAPI 业务本身的特殊性,大部分时候往往是由研发同学牵头在跟进业务,产品同学更多是辅助角色在关注 OpenAPI 相关业务,这也导致我们过去在关注 OpenAPI 的各项指标时,往往会关注其基建指标(Infrastructure metrics),而忽视用户相关指标(User-related metrics)。
不同的指标用途不同,只关注基建指标,则会让我们开发出性能极强,但毫无卵用的 OpenAPI;只关注用户中心指标,可能能够发现我们的用户体验很不好,但又无法根因到具体的问题;因此,作为一个好的 OpenAPI 业务同学,应该同时关注 OpenAPI 的基建指标和用户相关指标,从而更好的通过指标,数据驱动优化业务。
什么是基建指标?
基建指标的特点是不以用户为中心,而是更多关注的是大盘上的全局趋势,我们会通过关注基建指标,来了解业务本身的情况。OpenAPI 是否是稳定的、我们是否需要对我们的服务做一些什么。常见的基建指标包括:SLA、CPU 使用率、内存使用量、API 调用量、错误率、调用的平均时延等一系列与我们的技术相关的指标。从技术视角来看,基建指标往往是一些具有时间属性的数据,我们通过把这些具有时间属性的数据进行聚合、分析,得到我们想要的分析纬度。
这些指标往往关注的是我们在当前的基建之上,还需要做哪些事情,来帮助我们优化服务的稳定性、可用性。
在基建指标上,我们常用的指标包括:
- SLA:作为一个 API,服务自身的 SLA 是需要关注的,API 作为一个后台调用的产品,崩溃后如果没有监控,可能很难会被发现。在实际使用过程中,我们需要通过很多手段监控我们自己的 API 的 SLA,从而确保在对客服务中不出岔子。
- QPS(Queries Per Second):OpenAPI 作为一个高并发的服务, QPS 是一个重要的观测指标,通过对 QPS 的观察,可以在出现问题时,快速评估是否是量变导致的质变。同时也是一个系统性能优化的指标。
- RT(Response Time):Response Time 在开放平台是一个重要的观察指标。对于开发者来说,需要通过 OpenAPI 的调用来完成业务逻辑,如果 Response Time 过长,则可能会导致开发者链路上的超时或体验差等问题,因此,Response Time 也是一个非常重要的指标。这里需要注意的是,Response Time 除了要关注平均值,也需要关注 PCT 95、PCT99 和极值,这些指标引导了业务系统中的峰值和方差,对于 OpenAPI 来说,稳定的 Response Time 对于开发者来说,是更加可预期的。
- 成功率:成功率展示了我们的服务到底服务的如何,一方面,我们会重点关注 200 成功的比率,成功的比率可以间接的展示出我们的系统在实际使用上的情况。而另一方面,我们也会重点关注 500 失败的比率,每一个 500 报错,对应的可能都是我们在代码系统中存在的 Bug,需要尽快修复,以避免更大的问题。
- Top N API:Top N API 可以帮助我们快速找到业务中被开发者广泛使用的 OpenAPI,从而引导我们进行不同的工作重心的投入和安排。此外,也可以围绕着 TOP N API ,进行用户引导和宣传,让开发者更加深入的使用我们提供给开发者的 API 。
什么是用户相关的指标?
和基建指标更加关注大局不同,基建指标则更加关注每一个具体的用户的使用体验。通过对于用户中心指标的分析,可以发现我们在 OpenAPI 的设计上的使用问题,同时找到用户中的核心用户、先锋用户,对于用户进行进一步的触达,撬动更大范围的用户影响力。和基建指标相比,用户相关的指标不以时间维度聚合,而是以用户为维度聚合,通过将这些数据聚合起来,我们可以得到对于产品的洞察。
这些洞察可以引导我们关注一个用户的行为和路径,从而得出一个用户是如何使用我们的产品的;我们又是在哪个环节流失了用户的。
用户中心指标因为其组织形式,决定了往往关注的是一些特定的个体,比如:
- 某个 OpenAPI 的月活是多少?以及调用这个 OpenAPI 的最多的用户是谁?:这个数据可以帮助我们发现我们的用户中的 VIP 用户。产研可以和这些用户沟通,了解他们的需求和问题,并帮助他们解决具体的问题。
- 哪些用户的使用深度最深,流失的可能性最低?:通过分析用户的用量,从而分析出深度用户和浅度用户,并找到那些使用量在逐步降低的用户,可以和他们沟通是否遇到了什么问题,是否需要进一步的帮助。
- 某个 API 的增长情况如何,最近一个月那些用户开始使用 OpenAPI?:通过这个数据,你可以发现你的 API 的增长情况,并进一步分析他们是如何使用你的 OpenAPI 的,并通过对他们进行定向的触达和营销,从而进一步增大产品的价值。
用户中心指标会更加导向产品的迭代方案,但同时,其建设成本也会更高,你需要提供一整个声明周期的数据,才能判断用户的行为,预测下一步动作。当你的用户量级足够大的时候,用户中心的指标,会帮助你发现用户的问题,解决问题,取得更大的成功。
总结
如果你到了一个新的业务当中,不知道怎么下手时,不妨先问问自己 —— 我的基建指标有了么?我的用户中心指标有了么?毕竟,有了指标和数据的支撑,才好量化自己行为的有效性。
如果有,那就对着数据去分析,看看业务的技术基础如何?用户感知如何?用户到底是在哪个环节流失 / 转化失败的。如果没有,那不妨按图索骥,先把指标建立起来,然后围绕着这些指标,一步步去解决你的问题。
One More Thing
最近我使用阶跃星辰的大模型,做了一套工作流,来帮助我阅读海外的开发者生态的文章。在阅读过程中,如果我发现不错的文章,也会通过 Newsletter 推送给大家。
由于非 APILetter 的标准系列文章,所以我单独开了一个新的系列 — 他山之石,本 Newsletter 的读者也会默认收到这些推送。如果你不喜欢,后续收到第一封推送后,取消推送即可。