How to use Cohort Analysis in GA4
A practical walkthrough of GA4 cohort analysis: how to configure the Exploration, where the native report breaks down, and the export workflow that gets you to real revenue-cohort views.
Cohort Analysis in GA4
Grouping GA4 users by their acquisition week and tracking how a chosen metric evolves across subsequent weeks.
Cohort analysis in GA4 lives inside the Explore workspace as the Cohort Exploration template. You define an inclusion event (typically first_visit or first_purchase), a return event, and a metric — GA4 then renders a triangular matrix showing how each weekly or monthly cohort behaves over time.
It's the closest GA4 gets to a retention or repeat-purchase view out of the box. The setup is fast, but the report has hard limits: 60-day lookback on the free tier, sampling above ~10M events, no revenue-per-cohort breakdown, and no way to segment cohorts by acquisition channel without rebuilding the whole exploration. Most teams outgrow it within a quarter.
If you're running a Shopify or WooCommerce store and want to know whether March acquisition spend produced better 90-day repeat-purchase behaviour than April's, GA4's cohort exploration is the first place you'll look. It's free, it's already wired to your data, and it builds in under two minutes.
It's also the place most teams give up on cohorts entirely — usually because they hit a limit they didn't expect (sampling, lookback, or the absence of a revenue metric) and decide cohorts are a BI-tool problem. They don't have to be. This guide walks the setup, names the limits explicitly, and shows the export path that gets you to a usable view.
Setting up the cohort exploration
Open Explore, pick the Cohort Exploration template, and you'll land in a four-quadrant editor. The four decisions that determine whether the report is useful are: inclusion criteria, return criteria, cohort granularity, and metric type.
For DTC use cases, set inclusion to first_visit (acquisition cohorts) or first_purchase (buyer cohorts). Return criteria should match the behaviour you actually care about — purchase for repeat-buyer rates, session_start for engagement retention. Use weekly granularity if you have under 100k weekly users; monthly above that. For metric, choose 'Per cohort user' rather than 'Sum' — the sum view double-counts and is almost always misleading.
Add a breakdown dimension last. First user source / medium is the most common, but it forces GA4 to fan out the matrix, which is where sampling starts biting on larger properties. If breakdown is essential, narrow the date range before adding it.
The 'Sum' metric trap
GA4 defaults the cohort metric calculation to 'Sum' for event counts and revenue. For a cohort report this is almost never what you want — it shows total purchases by week-since-acquisition, which grows with cohort size and obscures the actual retention signal. Switch it to 'Per cohort user' immediately. This single change is the difference between a useful report and a misleading one.
Where GA4's native cohort report breaks down
The native report has four limits worth naming explicitly, because each one will eventually push you to a workaround. The lookback ceiling is 60 days for standard reports and the data retention setting (default 2 months, max 14) for explorations. If you didn't change retention when you first set up GA4, your historical cohort window is shorter than you think.
Sampling kicks in above roughly 10 million events in the selected range. You'll see a yellow shield icon and a sampling percentage — anything below 80% data quality makes cohort cells unreliable, especially in the lower-right triangle where cell counts are already small. Revenue cohorts are particularly affected because purchase events sit at the long tail of the distribution.
Typical repeat-purchase rate by weeks since first order (apparel DTC)
The shape above is what a healthy apparel cohort looks like — steady accumulation through week 12, then a long tail driven by seasonal repurchase. The problem: GA4's native cohort report, on default settings, will only show you the first 8-10 weeks of that curve. The most strategically interesting part (week 12 onward, where channel-quality differences become obvious) is invisible unless you extend retention before you need it.
The export workflow that gets past the limits
Once you've outgrown the native report, the standard fix is BigQuery export. Link GA4 to BigQuery (free tier handles up to 1M events/day), wait 24 hours for backfill to start, then write a cohort query that pivots first_purchase date against subsequent purchase dates. The full pattern is a self-join on user_pseudo_id with a date_diff in weeks — about 40 lines of SQL once you've done it twice.
BigQuery solves sampling and lookback, but it doesn't solve the cold-start problem. The export only contains events from the moment you linked the property forward — your Universal Analytics history doesn't move with it. For a store that switched to GA4 in mid-2023, that means no 12-month cohort view until mid-2024, no year-over-year comparison until 2025.
GA4 cohort options compared
| Approach | Lookback | Sampling | Revenue per cohort | Channel breakdown | Setup time |
|---|---|---|---|---|---|
| Native Cohort Exploration | Up to 14 months* | Yes, above 10M events | Limited | Yes, but degrades sampling | 5 min |
| BigQuery export + SQL | From export date forward | No | Full control | Full control | 1-2 days |
| BigQuery + historical import | Full historical window | No | Full control | Full control | Hours, not days |
| Third-party BI on GA4 API | API quota limits apply | Inherits GA4 sampling | Workaround needed | Yes | Half day |
*The 14-month figure assumes you changed data retention to the maximum when you set up the property. The default is 2 months. Check Admin → Data Settings → Data Retention before you assume you have history — and note that changing it now does not backfill older data.
Connecting cohorts to revenue
The reason teams want cohorts in the first place is rarely retention curves in the abstract — it's cohort revenue analysis: how much does a customer acquired in March actually generate over 12 months, versus April, versus a paid-social cohort versus organic? GA4's native cohort report cannot answer that question cleanly. The metric picker offers 'Purchase revenue' but the breakdown by acquisition source forces sampling, and the 14-month ceiling clips the answer for any considered-purchase vertical.
The realistic stack is: GA4 for fast directional reads (is March worse than April? roughly), BigQuery export for clean post-export cohort analysis, and a historical GA4 import to fill the gap between when you switched to GA4 and when you need full-window cohort revenue analysis. The third piece is what most teams skip — and then spend a year waiting for organic data accumulation that they could have had on day one.
The historical-import unlock
A historical GA4 import pulls your Universal Analytics or warehouse history into the same schema GA4 uses, so cohort queries span the full window from the start. For a store that switched to GA4 in 2023, that's the difference between a 12-month cohort view today and a 12-month cohort view in 2025. The setup is a one-time data engineering job; the payoff is every cohort, retention, and LTV question you ask afterwards.
GA4 cohort analysis — common questions
It's not in standard reports. Go to Explore in the left nav, then pick the 'Cohort exploration' template from the template gallery. There's no link to it from the standard reporting interface, which is why a lot of people assume GA4 doesn't have cohorts.
Your data retention setting is on the default of 2 months. Go to Admin → Data Settings → Data Retention and change it to 14 months. Note that this change is not retroactive — it only extends retention from the date you change it forward.
Partially. You can pick 'Purchase revenue' as the metric in the cohort exploration, but as soon as you add a breakdown dimension (like first user source) sampling kicks in for properties above ~10M events. For clean cohort revenue analysis, export to BigQuery.
Weekly gives you faster signal — you'll see a problem with a campaign within two weeks instead of two months. Monthly smooths noise and is better above 100k weekly users where weekly cells get too dense. For most mid-sized stores, weekly is the right default.
Per cohort user, almost always. Sum shows total events or revenue per cohort cell, which inflates with cohort size and hides the actual retention pattern. Per cohort user normalises it and is what 'cohort analysis' conventionally means.
In GA4 Admin → BigQuery Links, create a daily export link to a BigQuery project. The free GA4 tier covers up to 1M events/day. After 24 hours you'll have an events_YYYYMMDD table per day; cohort queries are a self-join on user_pseudo_id with a week-difference between first_purchase and subsequent purchases.
Yes — above roughly 10 million events in the selected range it applies sampling, and the report shows a shield icon with the sampling percentage. Adding breakdown dimensions accelerates this. Anything below 80% data quality makes the lower-right cells of the cohort matrix unreliable.
Yes, add 'First user source / medium' or 'First user default channel group' as the breakdown dimension. Be aware this often triggers sampling on larger properties and can make week-12+ cells thin. For cleaner channel-cohort analysis, BigQuery export is the standard fix.
UA's cohort report was simpler — date-range cohorts and retention metric only, no exploration flexibility. GA4's version is more configurable (custom inclusion/return events, multiple metrics) but loses UA's deeper lookback. The migration tradeoff catches teams off guard, which is why a historical GA4 import matters for any year-over-year cohort work.
Two reasons, usually. Either the cohort is too recent to have a full lookback window (a cohort acquired last week can't have a week-12 cell yet), or the cell counts are below the privacy threshold GA4 applies to small audiences. The empty cells are not a bug — they're a structural feature of how cohort matrices fill in over time.
See Metricuno on your data
Bring your stack — Google Analytics, Stripe, a CRM, anything — and we'll walk through the metric tree that turns your funnel into one number.