本指南介绍了一些最佳做法，您可以运用它们来优化应用的效率和性能。
日常维护
为确保您的应用不间断运行，可采取以下做法：
确保 API 中心中的开发者联系电子邮件地址是最新的。 这是我们与您联系时使用的别名。如果我们无法就 API 条款及条件的遵从事宜与您取得联系，您的 API 访问权限可能会在您事先不知情的情况下被撤消。因此请避免使用与个人账号或无人监控的账号相关联的个人电子邮件地址。
如需获知产品更改、维护停机、弃用日期等信息，请订阅我们的
Google Ads API 团队会定期监控论坛，因此这里非常适合发布有关 API 的问题。
- 确保您的应用遵守 Google Ads API 条款及条件 (T&C)。 如果需要，令牌审核和合规性团队将通过您的联系电子邮件地址与您联系。如果您对条款及条件有任何问题或疑虑，请回复该团队在审核您的开发者令牌申请时发送给您的电子邮件，以便与他们联系。
优化
批量操作
向 API 发出请求需要承担许多固定开销，例如往返网络延迟、序列化和反序列化处理以及对后端系统的调用。为了减少这些固定开销的影响并提高总体性能，API 中的大多数 mutate 方法都可以接受批量操作。在每个请求中包含可批处理的多个操作，可以减少所发出请求的数量和相关的固定开销。如果可以，请避免只通过一个操作发出请求。
下面我们举例说明如何向某个广告系列的多个广告组添加 5 万个关键字。与其发出 5 万个请求，每个请求只包含 1 个关键字，不如发出 100 个请求，每个请求包含 500 个关键字，甚至只发出 10 个请求，每个请求包含 5000 个关键字。一个请求中所允许的操作数量是有限制的，因此您可能需要调整批处理的操作规模，以获得最佳性能。
发送稀疏对象
在将对象发送到 API 时，系统必须对字段进行反序列化处理和验证，然后将其存储在数据库中。如果您只希望更新少数字段，传入完整对象可能会导致处理时间增加而性能下降。
为避免上述问题，Google Ads API 支持稀疏更新，允许您仅填充对象中需要更改或必需的字段。稀疏更新的处理速度更快，产生错误的可能性更小。
不在 update_mask（也称为 FieldMask）中的字段将保持不变。
例如，使用稀疏更新可让需要更新关键字级出价的应用受益，因为只需填充广告组 ID、条件 ID 和出价字段。
错误处理和管理
在开发过程中，您可能会遇到错误。本部分介绍了在应用中构建错误管理功能的注意事项和策略。除了本节之外，您还可以参阅问题排查指南，详细了解如何管理错误。
区分请求来源
一些应用主要具有交互性，它们直接发出 API 调用来响应用户在界面中发起的操作。另一些 API 主要离线工作，在定期后端进程中发出 API 调用。许多应用结合了这两者。 在考虑错误管理时，区分这些不同类型的请求会很有帮助。
对于用户发起的请求，您的主要关注点应该是为用户提供良好的体验。请根据发生的具体错误，在界面中尽可能多地为用户提供上下文。提供解决错误的简单步骤（查看下面的建议）。
对于后端发起的请求，请针对应用可能遇到的各种错误类型，实现相应的处理程序。请务必加入一个默认处理程序，用来处理罕见或以前未遇到过的错误。对于默认处理程序，建议将失败的操作和错误添加到队列中，供操作员查看并确定适当的解决方案。
区分错误类型
为构建有效的错误处理机制，了解 Google Ads API 中错误类型之间的差异至关重要。下面是最常见的一些错误类型：
同步后端
如果应用用户有手动访问 Google Ads 账号的权限，他们可能会做出应用无法知晓的更改，导致应用的本地数据库不同步。如错误类型指南中所述，对于与同步相关的错误，您既可以在其发生时解决，也可尝试主动防范。一种主动策略是对所有账号每晚执行一次同步作业，获取账号中的 Google Ads 对象，并与本地数据库进行比较。
记录错误
应将所有错误都记录到日志中以便进行调试和监控。至少应记录请求 ID、引发错误的操作和错误本身。其他要记录的信息包括客户 ID、API 服务、往返请求延迟、重试次数以及原始请求和响应。
监控趋势
请务必监控 API 错误的趋势，以便检测并解决应用存在的问题。不妨考虑构建自己的解决方案，或者从诸多现有的商业工具中选择一个，以便使用您的日志生成交互式信息中心并发送自动提醒。
开发
使用测试账号
测试账号是不会实际投放广告的 Google Ads 账号。您可以使用测试账号对 Google Ads API 进行实验，并测试应用的连接性、广告系列管理逻辑或其他处理过程能否正常运作。您的开发者令牌无需获得批准即可用于测试账号，因此您可以在申请开发者令牌之后（甚至在应用审核完成之前）立即开始使用 Google Ads API 进行开发。