Which Google Ads Conversions API should I use?

Over the past few years, the popularity of conversions API (aka CAPI) has grown exponentially. Much of this growth has been fueled by the ad platform’s themselves that are actively pushing advertisers to switch to this method.

The reasoning behind this promotion is split into two:

  1. Data degradation
    • Regulations limiting cookie based tracking
    • Browser restrictions and ad blockers
  2. Data quality – The simple realization that the user journey doesn’t end when leaving a lead on the website, and measuring leads that actually convert drives better campaigns

While most ad platforms offer a (mostly) simple and unified API, Google Ads has multiple different APIs serving different purposes.

In this article I’ll try to breakdown the use case for each the two popular APIs:

  1. Upload Click Conversions
  2. Enhanced Conversions for Leads

For the purpose of this post, I’ll skip the Upload Call Conversions API as it often isn’t used directly by developers but rather via a 3rd party solution such as CallRail or Callbox.

I’ll also ignore the Upload Store Sales Conversions API which the access to is dependent on plenty of limitations so only a handful of brands actually use it.

Upload Click Conversions

This is the classic all-time favorite API for uploading conversions into Google Ads. The majority of platforms integrated with Google Ads use this integration to send offline conversions.

Documentation

Mechanics

This API is very straightforward.

The user is identified solely based on the Click ID fetched from the gclid parameter appended to the URL when clicking an ad served by Google (on search, GDN, YouTube etc.). The Click ID is also stored in the _gcl_aw cookie on the domain, so can be fetched at the conversion URL regardless of the landing page (assuming the Google Tag was able to run and save this value). In the case of user’s not consenting to tracking, the gclid parameter is often passed on any internal navigation in the site to persist it even without setting a cookie on the user’s browser.

On iOS devices, the gBRAID and wBRAID can also be used for matching.

There are no prerequisites for using this API. Note that Click IDs imported for this conversion event must have been created after creating the conversion event (i.e. can’t backfill events) and will only be available 4-6 hours after the conversion was created.

When to use this API

This API can be used when the user has directly visited the website by clicking on an ad. This is usually the case with Search campaigns.

Caveats

This API relies on the Click ID being known. Without it, it won’t work.

This means that it won’t take credit for any view through attribution in any way.

Enhanced Conversions for Leads

Technically, these two APIs are identical, simply use different user identifiers for matching the conversion with a specific user.

Documentation

Mechanics

The purpose of this API is to extend the capabilities of the Enhanced Conversions setup done on the site. This API assumes that the Enhanced Conversion setup is present on all conversions, thus matching the user hints on the browser (e.g. IP, user agent, etc.) with a single-valued identifier such as the user’s email. Subsequent offline conversion events sent from the CRM will try to match the email with previous online events and identifier that Google already possesses for that user.

Google explicitly recommends using the user’s email as an identifier as it is easier to standardize (i.e. lowercase and trim) compared to a phone number (trim, remove excess characters and add intl. prefix).

Source: Google

When to use this API

First and foremost, this API assume your conversions necessarily include user’s PII data and the user’s journey continues offline – a call center rep will reach out to complete the purchase or schedule a meeting etc.

Campaign-wise, this API is relevant if you use Google Ads channels that don’t drive direct conversions, e.g. YouTube and Display.

Caveats

So far I’ve found this API to be significantly less accurate than using the gclid parameter.

Since both APIs are identical, it’s technically possible to send both identifiers (GCLID and PII) in a single request. However, Google Ads will prioritize PII over GCLID. This could be problematic because if Enhanced Conversions isn’t functioning at the time of conversion, the conversion might not be recorded.

Can I use both?

Well, yes.

Since technically these APIs are identical, any conversion from your CRM can be sent into one of the two based on a simple conditional logic – GCLID exists yes or no.

Sending conversions with conditional logic in Make

Should you use both? Well, it mostly depends on the type of campaigns you’re using and the prevalence of ad blockers or cookie consent regulations in your target audience.

I generally lean towards sending as many signals as possible back to the ad platforms, risking over attribution by the platforms, as my naive assumption is that the more (quality) data you feed them, the better they are able to optimize your campaigns.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts