Job tracking-cross-domain-site-to-checkout · revised 11 October 2026
Keep one visitor as one visitor when your site hands them to a separate checkout
A test journey from your site to your checkout domain stays in one GA4 session, with the checkout not listed as the traffic source.
You might be seeing
- The checkout or booking domain appears as a top referral source in GA4
- Orders show as direct or as a new session although the buyer arrived from an ad or email
No passwords, keys, card details or admin invites needed to start.
What usually happened
When a visitor moves between two domains, GA4 sets separate first-party cookies on each and counts the person twice unless the identifiers travel in the link or form. Google documents the _gl parameter for this. A hand-off fails when the domain list is wrong, a redirect strips the parameter, a script stops the click reaching the listener, or the flow uses a form or script navigation.
Who it’s for: An owner or marketer whose site sends buyers to a booking, payment or shop domain and who sees the checkout domain as a referrer.
Usually starts when: Purchases or bookings are attributed to the payment or booking domain, or new users spike at the hand-off.
The result: A test journey from the site to the checkout domain, by link and by form where used, carries the _gl parameter, shows the same session ID on the site page view and the checkout page view in DebugView where the checkout side can be put into debug mode, and, in a separate marker journey made without debug mode, is not attributed to the checkout domain as a referral once Google has processed the data.
Check whether this job fits
Answer these without logins or customer data.
Checks you can run yourself
Click through and read the address
From a landing page, click the link or submit the form to the other domain and look at the new address.
Look for: A _gl parameter in the address means the linker ran. Its absence points to the domain list, a redirect or a script.
What you get
- The corrected domain configuration and Tag Manager settings prepared for approval
- A hand-off test table: link or form, destination URL with _gl, the session IDs seen in DebugView, and the report result for the test marker
- A note on any fix that belongs to the checkout provider rather than to you
Included
- One GA4 web stream, one site domain and one checkout or booking domain, with up to two hand-off points
- Configure the domains in the stream and the Tag Manager linker settings as Google documents
- Find and fix a redirect, a stripped parameter or a blocking script on the hand-off, where it is on your site
- Add the checkout domain to the unwanted referrals list if the payment return needs it
Not included
- Changes inside a third-party checkout that you do not control
- Repairing past sessions or past attribution
- Cross-domain for more than two domains or more than two hand-off points
- Ad-platform cross-domain linking beyond the Google tag settings
- Any promise about conversion or ad performance
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Following Google's own check, clicking the hand-off link, or submitting the hand-off form, from the site opens the checkout page, the page loads normally, the address contains a _gl parameter, and a download starts if the hand-off offers one.
Evidence: Screenshot of the destination address and the loaded page for each hand-off point.
In DebugView, in one test journey with debug mode on for the tag on both domains, the page_view on the site and the page_view on the checkout page carry the same ga_session_id value and come from the same debug device. Where the checkout side cannot be put into debug mode, this check is marked not run in the test table and the next check decides.
Evidence: DebugView screenshots of both page_view events with their parameters expanded and the ga_session_id value shown.
After Google has processed the data, a separate test journey made without debug mode, which began on a site address carrying the unique test campaign value, appears in Traffic acquisition (or an exploration filtered to that value) under that campaign, and no test session is listed with the checkout domain as its source.
Evidence: Traffic acquisition or exploration screenshot filtered to the test marker, showing the session campaign and session source / medium.
Sign-off. You review the three results, sign off in writing and publish yourself. Payment follows sign-off.
If it fails. If the test journey does not pass, you do not pay for this fixed scope. If the cause is on the checkout provider's side, we explain it and stop or re-quote in writing.
When it fits, and when we stop
It fits when
- The same GA4 web stream tag runs on both domains, or the checkout provider lets you add it
- You can click through the hand-off in test mode or without a purchase
- An account holder can grant a scoped role on the property and the container
- Debug mode can be switched on for the GA4 tag on both domains for the test; where the checkout side cannot be put into debug mode, the report check decides and the test table says so
- No Active data filter on the property drops the marker journey. Google says a developer-traffic filter removes activity from debug mode and that excluded data is never processed, so the report check uses a separate marker journey made without debug mode; if any other Active filter would drop it, the filter and the way round it are agreed in writing before work starts
- A test browser can accept analytics cookies on both domains
We stop and tell you if
- The checkout provider does not allow your GA4 tag on its pages
- The hand-off relies on a script navigation we cannot change
- More than two domains or hand-offs are in scope
What could go wrong
Domain and linker changes are a Tag Manager workspace change, recorded as a version when you publish, plus a recorded stream setting, so they can be reverted to the earlier values.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Appending a parameter causes a server error or breaks a download. | Google notes this can happen; every hand-off link is clicked and must load, and downloads are tested. |
| The unwanted referrals list hides a real referral source. | Only domains that are part of your own flow are added, and the list is recorded in the handover. |
A separate reviewer repeats the test journey and confirms no personal data is placed in the link. You publish the change.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the domains, hand-off points, test marker and test route in writing
- Record the current journey: address after hand-off, the session ID on each page view in DebugView and the referral shown
- Configure the domain conditions and linker settings; fix a redirect or script on your side if needed
- Re-run the journey with debug mode on, where the checkout side allows it, and read the address and the session IDs in DebugView
- Make a separate marker journey with the test marker and without debug mode, then, after Google has processed the data, check the Traffic acquisition report for the test marker
- Independent review, then hand over for you to publish
This is a one-off job, not a subscription or emergency cover. We confirm eligibility, the price, a start window and a delivery date before you accept. Work starts only after the agreed inputs and the least access the job needs are in place. Fees charged by Google, Meta, your host or any tool you use are not included. No charge or booking is created by an enquiry.
Need to keep it working?
A standing check can repeat the hand-off test after each checkout or site change.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Google documents the domain configuration steps and the five-step check of the _gl parameter, which a developer can follow in-house. support.google.com
- Ask your checkout provider whether it offers a built-in GA4 integration for cross-domain.
Questions
Why does the checkout domain show as a referral?
Without the linker parameter, GA4 sees the visitor arrive from the other domain as a new visit. Google documents the cross-domain set-up that avoids this.
Can you change my payment provider's pages?
No. If the fix belongs to the provider, we tell you exactly what to ask them.
Send an enquiry
Send us
- The two domains and where on the site the hand-off happens (link, button or form)
- The referral source that looks wrong in GA4
- No logins.
Later, once you agree
- A scoped Editor role on the property and Edit access to the container (Google describes Edit as able to create workspaces and make edits but not create versions or publish; you publish), granted to the identity we agree with you before work starts
- A test route through the checkout without payment, or in test mode
- Contact with the checkout provider if their side needs a change
You own the website, the Google and Meta accounts, the tag manager container and all the data. We ask for the lowest role that lets us do the job. Before any work starts we agree with you in writing which identity receives that role; you grant it and can remove it at any time. We never ask for your passwords. You keep the right to publish: we prepare changes and you publish them.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “tracking-cross-domain-site-to-checkout” as the subject.