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

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

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

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

入门很难——数据量巨大

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

在许多情况下，公司采取的第一步是将非结构化 API 数据或系统日志的整个原始转储转储到数据湖中亚马逊 Redshift或者Splunk. 然后，数据基础设施团队提取 PM 感兴趣的系统日志事件，并将它们传递到数据仓库，通常是雪花，这样查询起来就更容易了。在这里，指标的实际处理和汇总通常由商业智能团队、项目经理甚至工程师主持。

采用：工具和指标

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

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

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

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

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

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

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

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

API 令牌（按获取渠道）

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

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

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

每周活跃 API 令牌

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

由于单个开发者帐户可以创建多个 API 令牌（例如用于沙盒和生产环境），因此更准确的衡量标准是“每周活跃用户”或“每周活跃公司”。但是，这需要能够将 API 令牌链接到相应用户或公司帐户的分析基础架构。

用户数

“让邀请他人变得简单”

一些 PM 发现，账户转换和用户数量之间存在直接关联。用户越多通常意味着客户对项目越认真。因此，PM 会尽力邀请其他人加入注册流程，比如说“邀请其他人加入此项目来帮助您完成工作”。通常，额外的好处是，这是另一个从用户那里获得公司电子邮件的机会，因为邀请者可能不知道受邀者的 Gmail，但会知道他们的工作电子邮件。

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

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

由于大多数开发人员更喜欢自助服务方式，因此很难从该群体获得超出 PM 为企业帐户所做工作的额外见解。

“这不是绝对的说法，但大多数开发人员不想和你说话，他们不愿意和销售人员交谈，也不想回复电子邮件。事实上，他们经常使用个人电子邮件注册，试图隐藏他们为谁工作，”旧金山的 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 查询。