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 Adwords API the documented limit for results per page (i.e. "page 
size") is 10000, see 
https://developers.google.com/adwords/api/docs/appendix/limits#general . 
This behavior was predictable, same queries for different accounts and 
issued at different times work consistently.

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

-- 
-- 
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
Also find us on our blog:
https://googleadsdeveloper.blogspot.com/
=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~

You received this message because you are subscribed to the Google
Groups "AdWords API and Google Ads API Forum" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/adwords-api?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"AdWords API and Google Ads API Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/group/adwords-api.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/adwords-api/90392834-f5fe-4aef-a03c-454ffabe2839%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to