GoogleAdsService.Search
supports
paging by specifying
page_size
in your request.
This splits the result set of the query into multiple responses, each of which
contains up to page_size
number of objects. If
page_size
is not specified,
it is automatically set to the maximum of 10,000 rows.
As an example, for the following query:
SELECT
ad_group.id,
ad_group_criterion.type,
ad_group_criterion.criterion_id,
ad_group_criterion.keyword.text,
ad_group_criterion.keyword.match_type
FROM ad_group_criterion
WHERE ad_group_criterion.type = KEYWORD
If your account contains 50,000 keywords and
page_size
is set to 1,000
,
the result set will contain 1,000 GoogleAdsRow
objects in the first response, along with a
next_page_token
.
To retrieve the next one thousand rows, send the request again with the same
page size, but update the request's page_token
to the response's
next_page_token
. The
value of page_size
in
subsequent requests can be different each time. Note that
next_page_token
is not
populated in the response that contains the last batch of rows.
Our client libraries handle paging automatically. You only have to iterate through the rows of the response. When all rows in the current page have been returned, the client library fetches a new page of rows automatically on your behalf until the entire data set is retrieved. If using REST instead of gRPC, you must explicitly make a request for each new page.
The Google Ads API internally caches the entire data set, so subsequent requests are
faster than the initial one. Depending on your use case, you can set
page_size
to any value
between 1 and 10,000. In general, for faster overall performance, use a larger
page_size
for fewer round
trips.
Your query must remain exactly the same in subsequent requests to take advantage of the cached data; the requests won't contribute towards your quota, particularly for basic access. If the query differs and is sent along with the same page token, an error is returned.