Google Ads API is returning to beta status. Please read our blog post for more details.

最佳做法

本指南介绍了一些最佳做法,您可以运用它们来优化应用的效率和性能。

日常维护

为确保您的应用不间断运行,可采取以下做法:

  • 确保 API 中心内的开发者联系电子邮件地址是最新地址,这是我们在与您联系时使用的别名。如果我们无法就 API 条款及条件的遵从事宜与您取得联系,您的 API 访问权限可能会在您事先不知情的情况下被撤消。因此请避免使用与个人帐号或无人监控的帐号相关联的个人电子邮件地址。

  • 如需获知产品更改、维护停机、弃用日期等信息,请订阅我们的

Google Ads API 团队会定期监控论坛,因此这里非常适合发布有关 API 的问题。

  • 确保您的应用遵守 Google Ads API 条款及条件 (T&C)。如果需要,令牌审核和合规团队会通过您的联系电子邮件地址与您联系。如果您对条款及条件有任何问题或疑虑,请回复该团队在审核您的开发者令牌申请时发送给您的电子邮件,以便与他们联系。

优化

批量操作

向 API 发出请求需要承担许多固定开销,例如往返网络延迟、序列化和反序列化处理以及对后端系统的调用。为了减少这些固定开销的影响并提高总体性能,API 中的大多数 mutate 方法都可以接受批量操作。在每个请求中包含可批处理的多个操作,可以减少所发出请求的数量和相关的固定开销。请尽可能避免发出只含一个操作的请求。

下面我们举例说明如何向某个广告系列的多个广告组添加 5 万个关键字。与其发出 5 万个请求,每个请求只包含 1 个关键字,不如发出 100 个请求,每个请求包含 500 个关键字,甚至只发出 10 个请求,每个请求包含 5000 个关键字。一个请求中所允许的操作数量是有限制的,因此您可能需要调整批处理的操作规模,以获得最佳性能。

重用访问令牌

在不同的线程和进程中重用相同的 OAuth2 访问令牌,可以减少定期刷新令牌的开销,也会降低您的应用因过度刷新令牌而受到速率限制的可能性。详细了解如何优化 OAuth2 请求

发送稀疏对象

在将对象发送到 API 时,系统必须对字段进行反序列化处理和验证,然后将其存储在数据库中。因此,在只需更新几个字段时,传入完整对象会增加处理时间,并降低性能。为避免上述问题,Google Ads API 支持稀疏更新,允许只填充对象中想要更改或必需的字段。稀疏更新的处理速度更快,产生错误的可能性更低。不在 update_mask(也称为 FieldMask)中的字段保持不变。

例如,使用稀疏更新可让需要更新关键字级出价的应用受益,因为只需填充广告组 ID、条件 ID 和出价字段。

错误处理和管理

在开发过程中,您可能会遇到错误。本部分介绍在应用中构建错误管理机制的注意事项和策略。除本节之外,还可参阅问题排查指南了解有关错误管理的更多信息。

区分请求来源

一些应用主要进行交互操作,它们直接发出 API 调用来响应用户在界面中发起的操作;还有一些应用主要是脱机工作,它们将 API 调用作为定期后端进程的一部分发出。很多应用结合了这两种情况。在考虑错误管理时,区分这些不同类型的请求会非常有用。

对于用户发起的请求,您的主要关注点应该是为用户提供良好的体验。就所发生的具体错误,在界面中尽可能多地为用户提供相关背景信息。在可能的情况下,为他们提供可以修正错误的简单步骤(查看下面的建议)。

对于后端发起的请求,请针对应用可能遇到的各种错误类型,实现相应的处理程序。请务必加入一个默认处理程序,用来处理罕见或以前未遇到过的错误。对于默认处理程序,建议将失败的操作和错误添加到队列中,供操作员查看并确定适当的解决方案。

区分错误类型

为构建有效的错误处理机制,了解 Google Ads API 中错误类型之间的差异至关重要。下面是最常见的一些错误类型:

  1. 身份验证错误
  2. 可重试错误
  3. 验证错误
  4. 与同步相关的错误

如需了解详情,请参阅错误类型常见错误

同步后端

如果应用用户有手动访问 Google Ads 帐号的权限,他们可能会做出应用无法知晓的更改,导致应用的本地数据库不同步。如错误类型指南中所述,对于与同步相关的错误,您既可以在其发生时解决,也可尝试主动防范。一种主动策略是对所有帐号每晚执行一次同步作业,获取帐号中的 Google Ads 对象,并与本地数据库进行比较。

记录错误

应将所有错误都记录到日志中以便进行调试和监控。至少应记录请求 ID、引发错误的操作和错误本身。其他要记录的信息包括客户 ID、API 服务、往返请求延迟、重试次数以及原始请求和响应。

请务必监控 API 错误的趋势,以便可以检测和解决应用的问题。可以考虑构建自己的解决方案或从市售的众多商业工具中选择一个,以便使用您的日志来生成交互式信息中心,并自动发送提醒。

开发

使用测试帐号

测试帐号是不会实际投放广告的 Google Ads 帐号。您可以使用测试帐号对 Google Ads API 进行实验,并测试应用的连接性、广告系列管理逻辑或其他处理过程能否正常运作。您的开发者令牌无需获得批准即可用于测试帐号,因此您可以在申请开发者令牌之后(甚至在应用审核完成之前)立即开始使用 Google Ads API 进行开发。