GA4's 14-Month Data Retention on Magento 2: You Already Own the Raw Data

TL;DR

Most retention advice is written for merchants who have no database of their own, so it treats the 14-month ceiling as data loss. A Magento operation is a different case: you run MySQL, you have someone with credentials to it, and the order record is yours in perpetuity. That changes the question from "how do I stop losing data" to "which of my analyses actually depend on GA4-only behavioral data, and what do I do about those before the window closes". This article works that second question, covers the reconciliation routine between Measurement Protocol sends and order rows, and gets to the multi-store-view problem that quietly destroys year-over-year comparisons.

Key Takeaways

• GA4's event data retention ceiling is 14 months on standard properties, with 26, 38 and 50 months available only on 360 [1], and the setting governs only the granular event and user records behind Explorations. Aggregated standard reports are unaffected.
• sales_order, sales_order_item and the Magento reports tables are your system of record for revenue. Nothing in GA4's retention policy touches them.
• What MySQL cannot reconstruct: source and medium per session, the path a visitor took before buying, and the entire funnel behavior of everyone who did not order. That last group is most of your traffic.
• Reconcile monthly, not annually. The GA4 PRO order grid carries a Measurement Protocol validation column, so you can filter Magento orders by whether the event was sent [2].
• Multi-store-view stores have a property question to settle before the retention window matters: one GA4 property for all views, or one per view.
• The extension has no BigQuery export and no retention feature. The BigQuery link is a Google Analytics feature and the warehouse decision is yours.

What actually expires, in three sentences

GA4's data retention setting controls user-level and event-level records: individual sessions, event parameters, user properties. On standard properties the maximum is 14 months, with 26, 38 and 50 months reserved for 360 [1], and new properties are created on the 2-month setting. Standard reports run on pre-aggregated tables that persist, so traffic and revenue totals from two years ago stay visible while the Exploration that would break them down does not.

There is one more clause worth knowing, because it fires without anyone choosing it: when a standard property becomes Large, or a 360 property becomes XL, the event-level retention setting is automatically reduced to 2 months and older event-level data is permanently deleted [1]. Analytics emails property administrators a warning beforehand and a confirmation afterwards, and nothing else surfaces it. Your MySQL tables have no equivalent behavior.

That is the whole mechanic. Our Shopify-side article covers the settings screen and the recovery question in detail, and the mechanics are identical on any platform: GA4 data retention and the 14-month limit. The rest of this piece is the part that is specific to running a Magento store.

Your system of record is in MySQL, and it does not expire

Open a shell on your Magento database and the picture changes.

sales_order holds one row per order with totals, currency, store ID, customer ID and status. sales_order_item holds the line items. sales_order_grid is the flattened view the admin grid reads. Magento's reporting tables, including report_event, hold the catalog-side activity that powers the built-in product reports. Adobe Commerce Intelligence, previously Magento Business Intelligence, is Adobe's separately licensed reporting and dashboard platform over that same data [3].

None of this is a workaround. It is the ordinary state of a self-hosted commerce platform: the transactions live in a database you administer, backed up on your schedule, queryable with SQL, retained for as long as your accountant and your privacy policy agree.

So when a GA4 property hits 14 months and the Explorations go blank for last year, your revenue history is intact. Anyone telling a Magento merchant that GA4 retention is a threat to their sales records has not looked at where the sales records are.

So what does GA4 hold that MySQL cannot reconstruct?

Three things, and they matter more than the list length suggests.

Source and medium per session. Magento stores an order and, if your tracking is set up for it, some campaign context attached to that order. It does not store the acquisition history of a dozen or so sessions that preceded the order across two devices. GA4's event data does, until it expires.

The path. Which category pages, which internal searches, which product pages, in what order, with what timing between them. report_event gives you catalog-side aggregates, not sequenced individual journeys.

Everyone who did not buy. This is the big one. Your database knows a great deal about the small fraction of visitors who converted and essentially nothing about the rest. Funnel drop-off, cart abandonment sequencing, the landing pages that produce sessions with no add-to-cart: all of that lives only in analytics, and all of it is on the 14-month clock.

Write down which recurring decisions in your business depend on those three. If the answer is a quarterly channel review that only ever looks back four months, the retention ceiling is theoretical for you. If it is an annual planning cycle that compares this Black Friday's funnel to last year's, you have a real deadline, and it lands before Black Friday on November 27.

Reconciling Measurement Protocol sends against order rows

Here is where owning the database pays off in a way that a hosted platform cannot match: you can check GA4 against the truth instead of against another report.

The routine is monthly, and it is a four-query routine.

1. Count orders in sales_order for the period, filtered to the store views that feed the property, excluding the statuses you have configured to be excluded from tracking.
2. Pull the GA4 purchase count for the same period and the same property.
3. If the numbers disagree, use the Measurement Protocol validation column in the Magento order grid to filter for orders that were not sent [2].
4. Check var/log/ga4.log for the order increments that came back with an error, if file logging is on [2].

If you have not enabled server-side purchases yet, the mechanics are in our walkthrough on getting accurate sales data into GA4 via the Measurement Protocol. Step 3 is the one that turns a guessing exercise into a lookup. The order grid column exists precisely so reconciliation starts from a filterable list rather than a hunch. The causes behind a persistent gap are their own subject, and we have written up the ones that recur in support tickets: missing transactions and revenue in GA4 on Magento 2.

Run this monthly and the retention window stops being frightening, because you know what the analytics data is worth while you still have it.

Which property holds which store view's history?

Multi-store-view Magento setups have a decision here that single-store merchants never face, and it is the one that most often ruins a year-over-year comparison.

If all your store views report into one GA4 property, you have a single 14-month history covering the whole business, and per-view analysis depends on a dimension being present on every event. If each view reports into its own property, you have clean per-view histories and no combined view at all past the aggregate reports.

The trap is a store that changed its mind midway. A merchant who consolidated three properties into one last spring has one property with eighteen months of aggregate totals and three abandoned properties whose event-level data quietly expired while nobody was logging into them. Nothing warns you. The properties still exist, the Explorations just come back empty.

If you are planning a property change, export or query what you need from the outgoing property first, and give yourself the full 14 months of overlap rather than the two you will actually use.

BigQuery or your own warehouse?

The standard advice is to link GA4 to BigQuery, which streams raw event data out from under the retention ceiling. That advice is sound and it is a Google Analytics feature, configured in GA4 rather than in Magento. Ours does not provide it, and it is not a Magento-side setting.

What is different about the Magento case is the second option. You already run a database and you already have someone who maintains it. Pulling GA4's behavioral export into the same warehouse as your order tables gives you joins that neither system can do alone: session source against actual lifetime value, funnel position against real margin per line item. A Shopify merchant on a hosted plan gets to that point by buying a third system. You get there with a scheduled job.

The cost side is not the deciding factor at store scale in either direction, and anyone quoting you a precise monthly figure without seeing your event volume is guessing. The deciding factor is whether anyone on your team will actually query the result. A warehouse nobody opens is an expense with a dashboard attached.

FAQ

Does GA4 data retention affect my Magento sales reports?

No. Magento's sales reports read from your own database tables, and GA4's retention setting governs only the event-level data held inside Google Analytics [1]. The two systems keep separate records, which is exactly why reconciling them is useful.

Can I recover GA4 event data after it expires?

No. Once event-level data passes the retention window it is deleted permanently. Increasing the setting applies to data you have already collected and not yet lost, so it is not recoverable, but it is not purely forward-looking either [1].

Which Magento tables should I keep for long-term analysis?

At minimum sales_order and sales_order_item, since those carry the transaction and line-item detail. Adobe Commerce merchants also have Adobe Commerce Intelligence, previously Magento Business Intelligence, as a separately licensed reporting platform over the same data [3]. Your retention period for those tables is a business and privacy decision, not an analytics one.

Does the WeltPixel GA4 extension store historical data of its own?

It writes a Measurement Protocol validation column to the order grid and, when file logging is enabled, a var/log/ga4.log record of what was sent [2]. There is no separate historical store, and the extension has no BigQuery export.

If the reconciliation routine above is the part you want to start with, it depends on the Measurement Protocol layer being in place. The WeltPixel Google Analytics 4 PRO extension sends purchases and refunds server-side and adds the order grid column that makes step 3 a filter instead of an investigation.

One thing to do before you close this tab: open GA4 Admin and check whether your property is still on the 2-month setting. Twelve of the fourteen available months are sitting behind that one dropdown.

Sources

1. Google Analytics Help, "Data retention," https://support.google.com/analytics/answer/7667196
2. WeltPixel Google Analytics 4 User Guide, v1.17.3, August 3, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
3. Adobe Experience League, Adobe Commerce Intelligence guide overview, https://experienceleague.adobe.com/en/docs/commerce-business-intelligence/mbi/guide-overview