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 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
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 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 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
ordelete
requests, you can use a singlebulkEdit
orreplace
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
andeditAssignedTargetingOptions
in theadvertisers
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.
- 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.