Hi Google Ads API team,
I stumbled into
the same issue regarding a byte size page limitation in the Google Ads API as described in
https://groups.google.com/d/msg/adwords-api/CXCz72ZIAbs/nLuCvDOEAQAJ. That forum entry was marked completed, though to my understanding the issue is a lot bigger bummer and has to be resolved in a solid way in the Google Ads API itself. I'd like to emphasize, that the change for the page
size in the Ads API makes requests (and thus a production use of the
Google Ads API) basically a gamble... Please read my considerations below why this is a major issue in the Google Ads API.
In
the Google Ads API Workshop in Munich in March 2019, the Google Ads
team suggested to use the same limits for the Ads API as they were
defined to the Adwords API. Now during the migration to the Ads API we
were astonished to see that instead of a predictable row count, an actual byte size
is used to limit page sizes. A byte size limitation feels awkward for
the Ads API use, where the number of columns vary for GAQL queries and
also the content for each requested column varies a lot for different account IDs and over time. So in the end for exactly the same GAQL query an account ID works fine, while another one fails due to hitting the 4MB page limit - although the Ads API PAGE_SIZE is still the same for both. Even worse, the fetch for the same account ID fails over time if some values (i.e. product type) become larger, thus making pages reach the 4MB limit.
This
behavior in the Ads API is basically making a production use a gamble as the behavior is unpredictabl.
One option is of course to change the page size in case the error
occurs. Though this feels ridiculous, as the error might occur also during paging for any page inbetween - and paging is handled by the client libraries seamlessly, so actually we'd need to change the client library code... A different option is to use a very low page size which hopefully fits
the same GAQL query for all accounts for all time - though this leads to
even worse performance due to many additional roundtrips due to tiny pages. Obviously
setting the page_size to the maximum possible value is the favored
option. Though knowing the right page size in advance is impossible as
it depends on the data content which can't be known in advance.
It would be great if the Ads API could apply a real page_size limitation based on number of rows, instead a byte size. Number of rows, as implemented in the Adwords API leads to a predictable behavior for same GAQL queries for all accounts for all time.
Regards,
Robert