Google Ads Query Language supports paging by specifying page_size in your request. This will
break up the result set of the query into multiple responses that each contains
up to page_size objects. If page_size is not specified, it is automatically
set to the maximum page size of 10,000 rows.
For example, with 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, simply
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
the subsequent requests can be different each time.
Our client libraries handle paging automatically. You only have to iterate through the rows of the response. When all the rows in the current page have been returned, the client library will fetch a new page of rows automatically on your behalf until the entire data set has been retrieved. If using REST instead of gRPC, you must explicitly make a request for each new page.
Google Ads API internally caches the entire data set, so subsequent requests are faster
than the first request. Depending on your use case, you can set page_size to
any value between 1 and 10,000. In general, for faster overall performance, you
should use a larger page_size due to fewer round trips in your responses.
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 it is sent along with the page token, it will result in an error.