你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用 Azure API Management 变现
适用于：所有 API 管理层级
新式 Web API 支撑着数字经济。 它们向第三方提供公司的知识产权 (IP)，并通过以下方式生成收入：
- 以数据、算法或进程的形式打包 IP。
- 允许其他参与方以一致、顺畅的方式发现并使用有用的 IP。
- 提供适用于此使用情况的直接或间接支付机制。
API 成功案例中的一个常见主题是健康的业务模型。 在所有参与方之间以可持续方式创建和交换价值。
初创公司、成熟的组织以及介于两者之间的所有组织通常都从业务模型开始寻求数字化转型。 通过 API 可以实现业务模型，从而为推广、采用、使用和扩展基础 IP 提供更简单、更经济高效的方式。
发布其第一个 API 的组织面临着一组复杂的决策。 尽管 Azure API Management 平台会降低风险并加速关键元素，但组织仍需围绕其独特的技术和业务模型来配置和构建 API。
制定变现策略
变现是将某种事物转换为金钱的过程 - 在本例中是 API 价值。 在价值链中，API 交互通常涉及三个不同的参与方：
API 变现策略的类别包括：
| API 变现策略 | 说明 |
|---|---|
| 免费 | 一个 API 可促进企业到企业集成，如简化供应链。 该 API 未变现，但通过为 API 提供者和 API 使用者提高业务流程效率来提供巨大的价值。 |
| 使用者付费 | API 使用者根据使用 API 进行的交互数进行付费。 本文档重点介绍此方法。 |
| 使用者获得费用 | 例如，API 使用者使用 API 在其网站中嵌入广告，并获得所产生收入的份额。 |
| 间接变现 | API 变现不是由与 API 的交互次数进行驱动，而是通过 API 促进的其他收入源进行驱动。 |
注意
变现策略由 API 提供者进行设置，应设计为满足 API 使用者的需求。
由于有许多各种因素会影响设计，因此 API 变现没有适用于所有情况的解决方案。 变现策略会将 API 与竞争对手区分开来，并最大程度提高产生的收入。
以下步骤说明如何实现 API 的变现策略。
步骤 1：了解客户
规划 API 使用者可能经历的阶段（从 API 的首次发现到最大规模）。
例如，一组客户阶段可以如下所示：
客户阶段 说明 调查 使 API 使用者可在零成本且顺畅的情况下试用 API。 实现 提供对 API 的充足访问，以支持与它集成所需的开发和测试工作。 预览 允许客户推出其产品/服务并了解初始需求。 初始生产使用情况 支持在未完全了解使用水平时，在生产中尽早采用 API，可能需要采用规避风险的方法。 初始增长 使 API 使用者可以增加 API 的使用，以响应最终用户的需求增加。 可伸缩 一旦 API 每月持续达到较高的使用水平，便激励 API 使用者承诺增加购买量。 全球增长 通过提供最佳批发价格，在全球范围内奖励使用 API 的 API 用户。 分析 API 在客户旅程的每个阶段为客户创造的价值。
如果非常了解 API 对客户的直接价值，请考虑应用基于价值的定价策略。
计算客户的 API 预期生存期使用水平，以及 API 生存期内的预期客户数。
步骤 2：量化成本
计算 API 的总拥有成本。
| 成本 | 说明 |
|---|---|
| 客户购置成本 (COCA) | 营销、销售和加入成本。 最成功的 API 往往会随着采用水平提高，使 COCA 为零。 API 在加入时应该很大程度上是自助服务。 各种因素包括文档以及与付款系统的顺畅集成。 |
| 工程成本 | 在生存期内构建、测试、操作和维护 API 所需的人力资源。 往往是最重要的成本组成部分。 如果可能，请利用云 PaaS 和无服务器技术来最大程度减少该成本。 |
| 基础结构成本 | 在生存期内为 API 提供支持所需的基础平台、计算、网络和存储的成本。 利用云平台实现根据 API 使用水平按比例纵向扩展的基础结构成本模型。 |
步骤 3：开展市场研究
- 研究市场，确定竞争对手。
- 分析竞争对手的变现策略。
- 了解竞争对手通过其 API 提供的具体特性（功能和非功能）。
步骤 4：设计收入模型
根据以上步骤的结果设计收入模型。 工作可以涉及两个维度：
| 维度 | 说明 |
|---|---|
| 服务质量 | 通过对 API 使用设置上限，对所提供的服务级别施加约束。 针对可在一段时间内进行的 API 调用定义配额（例如，每月 50,000 次调用），然后在达到配额后阻止调用。 还可以设置速率限制，从而限制在短时间内可以进行的调用数（例如，每秒 100 次调用）。 上限和速率限制可结合应用，以防止用户在短时间的密集 API 调用突发中消耗其每月配额。 |
| 价格 | 定义要为每次 API 调用支付的单价。 |
通过设置可在客户旅程的每个阶段为客户提供支持的收入模型，最大程度提高从每个客户产生的生存期价值 (LTV)。
- 使客户能够尽可能轻松地进行缩放和增长：
- 建议客户在收入模型中上移到下一层。
- 例如，通过更低单价来奖励购买更高 API 调用量的客户。
- 使收入模型尽可能简单：
- 平衡需求以提供选择，不过存在大量选项会使客户无所适从的风险。
- 减少用于区分收入模型层级的维度数。
- 透明：
- 提供有关不同选项的清晰文档。
- 为客户提供用于选择最适合其需求的收入模型的工具。
确定所需定价模型的范围。 定价模型描述了一个特定规则集，供 API 提供者将 API 使用者的使用转化为收入。
例如，若要为以上客户阶段提供支持，需要六种类型的订阅：
| 订阅类型 | 说明 |
|---|---|
Free |
使 API 使用者能够以一种义务且免费的方式试用 API，以确定它是否满足用例。 消除所有进入屏障。 |
Freemium |
允许 API 使用者免费使用 API，但是随着需求增加转换为付费服务。 |
Metered |
API 使用者每月可以进行所需次数的调用，每次调用支付固定金额。 |
Tier |
API 使用者每月为一定次数的调用付费。 如果超出此限制，则为每次额外调用支付超额费用。 如果经常产生超额费用，则可以升级到下一层。 |
Tier + Overage |
API 使用者每月为一定次数的调用付费。 如果超出此限制，则为每次额外调用支付一定金额。 |
Unit |
API 使用者每月为一定数量的调用付费。 如果超过此限制，则必须为另一个调用单位付费。 |
收入模型会定义一组 API 产品。 每个 API 产品都实现特定的定价模型，以面向 API 使用者生命周期中的特定阶段。
虽然定价模型通常不应更改，不过可能需要针对收入模型调整定价模型的配置和应用。 例如，可能要调整价格以匹配竞争对手。
在以上示例的基础上，可以应用定价模型来创建总体收入模型，如下所示：
| 客户生命周期阶段 | 定价模型 | 定价模型配置 | 服务质量 |
|---|---|---|---|
| 调查 | 免费 | 未实现。 | 配额设置为将使用者限制为每月 100 次调用。 |
| 实现 | 免费增值 | 分级层：
|
未设置配额。 使用者可以继续进行调用并付费，速率限制为每分钟 100 次调用。 |
| 预览 | 按流量计费 | 价格设置为每 100 次调用向使用者收费 0.15 美元。 | 未设置配额。 使用者可以继续进行调用并付费，速率限制为每分钟 200 次调用。 |
| 初始生产使用情况 | 层 | 价格设置为每月向使用者收费 14.95 美元。 | 配额设置为将使用者限制为每月 50,000 次调用，速率限制为每分钟 100 次调用。 |
| 初始增长 | 层 + 超额 | 分级层：
|
未设置配额。 使用者可以继续进行额外调用并付费，速率限制为每分钟 100 次调用。 |
| 缩放 | 层 + 超额 | 分级层：
|
未设置配额。 使用者可以继续进行额外调用并付费，速率限制为每分钟 1,200 次调用。 |
| 全球增长 | 计价单位 | 分级层，其中每层统一金额为每月 749.95 美元，用于 1,500,000 次调用。 | 未设置配额。 使用者可以继续进行额外调用并付费，速率限制为每分钟 3,500 次调用。 |
有关如何解释基于上表的收入模型的两个示例：
“层”定价模型
在生命周期的初始生产阶段进行应用，以便为 API 使用者提供支持。 使用“层”定价模型配置时，使用者：- 每月支付 14.95 美元。
- 每月最多可以进行 50,000 次调用。
- 速率限制为每分钟 100 次调用。
生命周期的缩放阶段，通过应用“层 + 超额”定价模型来实现，其中使用者 ：
- 每月为前 500,000 次调用支付 449.95 美元。
- 超过前 50,000 次调用后，每 100 次调用额外支付 0.06 美元。
- 速率限制为每分钟 1,200 次调用。
步骤 5：校准
在收入模型中校准定价，以便：
- 根据上面步骤 3 中的市场研究，设置定价以防止 API 定价过高或过低。
- 避免收入模型中出现任何不公平的情况，或鼓励客户围绕模型开展工作以实现更优惠的定价。
- 确保收入模型旨在产生足以涵盖总拥有成本和利润的总生存期价值 (TLV)。
- 验证解决方案是否可以支持每个收入模型层中服务产品的质量。
- 例如，如果提供支持每分钟 3,500 次调用，请确保端到端解决方案可以进行缩放以支持该吞吐量级别。
步骤 6：发布和监视
选择适当的解决方案以收集对 API 使用的付款。 提供者往往分为两组：
付款平台，如 Stripe
通过应用客户选择的特定收入模型，基于原始 API 使用指标计算付款。 配置付款平台以反映变现策略。
付款提供程序，如 Adyen
仅涉及促进付款交易。 调用此服务之前，需要应用变现策略（例如，将 API 使用指标转换为付款）。
使用 Azure API Management，通过 API Management 中提供的内置功能来加速实现并降低实现风险。 有关 API Management 中特定功能的详细信息，请参阅 API Management 如何支持变现。
实现一种解决方案，以便可使用与示例项目相同的方法，灵活地在基础系统中制定变现策略。 借助灵活的编码，可以动态响应并最大程度降低更改的风险和成本。
按照变现 GitHub 存储库文档在自己的 Azure 订阅中实现示例项目。
定期监视 API 的使用方式，以便可做出基于证据的决策。 例如，如果证据显示你在流失客户，请重复以上步骤 1 到 5 来发现并解决根源。
持续演变
通过重新访问并重新评估以上所有步骤，定期查看变现策略。 随着详细了解客户、提供 API 的成本以及如何响应市场上的变化竞争，你可能需要随时间推移发展变现策略。
请记住，变现策略只是成功 API 实现的一个方面。 其他方面包括：
- 开发人员经验
- 文档的质量
- 法律条款
- 是否能够缩放 API 以满足承诺的服务级别。
后续步骤
- API Management 如何支持变现。
- 通过关联 Git 存储库部署演示 Adyen 或 Stripe 集成。