You open an exploration in GA4, set the range to this September and last September, and the older period is empty, even though the site was already running back then. The usual culprit is one setting: in Google Analytics 4, user-level data retention is set to either 2 or 14 months, and after that window the data disappears from explorations and funnel reports for good.
This article covers what that one setting in Data Settings actually controls, what it never touches, how to change the period safely without losing data, and how to work out on your own dates when your exploration will start showing gaps. At the end — how to keep your own history of numbers independent of that GA4 limit.
When last year's data suddenly disappears
Seasons in retail, a clinic or a repair shop tend to repeat every year, so the natural move is to compare "this September to last one." In GA4's standard reports, that comparison works without limits. The problem shows up in explorations and funnel reports — there, GA4 only reaches as far back as the user-level data retention setting allows: 2 or 14 months. If someone once left it at 2 months, any exploration older than that is simply empty — not because of a tracking failure, but because the data has already been deleted from Analytics servers.
This setting is easy to miss because it never appears in day-to-day reports — it sits in the technical part of Admin, opened once during setup and rarely revisited. Before you start suspecting your tracking code or a data loss, check this one setting first.
What the data retention setting actually controls
The setting lives in Admin: the Property column › Data Settings › Data Retention. It applies to data tied to user identifiers — cookies, User-ID, advertising identifiers.
Retention for user-level and key event data
For user-level data (and key event data along with it), there are two choices: 2 months or 14 months. For all other event data, additional options exist, available only in Google Analytics 360: 26, 38 and 50 months, as described in Google's data retention documentation. The source doesn't say which value is the default on a freshly created property — instead of guessing, check directly what's set in your own account.
Exceptions: age, gender, interests, and Large and XL properties
Age, gender and interest data always carry a hard 2-month limit, no matter what you set for the rest. That same 2-month limit kicks in automatically for properties marked Large (standard) or XL (360) — ones that have crossed event-collection limits. When a property hits that state, GA4 first sends administrators a warning email, then a second one confirming that retention has been reduced and older event data has been permanently deleted.
What this setting never touches
The most common mix-up is assuming a short retention period wipes out a company's entire history. In reality it only affects two report types.
| Report / data | Shrinks with the retention setting | Always keeps full, unchanged history |
|---|---|---|
| Explorations | Yes | No |
| Funnel reports | Yes | No |
| Standard aggregated reports (including period comparisons) | No | Yes |
| Primary and secondary dimensions in standard reports | No | Yes |
In other words, the number of sessions, users or events in a standard monthly report stays visible indefinitely, even if user-level retention on the same account is set to 2 months. What you actually lose is the ability to build custom breakdowns and funnels past the retention boundary — and that's exactly where you'd check why customers don't leave inquiries or exactly where people drop out of a booking flow.
Work it out on your own dates
The rule in Google's documentation is simple: if the exploration's date range is longer than the set retention period, data for the extra time simply isn't available. The provider gives its own example: with a 14-month retention period and a 14-months-plus-one-day exploration range, data for that extra day is not shown in the report.
Your own example: today and the retention boundary
Apply the same rule to your own date. Today is 2026-09-14, and retention is set to 14 months. Boundary: 2026-09-14 − 14 months = 2025-07-14. If you open an exploration ranging from 2025-07-01, the days from July 1 through July 13, 2025 — 13 days — are older than the boundary and will be empty; data only appears from 2025-07-14 onward. Run the same calculation for your own report date before assuming something is broken.
How to change the setting safely, step by step
Changing retention requires the Editor role on the property — a read-only role isn't enough. The path in the interface: Admin, Property column, Data Settings, Data Retention — first make sure you're in the right account and property. There, choose the event data retention period, toggle reset on new activity, and click Save.
- 01Changing the retention setting
- →0224 hours to revert
- →03the set period ends
- →04monthly data deletion
- →05shorter history in explorations
Once saved, the change doesn't apply immediately — Analytics waits 24 hours before implementing it, and during that window you can revert with no effect on your data. When you shorten the period, data older than the new boundary is deleted during the next monthly cleanup process, not on the same day. When you lengthen it, the change applies to data you've already collected and haven't deleted yet — you cannot bring back what was already removed earlier.
Reset on new activity: what it means for repeat customers
A separate toggle, "Reset user data on new activity," decides whether a given user identifier's retention clock counts from the first visit or refreshes with every new one. Reset on: each new session from the same user pushes their expiration date forward by a full retention period, so as long as they keep coming back, their user-level data never disappears. Reset off: that identifier's data is deleted once the retention period elapses, regardless of whether the user returned in between. This option applies only to user-level data — it has no effect on standard aggregated reports.
For a service business with repeat customers, this is a real practical difference: GA4 will always be a source of on-site behavior within a given time window, not a substitute for a customer record. If you need one specific person's history — what they ordered, when they visited, what you discussed — that's the job of Customer Data, which merges bookings, calls and orders into one profile independent of GA4's retention settings.
Longer isn't always better: GDPR and data minimisation
The temptation is simple: set 14 months everywhere and stop thinking about it. But it's worth remembering the principle from Article 5 GDPR, cited in a guide by Poland's data protection authority (UODO): data should be adequate, relevant and limited to what is necessary for the purposes for which it's processed (data minimisation), and kept no longer than necessary (storage limitation). UODO's GDPR guide is written for schools specifically, but the Article 5 principle itself is general and applies to any data controller, including a business running GA4.
In practice that means one decision worth writing down, not just remembering: what retention period your analyses actually need, and why that one. If you mostly rely on standard year-over-year reports, longer user-level retention may be unnecessary — those reports keep their full history regardless of the setting.
Roles, permissions and the key event limit
Changing retention can be done by someone with the Editor role on the property. That's a different role from the one needed to manage users themselves: adding or changing someone on the account or property access list requires the Administrator role at the account or property level; only an account-level Administrator can delete a user account, as explained in Google's help on managing users. It's worth splitting these two roles across a team — otherwise one person's vacation blocks both tasks at once.
While you're there, it's worth checking the key event limit too: a standard property can mark up to 30 events as key events, a Google Analytics 360 property up to 50, per Google's key events rules. The purchase event is a key event by default; with ads personalisation enabled and Google Ads linked, events like add_to_cart and begin_checkout also become key events. That's a separate topic from data retention — worth checking which limit actually applies to your account in the events panel.
Do this today — check and record the decision
- Go to Admin › Data Settings › Data Retention and see what period is currently set — don't assume it's 14 months.
- Check whether reset on new activity is turned on if tracking returning users in explorations matters to you.
- Write the decision and the change date down in an internal note — your evidence in case anyone asks about data minimisation compliance.
- Once a month, export the exploration and funnel numbers you actually rely on into your own spreadsheet, before access to them disappears.
- When planning paid campaigns, check whether conversion measurement in Google Ads counts inquiries and bookings rather than clicks alone — that depends on the quality of your source data, not retention, but it's worth verifying both together.
What this looks like when a system runs it
Since standard GA4 reports keep their full history regardless, and only explorations have a boundary, it makes sense to move the numbers that matter out of GA4 before you lose access to them in a custom view. Aura's system saves key numbers from analytics and CRM into a business's own history once a month, so a year-over-year comparison no longer depends on whatever retention period happens to be set in GA4.
Here's what that looks like: Analytics and BI pulls data from several channels into one place and turns it into numbers you can put next to revenue, and Dashboards show leads, sales, marketing and finance on one screen, for whoever actually makes decisions based on them. If you'd rather get a summary in your inbox than open a dashboard nobody checks, the same numbers arrive as a weekly digest through AI Reports. For how to actually measure marketing return on your own data once you have a longer history, worth a separate look: restaurant marketing ROI measured on margin, did the promotion work — holdout groups explained, or cost per restaurant booking, channel by channel — methods that only make sense once you have your own longer history of numbers. Which numbers are even worth tracking every month is a separate question we covered in reporting automation.
Frequently asked questions
If I change retention from 2 to 14 months, will the old, already-deleted data come back?
No. Lengthening the period only applies to data you've already collected and haven't deleted yet. Data removed earlier under the shorter retention setting doesn't return — the new setting works going forward, not backward.
Why do I see data older than 14 months in a standard report but not in an exploration?
Because they're two different mechanisms. The data retention setting only affects explorations and funnel reports. Standard aggregated reports, including period comparisons, keep their full history regardless of this setting.
Who can change the data retention period in GA4?
Someone with the Editor role at the property level. That's a different role from the permission needed to manage the user list — adding or removing people with access requires the Administrator role at the account or property level.
Can age and interest data also be kept for 14 months?
No. Demographic data — age, gender, interests — always carries a hard 2-month limit, regardless of what value you set for the rest of your user data.
What happens if my GA4 property becomes Large?
Event-level data retention is automatically reduced to 2 months, and older event data is permanently deleted. Before that happens, GA4 sends administrators a warning email, and once the limit is crossed, a second one confirming the reduction.
How do I check exactly what retention period is set right now?
Go to Admin, make sure you're in the right property, and open the Property column › Data Settings › Data Retention. You'll see the current value for event data and the state of the reset-on-new-activity toggle.