API-first产品经理的热门 API 工具和 API 指标

我们采访了旧金山多家大型 API-first 公司的产品经理。这些公司均为上市公司，TTM 收入超过 1 亿美元，涉及计费、安全、通信和工作流自动化等领域。

我们询问了 PM 他们最喜欢的工具是什么以及他们最关心的API 指标是什么。我们尽可能地确定了所有细分市场中通用的工具和指标，排除了客户群达到 1,000 人时可能出现的（许多）极端情况。

不出所料，我们的答案可以很好地分为三个经典领域：采用、参与和保留。在深入研究这些领域之前，我们需要将数据放入我们的分析生态系统中。

入门很难——数据量巨大

最一致的结论之一是，分析数十亿次 API 调用所需的存储和数据处理量非常大。数据湖通常非常大，以至于追溯分析必须限制在几天甚至几个小时内。

在许多情况下，公司采取的第一步是将非结构化 API 数据或系统日志的整个原始转储转储到Amazon Redshift或Splunk中的数据库中。从那里，数据基础设施团队提取 PM 感兴趣的系统日志事件并将它们传递到数据仓库（通常在Snowflake中），在那里更容易查询。在这里，指标的实际处理和汇总通常在商业智能团队、PM 甚至工程师的主持下进行。

采用：工具和指标

对于我们采访过的大多数 API-first 公司来说，产品经理跟踪的首要指标之一，也可以说是最重要的指标，就是开发人员激活。一般来说，产品采用的步骤很简单：

注册新账号
首次 API 调用
部署工作 API

我们一批成熟的 API 优先公司使用Tableau或Looker仪表板来显示有多少人正在注册、有多少人正在登录、有多少人正在创建应用程序以及有多少应用程序创建了 API 令牌。为了使 Tableau 和 Looker 仪表板运行得更快，您可以清除设备上的缓存。

PM 的 OKR 主要致力于提高开发人员的激活率并确保缩短激活时间。由于开发人员可能会在单个漏斗阶段停留数天甚至更长时间，因此跟踪每个步骤的转化率以及到达下一步所需的时间非常重要。

如果正常销售周期为 90 天，则 PM 喜欢查看四分位数：第五十四分位数在做什么，第七十五四分位数在做什么，然后他们使用它作为代理来确定他们的 SDK 和文档有多大用处。

一旦 API 被采用，PM 希望看到使用量增加，从而促成付费计划、突出热门端点以及识别缺失功能的能力。在此阶段，客户的购买动向根据其公司规模分为两类：大型企业或中小型企业/初创公司。

参与：企业客户工具和指标

大多数情况下，领导层都会要求大多数开发人员评估 API 产品的可能性。有时他们会创建一个开发人员组织并试用所有功能。然后，当他们的公司决定签署协议时，他们实际上最终会提供一个单独的帐户。将开发人员组织映射到付费帐户，并将收入帐户绑定到 Salesforce 中，并不总是非常清晰。因此，PM 有时不会尝试解决该映射问题，而是只关注更多的采用，因为采用是客户是否会使用该产品的一个很好的指标。

API 令牌（按获取渠道）

大多数公司认为，在面向用户的控制台中跟踪活动有助于提高使用率和参与度。当客户注册、配置帐户、管理可用的 API 或打开和关闭功能时，他们会通过管理 Web 界面。如果您的 API 监控工具不是以用户为中心的（即它无法深入研究 API 调用并确定其归属用户和公司），那么 PM 必须部署Heap或Google Analytics 360等分析工具。然后配置这些工具以将 Web 界面上的用户与其组织中其他人可能进行的 API 调用相关联。

然后，PM 可以跟踪营销渠道对相应 Google 或 Facebook 广告的归因。他们可以从创建帐户开始，一直跟踪到客户转换为付费计划，再到他们首次开始进行 API 调用。

在 Moesif 等以用户为中心的工具中，UTM 参数的监控方式与 HTTP 状态响应代码的监控方式相同。这样就可以按 UTM 源或 UTM 活动对 API 令牌进行分组，从而更好地了解哪些营销渠道有助于提高参与度。

每周活跃 API 令牌

在给定的一周内访问 API 的不同令牌的数量，即每周活跃令牌(WAT)，是产品经理用来跟踪其产品的最佳北极星指标之一。与正常运行时间、SLO 或每分钟请求数等与工程目标保持一致的基础设施指标不同，WAT 与推动采用和提高参与度的业务目标直接保持一致。为了计算 WAT，数据基础设施团队需要从 Redshift 中提取相关的系统日志事件并将其传递到 Snowflake 中。到达那里后，BI 团队编写 SQL 查询并在 Tableau 中将其可视化。

由于单个开发者帐户可以创建多个 API 令牌（例如用于沙箱和生产环境），因此更准确的衡量标准是Weekly Active Users或Weekly Active Companies 。然而，这需要能够将 API 令牌链接到相应用户或公司帐户的分析基础设施。

用户数量

“让邀请他人变得容易”

一些产品经理发现帐户转换和用户数量之间存在直接相关性。更多的用户通常意味着客户对项目更加认真。因此，产品经理会通过诸如“邀请其他人加入这个项目来帮助你完成工作”之类的话来推动邀请其他人加入注册流程。通常，额外的好处是，这是从用户那里获取公司电子邮件的另一个机会，因为邀请者可能不知道被邀请者的 Gmail，但会知道他们的工作电子邮件。

参与度：中小企业/初创企业自助服务客户

在自助服务购买动议中，客户是一名独立开发人员，在 5 人或 10 人的初创公司或中小型企业中，他只需插入 CTO 信用卡即可立即开始使用付费服务。

除了 PM 为企业帐户所做的工作之外，很难从这个群体中获得更多见解，因为大多数开发人员非常喜欢自助服务路线。

“这不是一个绝对的声明，但在大多数情况下，开发商不想与你交谈，他们不愿意与销售人员交谈，也不想回复电子邮件。事实上，他们经常使用个人电子邮件注册，试图隐藏他们为谁工作，”旧金山的总理。

然而，通过查看开发人员在产品中使用的内容、他们点击的内容、他们进行的 API 调用以及来自 GitHub 中 API 的 SDK 的使用统计信息，可以在一定程度上收集开发人员情绪的代理信息。

保留

在项目经理对采用和参与度有了很好的了解后，他们开始研究 API 产品留存率，以找到需要改进的领域。产品留存率是一个源于收入留存率的概念，需要将用户群细分为群组，例如通过注册日期。项目经理会跟踪每个群组返回与您的平台互动的百分比。在下面的示例中，API 留存率按用户的 SDK 分组。您可以看到 PHP 的留存率远低于其他 SDK，这意味着 PHP 存在错误，或者存在需要修复的性能问题。

确定要添加或弃用哪些产品功能的另一种方法是查看计费 SKU。许多 API 被分为一组 SKU，每种不同的活动类型都分配有自己的单个 SKU。通过查看谁为哪些功能付费，可以确定哪些功能正在使用，哪些功能没有使用。

设置指标跟踪很困难

从项目经理的角度来看，监控商业智能的速度无疑是一个问题。

一位不满的总理表示：“从提出新指标请求到得到统计数据，需要花太长时间。”

设置指标跟踪的过程分为五个步骤。它涉及向单独的 BI 团队发出请求，然后该团队必须对请求进行分类，然后将其纳入，并且通常涉及谈判和政治。代表性步骤包括：1) 所讨论的数据是否有事件？2) 如果答案是肯定的，那么它是否在数据仓库中？如果答案是否定的，那么数据基础设施团队中的某个人需要创建一个新的系统日志事件，然后将其纳入。3) 创建指标在 Tableau 中可视化的方式的要求或更改报告。4) BI 数据团队必须执行请求。5) 如果 BI 因太忙或超出其能力而无法将其可视化，那么 PM 将不得不要求工程部门对数据库本身进行自定义 SQL 查询。

原文链接：API-First Product Managers’ Popular API Tools and API Metrics