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 your daily quota or the set rate limit. This page details general best practices and highlights supplementary features in the Display & Video 360 API that can help reduce your quota usage.

Utilize filters and order by parameters

Use LIST methods instead of GET methods when retrieving multiple resources. However, LIST calls can still consume a lot of quota due to limits on page size. 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 order by 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, all creatives assigned to a line item, and all line items whose serving is controlled by a certain manual trigger.
• 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 order by parameter allows you to presort the retrieved resources by specific properties, ascending or descending. order by, 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 functions

Bulk functions are methods that execute numerous actions with a single request. In the Display & Video 360 API, bulk functions are mostly reserved for the bulk editing of child resources beneath a parent resource. Common uses of bulk functionality include:

• Bulk editing sites belonging to a single channel. Channels can have thousands of sites assigned to them. Instead of populating a new channel or overhauling an existing one with individual advertisers.channels.sites.create requests, you can use an advertisers.channels.sites.bulkEdit request to add and remove entire lists of sites from a channel.
• Managing the entire targeting suite of a line item. Targeting is complex and stratified across various targeting types. Bulk functions help you manage targeting efficiently. advertisers.lineItems.bulkListLineItemAssignedTargetingOptions retrieves the entirety of a line item’s targeting suite across all targeting types. advertisers.lineItems.bulkEditLineItemAssignedTargetingOptions allows you to create and delete numerous assigned targeting options across targeting types, reducing the quota cost of setting a resource’s targeting suite to a single request.

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.