GA4 Data Retention Settings: What They Delete and How to Fix It

GA4 data retention controls how long Google stores the user-level and event-level data behind your explorations before deleting it. It does not affect standard aggregate reports. The default window is shorter than most teams expect, so set retention to the maximum your property offers and export raw events to BigQuery to keep history.

Key Takeaways

• GA4 data retention only governs user-level and event-level data used in explorations and raw exports. Your standard aggregate reports are not deleted when the window expires.
• The setting lives in Admin > Data Settings > Data Retention. Standard properties offer a shorter default and a longer maximum; Analytics 360 properties may offer an additional longer option.
• "Reset user data on new activity" restarts the retention clock for individual users every time they return, which can quietly extend how long specific user histories persist.
• BigQuery export removes the retention ceiling for raw events: once data lands in your own warehouse, Google's deletion window no longer applies to it.
• The safe default policy is maximum retention plus a BigQuery archive plus a documented consent and deletion workflow -- and you should confirm the current limits inside your own property admin.

What GA4 Data Retention Actually Controls?

GA4 data retention is the property-level control that decides how long Google keeps the granular, user-scoped data that powers anything beyond the headline aggregate reports. Think of it as a timer on the rawest, most identifiable layer of your analytics: the event-level timestamps, the user-level sequences, and the detailed rows that explorations and the BigQuery export read from. When that timer expires for a given piece of data, Google deletes it from the storage that backs those user-level and event-level features.

The critical thing to internalize is what this setting is not. It is not a delete switch for your whole property. It does not erase your audience definitions, your conversion counts, or your standard report metrics in any retroactive sense -- those are rebuilt from aggregated, modeled data that survives the retention window. What it deletes is the ability to drill into the underlying individual events and users past the cutoff. For a startup trying to reconstruct "what did this cohort actually do 18 months ago" in an exploration, that distinction is the difference between a useful answer and a dead end.

Because the setting operates at the user-and-event level, it interacts directly with the event model we cover in our GA4 events guide. Every exploration, every custom funnel, every path that depends on seeing individual event sequences is reading from the layer that retention governs. If you only ever look at standard acquisition and engagement reports, you may never notice the window expire. The moment you need behavioral depth, you will.

Which Reports Survive Retention Expiry and Which Do Not?

This is the section most teams get wrong, because the answer is not "GA4 loses your data." It is "GA4 loses the detailed layer while keeping the summary layer." Standard reports -- the ones in the Reports tab built on aggregated, modeled data -- continue to function after retention expires. Google retains the aggregated results it has already computed, so your historical trends in the default dashboards do not vanish on the expiration date.

What does vanish is the ability to query the underlying user-level and event-level data. Explorations (the Analysis Hub / Explore section) depend on that granular layer, so a free-form report you built today may return thinner history a year from now. The same is true for any feature that reconstructs individual user journeys or event sequences. The BigQuery export, if you use it, is a special case we cover below: it streams the raw rows to your own project before deletion happens, so your warehouse copy is unaffected.

Where the Setting Lives and How to Change It?

The control is in the GA4 interface under Admin, then Data Settings, then Data Retention. You need Editor or Administrator access on the property to change it. Inside that screen you will see the retention period selector and, separately, the "Reset user data on new activity" toggle. Changing the period applies going forward: Google begins deleting data that is older than the new window on its scheduled processing cycle.

For standard properties, you typically choose between a shorter default period and a longer maximum period. The exact months offered change over time and differ by property type, so do not trust a blog post -- open your own Admin > Data Settings > Data Retention and read the current options before you commit a number to a dashboard footnote. Analytics 360 properties generally expose an additional longer option beyond what standard properties offer, which matters if you are a Series A+ company with a 360 commitment and long compliance horizons.

Set it to the longest option your property type allows. There is rarely a good reason for an early-stage startup to accept the shorter default: you are not saving meaningful cost, and you are throwing away the exact behavioral depth you will want when you raise your next round and need to tell a retention-and-engagement story. When you pair this with proper GA4 marketing reporting, the longer window means your explorations stay useful across full annual cycles.

What Does "Reset User Data on New Activity" Do?

The "Reset user data on new activity" toggle changes the retention clock from a fixed age-per-record model to an activity-per-user model. When it is on, every time a user returns and generates new activity, the retention timer for that user's data resets to zero. A user who comes back once a quarter can therefore have their entire history preserved indefinitely, because the clock never reaches the cutoff.

This is convenient for longitudinal analysis but it is also a privacy and compliance footgun. It means the retention setting you thought was a hard ceiling is, in practice, a soft ceiling for anyone still active. For teams operating under consent and deletion obligations, an active user's data may persist far longer than your stated policy implies. If your legal or privacy posture requires a true maximum age on user data, you should turn this toggle off and rely instead on a documented deletion process -- and on BigQuery archival only for the aggregate or anonymized copies you are permitted to keep.

How Does BigQuery Export Remove the Retention Ceiling?

The BigQuery export is the single most important mitigation in this entire guide. When you link a GA4 property to BigQuery, Google streams the raw event data -- one row per event, with all parameters -- into a dataset you own, on a daily (and for some connection types, intraday) basis. Once those rows are in your BigQuery project, they are your data, sitting in your storage, subject to your own retention rules and not Google's GA4 deletion timer.

This is what "removes the retention ceiling" means in practice: GA4 may delete the user-level and event-level source after its window, but your warehouse still has the complete history. You can then run the explorations, cohort analyses, and long-window funnels that GA4 itself can no longer serve, directly against BigQuery using SQL. For startups that treat their analytics as a durable asset, this is the difference between "we lost two years of behavioral data" and "we archived it before Google could delete it."

The export is available for standard properties at no additional Google charge for the export itself (you pay BigQuery storage and query costs), which makes it an easy yes for a data-minded team. If you are already running server-side collection, the export pairs naturally with the architecture in our server-side tagging guide, giving you both a clean ingest path and a durable archive.

What Does a Sensible Retention and Archival Policy Look Like Alongside Consent?

A sensible policy stacks three layers. First, set GA4 data retention to the maximum offered for your property type and leave it there -- this is the no-cost, five-minute change that keeps the in-product explorations useful for as long as Google allows. Second, enable the BigQuery export on day one of the property, before you have accumulated anything worth losing, so your warehouse has an unbroken history from launch. Third, write down the policy: what you keep, where, for how long, and what happens on a deletion request.

Consent is the layer that trips up teams who treat retention as a pure analytics decision. Under consent frameworks, you cannot simply hoard user-level data indefinitely; you need a lawful basis and a deletion path. This is where the "reset user data on new activity" toggle becomes a liability rather than a convenience, and where a documented archival strategy matters. Our Consent Mode v2 guide explains how to align collection with user choices, and you should map your BigQuery archive against the same consent states: export only what you are permitted to keep, and build a deletion job that honors requests at the warehouse level too.

The practical checklist below assumes a brand-new property. For an existing property, the same steps apply, but you should audit what history you already have in BigQuery before assuming the archive is complete.

1. Open Admin > Data Settings > Data Retention in the new property and confirm the current period options available to your property type.
2. Set the retention period to the longest option offered for your property (shortest default vs longer maximum for standard; check 360 options if applicable).
3. Decide the "Reset user data on new activity" toggle deliberately: off if you need a true maximum age for compliance, on only if longitudinal user analysis outweighs that risk.
4. Link the property to BigQuery and verify the daily export is landing rows in your dataset before you rely on it as an archive.
5. Document your retention and archival policy, including consent alignment and the deletion workflow for both GA4 and BigQuery.
6. Re-confirm the retention options in admin at least annually, since Google changes the available periods over time.

Frequently Asked Questions

Does GA4 Data Retention Delete My Standard Reports?

No. Standard aggregate reports are built on modeled, summarized data that Google retains beyond the retention window, so your acquisition, engagement, and monetization dashboards keep working after expiry. What expires is the underlying user-level and event-level data that powers explorations and individual user detail, not the headline aggregates themselves.

What Is the Difference Between Standard and Analytics 360 Retention?

Standard properties generally offer a shorter default period and a longer maximum period, while Analytics 360 properties expose an additional longer option beyond the standard maximum. The exact months change over time and by property, so you should open your own Admin > Data Settings > Data Retention to see the current choices rather than relying on a fixed figure from documentation.

Should I Turn On "Reset User Data on New Activity"?

It depends on your privacy posture. Turning it on keeps active users' histories indefinitely by resetting their timer on every return, which is great for longitudinal analysis but problematic if you must enforce a true maximum data age for compliance. For most consent-bound startups, leaving it off and relying on a documented deletion process is the safer choice.

Does BigQuery Export Protect Data from Retention Deletion?

Yes. Once GA4 streams raw event rows into your BigQuery project, those rows are stored in your own warehouse and are no longer subject to Google's GA4 deletion timer. You can query years of history directly in SQL even after GA4 would have deleted the source, which is why enabling the export on day one is the core of any durable archival policy.