When the customer journey passes through several domains or subdomains (the shop, the payment, the blog, a customer area), badly configured measurement splits the session into several, attributes sales to the site itself as the source and hides the campaign that brought them. Fixing this improves attribution immediately.
The essentials in a definition
Cross-domain and subdomain measurement keeps the same session when the user moves from one site to another (for example, from the store to a checkout on another domain). Without configuration, the session breaks and the real source is lost, attributing the sale to “direct” or a referral. Configuration involves the domain list in GA4 and in tags (developer documentation, Tag Manager), and validation with key events.
The problem
If the user moves from one domain to another and measurement does not link them, the second domain counts a new session, with the first as “referral”. Purchases begin to appear to come from your own site or the payment processor. The original campaign loses credit and decisions get distorted.
Wrong source, wrong decision.
How to configure
Set up cross-domain measurement for the domains involved, so they keep the same user identifier. For subdomains of the same main domain, it generally works without extra steps. Include payment and booking domains. Ensure campaign parameters are kept in links. Options may vary; consult the documentation.
Test the complete journey.
Cross-domain and subdomain measurement
- Map all domains in the journey
- Set up cross-domain measurement
- Exclude payment and third-party referrals
- Test the complete journey
Referral exclusions
Define as unwanted referrals the payment and third-party domains that are part of the journey, so they are not counted as a source. Check that the thank-you page keeps the initial source. Analyse acquisition reports to see whether “direct” or “referral” grow suspiciously.
A “referral” source that is your own domain is an alarm sign.
When the session breaks, the campaign that brought the customer loses credit.
Test and monitor
Make test purchases or submissions and follow the journey in real time and in reports. Compare sales by source before and after the fix. Repeat the test after site or payment changes. Document the configuration and the domains included.
Cross-domain measurement needs maintenance.
Decision table
| Situation | Problem | Solution |
|---|---|---|
| Checkout on another domain | Broken session, lost source | Configure cross-domain measurement |
| Subdomains | Usually keep the session, but check | Correct cookie domain |
| External payment | Source becomes the provider | Exclude unwanted referrals |
| Several properties | Scattered data | Single measurement plan |
Common mistakes to avoid
- Not testing the complete journey. Errors only appear in reports, late.
- Forgetting payment domains. Purchases attributed to the provider.
- Changing without documenting. The logic is lost.
How to measure the result
Track the percentage of sales attributed to “direct” and to payment referrals before and after.
Limits and exceptions
Some payment platforms limit data passing, and browser restrictions affect continuity. Configuration needs maintenance when domains change.
Illustrative example
Illustrative example: a store sees many purchases attributed to a payment provider. It configures cross-domain measurement and excludes the provider from referrals, and tests the full journey, from ad to purchase. Attribution comes to reflect the campaigns.
In practice: checkpoints
Test the complete journey from ad to purchase, with the debug tool, and confirm that the source persists when moving from one domain to another. Exclude from the referral list the payment and service domains that are part of the journey. Document the list of configured domains and update it when you create a new subdomain or change payment platform. Compare, before and after the change, the percentage of sessions attributed to direct and to your own domains, since a fall in these suggests the configuration is working. Repeat the test whenever the checkout or login flow is redesigned, and include it in the release checklist for the web team, so that nobody has to remember it.
Frequently asked questions
How do I know I have broken sessions?
If your own or the payment domain appears as the source of sales.
Do subdomains need configuration?
They generally work, but confirm with a test.
When do I test?
Whenever the site, payment or booking changes.
How do I test?
By walking through the flow with the debug tool and confirming the session persists.
Do I need technical support?
Often, especially with commerce platforms and external checkouts.
Configure cross-domain measurement, exclude payment referrals, test the complete journey and document changes.
Sources and recommended reading
Last editorial review: October 2026. Informational content; always confirm current conditions in the official sources before deciding.