Google Ads has approached server-side conversion tracking with the kind of enthusiasm typically reserved for necessary dental work. They’ll do it, certainly, but they’ve made absolutely sure it’s more complex than it needs to be, with multiple overlapping systems that accomplish similar things in slightly different ways.
Let’s untangle this mess, shall we?
Unlike Meta’s relatively straightforward Conversions API, Google offers you several delightful ways to send server-side conversion data, each with its own authentication dance and quirks:
All of these ultimately accomplish the same thing: telling Google Ads that someone who clicked your ad subsequently did something worth measuring. The devil, as always, lurks in the details.
When you send a conversion to Google Ads, you need to tell them which click resulted in this conversion. Google supports three types of click identifiers, in a clear hierarchy of preference:
The gclid is Google’s original click tracking parameter, that delightful string of gibberish appended to your landing page URLs when someone clicks a Google ad. It looks something like gclid=CjwKCAiA8YyuBhBSEiwA5R3-E7vQxK... and continues until you lose the will to live.
This is Google’s gold standard. If you have a GCLID, send the GCLID. Google knows exactly which click this was, which campaign, which keyword, which ad — everything necessary for proper attribution. Your conversion will be matched with the confidence of someone who actually read the manual.
How to get it: Capture it from the URL parameter when users land on your site, store it (in a cookie, database, or wherever you keep such things), and include it when you send the server-side conversion event.
Because Apple decided that user privacy was more important than Google’s business model (imagine!), iOS 14.5+ made tracking considerably more annoying. Google’s response was to create two new click identifiers specifically for iOS traffic:
These are Google’s attempt at privacy-preserving attribution. They don’t contain as much information as a GCLID, but they’re better than nothing and specifically designed to work within Apple’s ATT (App Tracking Transparency) framework.
They combine best of both worlds: while they don’t point to a single click or user, they’re usually unique enough to allow Google to identify a campaign and an ad behind the ad click.
How to get them: Same as GCLID — they appear as URL parameters (gbraid= or wbraid=) that you need to capture and store.
At the bottom of the pyramid sits Enhanced Conversions—Google’s fallback solution for when you don’t have any click identifiers. This is designed for offline conversions: purchases that happen in the real world, over the phone, via sales teams, or any other scenario where a click ID was never captured or simply doesn’t exist.
To work correctly, Enhanced Conversions require first-party data (such as customer emails or phones) ideally to be both:
Make no mistake: this is not the gold standard. It’s what you use when the gold standard isn’t available. If you have a GCLID or WBRAID/GBRAID, use that instead. Always. Click identifiers provide deterministic attribution — Google knows with certainty which click led to the conversion and you know which visitor’s click ID you’ve sent it. Enhanced Conversions provides probabilistic attribution — Google will try to match your customer data back to an ad interaction, with varying degrees of success.
Important: You cannot mix click identifiers with Enhanced Conversions data in the API. It’s one or the other. If you have a GCLID, send the GCLID. If you don’t, send Enhanced Conversions data. Google’s API will reject attempts to send both.
Enhanced Conversions is designed for a specific workflow:
The canonical use case: someone clicks your ad, fills out a lead form (Google Tag captures their email), three weeks later your sales team closes the deal for £50,000, and you upload that conversion with the customer’s email address so Google can connect the dots and understand which ad ultimately drove that revenue.
This is genuinely useful for businesses with long sales cycles, phone-based sales, or any scenario where the conversion happens outside the browser entirely.
But if you do keep track of GCLIDs and other clicks ID for the customer, using them instead of Enhanced Conversions provides a much more predictable and deterministic way of matching.
What about using it to bypass ad blockers? You might be thinking: “If ad blockers prevent my GCLID from being captured, couldn’t I just use Enhanced Conversions instead?” Technically, perhaps. But you’d be using a fallback mechanism as your primary strategy, accepting lower match rates and probabilistic attribution when deterministic attribution should be available. It’s like using your spare tyre as your main tyre — it may get you there, but it’s not what it was designed for.
When you send a conversion via the Google Ads API, your request structure depends entirely on which identifier type you’re using (examples are simplified for readability): Option 1: With GCLID
{
“conversionAction”: ".../987654321”,
“gclid”: “CjwKCAiA8YyuBhBSEi...”,
“conversionDateTime”: “2025-10-02 14:30:00”,
“conversionValue”: 149.99,
“currencyCode”: “GBP”
}
Option 2: With WBRAID/GBRAID
{
“conversionAction”: ".../987654321”,
“wbraid”: “CAEQAg...”, // or gbraid
“conversionDateTime”: “2025-10-02 14:30:00”,
“conversionValue”: 149.99,
“currencyCode”: “GBP”
}
Option 3: With Enhanced Conversions (no click ID)
{
“conversionAction”: ".../987654321”,
“conversionDateTime”: “2025-10-02 14:30:00”,
“conversionValue”: 149.99,
“currencyCode”: “GBP”,
“userIdentifiers”: [
{
“hashedEmail”: “a665a4...e3”,
“hashedPhoneNumber”: "...”
}
]
}
Choose your path: click identifier if you have it, Enhanced Conversions if you don’t.
You’re giving Google three pieces of critical information:
Send the GCLID if you have it. Send Enhanced Conversions data as a fallback if not.
In Google Ads, conversions aren’t just conversions — they’re categorized into Conversion Actions, and each action can be configured as either Primary or Secondary.
Primary conversions are what Google optimizes towards. When you tell Smart Bidding to “maximize conversions,” these are the conversions it cares about. They appear in your main reporting. They affect your automated bidding. They matter.
Secondary conversions are... well, secondary. They’re tracked and reported, but Google’s algorithms ignore them for optimization purposes. They’re useful for measurement — tracking newsletter signups alongside purchases, for instance — without confusing your bidding strategy by treating a £0 email subscription the same as a £500 purchase.
The practical implication: you need to decide which conversions actually matter to your business and configure them accordingly. Most businesses set purchases as Primary and everything else (leads, signups, downloads) as Secondary. Google’s algorithms will then optimize for revenue, not just action volume.
While Secondary conversions aren’t included in the total Conversions count, if needed, Secondary conversions can be reported in Google Ads with a simple report customization.
When you send a conversion, you can include a conversionValue—the monetary worth of that conversion. For e-commerce, this is straightforward: the order total. For leads, you might assign an estimated lifetime value. For subscriptions, perhaps the first month’s fee or the annual contract value.
Google’s bidding algorithms absolutely love conversion values. Without them, Google treats a £10 purchase the same as a £1,000 purchase, which leads to the kind of optimization that makes finance directors weep. With values, Google can optimize for value rather than just volume—bidding more aggressively for high-value customers and easing off for small transactions.
The catch: Google doesn’t make conversion values mandatory. You can send conversions without values, and everything will appear to work fine. Your campaigns will optimize. Reports will generate. It’s only when you realize six months later that Google has been driving £5 transactions at a £20 cost-per-conversion that the problem becomes apparent.
Each Conversion Action has three options for its value in Google Ads settings: always use the reported value, always use the fixed value or fall back to default only when the value is missing. Make sure you select the right one.
Here’s something Google won’t emphasize in their documentation: your server-side conversion numbers will not match your Google Ads conversion reports. Ever. Get comfortable with this now.
Why? Several reasons:
This doesn’t mean the system is broken. It means attribution is fundamentally probabilistic, and different systems use different models. Your job is to ensure that directionally, things make sense — that when conversions increase in your system, they increase in Google Ads reporting too.
To implement Google Ads server-side conversion tracking properly:
It’s more work than browser-based tracking, certainly. But it’s also more reliable, more privacy-compliant, and increasingly, simply necessary if you want your campaigns to optimize effectively in a world where cookies are becoming as deprecated as Flash animations or have key conversion event happening offline.
Sounds tricky? Look into Able CDP Google Ads server-side tracking solution, which does most of this for you.