Quota Optimization

Quota optimization is imperative for any application using the Display & Video 360 API. Optimizing quota usage improves performance by streamlining API requests and helping you avoid errors returned when exceeding set rate limits.

This page details general best practices and highlights supplementary features in the Display & Video 360 API that can help reduce your quota usage.

Make concurrent requests against various advertisers

A majority of methods in Display & Video 360 API specify an advertiser in the URL. In addition to project-wide quota, more restrictive "per advertiser per project" rate limits are enforced for these methods when making calls specifying the same advertiser.

To optimize for this quota, limit concurrent requests to those specifying different advertisers.

Utilize pageSize, filter, and orderBy parameters

Use list methods instead of get methods when retrieving multiple resources. Due to limits on page size, list calls can still consume a lot of quota.

Optimize all of your list requests by setting the pageSize parameter to the maximum allowable value. A method's default page size, used when the parameter is not set, may be less than its maximum allowable value and require more requests to retrieve an exhaustive list of resources.

If you need to only retrieve a subset of the full list response, you can optimize quota use by taking advantage of optional filter and orderBy parameters.

The filter parameter allows you to restrict the resources retrieved by the list call to those whose properties abide by given expressions. This parameter is useful when attempting to retrieve:

• A specific resource with an unknown ID but known properties. If searching for a specific resource, you can filter the returned list by known properties of the desired resource. Examples include filtering line items by a known displayName, creatives by the expected creativeType, and inventory sources by the relevant exchange.
• Associated resources. Resources in Display & Video 360 are often associated with each other. You can use filters to restrict the returned resources to those that have a specific relationship with another. Examples include retrieving all insertion orders beneath a specific campaignId and all creatives assigned to a line item.
• Only resources that have actionable properties. API functionality allows you to easily check the status of resources and react programmatically. Using filters, you can use list calls to only obtain resources where an action is needed. Examples include retrieving all line items that show a certain actionable lineItemWarningMessage, all insertion orders that have been updated since a given datetime, or all creatives that have a failed approvalStatus.

The orderBy parameter allows you to sort the retrieved resources by specific properties, ascending or descending. orderBy, especially when utilized alongside filter, can be used to limit the number of pages that need to be traversed before finding a specific resource. It also enables you to easily get the upper and lower bounds of a resource list. For example, ordering by updateTime would allow you to quickly find the most recently updated line items or insertion orders of an advertiser.

Use bulk and resource-wide functions

Display & Video 360 API offers a number of bulk and resource-wide functions that execute numerous actions with a single request. Examples of these kinds of functions include:

• Bulk editing sites belonging to a single channel. Channels can have thousands of sites assigned to them. Instead of managing the site list of a channel with individual create or delete requests, you can use a single bulkEdit or replace request to add and remove numerous sites or replace the entire contents a channel, respectively.
• Managing the entire targeting suite of an advertiser. A resource's targeting suite is assigned across multiple targeting types. Resource-level targeting functions, such as listAssignedTargetingOptions and editAssignedTargetingOptions in the advertisers service, allow you to retrieve, create, and remove targeting across multiple targeting types in a single request. This reduces the quota cost of setting an advertiser’s targeting suite to a single request.
• Setting the same targeting restriction across multiple line items. If you need to make the same targeting changes across multiple line items at once, this can be done using a single advertisers.lineItems.bulkEditAssignedTargetingOptions request.
• Activating or pausing multiple line items. Line items have to be activated after being created before they begin serving. If you are creating multiple line items in quick succession, you can activate all of them with a single advertisers.lineItems.bulkUpdate request. The same method can be used to pause multiple line items to stop them from serving.

Cache and check regularly used IDs

Many operations in the Display & Video 360 API require the use of resource IDs that are retrieved through the API itself, including targeting option IDs, Google audience IDs, and more. In order to avoid retrieving the IDs from the API at every use, we recommend that you locally store these IDs.

However, some resources can be deprecated, deleted, or otherwise made unavailable for use. Attempting to use the IDs for these resources may return an error. Therefore, we recommend that you check all cached IDs on a weekly basis using the appropriate get or filtered list method to confirm that it is still retrievable and has the expected status.

Implement exponential backoff for long-running operations

While polling to see if a long-running operation, such as a SDF download task, is finished, use an exponential backoff strategy to reduce the frequency and total number of requests sent.

Exponential backoff is a standard error handling strategy for network applications in which the client periodically retries requests over an increasing amount of time. Used properly, exponential backoff increases the efficiency of bandwidth usage, reduces the number of requests required to get a successful response, and maximizes the throughput of requests in concurrent environments.

You can find the exponential backoff strategy implemented with client libraries in our SDF download code examples. The step-by-step flow for implementing simple exponential backoff is as follows:

• Make a sdfdownloadtasks.operations.get request to the API.
• Retrieve the operation object.
  • If the done field is not true, that indicates that you should retry the request.
  • Wait 5 seconds + a random number of milliseconds and retry the request.
• Retrieve the operation object.
  • If the done field is not true, that indicates that you should retry the request.
  • Wait 10 seconds + a random number of milliseconds and retry the request.
• Retrieve the operation object.
  • If the done field is not true, that indicates that you should retry the request.
  • Wait 20 seconds + a random number of milliseconds and retry the request.
• Retrieve the operation object.
  • If the done field is not true, that indicates that you should retry the request.
  • Wait 40 seconds + a random number of milliseconds and retry the request.
• Retrieve the operation object.
  • If the done field is not true, that indicates that you should retry the request.
  • Wait 80 seconds + a random number of milliseconds and retry the request.
• Continue this pattern until the query object is updated or a maximum time elapsed is reached.