TL;DR
Setup takes two steps; the third, the test, is where Magento's stock switcher fails. It never gives the Google tag a link to the other domain, so the linker has nothing to decorate, and Cookie Restriction Mode brings the banner back on each domain. A failed hop still delivers the purchase, credited to your own other domain as a referral. Decide what to do about the switcher, then test every hop twice.
Key Takeaways
- Magento's stock switcher, on Luma and on Hyvä's default theme, sends the shopper through two redirects that land on the other domain without
_gl[9] [10], so GA4 counts two users. - Those redirects also carry the login and guest cart across, so swapping them for plain links has a cost, and keeping
_glthrough them is developer work [2]. - Both store views load the same GTM container and Measurement ID, and both domains go into GA4's domain list [2].
- With the extension's default consent method, the container waits for Magento's cookie banner, and the banner appears again on the second domain [1] [6].
- A broken hop shows up as revenue under your own other domain as referral. The unwanted referrals list hides that label without joining the two users [4].
Put both domains on one container, then list them in GA4
This guide starts after the property decision; our guide to mapping Magento 2 store views to GA4 properties settles that. Cross-domain measurement only applies to the one-property answer, because "the tag on each page must use the same tag ID (i.e., the same 'G-' ID) from the same web data stream" [2].
In Magento, switch the extension's configuration to each domain's store view in turn and compare the Google Tag Manager Javascript Code and the Measurement ID. They should match on both domains.
Then go to GA4: Admin > Data collection and modification > Data streams > Web, open the stream, then Configure tag settings > Configure your domains [2]. Add each domain as a condition (Editor role or above; up to 100 conditions [2]).
The GA4 extension has no cross-domain setting, so there is nothing to switch on in Magento. If your container still shows a GA4 Configuration tag, Google says such tags "will be automatically upgraded to the Google tag" and "you don't need to take any action" [5].
Use the exact host from each store view's base URL (Stores > Settings > Configuration > General > Web) in the domain list and in every link between the domains. Adobe says "Do not use auto-redirect to base URL for multi-store setups" [7]. With that redirect on, a link to example.de on a store whose base URL is www.example.de is redirected to an address Magento builds from the page path, so expect _gl to be gone. The click test below settles it.
Why doesn't the store switcher carry _gl?
Google's mechanism: "The source domain decorates URLs that point to the destination domain" [3], and the IDs carry over "when the user navigates between domains through a link or a form" [2].
Magento's switcher never offers such a link. The language switcher points at a switching address on the domain the shopper is already on; on Luma, the store switcher submits a form to that address by script; Hyvä's default theme links to it in both switchers [10]. Magento then redirects twice, to the switching address on the target domain and then to the page, and each redirect builds its address from scratch, from a page address the server computed before any tag ran. We read this in the 2.4.9 and 2.4.8-p5 releases, which behave the same [9].
Google's troubleshooting names both things the switcher does. "If the destination page redirects or doesn't support arbitrary query parameters, the parameter _gl may end up being removed from the URL even if it was appended by Analytics in the previous page" [2]. And cross-domain measurement "cannot work properly" when "the navigation is triggered by JavaScript as opposed to a direct response to a user action" [2], which is how Luma's store switcher submits.
So the second domain counts the shopper as a separate GA4 user. A country selector built from plain links to the other domain is the case the linker handles, which is why the click test, not the theme name, gives the answer. If you run our Multi-Store Multi-Brand extension or another switcher module, test it the same way.
The redirects have a job. During the switch Magento signs a logged-in customer in on the target store when the account is shared there, and moves a guest cart when the target store shares it [9]; Adobe describes stores that "can share cart, user sessions, payment gateways, and more" [8]. Separate domains mean separate cookies, and the switching route is how Magento crosses that gap.
Three ways to handle the switch
You are choosing which side loses something:
| Option | What GA4 records | What happens on the Magento side |
|---|---|---|
| Keep the stock switcher | Two users per shopper; the order is credited to your other domain as referral | Login and guest cart follow the shopper |
| Replace it with plain links to the other domain | One user, when _gl arrives and the page can read it |
The shopper arrives without Magento's login and cart carry-over |
Have a developer keep _gl through the switch |
One user, if the value survives both redirects | Both kept, at the cost of custom work you retest after upgrades |
The third row is Google's own instruction, "configure your site to preserve the parameter _gl in redirects" [2]. Budget it as development work: the linker only decorates links that point at another domain, and the switcher's link points at its own.
The criterion is how shoppers move between your domains. If the switcher is the main route (one brand on language domains, shoppers flipping between them before buying), the first row costs the most and the third earns its budget. If shoppers mostly land on the right country domain from search or ads and rarely switch, keep the stock switcher and accept the referral label described below.
What does the cookie banner do to the second domain?
This part catches stores that got the linker right.
The extension's Consent Management Method is a PRO setting [1], and its default since v1.16.1 (March 6, 2026) is Magento Cookie Restriction Mode: "Uses Magento's built-in cookie banner. GTM loads only after the user accepts cookies (Basic Consent Mode)" [1]. Magento's banner is switched on under Stores > Settings > Configuration > General > Web > Default Cookie Settings, and the acceptance is kept in user_allowed_save_cookie [6] on the domain where the shopper clicked Allow. The second domain has no such cookie yet, so the banner appears again and the container waits.
On the destination, Google says, "tags are configured to check for linker parameters in the URL" [3]. On a fresh visit to the second domain, the container does not run on the landing page, so none of its tags does that check. In Tag Assistant you will see the container start on the page view that follows the Allow click, and that page's address no longer carries _gl. A shopper who has not accepted the banner on the second domain is not stitched by the container, however well the link was decorated.
With External CMP, "GTM always loads, and the CMP handles consent via Google Consent Mode v2" [1], so the tag is on the landing page and what it may store is Consent Mode's business. Our article on keeping the GTM container loading covers both methods. On the server side, since v1.17.4, with Require Visitor Consent for Server-Side Events switched on, the extension gates the PRO Measurement Protocol purchase on the shopper's Consent Mode v2 choice [1], as our guide to server-side events and consent explains.
Where broken GA4 cross-domain tracking shows up in your reports
Our article on purchases landing as Unassigned puts the server side in one line: "The extension captures GA session identifiers from the GA cookies at the moment the order is placed." The order is placed on the checkout domain, so the Measurement Protocol purchase (PRO, see our Standard vs PRO comparison) joins that domain's client ID and session.
If the hop lost _gl, that session began with your first domain as referrer, and Google's rules decide the label. GA4 ignores a referral from a listed domain when, in Google's example, "a user navigates across domains that you have configured in your domains list and the current page contains the linker parameter _gl" [4]. Its automatic self-referral detection covers "the same domain of the current page or any of its subdomains" [4], and example.fr is not a subdomain of example.de. The order still arrives, under example.fr / referral, and the shopper is counted as two users.
The unwanted referrals list (Configure tag settings > Show all > List unwanted referrals, up to 50 per data stream [4]) tells GA4 that "the referrer should not be displayed as a traffic source" [4]. For a shopper new to the second domain, that client ID has no earlier source to fall back on, so the session reads as Direct, and the original campaign stays with the first domain's client ID. The label changes and the split stays.
The fix belongs in the hop, so start with the switcher rows of the click test below.
How do you test each hop?
Google's verification is a click, then "verify that the URL in the destination domain contains the linker parameter _gl" [2]. Run it on the hops your store actually has, with Tag Assistant open as our verification guide describes:
| Hop | What to click | What a working hop shows |
|---|---|---|
| Language switcher | The switcher on a product page |
_gl in the final address on the other domain |
| Store switcher | The store selector, where your theme has one | Same as above |
| Header, footer or content link | A link that points straight at the other domain |
_gl present, and no outbound click event |
| Link to a host that differs from the base URL |
example.de when the base URL is www.example.de
|
_gl still present after any redirect |
Once a domain is listed, enhanced measurement's outbound clicks "are ignored when the outbound link leads to a domain that you've listed as part of cross-domain measurement" [2]. An outbound click on the domain change means the list is not matching that host.
On a Cookie Restriction Mode store, run the table twice: once with the banner accepted on both domains, then in a fresh private window without accepting anything. Expect only the first pass to stitch, and the second shows what a new visitor gets. Full page cache is not a suspect: Varnish keeps the tagged address in the address bar, where the tag reads it, as our article on UTM and gclid attribution through Varnish shows for _gl and the other parameters.
If the store switcher fails its row, as Magento's stock switcher does on 2.4.8 and 2.4.9, go back to the three options and pick one.
FAQ
Does the WeltPixel GA4 extension set up cross-domain tracking?
No. It has no cross-domain setting. It loads your GTM container on each store view, and the domain list is configured in GA4 itself [2].
Do I need a separate GA4 property for each domain?
Not for cross-domain measurement, which works only inside one web data stream with the same tag ID on every domain [2]. Whether one property suits your store views is a separate decision, covered in the store views guide linked at the top.
Should I add my own domains to the unwanted referrals list?
It hides the label but leaves two users, and a shopper new to the second domain reads as Direct [4]. Fix the hop first.
Keep both domains on the Magento 2 Google Analytics 4 extension with the same container and Measurement ID, list them in GA4, and click the real switcher before you trust cross-domain numbers.
Sources
- WeltPixel Google Analytics 4 User Guide and Change Log (General configuration: Consent Management Method; v1.16.1 and v1.17.4 entries), retrieved October 8, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
- [GA4] Set up cross-domain measurement, Google Analytics Help, retrieved October 8, 2026, https://support.google.com/analytics/answer/10071811
- Measure activity across multiple domains, Google tag developer documentation, last updated July 30, 2026, retrieved October 8, 2026, https://developers.google.com/tag-platform/devguides/cross-domain
- [GA4] Identify unwanted referrals, Google Analytics Help, retrieved October 8, 2026, https://support.google.com/analytics/answer/10327750
- Announcement: Google tag and Tag Manager, Tag Manager Help, retrieved October 8, 2026, https://support.google.com/tagmanager/answer/13543899
- Cookie law compliance, Adobe Commerce Admin Guide, Adobe Experience League, retrieved October 8, 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/start/compliance/privacy/compliance-cookie-law
- General > Web, Adobe Commerce Configuration Reference, Adobe Experience League, retrieved October 8, 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/config/general/web
- Multiple websites or stores, Adobe Commerce Configuration Guide, Adobe Experience League, retrieved October 8, 2026, https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/multi-sites/ms-overview
- Magento Open Source 2.4.9 and 2.4.8-p5 release tags, Store, Customer and Checkout modules, GitHub magento/magento2, retrieved October 8, 2026, https://github.com/magento/magento2/tree/2.4.9/app/code/Magento
- Hyvä default theme, store and language switcher templates, GitHub hyva-themes/magento2-default-theme (main branch), retrieved October 8, 2026, https://github.com/hyva-themes/magento2-default-theme