Conversion Upload Concurrency

[gmcgilvray]

Describe the problem you are trying to solve: We manage conversion uploads for large advertisers who have thousands of google ads accounts. The way the google ads API is designed does not allow us to fire to a single account (unless cross conversion tracking is enabled) with conversion data and have it cascade down to the correct account. Because of this we sometimes need to make thousands of requests per conversion [O(n)].

We need to be able to fire these requests in parallel.

We are aware that we can batch conversion uploads by account, but we need to be able to fire conversions to many accounts in parallel.

Describe the solution you'd like:

We want to be able to use Async ruby (fiber aware) OR Concurrent Ruby with this library to upload conversion requests.

Describe alternatives you've considered: We have tried using Concurrent Ruby and Ruby3 Async to achieve concurrency in making these requests but have not attained true concurrency.

gRPC seems to have the concept of increasing channel connections for streaming. Still, the gem does not use streaming for conversion uploads AND every attempt to increase this channel connection value was prevented within the gem.

We have considered rolling our own REST API client and using async-faraday which we have shown to work.

Additional context:

[mcloonan]

The best practice is to keep track of which account a given conversion is for and then upload it to only the correct account. It sounds like your approach is instead to just try uploading it to every account until it succeeds, which would be extremely inefficient.

For the sake of our API processing power as well as your throughput, I strongly suggest that you develop a solution that reduces the number of upload attempts that you need to make rather than just finding a way to make attempts faster.

If I'm misunderstanding your ask, please clarify!

[gmcgilvray]

Thank you for the quick reply. You've understood our issue correctly.

We have a solution that currently has the ad account append the account ID to the URL params (we've automated updating the final_url_suffix). We can then capture this id in our attribution and fire to that account. While this seems trivial to implement, it can mean updating the tags on multiple thousands of landing pages and presents a large hurdle for many of our customers (and their customers).

It seems like the community of google ads API users has been asking for some time to be able to supply a glicd/wbraid/gbraid and receive the associated account in return. This would simplify the above use case greatly and make Google easier to interface with. My understanding is that this is not possible at this time.

With upcoming changes to third party cookies in chrome and Google's push towards enhanced conversions for leads, we need to be able to handle the case where the user does not interact with an ad, leaving us without an ad account to fire to. As described here, it is recommended that we continue to fire conversions even when a Google ad was not in play.

[mcloonan]

It sounds like you might benefit from cross-account conversion tracking, which lets you upload all your conversions from various accounts into one place, eliminating the need to figure out exactly where in your tree you need to upload the conversion. This works if you have all your accounts set up in a single manager hierarchy, but that is often the case even if you have your own customers, as you'd add your account as a manager of their account.

We have no plans to add the kind of parallelization you're asking for to the library. If you run into any difficulties implementing cross account conversion tracking, you can reach out to the Google Ads API support team at googleadsapi-support@google.com