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 filter and orderBy 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
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 expectedcreativeType
, and inventory sources by the relevantexchange
. - 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 actionablelineItemWarningMessage
, all insertion orders that have been updated since a given datetime, or all creatives that have a failedapprovalStatus
.
The orderBy
parameter allows you to presort 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 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 anadvertisers.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.
- If the
- 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.
- If the
- 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.
- If the
- 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.
- If the
- 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.
- If the
- Continue this pattern until the query object is updated or a maximum time elapsed is reached.