本指南介绍了如何使用 Google Play Developer API 创建和 为 Play 应用管理商品清单
如需通过 Google Play 结算系统销售您应用中的商品，您需要满足以下条件： 设置一个目录，其中包含您要销售的所有商品 。您可以通过 Play 管理中心完成此操作，也可以 使用 Google Play Developer API 自动执行目录管理。自动化技术可以 有助于确保您的目录始终保持最新状态，并可以扩展到 手动协调并不切实际。 在本指南中，您将了解如何使用 Play Developer API 为您的 Play 应用创建和管理商品清单。 请参阅我们的做好准备指南，了解如何设置 为后端集成设置 Google Play Developer API。
Catalog Management API
要了解您可以通过 Google Play 的 结算系统, 读取 了解应用内商品类型和目录注意事项。 Google 为 Play 上的目录管理提供了两套主要 API： 与两大产品类别相对应：
- 一次性商品
- 订阅产品
一次性商品
通过 inappproducts 端点，您可以一次性管理
从后端提取商品信息这包括创建、更新和删除
以及管理价格和库存状况。
根据您处理一次性商品购买交易的方式，
消耗型商品（可以根据需要购买任意次）或永久商品
使用权（同一用户不能进行两次授权）。您可以决定
一次性商品应该是消耗型商品。
订阅产品
monetization.subscriptions 端点可帮助您管理订阅
从开发者后端提取商品。您可以执行各种操作，例如创建、更新
和删除订阅，或控制其地区性库存状况和价格。
除了 monetization.subscriptions 端点，我们还提供
monetization.subscriptions.basePlans和
monetization.subscriptions.basePlans.offers分别管理
个订阅的基础方案和优惠。
批处理方法
inappproducts 和 monetization.subscriptions
端点提供许多批处理方法，
至 100 个实体。
批处理方法在启用延迟时间容限的情况下，支持更高的延迟 尤其适合大目录开发者 创建目录或进行目录对账
更新传播延迟时间与吞吐量
产品创建或修改请求完成后，不得进行更改
由于网络或后端，最终用户可立即看到其设备上的内容
处理延迟。
默认情况下，所有产品修改请求都对延迟时间敏感。这意味着
它们经过优化，可以快速通过后端系统传播，
并在几分钟内对最终用户的设备作出反应。不过，每小时有
。
如果您需要创建或更新许多商品（例如，在
初始大目录创建），您可以将批处理方法与
“latencyTolerance”字段已设置为
PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT。
这将显著提高更新吞吐量。可容忍延迟的更新
最长可能需要 24 小时才能应用到最终用户的设备。
配额配置
使用 Play Developer 时，您应该注意一些配额限制 用于管理商品清单的 API：
- Google Play Developer API 的默认上限为每个 Google Play Developer API 200,000 次查询 。此配额限制适用于所有端点中的用量汇总 包括 Catalogs 的 API
- 产品修改端点还强制实施每个周期 7,200 次查询的限制 小时。一次性商品和订阅都受这一限制 所有修改请求，包括创建、更新、激活 删除。对于此配额，批量修改方法调用计为一个查询， 无论包含的单个请求数量或其延迟时间 敏感度。
- 对延迟时间敏感的修改也不得超过 7,200 次修改 。对于批处理方法，每个嵌套修改请求都会计入 单独进行计算此配额为 仅对执行延迟敏感型批处理 API 用户的影响 因为在其他情况下，配额 2 将在同一时间之前或 作为此配额
下面几个说明示例可帮助您理解 不同的请求：
- 获取一件商品的单个
get请求将消耗 1 个配额为 1 的令牌， 没有配额 2 和 3 的令牌（因为它们只涉及修改端点）。 - 一次提取最多 100 个项的批量
get请求也将消耗 1 个 配额为 1，没有配额 2 和 3 的令牌。 - 一个商品的单个
modification请求将消耗 1 个配额为 1 的令牌 ，1 个配额为 2 的令牌。如果请求对延迟时间敏感，它也会 消耗 1 个配额的令牌，配额为 3。由于配额 C 与配额 2 的限制相同， 不会对只使用一次修改的用户产生任何实际影响 方法。 - 一个针对 100 个容错项的批量
modification请求将消耗 1 配额为 1 的令牌，1 个令牌为配额 2。这种配额设置应该能够 如果您的算法不注意更新目录， 并且超出此速率，则在额外调用时可能会收到错误消息。 - 针对 100 个延迟时间敏感项的批量
modification请求将消耗 配额 1 的 1 个令牌，配额 2 的 1 个令牌，配额 3 的 100 个令牌。
Catalog Management API 使用建议
只要您遵守这些准则，就能优化您与 API 的互动， 确保用户获得流畅高效的目录管理体验。
监控您的用量
请注意大量使用流程。例如，在 您的集成，您的目录管理端点更可能使用 从而创建完整的初始目录 对其他端点（如 purchase status API）进行生产环境使用 接近总体用量限额。 您需要监控自己的配额消耗情况， 超过 API 配额。您可以通过多种方式监控使用情况。例如： 您可以使用 Google Cloud API 配额信息中心 您选择的第三方 API 监控工具。
优化 API 配额使用情况
强烈建议优化速率消耗 API 错误。 为了有效地实现这一点，我们建议您：
- 选择合适的目录管理策略。了解 API 后 您需要选择适合应用的策略 高效地实现目录管理目标
- 请尽量减少反映您所做更改所需的调用次数。
- 请勿向 API 发送冗余或不必要的修改调用。这个 可能需要在后端目录中保留更新日志。
- 不要超过每小时 7,200 次查询的产品修改限制。您可以 建立需要大量产品的同步流程 （例如，初始目录 创建）。如果您预计这些流程会超过每小时限制 根据需要实施等待，将使用速度减慢到安全水平。建议将 批处理方法（具有容忍更新），以实现更高的吞吐量。
- 主动为扩大规模做好准备。随着应用规模的扩大，您可能需要 扩大 API 和各种端点的使用规模。阅读Google Play Developer API 配额文档，详细了解如何实现 在接近最大用量时增加配额。
- 有策略地安排繁重进程。尝试为内容丰富的目录安排发布时间 在临近使用高峰前后的进程中，例如，您可以避免 在一周的销售高峰期同步完整目录。
添加了配额错误处理逻辑
无论您如何高效地构建清单管理逻辑，
使其能够适应意外的配额限制，因为每日配额为
由集成的独立模块中使用的端点共享。请确保
您在错误处理过程中加入配额限制错误，并实施
适当的等待时间。
对 Google Play Developer API 的每次调用都会生成响应。在
调用失败时，您会收到失败响应，其中包含
HTTP 响应状态代码和 errors 对象，用于提供更多详细信息
错误域和调试消息。
例如，如果您超出了每日上限，就可能会遇到错误
类似于以下内容：
{
"code" : 403,
"errors" : [ {
"domain" : "usageLimits",
"message" : "Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API
Console: https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxxx",
"reason" : "dailyLimitExceeded",
"extendedHelp" : "https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxx"
} ],
}
目录管理实现
开发者使用 Google Play Developer API 产品发布端点 使其目录在后端和 Google Play 之间保持同步。制作 确保您的 Google Play 目录始终与后端的目录保持同步 最新信息有助于打造更好的用户体验。 例如：
- 您将可以查阅可用优惠的完整列表，并管理 优惠和基础方案标签，以影响您自己的资格条件和优惠的显示情况 逻辑。
- 您可以查看用户不同的价位和商品详情 查看各个平台的情况，并确保它们保持一致。
- 处理新商品时，您会在后端看到商品详情 而不必增加延迟时间和降低失败风险 在用户关键流程中额外调用 Google Play Developer API。
您应该遵守一些某些限制和注意事项 在 Google Play 上创建商品清单时的注意事项了解了 有了这些限制，而且知道如何构建目录后， 决定您的同步策略。
目录同步策略
借助 Google Play Developer API 发布端点，您可以 更改目录时会自动更新目录有时，您可能需要定期 更新方法，即在同一流程中发送一系列更改。每个 方法需要不同的设计选择。每个同步策略 更适合某些应用场景，并且您可能有一组 视具体情况而定。有时，您可能希望 在知晓新变化时立即对产品进行更新，例如， 处理紧急的产品更新（例如，需要更正错误的价格， ）。在其他时候，您可以使用定期后台同步 您的后端和 Play 目录始终保持一致。了解一些常见用法 可能希望实施不同产品目录管理系统的情况 策略
何时在本地目录发生变化时发送更新
理想情况下，应在后端发生任何更改后立即更新 以便最大限度地减少差异。
在以下情况下，此类更新是很好的选择：
- 您必须确保商品始终处于最新状态。
- 您需要每天对商品进行一些更改。
- 您需要更新已经生产并销售的产品。
此方法更易于实现，并且可让您保持目录保持同步 即可。
何时使用定期更新
定期更新与后端的产品版本异步运行， 在以下情况下，它们是不错的选择：
- 您无需确保在短时间内更新商品。
- 您需要规划批量更新或协调流程。
- 您已经拥有内容或目录管理系统来处理您的 并且会不断更新你的目录
对于大型目录，请考虑使用可容忍延迟的批处理方法 更新以实现最大吞吐量。
创建商品清单
如果您有大量要上传到 Google Play 的目录，不妨使用自动化操作 初始加载大小如果定期制定策略，这种繁重的流程 结合使用可容忍延迟的批处理方法。
创建一次性商品
在初始创建一次性商品大型目录时，我们建议您使用
inappproducts.batchUpdate 方法，并将 allowMissing 字段设置为
true，并将 latencyTolerance 字段设置为
PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT。
这样可以最大限度地缩短在配额限制内创建目录的时间。
对于较小的目录，您可以使用 inapp_products.insert 方法。
或者，您可以将 inappproducts.update 方法与
allowMissing 参数（如“产品更新”部分中所述）。
这种方法的优势在于，您无需编写脚本
有状态，并且可以在出现问题时从头开始重启。
创建订阅产品
对于初始订阅大型目录，我们建议您使用
monetization.subscriptions.batchUpdate 方法
allowMissing 字段设置为 true，且 latencyTolerance 字段已设置
共享给PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT。
这样可以最大限度地缩短在配额限制内创建目录的时间。
对于较小的订阅目录，Play Developer API 为
monetization.subscriptions.create 方法。
或者，您也可以使用
monetization.subscriptions.update 方法，
allowMissing 参数（如“产品更新”部分中所述）。
之前的所有方法都可以同时创建订阅及其基础方案
（在 Subscription 对象中提供）。这些基础方案最初是
无效。管理基础方案状态，您可以使用
monetization.subscriptions.basePlans 端点，包括激活
让相应基础方案可供购买。
此外，monetization.subscriptions.basePlans.offers 端点
可用来创建和管理优惠。
产品最新动态
通过以下方法，您可以高效地修改现有商品 确保您提供的产品/服务与您的最新调整相符。
更新一次性商品
您可以使用三种方法来更新现有的一次性商品。
inappproducts.patch：补丁端点用于部分更新资源。这意味着 可以更新您在请求正文中指定的特定字段。补丁 通常用于仅更新少数字段的 资源。inappproducts.update：更新端点用于更新整个资源。这意味着 您将需要在请求正文中发送整个资源对象。通过 如果您需要更新 资源。当allowMissing参数设置为true且提供的 产品 ID 不存在，端点将插入此产品 而不是失败inappproducts.batchUpdate：这是更新端点的批处理版本， 通过一次查询即可显示多个产品。将它与latencyTolerance字段已设置为PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT以实现更高的吞吐量
更新订阅产品
要更新现有订阅，您可以使用
monetization.subscriptions.patch 方法。此方法
采用以下必需参数：
packageName：订阅所属应用的软件包名称。productId：订阅的唯一商品 ID。regionsVersion：区域配置版本。
除非您使用 allowMissing 参数创建新订阅
，则必须提供 updateMask 参数。此参数是
您要更新的字段的列表（以逗号分隔）。
例如，如果您只想更新订阅商品的商品详情，
则需要为 updateMask 参数指定 listings 字段。
您可以使用 monetization.subscriptions.batchUpdate 同时更新多项订阅。
将 latencyTolerance 字段设置为
PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT，以实现更高的
吞吐量。
如需启用、停用或删除基础方案，或者将订阅者迁移到
最新的基础方案价格版本使用 monetization.subscriptions.basePlans 端点。
此外，您还可以更新基础方案的提供
monetization.subscriptions.basePlans.offers.patch
方法。
目录对账
您是否选择在每次后端发出数据时更新 Google Play 目录 或定期更改清单（如果您有目录管理系统或 Google Play 目录之外的其他数据库， 与 Play 中应用配置的目录不同步。 这可能是因为 Play 管理中心内的手动目录紧急更改、服务中断 或者如果您丢失了最新数据
您可以构建目录对账流程，以避免长时间出现差异 窗口。
差异比较系统考虑因素
我们建议构建一个 diff 系统来检测不一致问题并使 两个系统 下面介绍了在构建差异系统时需要考虑的一些事项 同步的目录：
- 了解数据模型：首先要了解数据 开发者 CMS 和 Google Play Developer API 的两种不同模式。这包括 了解每个系统中存储的不同类型的数据，以及如何 不同的数据元素相互映射。
- 定义差异规则：了解数据模型后，您需要 定义差异规则这些规则将决定 进行比较例如，您可能希望将产品 ID 和 比较订阅及其相关基础方案的关键属性 优惠。
- 实施差异算法：定义差异规则后，
需要实现差异算法该算法会从
这两个系统，然后根据您定义的规则对其进行比较。要获得
Google Play 中的目录数据后，您可以使用
inappproducts.list、inappproducts.batchGet,monetization.subscriptions.list和monetization.subscriptions.batchGet方法。 - 生成差异报告：差异算法将生成差异报告。 此报告会显示这两个系统之间的区别。
- 协调差异：生成差异报告后， 来解决差异问题。这可能涉及更新 CMS 中的数据，或者 可能涉及使用 Developer API 更新 Google Play 端的数据 更新清单管理端点，具体取决于 目录。 要协调不同步的产品，请按照 “产品最新动态”部分
产品弃用
Google Play Developer API 提供了多种方法来协助开发者
弃用其产品：
inappproducts.delete和
inappproducts.batchDelete
包括一次性商品和
monetization.subscriptions.delete
。在各种情况下，都可能需要弃用产品
，例如：
- 误创作。
- 停止使用某项功能或服务。
我们建议将产品弃用功能纳入目录管理中 策略
弃用一次性商品
要使用 Google Play Developer API 删除一次性商品，您需要使用
该
inappproducts.delete
或
inappproducts.batchDelete
方法。
弃用订阅产品
您可以使用
monetization.subscriptions.delete
方法。必须至少有一个基础方案，才能移除订阅
。