最佳实践

本文档提供了最佳做法指南。如需了解详情,请参阅性能提示

何时使用 API

以编程方式发送请求

无论您是希望自动执行工作流的每个部分,还是要在 ERP(企业资源规划)系统中创建钩子,都可以通过 Content API 在产品目录发生变化后立即发送更新。

获得即时反馈

在 Content API 中,您可以立即收到每个请求的响应,而不是在处理数据 Feed 后通过电子邮件摘要的形式收到响应。对于大批量请求,预计会有 5 到 10 秒的延迟。

需要经常更改商品数据

借助 Content API,您可以在一天内多次对快速发展的商品目录进行增量更新,而每次都发送整个数据 Feed 并不可行。如果更新单独可用,请单独发送这些更新,不要等到有多项更新时再批量发送。同样,如果可进行批量更新,请批量发送更新,不要将其拆分为单独的请求。

管理多个子账号

新创建的 Merchant Center 帐号是单个帐号,保留着自己的一组商品数据。这在大多数情况下效果很好,但随着帐号规模的扩大,您可能会发现您的商品需要更复杂的管理系统。如果您属于这种情况,不妨考虑使用多客户帐号 (MCA)。MCA 帐号的 API 级别管理可通过 Accounts 服务进行,并且允许以编程方式添加和管理子帐号。如需详细了解如何获取 MCA 帐号,请点击此处

如何使用该 API

请勿像使用数据 Feed 那样使用 API

使用 products 资源时,避免每天都更新整个商品 Feed。而是仅更新数据实际发生了更改的产品。通过 products 资源发送整个数据 Feed 会消耗 Google 和您更多的时间和资源。

请勿使用 API 定期检索您上传的商品信息

如果您负责维护特定 Merchant Center 帐号中的商品信息,请避免定期通过 products.getproducts.list 方法从 Content API 请求商品信息。对于上传信息的客户,这些方法有助于在设计使用 Content API 的解决方案时调试问题。但是,不适合此类客户端定期检索商品信息。您应还有其他商品信息来源(例如本地商品数据库),并且 Merchant Center 中的商品应反映该来源的内容。

请勿同时使用数据 Feed 和 Content API 提交商品

如果您打算改用 API 来提交商品,请确保您不再使用数据 Feed 来提交商品。如果您继续同时通过这两种媒介提交商品,可能会出现意外结果。

有没有办法安全地结合使用 API 和数据 Feed?

您可以使用 API 的数据 Feed 服务处理您的数据 Feed。虽然这样可以更轻松地大规模管理数据 Feed,但请注意,您不应同时使用 API 和 Feed 来插入或更新商品,否则可能会出现意外结果。

下面列出了将 Feed 和 API 结合起来可接受的一些其他可接受方式示例:

  • 通过 API 执行只读请求(get 或 list):某些商家希望使用 API 提取商品的信息和状态更新。这是可以接受的,因为商品信息仅通过 Feed 更新。

  • 使用 API 管理您的子帐号(Accounts 服务)和/或帐号级税费和运费设置(Accounttax 服务Shippingsettings 服务)。 这些不是 Datafeeds 能够提供的函数,因此与使用 API 管理这些函数时没有冲突。

如何从使用数据 Feed 迁移到仅使用 API,或从仅使用 API 迁移到使用数据 Feed?

如果您目前使用的是数据 Feed,并且只想改用 API 来更新商品,则需要使用 API 重新上传商品数据。当您使用商品服务更新给定商品时,API 会控制商品信息,从数据 Feed 中删除商品或删除数据 Feed 本身不会再从您的 Merchant Center 帐号中移除商品信息。如果您要从数据 Feed 或数据 Feed 中移除商品,请确保没有数据 Feed 更新,否则数据 Feed 将重新获得所有权,从数据 Feed 中移除商品将会导致商品被移除。

如果您目前仅使用 API 获取商品信息,并且希望将数据 Feed 用作商品信息的主要来源,那么只需将新数据 Feed 添加到您的 Merchant Center 帐号,它们就会获得所列出商品的所有权。如果您希望在到期之前移除仅通过 API 上传的商品,则必须通过 Merchant Center 或通过 API 将其删除。

如何使用 Content API for Shopping 将商品定位到多个国家/地区?

如需为通过 Content API 提交的商品的广告和非付费商品详情定位到多个国家/地区,请在 Merchant Center 的 Content API 主要 Feed 中配置其他国家/地区,或通过 products 资源中的 shipping 字段添加这些其他国家/地区。

以下示例说明了如何修改 Content API 主要 Feed 设置。

如需了解详情,请参阅:定位到多个国家/地区的购物广告和非付费商品详情

确保您的客户端库是最新版本

如果您使用 Google 客户端库与 Content API 进行交互,请务必使用所选编程语言的软件包管理器,并确保库版本是最新版本。如需了解详情,请参阅示例和库中与您所选语言的开发者指南。

请务必使用平台属性来控制在不同购物计划中展示哪些商品

Content API 会自动采用在 Merchant Center 中配置的 Content API Feed 的默认设置。您可以使用 includedDestinationsexcludedDestinations 商品属性来控制 Feed 中商品级别的计划参与情况或通过 Content API 进行控制。

如果您的 API Feed 已选择加入一项计划(例如 Google 易购(以前称为“购物行动”),但您希望排除某些商品,请使用 excludedDestinations 属性并指定 Shopping Actions 作为值。只要没有错误,这将覆盖 Merchant Center 中的默认 Feed 设置,并且该特定商品将不会在“在 Google 上购买”(以前称为“购物行动”)中显示。相反,如果您的 Feed 尚未选择加入某个计划(例如“购物”),您可以通过使用 includedDestinations 属性和 Shopping_ads 作为值来添加单件商品,这样商品就会在购物广告中展示。

如需详细了解 includedDestinationsexcludedDestinations 商品属性,请参阅帮助中心

请务必在商品到期前进行更新

如果在过期之前、上次更新 30 天后或指定的失效日期(以较早者为准)之前未更改内容,请更新该内容以避免停用。如果您需要更新许多项,因为所有项都没有更改,或者您无法跟踪它们的最后更新时间,请不要同时更新所有项,而是将负载均匀分布到多天。

请勿删除 Content API Feed,否则您的商品可能会消失

当您首次通过 Content API 使用 channel:online 上传商品时,Merchant Center 中会显示一个名为 Content API 的新 Feed。当您首次通过 Content API 使用 channel:local 上传商品时,Merchant Center 中会显示一个名为 Content API 的新 Feed,其子标题为本地商品。确保您没有意外删除在线或本地 Content API Feed。您通过 Content API 添加到 Merchant Center 的在线或本地商品将被移除,具体取决于您删除的 Feed。

使用 custombatch 方法对同一服务的多个请求进行批处理

不要向同一服务发出许多连续或并行请求,而应发出包含所有所需请求的单个 custombatch 请求。这样,向 API 端点发出请求时,延迟仅发生在 custombatch 调用一次,而不是每个单独的请求。如果您要发出依序请求,这一点尤为重要。

不要以批量方式向单个商品发送多个更新

由于更新顺序的不确定性,这将导致意外结果,并且可能会导致冲突错误

不针对未更改的商品发送更新

请确保仅针对新商品、已更改的商品或已删除的商品发送请求,除非这些商品即将过期。

如果价格和/或库存状况快速变化,请使用补充 Feed

如果您无法使商品的价格、库存状况或促销信息保持最新状态,请考虑使用 products 资源中的补充 Feed 仅针对这些属性发送更新。由于补充 Feed 更新规模较小,因此与完整的商品更新相比,您可以在特定时间段内进行更多补充 Feed 更新,这有助于确保商品的价格和库存状况与着陆页保持一致。

更新商品价格和库存状况的另一种方法是使用自动商品更新。此 API 可配合 API 更新使用,帮助避免 Merchant Center 中的信息与商品着陆页上的信息不一致。但请注意,该功能旨在解决商品价格和库存状况准确性方面的小问题,因此自动商品更新不能取代通过 API 提供正确信息的功能。

何时使用刷新令牌

刷新令牌在授权请求的 HTTP 标头中返回。它包含许多与身份验证相关的其他信息,但刷新令牌通常是开发者最需要的,因为它无需反复提示用户进行身份验证,因为访问令牌只有 60 分钟就会过期。