GOOGLE ADS CONVERSION TRACKING WHEN THE CONVERSION HAPPENS ON A DIFFERENT DOMAIN

The pattern I see over and over: a client swears their google ads campaigns are working, the sales are real, and yet the Conversions column is nearly empty. Nine times out of ten the purchase finishes somewhere the ad click never followed it. The user clicked the ad, browsed the main site, then got handed off to a separate checkout domain or an external marketplace to pay. That handoff is where the tracking quietly falls apart, and nobody notices because everything except the reporting looks fine.

Getting google ads conversion tracking working on a single domain is a solved problem. The hard part is when the journey crosses a boundary the tracking wasn't built to cross. This is one of the most common invisible failures in ecommerce and lead-gen accounts alike, and the accounts most affected are usually the ones spending the most.

My angle is practical: why the break happens mechanically, how I fix it when I control the destination, and what to do when the conversion happens on a domain you don't own. That last case is where advice usually gets vague, and it's where I'll be most concrete.

Why cross-domain tracking breaks in the first place

The failure isn't a bug, it's the browser working exactly as designed. When someone clicks your ad, Google appends a unique identifier to the landing page URL, the google click id gclid. Your tag reads it and stores it in a first-party cookie on your domain, and that cookie is the thread connecting the click to whatever happens next. The catch: a first-party cookie can only be read by pages on the same domain that set it. The moment the user crosses to a different domain, the destination has no access to that cookie, so the thread is cut.

So the mechanics of google ads conversion tracking when conversion happens on different domain come down to one problem: the identifier that proves "this sale came from that click" is trapped on the origin domain. The conversion tag on the checkout domain fires, but has no click information to attach the conversion to. The result is a conversion that goes unrecorded or gets misattributed to direct or referral traffic, and your ad gets zero credit for a sale it drove.

What the browser sees versus what happened

To the browser, a user arriving on the checkout domain with no shared cookie is a brand-new, unattributed visitor, so it treats the origin visit and the checkout visit as two separate people. One journey gets shredded into disconnected fragments, and every downstream decision inherits that distortion. That's why I treat this as a measurement-integrity problem, not a cosmetic reporting gap.

Why redirects make it worse

There's a sneakier layer. Even before a different domain, if your stack uses redirects, HTTP to HTTPS, vanity URLs, payment-provider hops, the identifier has to survive every one of them via the url parameters to reach the final page. I've audited accounts where it was stripped on a redirect long before any cross-domain issue came into play. So I first confirm the identifier is intact by the time the user leaves the origin domain at all; if it's already gone, no cross-domain linking downstream will save it.

How I fix it when I control both domains

When I have access to both the origin and the destination site, the fix is clean: the domain linker. When a user clicks a link pointing to the destination domain, the tag appends a linker parameter (you'll see it as _gl in the URL) that carries the first-party cookie across the boundary. The destination reads that parameter, extracts the cookie, and stores it locally, so the click identifier is now available where the conversion fires. The thread is re-connected.

Google's documentation on how Google Ads tracks website conversions spells out that when your conversion page sits on a different domain than your landing page, you need the domain linker to pass the identifier through. That's the authoritative confirmation this isn't optional, it's what makes cross-domain measurement possible at all.

The two ways I deploy it

If the site uses the Google tag directly, I add the linker configuration listing every participating domain, on all pages. If the account runs on google tag manager gtm, I use the Conversion Linker tag with cross-domain linking enabled and every domain listed. One detail that surprises people: the two domains don't need to share the same container, what matters is that the origin decorates its outbound links so the destination can capture the gclid from the incoming parameter. It slots into the same discipline I describe for a clean GTM conversion tracking build.

Why direction matters

The mistake I see most is decorating links in only one direction. If a user can move A to B and back, and only A is configured, you lose attribution on the return path. My rule is to list all participating domains on every site, so the link is bidirectional. It eliminates an entire category of "sometimes it tracks, sometimes it doesn't" ghosts that are miserable to debug later.

When you don't control the destination: marketplaces and hosted checkouts

Here's the situation that keeps people stuck: what do you do when the conversion happens somewhere you can't add a single line of code? This is the reality for anyone trying to track google ads conversion on third party marketplace like Amazon, Etsy, or eBay, and it's common with hosted checkout providers too. The domain linker is off the table, because it requires configuration on the destination, and you don't have it.

So I change what I optimise toward. When I can't see the final purchase, I pick the last meaningful action I can see on a domain I control, usually the click on the "Buy on [marketplace]" button or reaching the handoff page. It's not the sale, and I'm honest that it's a proxy, but a proxy that fires reliably beats a perfect signal that never fires.

Bringing the real sale back in later

When the marketplace gives you sales data, the stronger move is to reconcile the real outcome after the fact rather than catch it live. If you export orders and match them to the original click, you feed the true conversion in through offline conversion tracking instead of a website tag. This is the logic behind feeding offline conversion signals back to the algorithm: the sale that closed off your domain re-enters the account tied to the click that started it. An alternative import path is google analytics, defining the outcome there and importing it, though for marketplaces you don't control the raw order export is usually cleaner.

Hashed matching and the server-side option

Where you do control the conversion page but cookies are unreliable, enhanced conversions can recover matches by sending hashed first-party data collected at conversion time. And when there's any technical cooperation, server side measurement can bridge what client-side cookies can't, because it moves measurement off the browser entirely and sidesteps the same-domain cookie restriction. It's more involved, but for high-value accounts where a proxy isn't accurate enough it's the direction I explore, and I go deeper in my write-up on server-side conversion tracking.

The through-line is the same: the cleaner the signal you get across the boundary, the better every downstream decision becomes. A proxy, an offline reconcile, or a server-side bridge all exist to protect the quality of what your Smart Bidding reads, because the algorithm can only chase outcomes it can see.

How I verify the click survives the hop

I never assume a cross-domain setup works just because I configured it. The failure is invisible, so verification is the only thing that turns "it should work" into "I watched it work." My routine is to click a real ad, or a test URL carrying a click identifier, then physically walk the entire journey the way a customer would.

The most important check is at the moment of crossing: when I move from origin to destination, I confirm the destination URL carries the _gl linker parameter. If it's there, the cookie is being passed. If it's missing, the origin isn't decorating its links and I fix that first. Then on the destination side I use Tag Assistant to confirm the conversion event fires exactly once and picks up the click information, not zero times and not twice.

I also watch for a telltale symptom: if your domains show up as referrals to each other, the cross-domain configuration is incomplete. Self-referrals are the smoke that tells me the thread is being cut somewhere.

This end-to-end walk is a non-negotiable step in my conversion tracking testing process, repeated whenever the site structure or tagging changes. The takeaway: this doesn't break because it's hard, it breaks because a first-party cookie can't cross a domain by itself. Pass the identifier across deliberately with the domain linker where you can, fall back to a proxy or offline reconciliation where you can't, and verify the hop with a real journey before you trust the numbers.