Cross-Domain Tracking Setup: Stop Losing Attribution at the Domain Hop

Your funnel starts on yourbrand.com and checks out on a separate domain. Or it detours through a booking tool, or bounces to PayPal and back. Every hop can reset the visitor's identity, and when it does, GA4 credits the sale to the wrong source. I've audited plenty of accounts where the top revenue "channel" was paypal.com. That's not a channel. That's a plumbing leak.

Why does moving between domains break my tracking?

Because first-party cookies don't cross domains. GA4 stores the visitor's client ID in a _ga cookie scoped to the domain that set it. On your checkout domain the browser won't send that cookie, so GA4 mints a new client ID, starts a new session, and records the traffic source as the domain the visitor just came from. Your own site.

The damage: self-referrals in your reports, one person counted as two users, and the one that costs money — a purchase attributed to "yourbrand.com / referral" instead of the Google ad that paid for the click. Everything downstream is wrong until you stitch the two identities together.

1. Visitor on your site — GA4 client ID sits in a _ga cookie
2. Link to second domain — Cookies can't be read on the new domain
3. GA4 appends _gl — An encoded copy of the client ID in the URL
4. Destination reads _gl — Writes the same client ID into a new _ga
5. One user, one session — The original traffic source survives the hop

How does the GA4 linker (_gl parameter) actually work?

The linker puts the identity that can't travel in a cookie into the URL instead. When a visitor clicks a link between two configured domains, the GA4 tag appends a _gl parameter to the destination URL. It looks like gibberish: ?_gl=1*abc123*_ga*NDYxOTk...

That gibberish is an encoded copy of the client ID. The GA4 tag on the destination domain reads _gl, verifies it's fresh, and writes the same client ID into a new _ga cookie on the second domain. One visitor, one ID, one continuous session. The original traffic source survives the hop. Two caveats: the parameter is short-lived by design, and it's only appended on links between domains you've explicitly configured.

How do I set up cross-domain tracking in GA4?

Three pieces: the linker configuration, the Conversion Linker tag for ad click IDs, and referral exclusions.

1. Put both domains in one GA4 property. Cross-domain tracking only works within a single property, so both sites need the same Measurement ID.
2. Configure your domains. Admin > Data streams > your web stream > Configure tag settings > Configure your domains. Add every domain in the journey.
3. Add a Conversion Linker tag in GTM. New tag > Conversion Linker > check "Enable linking across domains" and list the same domains > trigger on All Pages, on both sites. This handles Google Ads click IDs, which the GA4 linker alone does not (more below).
4. Add unwanted referrals. Same Configure tag settings screen > Show all > List unwanted referrals. Add any payment gateway in the path: paypal.com, checkout.stripe.com, your bank's 3D Secure domain.
5. Test the hop before you trust a single report. Steps below.

Why do I need a Conversion Linker tag if GA4 has its own linker?

Because Google Ads attribution rides on a different cookie. When someone clicks your ad, the URL carries a gclid, and the Conversion Linker tag stores it in first-party cookies (_gcl_aw and friends) on the landing domain. If the purchase happens on a second domain and that cookie never made the trip, your Google Ads conversion tag can't find the click ID.

With "Enable linking across domains" checked, the Conversion Linker passes the click ID across in the same _gl parameter. GA4 linker for analytics identity, Conversion Linker for ad click IDs; you want both. Meta has the same problem: _fbp/_fbc cookies don't cross domains either, which quietly wrecks match quality on checkout-domain purchases.

1. Google ad click — gclid lands on yourbrand.com
2. PayPal detour — Buyer leaves checkout to pay on paypal.com
3. New session on return — GA4 sees a fresh referral from paypal.com
4. Credit goes to PayPal — The ad that paid for the click gets nothing
5. Add unwanted referrals — Listed here, the original source keeps credit

Why is PayPal or Stripe showing up as my conversion source?

Because the return hop from the payment gateway looks like brand-new referral traffic. The visitor leaves your checkout for paypal.com or a Stripe-hosted payment page, pays, and lands back on your thank-you page in what GA4 sees as a new session referred by paypal.com. The ad that actually drove the sale gets nothing. This is the single most common attribution bug I find in ecommerce audits.

The fix is the unwanted referrals list from step 4: add paypal.com and any other gateway domain, and GA4 stops treating it as a traffic source. Domains configured for cross-domain linking are already handled; gateways you can't put your GA4 tag on (most of them) go in unwanted referrals.

Do subdomains need cross-domain tracking?

Mostly no. Moving from www.yourbrand.com to shop.yourbrand.com is not true cross-domain, because GA4 sets the _ga cookie at the root domain (.yourbrand.com) by default. Every subdomain reads it, so identity and session carry over without any linker. Just keep both subdomains in the same GA4 property, and save the linker for journeys that cross registrable domains.

How do I test that cross-domain tracking is working?

Two checks, five minutes.

1. Watch for _gl on the hop. Click through to the second domain and look at the address bar the moment you land. You should see _gl= in the URL. No parameter means the linker isn't decorating that link.
2. Compare client IDs in DebugView. With debug mode on, fire an event on each side of the hop, then compare the client ID on both events in GA4 DebugView. Same ID on both sides: working. Different IDs: broken, even if _gl appeared.

Then check Traffic acquisition a couple of days later. Self-referrals and gateway referrals trending to zero means it's holding in production.

What can't the linker fix?

The linker only works on a live, immediate hop. It fails whenever the URL parameter goes stale or never existed:

• Saved and shared links. Visitor copies the checkout URL, comes back tomorrow. The _gl value has expired; new identity.
• The email confirmation path. Booking tools and payment providers that finish the journey with an emailed link break the chain completely. The click from the inbox has no linker parameter at all.
• Cookie-hostile browsers. Safari's ITP caps JavaScript-set cookies at seven days. The linker can pass the ID today, but if the visitor converts on day nine, both domains have forgotten them.
• Ad blockers. If the GA4 tag never loads on either side, nothing reads or writes the parameter.

And the honest structural advice: keep the whole funnel on one domain if you can. A checkout at yourbrand.com/checkout has none of these problems. Every hop you remove is a class of bugs you never debug.

Do I need first-party server-side tracking for this?

If your funnel crosses domains, it's the difference between a patch and a fix. The linker depends on a URL parameter surviving the hop, cookies surviving the browser, and JavaScript surviving ad blockers. Server-side tracking moves the fragile parts off the browser entirely.

Plain-language version: instead of every tag firing from the visitor's browser, events go to a tagging server you own, on your own subdomain (something like track.yourbrand.com), which forwards clean data to GA4, Google Ads, and Meta. Because the server sets your identity cookie in an HTTP response, Safari doesn't cap it at seven days, ad blockers don't see it, and your first-party ID plus the click IDs (gclid, fbclid) live server-side where a domain hop can't reset them. The gateway detour that made PayPal your top channel? The server already knows which ad the buyer clicked, so the conversion goes out with the right identity no matter what the browser forgot on the way back.

That's also why match quality improves: purchases arrive at Meta and Google with stable IDs and click IDs attached, so the platforms match more conversions to real users and bid on complete data. Cross-domain funnels are exactly where the gap between client-side and server-side is widest, because they stack every failure mode on top of each other.

Frequently asked questions

How do I set up cross-domain tracking in GA4?

Go to Admin > Data streams > your web stream > Configure tag settings > Configure your domains, and add every domain in the journey. Both domains must share one GA4 property.

What is the _gl parameter in my URLs?

It's the GA4 linker parameter: a short-lived, encoded copy of the visitor's client ID appended to links between your configured domains. Expected behavior, not a bug.

Why does PayPal show as a traffic source for my purchases?

The redirect back from PayPal starts a new session that GA4 attributes to paypal.com as a referral. Add paypal.com to "List unwanted referrals" in your web stream settings and the original source keeps the credit.

Does the Conversion Linker tag replace GA4 cross-domain settings?

No. GA4's domain configuration carries the analytics client ID across domains; the Conversion Linker carries Google Ads click IDs. Cross-domain funnels running ads need both.

Why is cross-domain tracking still not working after setup?

Check that _gl appears in the URL on the hop. If it doesn't, the destination domain isn't configured, the tag isn't firing, or the hop is a JavaScript redirect the linker can't decorate automatically.

Can server-side tracking fix cross-domain attribution?

Largely, yes. A tagging server on your own subdomain keeps the first-party ID and click IDs server-side, so identity survives domain hops, gateway redirects, Safari's cookie limits, and ad blockers.