How to Map Magento 2 Store Views to GA4 Properties Without Losing Data

TL;DR

A Magento 2 instance with several store views and one GA4 property is a deliberate reporting decision. Where multi-view stores lose data is in the mechanics underneath it: a second property that receives purchases but no page views, a currency setting that makes two properties incomparable, a data layer that fires alongside Measurement Protocol and doubles a transaction, and two bugs in the extension's own history that routed per-view events to the Default store. This walks the scope model Magento actually uses, then each of those four, in the order they cost you money.

Key Takeaways

• Magento scope is a parent and child hierarchy of websites, stores and store views, and a setting inherited from the parent level applies until you override it [1].
• The mechanism is the Store View chooser plus one checkbox, labeled Use system value at Default Config, Use Default at website level and Use Website at store view level. The field stays locked while it is selected [2].
• Multi-property Measurement Protocol sending is documented inside the section headed "Measurement Protocol Tracking Configuration (PRO VERSION ONLY)" [3], and arrived in v1.15.5, released July 29, 2025 [4].
• Extra properties need the ID and the API secret of each, and they receive the enabled ecommerce events only. Page views need a separate GTM container loaded for that view [3].
• Currency And Amount Scope chooses base or display currency [3]. Google converts using the prior day's exchange rate, and changing a property's currency type rewrites historical data as well as future data [6].
• One account holds up to 2,000 properties and one property up to 50 data streams [5], so GA4's limits are almost never the constraint. Your reporting habits are.
• Two changelog dates let you date your own wrong numbers: admin-created orders were sent to the Default Store View before v1.14.5, July 22, 2024, and refunds were sent from the Default store before v1.15.7, September 2, 2025 [4].

One property or many

One property gives you a single funnel, cross-view audiences and no reconciliation work, at the cost of needing a dimension to separate brands. Separate properties give each brand or market a clean house, at the cost of never comparing them in one report and of maintaining every setting twice.

That is the whole trade-off, and the longer version, including what happens to the history when you change your mind later, sits in the article on GA4's 14 month data retention on Magento 2. The documentation takes no position on which shape is correct, and neither will this page. What follows assumes you have chosen, and covers the mechanics that break either way.

What GA4's own hierarchy allows before you multiply properties

Worth thirty seconds, because merchants often assume a limit that is not there.

An account can contain up to 2,000 properties, and each property can hold up to 50 data streams, with a limit of 30 app data streams inside that [5]. So the ceiling is not the reason to keep views in one property.

The more useful line from the same page is what a data stream is for. Google's framing: a property "represents an app and/or website", and if you collect data for a single logical application across platforms, you create a data stream per platform [5]. Whether five store views of one catalog read as one logical application, or two unrelated brands on one Magento instance read as two, is the question Google's framing puts in front of you. That is what to argue about internally, rather than a quota nobody is close to.

How Magento scope works, and the checkbox that actually does it

Adobe's model is a hierarchy: websites, stores and store views in "one-to-many parent/child relationships" [1], where "the global default configuration settings are used through the store hierarchy, unless they are overridden at a lower level" [2], and "any item with the scope of store view can be set differently for each store view" [1].

The operating mechanism is two controls. The Store View chooser in the upper left corner of the configuration page sets which level you are editing, starting at Default Config [2]. Next to each field is an inherit checkbox whose label changes with that level: Use system value at Default Config, Use Default at website level and Use Website at store view level, and "the default field value cannot be changed when the checkbox is selected" [2].

That is why a per-setting scope table is the wrong thing to go looking for. Switch the chooser to the view you care about, clear the checkbox on the field you want to differ, save. Where the checkbox appears, that field can differ at that level. Reading its absence as proof that a field never varies there is our inference rather than a documented Adobe rule. One exception to note: single store mode is its own case, and a fix in v1.14.19, released April 8, 2025, addressed extension options that were not applying correctly in Single Store Mode instances [4].

What does a second property actually receive?

This is the part that quietly produces bad numbers, and the guide documents the limit plainly.

Send eCommerce Event Data to multiple endpoints opens a Properties Configuration table where you add additional GA4 property IDs. You need "the ID and API secret of each additional property you want to add" [3]. The GA4 platform term is API secret, found under Admin Settings → Data Stream → Measurement Protocol API secrets [3], and it is not the measurement ID.

Then the note that decides whether the second property is usable: "Adding a new property here will only send the enabled eCommerce events in the Measurement Protocol configuration. If you need to also send Page View events, in order to stitch data and ensure attribution, you'll also need to load a separate GTM container by adding it to the Google Tag Manager Javascript Code and Google Tag Manager Non-Js Code sections above" [3].

Follow that through. A second property receiving purchases and no page views has revenue with no sessions behind it. Its conversion rate is arithmetic on an empty denominator, its channel report has nothing to attribute, and its landing page report is blank. The revenue number will look right, which is what makes this expensive to catch. Budget a container per view you split, and the setup work for that container is the subject of the Magento 2 GA4 server-side tracking setup guide.

Two boundaries on the feature itself. It lives inside the section headed "Measurement Protocol Tracking Configuration (PRO VERSION ONLY)" [3], which is where the tier answer comes from, and the tier comparison as a whole belongs to GA4 STANDARD vs PRO on Magento 2. And if you also run ad platform addons per view, the API addons carry an equivalent multi-account setting; the Bing UET addon's version is documented, with the same ecommerce-only note attached [7].

Can two properties be compared at all?

Only if they agree on currency, and that agreement is harder to retrofit than to get right now.

Currency And Amount Scope chooses whether the extension sends the base or the display currency to Google Analytics [3]. It arrived in v1.15.1, released May 17, 2025, as a way to control which currency figure leaves the store [4]. On a store where one view sells in euro and another in pounds, that single choice decides whether your two properties are reporting comparable numbers or two different quantities with the same label.

Google's side of it is stricter than most merchants realize. If you set value in event data, currency is required for revenue metrics to be computed accurately [6]. A property's global currency type defaults to USD, and Analytics converts using the prior day's exchange rate [6]. And the sentence that removes the easy fix: "Changes to the global currency type will affect future as well as historical data, and previous data will be converted to the newly configured currency" [6]. Discover a mismatch a year in, switch the property's currency, and you have rewritten the values of every month you were trying to compare.

Decide it once, per property, and write it down. Base currency across all views gives you comparable numbers and figures your finance team recognizes; display currency gives you what the shopper saw. Neither is wrong. Mixing them across two properties that you intend to compare is. The neighboring question, why GA4 totals and Magento totals disagree at all, runs through taxes, shipping and order statuses and lives in GA4 and Magento sales reports don't match.

Keeping one order out of two reports

Multiple containers make the classic double count easy to create, so handle it deliberately. The guide's own instruction is a choice, not a suggestion: "To avoid any chance of duplicate events to be sent, you must choose which event is sent via Measurement Protocol or via Data Layer." The Automatically disable data layer for enabled measurement protocol events option makes that choice for you, and when it is on, existing GTM tags will not fire because the data layer is not sent [3]. The manual alternative is pausing the client-side tags that duplicate your Measurement Protocol events in each container.

One guard rail comes with it, and it is the mistake to avoid: "Ensure you don't disable the main Analytics Tag, labeled WP - GA4, as this tag is required for tracking sessions, page views and other important user metrics" [3]. Sessions and page views are exactly what the second property is short of already.

Last, the habit that saves a confused afternoon. The guide repeats it for a reason: after any extension configuration change, regenerate the JSON and re-import and overwrite the existing container so Google picks up your settings [3]. With one container that is a footnote. With one container per store view it is a checklist item you will forget at least once.

Which release fixed your wrong per-view numbers?

If your per-view revenue already looks wrong, check your version before you debug your configuration. Two fixes in the extension's history produced exactly this symptom.

Before v1.14.5, released July 22, 2024, orders created in the Magento admin were sent to the Default Store View "regardless under which Store View they were created" [4]. Before v1.15.7, released September 2, 2025, refund events on multi-store setups were sent from the Default store "regardless of which store they were initiated from" [4]. A related fix in v1.15.9, released October 28, 2025, addressed an error thrown on credit memo generation caused by a dynamically created store ID variable in the code [4].

The practical reading: if a Default view in your reporting carries more revenue than its traffic can explain, and your build predates those releases, you have found the cause of the historical distortion rather than a configuration error. Note the version you upgraded from, and treat the period before it as known-skewed rather than comparable.

FAQ

Should each store view get its own GA4 property?

The documentation takes no position, and neither should a default. Decide on how you report, not on how Magento is structured; the trade-off and what it does to your history are in the retention article linked above.

Is multi-property sending available on the standard tier?

The setting is documented inside the section headed "Measurement Protocol Tracking Configuration (PRO VERSION ONLY)" [3], and the feature arrived in v1.15.5, released July 29, 2025 [4].

Do I need a separate API secret for each property?

Yes. The Properties Configuration table asks for the ID and the API secret of each additional property [3]. The secret is created per data stream under Admin Settings → Data Stream → Measurement Protocol API secrets [3].

Why does my second property show revenue but no sessions?

Because additional properties receive the enabled ecommerce events only. Page views need a separate GTM container loaded for that store view [3]. Until it is, that property's conversion rate and channel reports have no session data behind them.

Can I fix a currency mismatch by changing the property's currency later?

Not without consequences. Changing the global currency type affects historical data as well as future data, and previous values are converted to the new currency [6]. Set Currency And Amount Scope deliberately in Magento first [3].

Measurement Protocol sending to multiple properties, the Properties Configuration table and Currency And Amount Scope are features of the Magento 2 Google Analytics 4 extension in its PRO edition. The tier-by-tier breakdown, pricing included, is in the STANDARD versus PRO comparison linked above.

Before you split anything, run one check: open the Store View chooser, switch to a non-default view, and see which of your GA4 fields offer an inherit checkbox at that level. That is what you can vary without guessing.

Sources

1. Adobe Experience League, "Site, store, and view scope", Adobe Commerce, accessed September 21, 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/start/setup/websites-stores-views
2. Adobe Experience League, "Configuration scope", Adobe Commerce, accessed September 21, 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/config/scope-change
3. WeltPixel Google Analytics 4 User Guide, v1.17.5, September 16, 2026, accessed September 21, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
4. WeltPixel Google Analytics 4 change log (Version History, same page), versions 1.14.5 (July 22, 2024) through 1.15.9 (October 28, 2025), accessed September 21, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
5. Google Analytics Help, "Google Analytics hierarchy", accessed September 21, 2026, https://support.google.com/analytics/answer/9303323
6. Google Analytics Help, "Currency reference", accessed September 21, 2026, https://support.google.com/analytics/answer/9796179
7. WeltPixel, "Microsoft Ads (Bing UET) API Addon for Google Analytics 4 PRO User Guide", accessed September 21, 2026, https://docs.weltpixel.com/BingUETAddon/User-Guide-WeltPixel-Bing-UET-Addon.html