Cross-Domain Tracking 2026: Fix Lost Ads Conversions

You pay for a click on yourbrand.com. The signup form lives on app.yourbrand.io. Checkout runs on secure.paymentprovider.com. The demo booking is a Calendly widget. Then Google Ads reports roughly half the conversions your CRM recorded, and GA4 quietly files a third of your paid traffic under Direct / (none). This is what broken cross-domain tracking looks like.

Nothing is broken inside Google. What is broken is the handoff between your own domains: every hop resets cookies, and with them the click identifier that ties a sale back to an ad. This guide covers how cross-domain tracking actually works, how to locate the exact break in about twenty minutes, how to configure it so it survives redirects, iframes and payment gateways, and which mistakes cost advertisers the most in 2026.

Why cross-domain tracking breaks in the first place

Browsers scope cookies to a single registrable domain. When a visitor moves from yourbrand.com to yourbrand.io, the second site cannot read anything the first one stored. And what it stored is exactly what matters:

_gcl_aw — the stored GCLID, the identifier of the ad click;
_ga — the Client ID that stitches GA4 sessions together;
_gcl_dc and _gcl_gb — identifiers for Display & Video and hybrid click surfaces.

Without them, a purchase on the second domain looks like a brand-new anonymous visitor who arrived from nowhere. Google Ads cannot attribute it to a click; GA4 starts a fresh session and overwrites the source.

The fix is mechanically simple: pass the identifiers explicitly in the URL. The Google tag does this with a _gl linker parameter, and the receiving domain reads it back into its own cookies. Every piece of configuration you will do exists to make sure every hop carries that parameter and the receiving side knows to trust it.

Cross-domain tracking is not a checkbox. It is a five-link chain: tag on domain A, decorated link, tag on domain B, the conversion action itself, and the transmission of data. Break any link and the whole chain fails silently.

The five setups that break most often

1. App or checkout on a separate registrable domain

Marketing site on brand.com, product on brand.app or getbrand.io. Subdomains of the same root share cookies automatically when the tag sets them at the root; separate second-level domains share nothing at all.

2. Hosted payment gateway with a return URL

The visitor leaves for a hosted checkout, pays, and comes back to yourbrand.com/thank-you. That return URL is configured in the gateway and is almost always clean — no _gl, no UTMs. If first-party cookies on your domain are still alive, the conversion lands. If the customer spent forty minutes on the payment page, GA4 may have rotated the session and reassigned the source, even though the Google Ads conversion survives on its own window (see our piece on conversion windows and conversion lag).

3. Booking widgets and embedded forms in iframes

Calendly, Cal.com, embedded CRM forms. An iframe is a different origin with its own cookie jar. Link decoration does not reach into it — you must pass the identifier into the iframe src yourself.

4. Redirect layers and internal short links

Any hop in between — a link shortener, a tracker, a landing page builder — must forward query parameters. Plenty of tools silently drop everything after the question mark, taking the GCLID with them. We covered how those identifiers behave in the guide to GCLID, GBRAID, WBRAID and tracking templates.

5. Web-to-app handoff

Deep links into a native app break everything — browser cookies do not travel. That case is not solved by the linker at all; it needs deferred deep-link parameters and a server-side conversion import.

Finding the break in twenty minutes

Do not implement anything until you know where the chain snaps. Work through this order:

Walk the funnel yourself. Click a real ad, or append ?gclid=TEST123 to the landing page manually, then go all the way to the confirmation page. Watch the address bar on every hop.
Look for _gl. On every cross-domain hop the URL should carry a long _gl=1*xxxxx*... parameter. If it is absent, link decoration never fired.
Compare cookies. DevTools → Application → Cookies. The receiving domain should show _ga and _gcl_aw with the same values as the origin. Different values mean the parameter arrived but the tag did not consume it.
Check load order. The Google tag has to be present before the visitor clicks. A tag dropped at the end of body on a heavy page can miss the first clicks entirely — one of the less obvious reasons landing page speed and Core Web Vitals affect data quality, not just conversion rate.
Reconcile three numbers. Google Ads conversions, GA4 conversions and CRM deals over the same window. A 30–50% gap between Ads and CRM while GA4 looks “fine” is almost always a cross-domain break.

If conversions dropped overnight rather than always being low, start elsewhere: work through conversion tracking diagnosis and the change history first. Cross-domain setups break at release time, not spontaneously.

Symptom table

Symptom	Likely cause	Where to look
Large Direct / (none) share despite heavy paid spend	Client ID lost between domains	`_ga` cookie on the second domain
Ads conversions roughly half of CRM deals	GCLID lost	`_gcl_aw` cookie, URL parameters
Sessions 2–3× users	Every hop starts a new session	session_start report
Conversions counted twice per sale	Tag fires on both domains	See duplicate conversions
Data missing for a segment, not everyone	Consent not granted	Consent Mode v2

Configuration, in the order that works

Step 1 — map every domain

List each domain a user touches from click to payment, including redirect layers and iframes. Mark which ones carry the Google tag. Eight times out of ten the problem is visible right here: the thank-you page or the checkout has no tag at all.

Step 2 — declare the domain list in the Google tag

In Google Ads → Tools → Google tag, or GA4 → Data streams → Configure tag settings, open Configure your domains and add every domain. Three details decide whether it works:

Enter domains without protocol or trailing slash: yourbrand.com, app.yourbrand.io.
The list must be identical on every domain. Configure only the sender and the receiver will not trust the incoming _gl.
Matching is substring-based. brand.com also matches notyourbrand.com, so avoid overly short fragments.

Step 3 — in GTM, set the linker on the configuration tag

Same idea inside Google Tag Manager: configure the Google tag’s cross-domain settings, or pass a linker configuration with the domain array. Verify the tag fires on Initialization or All Pages, not on a custom event that may arrive after the user has already clicked through.

Step 4 — pass identifiers into iframes explicitly

Link decoration does not cross an iframe boundary. Either use the widget’s own API for hidden fields, or set the src programmatically after reading the current identifier:

// simplified pattern
gtag('get', 'G-XXXXXXX', 'gclid', function (value) {
  iframe.src = baseUrl + '?gclid=' + encodeURIComponent(value || '');
});

For most commercial booking tools, pushing the GCLID into a hidden form field is more reliable than fighting with cookies.

Step 5 — store the GCLID in your own database

The most durable answer is to stop depending on the browser. Capture the GCLID in a hidden field on form submit, save it with the lead in your CRM, and push closed deals back through Data Manager and first-party data. Then even a badly broken front end cannot stop you measuring revenue — the click-to-lead-to-deal chain lives on your server.

Step 6 — turn on enhanced conversions

Enhanced conversions recover part of what the browser lost: a hashed email or phone number sent with the conversion lets Google match it to a click without a surviving GCLID. Treat it as insurance on top of a correct setup, not a replacement — recovery in the 5–15% range is a common benchmark, but it depends entirely on how many of your users are identifiable.

Step 7 — move measurement server-side where it pays off

Server-side tagging does not solve cross-domain by itself — identifiers still have to travel — but it makes what does travel far more durable. The full architecture is in our guide to server-side tagging with sGTM.

Three real-world configurations and what each needs

Generic advice translates badly into tickets. These three patterns cover most actual funnels.

Configuration A: SaaS with marketing site and app on separate domains

Journey: brand.com (ad → landing page) → app.brand.io (signup) → in-app upgrade to a paid plan a month later.

What to do: the linker between the two domains is mandatory, but it only covers the first hop. The conversion that matters — the upgrade — happens weeks later, when no cookie survives. The working pattern is to write the GCLID into the user record at signup and send the payment event back through a server-side import keyed on that same GCLID. The browser tag is then only responsible for signup as a micro-conversion, while bidding optimises toward revenue.

Common failure: optimising campaigns toward signups because “payments do not show up in Ads.” The algorithm obligingly delivers cheap free signups and revenue stays flat.

Configuration B: e-commerce with a hosted checkout

Journey: shop.com (catalogue, cart) → pay.provider.com (payment) → shop.com/success (return).

What to do: you do not need a tag on the checkout and would not be allowed to place one. Fire the conversion on the return page, and verify two things. First, whether the gateway returns the user to the same browser context — a new tab, or a bank app handoff, will break the session. Second, whether the conversion re-fires when someone refreshes the thank-you page, the classic source of the problem covered in duplicate conversions. The insurance policy is a payment webhook from the provider plus a server-side event carrying the order ID.

Configuration C: lead generation with a booking widget

Journey: agency.com (landing page) → calendar widget in an iframe → booking confirmed → deal closes in the CRM two weeks later.

What to do: link decoration never reaches into the iframe. Read the GCLID on the landing page in JavaScript and pass it into a hidden widget field — most booking tools support UTM and custom parameters. From there the logic is the same: the GCLID arrives in the CRM alongside the booking, and the closed deal goes back via import. Treat “meeting booked” as a secondary conversion and optimise toward closed revenue once volume allows.

What happens to UTMs and the GA4 source

This is where people most often fix the wrong thing. Google Ads and GA4 determine source differently, and that is by design.

Google Ads relies on the GCLID. As long as that identifier reaches the conversion, the conversion is attributed to the click — even when GA4 says Direct.
GA4 relies on campaign parameters and Client ID. Lose _ga on a hop and a new session begins, re-deriving its source. If the referrer is also missing — common after redirects and app handoffs — the session lands in Direct.

The practical conclusion: do not try to cure GA4’s Direct problem by adding UTMs to internal links. A UTM on an internal hop forcibly ends the previous session and rewrites the source to whatever you hard-coded, making attribution worse rather than better. The answer is the linker, not tagging. Broader context on models is in GA4 attribution for media buyers.

Mistakes that cost the most

Mistake	What happens	How it shows up
Domain list configured on one site only	Parameter sent but not accepted	Loss in one direction only
Protocol included: `https://brand.com`	No match	Setting looks correct, changes nothing
Different Measurement IDs per domain	Sessions never stitch	User count roughly doubles
Redirect strips query parameters	GCLID and `_gl` both gone	One channel collapses
Tag loads after the click	Links never decorated	Fluctuating 10–20% loss
Conversion tag on both domains	Double counting	Conversions jump, revenue does not
CMP blocks the tag entirely	No cookies to pass	Data only from consenting users

Pay particular attention to double counting. It looks like a win — the numbers go up. Two weeks later Smart Bidding has retrained on inflated data, starts overpaying for traffic, and your true CPA climbs. Reconcile conversions against revenue routinely, not only when numbers fall.

Verifying the fix

Manual walkthrough. Ad to thank-you page with DevTools open. _gl present on every hop; _ga and _gcl_aw consistent everywhere.
Debug mode. GA4 DebugView should show one continuous session with the correct source, not two sessions with different source/medium.
Reconcile after 14 days. Compare Ads, GA4 and CRM. A 10–15% spread is normal given different attribution models and windows. More than that means something is still leaking.

Budget time for relearning. Once the tracking is fixed, the bidding algorithm sees a different conversion volume and effectively enters a fresh Smart Bidding learning period. Expect one to two unstable weeks. Do not roll back on day three.

What is different in 2026

Third-party cookies stayed. Google abandoned forced deprecation and retired most of Privacy Sandbox, so the doomsday scenario never landed. But first-party cookies still expire quickly in Safari and Firefox, which makes “set a cookie and forget it” less reliable than it reads on paper. Full context in our breakdown of third-party cookies after the Privacy Sandbox shutdown.

More of your conversions are modelled. A cross-domain break looks to Google like missing data, and the system dutifully models it. The more real signals you provide, the less guessing happens on your behalf.

Every rebuild breaks it again. If a redesign or domain change is coming, run through the site migration checklist for paid traffic before launch, not after the numbers crater.

Checklist

Every domain on the user journey is mapped and current.
The Google tag is present on all of them, with one Measurement ID.
The cross-domain list is identical everywhere, with no protocols.
_gl is visible in the URL at every hop.
Redirect layers forward query parameters.
Widgets and iframes receive the GCLID explicitly.
The GCLID is stored in the CRM and deals are imported back.
Enhanced conversions are enabled.
Each purchase fires exactly one conversion tag.
Consent Mode is configured; tags degrade rather than disappear.
Ads / GA4 / CRM reconciliation runs on a schedule.

If several issues are stacking up at once, it is usually faster to sweep the whole account — our Google Ads account audit checklist covers the sequence. And when the data finally agrees but campaigns still stall on platform-side restrictions, agency Google Ads accounts and advertiser verification are the next lever — but fix measurement first. Everything downstream depends on it.

FAQ

Do I need cross-domain tracking if everything is on one domain?

No. Subdomains such as www, shop and blog share cookies automatically when the tag sets them at the root. Configuration is only needed between separate registrable domains.

What is the `_gl` parameter and does it hurt SEO?

It is a short-lived technical parameter that carries identifiers between domains. It expires within minutes and will not be indexed if canonical tags are set correctly. For extra safety, exclude _gl in GA4’s unwanted-parameter settings.

Why does GA4 show so much Direct traffic when my spend is paid?

Usually a cross-domain break: a new session starts with no source and is filed as direct. The second most common cause is a redirect that strips UTMs and the GCLID.

Will bad GA4 configuration also cost me Google Ads conversions?

Not necessarily — Google Ads has its own tag and cookies, so a conversion can register there while GA4 shows Direct. But if the GCLID itself is lost, both systems lose it.

Can enhanced conversions compensate for no cross-domain setup at all?

Partially. They match on hashed email or phone, which only works for identifiable users. They do not replace correct identifier passing.

How do I track through a payment gateway I do not control?

Do not try to install tags there. Fire the conversion on your own return page and secure accuracy with a server-side import keyed on the stored GCLID.

How many conversions does a correct setup typically recover?

It depends on how many cross-domain hops your funnel has. When one critical hop was unconfigured, recoveries of 20–40% are common — treat that as a directional benchmark and measure on your own data.

Do I have to redo everything when moving to server-side tagging?

No. The domain list and _gl passing stay the same. What changes is the endpoint events are sent to and where you enrich them.

How do I tell a cross-domain problem from a consent problem?

Consent loss is spread evenly across journeys and correlates with geography, strongest in the EU. Cross-domain loss is tied to a specific hop: one purchase path counts, another does not.

Does this affect remarketing?

Yes. An unstitched user never joins the right audience, which is fatal for cart-abandonment flows — see dynamic remarketing.

What should I check first if I only have five minutes?

Walk the purchase path manually and see whether _gl appears in the URL at the hop. That single check eliminates half the hypotheses.

Who owns this — marketing or engineering?

Marketing owns diagnosis and the domain list. Engineering owns parameter forwarding through redirects and iframes, and storing the GCLID. Write the split down, or the task stalls between the two.