配额优化

对于使用 Display & Video 360 API 的任何应用，配额优化都是必不可少的。 优化配额用量可以简化 API 请求，并帮助您避免超出设定的速率限制时返回的错误，从而提高性能。

本页详细介绍了一些常见的最佳实践，并重点介绍了 Display & Video 360 API 中可帮助您减少配额用量的补充功能。

针对多个广告客户发出并发请求

Display & Video 360 API 中的大多数方法都会在网址中指定广告客户。除了项目级配额之外，在进行指定同一广告客户的调用时，系统还会对这些方法强制执行更严格的“每个项目的每个广告客户”速率限制。

如需针对此配额进行优化，请将并发请求限制为指定不同广告客户的请求。

使用 pageSize、filter 和 orderBy 参数

检索多个资源时，请使用 list 方法，而不是 get 方法。由于页面大小存在限制，list 调用仍可能会消耗大量配额。

将 pageSize 参数设置为允许的最大值，以优化所有 list 请求。方法的默认页面大小（在未设置该参数时使用）可能小于其允许的最大值，并且需要发出更多请求才能检索完整的资源列表。

要点 ：firstAndThirdPartyAudiences.list 方法的 pageSize 参数默认为 100，但支持的最大值为 5000。将这些请求的 pageSize 参数设置为 5000，以大幅优化受众群体检索。

如果您只需要检索完整列表响应的一部分，则可以利用可选的 filter 和 orderBy 参数来优化配额用量。

注意 ：每个 list 方法都支持对不同字段进行过滤和排序。如需查看支持的字段列表，请参阅方法文档中的 filter 和 orderBy 参数说明。

通过 filter 参数，您可以将 list 调用检索到的资源限制为属性符合给定表达式的资源。在尝试检索以下内容时，此参数非常有用：

• ID 未知但具有已知属性的特定资源。如果搜索特定资源，您可以按所需资源的已知属性过滤返回的列表。示例包括按已知的 displayName 过滤订单项、按预期的 creativeType 过滤广告素材，以及按相关的 exchange 过滤广告资源来源。
• 关联的资源。Display & Video 360 中的资源通常相互关联。您可以使用过滤条件将返回的资源限制为与其他资源具有特定关系的资源。例如，检索特定 campaignId 下的所有广告订单以及分配给订单项的所有广告素材。
• 仅包含可操作属性的资源。借助 API 功能，您可以轻松检查资源状态并以编程方式做出响应。借助过滤器，您可以使用 list 调用来仅获取需要执行操作的资源。例如，检索显示特定可操作 lineItemWarningMessage 的所有订单项、自指定日期时间起更新的所有广告订单，或approvalStatus 失败的所有广告素材。

借助 orderBy 参数，您可以按特定属性（升序或降序）对检索到的资源进行排序。orderBy（尤其是与 filter 搭配使用时）可用于限制在找到特定资源之前需要遍历的页面数量。您还可以轻松获取资源列表的上限和下限。例如，按 updateTime 排序可让您快速找到广告客户最近更新的订单项或广告订单。

使用批量函数和资源级函数

Display & Video 360 API 提供了许多批量和资源级函数，可通过单个请求执行多项操作。此类函数的示例包括：

• 批量修改单个渠道所属的网站。渠道可以分配数千个网站。您可以使用单个 bulkEdit 或 replace 请求分别添加和移除多个网站，或替换渠道的全部内容，而无需使用单独的 create 或 delete 请求来管理渠道的网站列表。
• 管理广告客户的整个定位条件套件。资源的定位套件会跨多种定位类型分配。借助资源级定位函数（例如 advertisers 服务中的 listAssignedTargetingOptions 和 editAssignedTargetingOptions），您可以在单个请求中检索、创建和移除多种定位类型的定位条件。这样可以将将广告客户的定位套件设置为单个请求的配额费用降低。
• 为多个订单项设置相同的定位限制。如果您需要对多个订单项同时进行相同的定位条件更改，可以使用单个 advertisers.lineItems.bulkEditAssignedTargetingOptions 请求来实现。
• 启用或暂停多个订单项。订单项在创建后必须先启用，然后才能开始投放。如果您要快速连续创建多个订单项，则可以通过单个 advertisers.lineItems.bulkUpdate 请求启用所有订单项。您可以使用相同的方法暂停多个订单项，以停止其投放。

缓存和检查经常使用的 ID

Display & Video 360 API 中的许多操作都需要使用通过 API 本身检索到的资源 ID，包括定位选项 ID、Google 受众群体 ID 等。为避免每次使用时都从 API 检索 ID，我们建议您在本地存储这些 ID。

不过，某些资源可能会被弃用、删除或以其他方式变为不可用。尝试使用这些资源的 ID 可能会返回错误。因此，我们建议您每周使用适当的 get 或经过过滤的 list 方法检查所有缓存的 ID，以确认其是否仍可检索且处于预期状态。

为长时间运行的操作实现指数退避算法

在轮询以查看长时间运行的操作（例如 SDF 下载任务）是否已完成时，请使用指数退避算法来减少发送请求的频率和总数。

指数退避算法是网络应用的标准错误处理策略，在此策略中，客户端按照不断增加的时间间隔定期重试请求。如果使用得当，指数退避算法还能提高带宽使用效率、减少获得成功响应所需的请求次数，并最大程度地提高并发环境中的请求吞吐量。

您可以在我们的 SDF 下载代码示例中找到使用客户端库实现的指数退避算法。实现简单指数退避算法的分步流程如下：

• 向 API 发出 sdfdownloadtasks.operations.get 请求。
• 检索操作对象。
  • 如果 done 字段不为 true，则表示您应重试该请求。
  • 等待 5 秒 + 随机毫秒数，然后重试该请求。
• 检索操作对象。
  • 如果 done 字段不为 true，则表示您应重试该请求。
  • 等待 10 秒 + 随机毫秒数，然后重试该请求。
• 检索操作对象。
  • 如果 done 字段不为 true，则表示您应重试该请求。
  • 等待 20 秒 + 随机毫秒数，然后重试该请求。
• 检索操作对象。
  • 如果 done 字段不为 true，则表示您应重试该请求。
  • 等待 40 秒 + 随机毫秒数，然后重试该请求。
• 检索操作对象。
  • 如果 done 字段不为 true，则表示您应重试该请求。
  • 等待 80 秒 + 随机毫秒数，然后重试该请求。
• 一直持续此模式，直到查询对象更新或达到最大间隔时间为止。