通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

使用 Azure API 管理实现盈利

适用于：所有 API 管理层级

现代 Web API 支撑着数字经济。 他们向第三方提供公司的知识产权（IP），并通过以下方式产生收入：

  • 以数据、算法或进程的形式打包 IP。
  • 允许其他各方以一致、无摩擦的方式发现和使用有用的 IP。
  • 提供用于该使用的直接或间接支付机制。

API 成功案例中的常见主题是一种 健康的业务模型。 价值是以可持续的方式在各方之间创造和交换的。

从业务模式开始，初创企业、已建立的组织以及介于两者之间的所有内容通常都寻求数字化转型。 API 使组织能够实施业务模型，从而以更简单和更具成本效益的方式实现市场推广、应用、使用和扩展基础IP。

发布其第一个 API 的组织面临一组复杂的决策。 尽管 Azure API 管理平台会解除风险并加速关键要素，但组织仍需要围绕其独特的技术和业务模型配置和构建其 API。

制定盈利策略

货币化 是将某些内容转换为金钱的过程：在本例中，API 值。 API 交互通常涉及价值链中的三个不同的参与方：

货币化价值链示意图

API 盈利策略的类别包括：

API 盈利策略 Description
免费 API 可促进业务到业务集成，例如简化供应链。 API 没有盈利化，但通过提升 API 提供者和使用者的业务流程效率，提供了重要的价值。
消费者付费 API 使用者根据与 API 的交互数量付费。 本文重点介绍此方法。
消费者获得报酬 例如，API 使用者使用 API 在其网站中嵌入广告，并接收一部分生成的收入。
间接货币化 API 盈利不是由与 API 交互的数量驱动，而是通过 API 促进的其他收入来源推动的。

注释

货币化策略由 API 提供程序设置，应设计为满足 API 使用者的需求。

由于各种因素影响设计，API 货币化并不是一种一刀切的解决方案。 盈利策略将 API 与竞争对手区分开来，并最大化生成的收入。

以下步骤说明如何为 API 实现盈利策略。

实现盈利策略的步骤示意图

步骤 1：了解客户

  1. 规划 API 使用者从初次接触 API 到达到最大使用规模的可能阶段。

    例如，一组客户阶段可以是：

    客户阶段 Description
    调查 使 API 使用者能够试用零成本和摩擦的 API。
    实现 提供对 API 的足够访问权限，以支持与其集成所需的开发和测试工作。
    预览 允许客户启动其产品/服务并了解初始需求。
    初始生产使用情况 当未完全理解使用级别并且可能需要采用风险不利的方法时，支持在生产中提前采用 API。
    初始增长 使 API 使用者能够增加 API 的使用，以响应最终用户的需求增加。
    Scale 在 API 月使用量持续达到较高水平后，激励 API 使用者承诺提高采购量。
    全球增长 通过提供最佳批发价格，奖励使用全球规模的 API 用户。

  2. 分析您的 API 在客户旅程每个阶段所产生的价值。

  3. 如果可以很好地了解 API 对客户的直接价值，请考虑应用基于值的定价策略。

  4. 计算单个客户的 API 预期寿命使用量，以及 API 整个寿命期间预期的客户总数。

步骤 2：量化成本

计算 API 的总拥有成本。

成本 Description
客户购置成本 （COCA） 营销、销售和入职培训的成本。 随着采用水平的提高，最成功的 API 往往具有零的 COCA。 API 在载入时应基本上是自助服务。 因素包括文档和与支付系统的顺畅集成。
工程成本 构建、测试、操作和维护 API 全生命周期所需的人力资源。 这往往是最重要的成本组件。 尽可能利用云 PaaS 和无服务器技术来最小化。
基础结构成本 支持 API 生存期所需的基础平台、计算、网络和存储的成本。 利用云平台来实现基础结构成本模型，该模型与 API 使用级别成比例扩展。

步骤 3：进行市场研究

  1. 研究市场以确定竞争对手。
  2. 分析竞争对手的盈利策略。
  3. 了解其 API 提供的特定功能（功能和非功能）。

步骤 4：设计收入模型

根据上述步骤的结果设计收入模型。 可以跨两个维度工作：

尺寸 Description
服务质量 通过设置 API 使用情况上限，对所提供的服务级别施加约束。 定义可在一段时间内进行的 API 调用的配额（例如，每月 50,000 次调用），然后在达到该配额后阻止调用。
还可以设置速率限制，限制短时间内可以进行的调用数（例如每秒 100 次调用）。
上限和速率限制会同时应用，从而防止用户在 API 调用的短时间内使用其每月配额。
价格 定义要为每个 API 调用支付的单价。

通过设计在客户旅程各阶段支持客户的收入模型，最大化从每个客户产生的生命周期价值（LTV）。

  1. 帮助客户尽可能轻松地扩展和发展：
    • 建议客户转到收入模型中的下一层。
    • 例如，奖励购买较高数量 API 调用的客户，其单价较低。
  2. 尽可能简单地保持收入模型：
    • 平衡提供选择的需要与用众多选项压倒客户的风险。
    • 减少用于区分收入模型层的维度数量。
  3. 透明：
    • 提供有关不同选项的清晰文档。
    • 为客户提供工具以选择最适合其需求的收入模型。

确定所需定价模型的范围。 定价模型描述了 API 提供程序将 API 使用者消耗转换为收入的特定规则集。

例如，为了支持 之前定义的客户阶段，我们需要六种类型的订阅：

订阅类型 Description
Free 使 API 使用者能够以义务和无成本的方式试用 API，以确定它是否满足用例。 删除进入的所有障碍。
Freemium 允许 API 使用者免费使用 API，但随着需求增加而过渡到付费服务。
Metered API 使用者可以每月进行任意数量的调用，并为每个调用支付固定金额。
Tier API 使用者每月支付固定数量调用的费用。 如果超出此限制，则为每次额外调用支付超额费用。 如果经常产生超额费用，则可以升级到下一层。
Tier + Overage API 使用者每月支付固定数量调用的费用。 如果超出此限制，则为每个额外呼叫支付一定金额。
Unit API 使用者每月支付一定数量调用的费用。 如果超出此限制，则必须支付另一个呼叫单位的费用。

收入模型定义 API 产品集。 每个 API 产品实现特定的定价模型，以面向 API 使用者生命周期中的特定阶段。

尽管定价模型通常不应更改，但可能需要根据收入模型调整定价模型的配置和应用。 例如，你可能想要调整价格以匹配竞争对手。

基于前面的示例，可以应用定价模型来创建总体收入模型，如下所示：

客户生命周期阶段 定价模型 定价模型配置 服务质量
调查 免费 未实现。 设置配额限制客户每月100个呼叫。
Implementation Freemium 分级层次
  • 第一层固定金额为 0 美元。
  • 下一层每单位费用设定为每100次呼叫收费0.20美元。
 未设置配额。 消费者可以在速率限制为每分钟100个呼叫的情况下继续拨打和支付电话。
Preview 按流量计费 价格设置为向消费者收取每100次呼叫0.15美元。 未设置配额。 使用者可以继续以 200 次呼叫/分钟的速度限制拨打和支付呼叫费用。
初始生产使用情况 层 价格设置为收取消费者 14.95 美元/月。 设定配额以限制用户每月最多拨打 50,000 次电话，并且限制速率为每分钟最多 100 次。
初始增长 层 + 超额 分级层次
  • 第一层收费为每月 89.95 美元，适用于前 100,000 次呼叫。
  • 下一个收费级别设置为每 100 次呼叫收费 0.10 美元。
 未设置配额。 使用者可以继续进行额外调用并付费，速率限制为每分钟 100 次调用。
Scale 层 + 超额 分级层次
  • 前500,000个呼叫的第一档固定金额为每月449.95美元。
  • 后续层每单位数量费用设置为每 100 次调用收费 0.06 美元。
 未设置配额。 消费者可以继续拨打额外的电话并支付费用，速率限制为每分钟 1,200 次呼叫。
全球增长 单位 分级层，其中每层统一金额为每月 749.95 美元，用于 1,500,000 次调用。 未设置配额。 消费者可以继续拨打和支付额外的呼叫，速率限制为 3,500 个呼叫/分钟。

下面两个示例说明了如何基于上表解释收入模型：

  • 层定价模型
    应用于生命周期初始生产阶段，以支持 API 使用者。 使用“层”定价模型配置时，使用者：

    • 每月支付 14.95 美元。
    • 最多可以进行 50,000 次呼叫/月。
    • 速率限制为每分钟 100 次调用。

  • 生命周期的缩放阶段，通过应用“层 + 超额”定价模型来实现，其中使用者：

    • 每月为前 500,000 次调用支付 449.95 美元。
    • 在前 50,000 个电话之后，将额外收取 0.06/100 美元的通话费用。
    • 速率限制为每分钟 1,200 次调用。

步骤 5：校准

将收入模型中的定价校准为：

  • 根据前面步骤 3 中的市场研究设置定价，以防止过度定价或低估 API。
  • 避免收入模型中看似不公平之处，或鼓励客户规避模型以获得更有利的定价。
  • 确保收入模型旨在生成总生存期值（TLV），足以支付总拥有成本加上利润率。
  • 验证解决方案是否可以支持每个收入模型层中服务产品的质量。
    • 例如，如果你提供支持 3,500 次呼叫/分钟，请确保端到端解决方案可以缩放以支持该吞吐量级别。

步骤 6：发布和监视

选择适当的解决方案以收取 API 使用的付款。 供应商往往分为两个组：

  • 支付平台，如 条纹

    通过应用客户选择的特定收入模型，根据原始 API 使用情况指标计算付款。 配置支付平台以反映盈利策略。

  • 付款提供商，如 Adyen

    只专注于促进付款交易。 在调用此服务之前，需要应用盈利策略（例如，将 API 使用情况指标转换为付款）。

使用 Azure API 管理通过内置 API 管理提供的功能加速和取消实施风险。 有关 API 管理中特定功能的详细信息，请参阅 API 管理如何支持货币化。

采用与示例项目相同的方法，实施一个解决方案，将灵活性注入到您如何在基础系统中对您的盈利策略进行编码的方式中。 使用灵活的编码，可以动态响应，并最大程度地降低进行更改的风险和成本。

按照 monetization GitHub 存储库文档，在自己的 Azure 订阅中实现示例项目。

定期监视 API 的使用方式，使你能够做出基于证据的决策。 例如，如果证据显示你正在流失客户，请重复上述步骤 1 到 5 来发现并解决源问题。

持续演变

定期重新审视您的盈利策略，并重新评估上述所有步骤。 在详细了解客户、提供 API 的成本以及如何响应市场竞争变化时，可能需要随着时间的推移发展盈利策略。

请记住，盈利策略只是成功实现 API 的一个方面。 其他方面包括：

  • 开发人员体验
  • 文档的质量
  • 法律条款
  • 能够扩展 API 以满足承诺的服务水平。

相关内容