Get your Cross-Domain Tracking tracking to 95%+ accuracy guaranteed in writing.
The moment a visitor leaves your domain for a hosted checkout, a booking widget or a payment gateway, the browser treats the return trip as a brand new visit from a new referrer. The ad click that paid for the sale is attached to a session that ended two pages ago. We make the identity survive the hop — and clean up the self-referrals already polluting your reports.
Free30 minutesNo obligation
Cross-Domain Tracking · what breaks
The tell-tale signs of a broken hop — Cross-Domain Tracking
- 01
checkout.stripe.com or paypal.com is a top referrer
A self-referral means the session was cut and restarted at the return leg. Every purchase that follows gets credited to the payment page, and your paid campaigns look worse than they are while direct traffic mysteriously converts brilliantly.
- 02
Sessions per user is inflated and duration is nonsense
One human buying one thing registers as two or three sessions — arrive, bounce to checkout, return, complete. Your funnel reports, engagement metrics and any audience built on session behavior are working from a split person.
- 03
Someone "fixed" it with referral exclusions alone
Excluding the gateway domain stops the new session from being labeled a referral, so it becomes direct instead. The session is still broken; you've only changed what the report calls it. The linker parameter is what actually stitches the visit together.
- 04
Subdomain and cross-domain treated as the same problem
shop.yoursite.com and yoursite.com share a registrable domain and just need the right cookie scope. yoursite.com and yourbooking.io are genuinely different origins and need the linker. Applying the wrong fix to the wrong case wastes a week and leaves the gap open.
Cross-Domain Tracking · the fix
What changes when the visit stays one visit — Cross-Domain Tracking
One session, one user, from ad click to receipt
The linker passes the client ID and session ID across the hop so GA4 stitches the journey. Landing page, campaign and source stay attached to the purchase instead of resetting at the gateway.
Your gateway disappears from the source report
With the linker doing the work and exclusions configured to match, the payment or booking domain stops appearing as a traffic source at all — because it was never a traffic source, only a detour.
gclid and fbclid survive the round trip
Click IDs captured at landing are persisted first-party and re-read at conversion, so the Google Ads and Meta conversions carry the click even when the purchase completes on someone else's domain.
Multi-domain businesses get one honest funnel
If you run a marketing site, a separate app domain and a third-party scheduler, they finally report as one property with one user journey rather than three unrelated audiences.
Cross-Domain Tracking · architecture
How one visit stays one visit across three different domains
There are only three fixes here and they are not interchangeable: cookie scope for subdomains, the linker for true cross-domain hops, and a server-side path for gateways that give you nothing.
- 1
Map every hostname between click and receipt
Trace real buyer journeys and list every domain and subdomain they touch, including the legacy scheduler and the financing partner nobody remembers.
- 2
Decide per hop: cookie scope or linker
Subdomains share a registrable domain and need the cookie set there. Genuinely different origins need the linker, and applying either fix to the wrong case wastes a week.
- 3
Decorate on the way out, read on the way in
The sending page appends the _gl parameter to the outbound link and the receiving container reads it, adopting the same client ID and session ID.
- 4
Persist click IDs independently of the hop
gclid, wbraid, gbraid, fbclid and msclkid are stored first-party at landing so the conversion still carries the click even when the linker is stripped.
- 5
Fire the conversion from the order webhook
Where the gateway offers no tag slot at all, the backend sends the conversion server-side, which needs no cooperation from the vendor.
Cross-Domain Tracking · events
What happens at each hop, and what carries the identity — Cross-Domain Tracking
The last row is the symptom you are paying to remove, not something we build.
| Event | Fires when | Key parameters | Sent from |
|---|---|---|---|
| page_view (landing) | The ad click arrives on your domain | gclid, wbraid, gbraid, fbclid, msclkid, page_referrer | Browser, stored first-party |
| begin_checkout | The visitor leaves for the hosted checkout | value, currency, items[], client_id and session_id passed in _gl | Browser, on the decorated link |
| checkout_return | The buyer lands back on your confirmation URL | _gl accepted, client_id adopted, session continued | Browser |
| purchase | The gateway webhook confirms payment | value, currency, transaction_id, items[], stored gclid and fbclid | Server |
| appointment_booked | A third-party scheduler confirms the slot | booking_id, value, currency, stored click IDs | Server, from the scheduler webhook |
| consent_update | A CMP choice is made on either domain | ad_storage, analytics_storage, ad_user_data, ad_personalization | Browser, on both domains |
| session_start (unwanted) | The return leg arrives without the linker | page_referrer = checkout.stripe.com or paypal.com | Browser, the symptom we remove |
Cross-Domain Tracking · prove
How we confirm the hop stopped cutting the session — Cross-Domain Tracking
This one is easy to verify and easy to fake. A clean referral report alone proves nothing if the exclusions are doing the hiding.
Source of truth
Charges in your payment gateway, or confirmed appointments in your booking tool
- Check the GA4 referral report: after launch the gateway and booking domains should not appear as sources at all.
- Run a real purchase through each gateway and watch client_id stay constant across the hop in DebugView.
- Repeat on Safari and in the Instagram and Facebook in-app browsers, where the linker fails differently.
- Compare GA4 purchases with gateway charges by day, and watch sessions per user fall back toward normal.
- Strip the _gl parameter deliberately and confirm the conversion still carries gclid from the server-side path.
- Reread the referral exclusion list against the domain map and delete entries that no longer describe a real hop.
Cross-Domain Tracking · free audit
What we check in the free audit
- checkout.stripe.com or paypal.com is a top referrer
- Sessions per user is inflated and duration is nonsense
- Someone "fixed" it with referral exclusions alone
- Subdomain and cross-domain treated as the same problem
Checked against
Charges in your payment gateway, or confirmed appointments in your booking tool
Free30 minutesNo obligation
Cross-Domain Tracking · when not to buy
When there is no hop worth paying us to fix — Cross-Domain Tracking
Check your own referral report before you book anything.
- Your whole funnel lives on one domain and checkout is embedded on-site. There is no hop, so there is nothing to stitch.
- Your referral report is clean and sessions per user looks sane. That is the diagnosis; spend the budget elsewhere.
- You want historical reports corrected. GA4 does not reprocess, so this fixes data going forward and nobody can fix the past.
- The only break is between subdomains you control. That is a cookie-scope change your own developer can make in an afternoon.
Cross-Domain Tracking · what we deliver
What the cross-domain build includes
Domain map of the full conversion path
Every hostname a buyer touches between ad click and confirmation, including the ones nobody remembers — the legacy scheduler, the financing partner, the older campaign microsite still running ads.
Linker configured on both sides of every hop
Cross-domain works only when the sending page decorates the link and the receiving page reads the parameter. We configure both ends, including on hops where we only control one side and have to work with the vendor's settings.
Cookie scope corrected for subdomains
Where the hop is between subdomains, we set the cookie at the registrable domain so the client ID persists naturally — and remove any linker misapplied there, which causes its own problems.
Referral exclusions aligned with the linker
Exclusion lists updated to match the real domain map, so they support the linker instead of masking its absence. We document why each entry exists, which is what stops someone re-adding noise in six months.
Click ID persistence and server-side continuity
gclid, wbraid, gbraid, fbclid and msclkid captured at landing and stored first-party through your own subdomain, then attached to the conversion event server-side regardless of which domain it completed on.
Live-fire validation on real payment paths
We run genuine transactions through each gateway and each device combination, including Safari and in-app browsers, and show you the session staying intact in the DebugView and the report.
Written guarantee
95%+ tracking accuracy
Measured against Charges in your payment gateway, or confirmed appointments in your booking tool. Miss it and we keep working at no cost.
FAQ
Cross-Domain Tracking questions, answered
Usually, yes. Most hosted checkouts and booking tools expose either a GTM slot, a cross-domain setting, or the ability to append parameters to the return URL. Where the vendor gives you none of those, the fallback is server-side: capture the click ID at landing, store it first-party, and fire the conversion from your backend when the order webhook arrives. That path doesn't need the vendor's cooperation at all.
No, and this is the single most common mistake in this area. Exclusions change how the new session is labeled — the session still breaks, it just gets called direct instead of referral. The linker parameter is what carries the client ID and session ID across, which is what keeps the visit whole. Exclusions are the cleanup step, not the fix.
Different fix. Subdomains of the same registrable domain can share a cookie, so the answer is cookie scope, not the linker. If you see subdomain self-referrals, something is setting the cookie at the host level — often a hand-rolled tag or a plugin with its own config. Applying the linker there adds parameters to your URLs for no benefit.
It's a transient query parameter on outbound links to your other domains, and it isn't in the URLs Google indexes for your pages. Two practical cautions: some strict server configurations reject unknown query parameters, and the linker has a short validity window by design, so a user who sits on the interstitial for a long time can still land unstitched. We test for both.
It will fix the part caused by broken sessions. It won't fix the part caused by different attribution models — GA4 and Google Ads count conversions on different rules, and Meta uses its own click and view windows. Expect a residual gap. Our job is to separate the modeling difference from real data loss, so you stop treating a definitional difference as a bug.
If your entire funnel lives on one domain and your payment step is an embedded iframe or a fully on-site checkout, there's no hop to survive and nothing here applies. Same if the gateway never appears in your source report and your session counts look sane. Check your referral list first; if it's clean, spend the budget elsewhere.
New sessions are correct immediately after launch, and you'll see it in DebugView the same day. Historical data doesn't change — GA4 doesn't reprocess. So plan on comparing whole periods after the fix rather than trying to reconcile against a broken baseline, and expect roughly a month before trend comparisons feel trustworthy again.
More on Cross-Domain Tracking
- GuideCross-Domain Tracking Setup: Stop Losing Attribution at the Domain Hop
- GA4 cross-domain tracking brokenWhy is my GA4 cross-domain tracking broken?
- cross-domain attribution lostWhy is my attribution lost across domains?
- Google Ads cross-domain conversion lossWhy am I losing Google Ads conversions across domains?
Free · 30 min
Check your referral report before we talk
WhatsAppFree30 minutesNo obligation
