The GA4 Transition Forensics: What Universal Analytics Did Better

TL;DR: Three and a half years after Universal Analytics stopped processing hits, it is finally possible to write a forensic account of the transition without it sounding like a complaint letter. GA4 genuinely improved the data model (events-first instead of sessions-first), the cross-platform story (web and app in one property), and the analytics floor (BigQuery export at no marginal cost for every account). It also genuinely degraded several workflows that mid-market operators relied on (session reporting, content groupings, custom channel grouping flexibility, and the speed at which a non-technical analyst could answer a routine question). The interesting question is not whether GA4 is better. It is what the same engineering investment could have produced if Google had iterated UA forward rather than retiring it.

A note on the named tools and authors. Universal Analytics, GA4, Looker Studio, and BigQuery are Google products that this essay names directly because no archetype framing would make sense. Krista Seiden and Avinash Kaushik are cited from their public writing. Quantitative observations on adoption, sampling thresholds, and migration timelines come from advisory engagements with anonymized partner operators in mid-market commerce, B2B SaaS, and media, not from the named individuals or from Google.

---

The Forensic Frame

The Universal Analytics sunset, July 1, 2023 for the free tier and July 1, 2024 for the 360 paid tier, is now far enough in the rearview that the rhetorical heat has dissipated. Most teams have a working GA4 setup. The dashboards that used to read in five seconds now read in twenty. The reporting that used to take an hour now takes three. The team has learned to think in events rather than in sessions, and the muscle memory has formed. The migration is over.

That is the right time for a forensic look. Not a "GA4 is broken" complaint, which was the dominant register in 2022, and not a "GA4 is the future" piece of vendor advocacy, which was the dominant register in 2024. The interesting question is narrower: what did Universal Analytics do better than GA4, what does GA4 genuinely improve, and what was unchanged. The answers matter because the same architectural choices Google made (event-first model, sampling thresholds, machine-learning attribution defaults, four-month data retention free tier) will propagate across the next decade of marketing measurement tooling. If we do not name the trade-offs precisely, we will repeat them.

This essay is structured as a forensic report. The patient is the UA-to-GA4 transition, the cause of death for Universal Analytics is on the record (Google's official migration announcement, March 2022), and what remains is the autopsy: what worked, what did not, and what the loss column looks like next to the gain column.

---

The Data Model Shift: Events First, Sessions as Derivative

The biggest single change between UA and GA4 is structural. Universal Analytics modeled the world as sessions containing hits, where a hit was the unit (pageview, event, transaction, social interaction, timing), and a session was a window of hits within a 30-minute idle threshold. GA4 inverts this: events are the unit, and session_id is a parameter attached to events. Sessions still exist in GA4, but they are computed from events rather than being the primary container.

For developers, this inversion is unambiguously cleaner. The UA hit type system (pageview vs event vs transaction vs social) was a legacy of how web measurement looked in 2005, when Urchin Software (the predecessor that became Google Analytics) shipped its first analyzer. In 2005, pageviews dominated; events were a bolt-on; mobile apps were not a meaningful surface. By 2015, the bolt-on had become the main attraction. By 2020, most meaningful measurement on a modern e-commerce site was already happening through custom UA events (add_to_cart, video_play, scroll depth, form abandonment), and the session-pageview frame was just baggage.

GA4 collapses all of this into one type. Everything is an event, every event has a name and parameters, and the schema is uniform across web and app. From a data engineering standpoint this is the right call. From a reporting standpoint, it created two problems.

The first problem is that the GA4 default UI is event-oriented in a way that does not match how most reporting questions are phrased. When a marketing director asks "how did the homepage perform last week," the question is implicitly about sessions and pageviews. The answer in GA4 requires the analyst to either pull the Engagement > Pages and Screens report (which exists but is structurally different from UA's Behavior > Site Content) or to query Explore. In UA, the equivalent answer was two clicks deep. In GA4, it is four clicks deep and the language has changed.

The second problem is that GA4 introduced "Engaged Sessions" as a metric distinct from "Sessions," with engaged sessions defined as sessions lasting longer than 10 seconds, having a conversion event, or having two or more pageviews. The new metric is arguably more useful, because it filters out bounces in a way that the old bounce rate did not. But it also means that the headline numbers reported in a GA4 property are not directly comparable to UA numbers from the same site, and explaining the difference to an executive consumes a 30-minute meeting that the analyst would rather have spent on the actual analysis.

The chart is composite, drawn from time-tracking notes across five advisory engagements with mid-market commerce and B2B SaaS analytics teams during the 2023-2024 migration window. The pattern that matters is not the absolute hours, which vary widely by team size, but the redistribution: routine reporting got slower while custom analysis got slightly faster and cross-platform reconciliation got materially easier. Whether that trade is worth it depends on the proportion of routine reporting in your team's actual workload.

---

What GA4 Did Better: Cross-Platform, BigQuery, and Defaults

It is worth being precise about what GA4 genuinely improved, because the legitimate gains are obscured by the complaints about what it broke.

The cross-platform story is the headline win. Before GA4, measuring a web property and an iOS/Android app required two separate properties (UA for web, Firebase Analytics for app), two separate event schemas, two separate reports, and a custom reconciliation pipeline if you wanted unified user counts. GA4 merged Firebase's event schema with web measurement into one property type. For any business that operates both a website and a native app (which is most direct-to-consumer brands above mid-market scale), this is not a marginal improvement; it removes a category of engineering work that used to consume several engineer-months per year.

The second genuine win is BigQuery export at no marginal cost on the free tier. Under UA, BigQuery export was a 360 (paid) feature that started at six figures per year. Under GA4, every property, free or paid, can export event-level data to BigQuery with no Google-side charge (the BigQuery storage and query costs are borne by the operator, but those are typically a few dollars per month for a mid-market site). This single change democratized warehouse-grade analytics access in a way that the UA-era market had been waiting for since Heap and Snowplow popularized event-level capture.

The democratization effect is easy to undersell. Before GA4, a mid-market team that wanted event-level data in its warehouse either paid for UA 360 (out of reach below maybe $50 million in revenue), or implemented Segment / mParticle / Snowplow alongside UA, paying for the duplicate capture infrastructure and the duplicate identity stitching. GA4 collapsed this into the default. A team can now stand up a GA4 property, enable BigQuery export, and have warehouse-resident clickstream within hours rather than weeks. That is a meaningful productivity gain.

The third genuine win is sampling thresholds. UA's free tier sampled aggressively. A custom report on a high-traffic site would routinely sample at 100,000 or 250,000 sessions, and the "Unsampled Reports" feature was 360-only. GA4 standard properties have much higher thresholds (10 million events in the standard reports, with sampling in Explore at 10 million per query for standard and 1 billion for 360). For a mid-market site, the practical effect is that exploratory analysis rarely hits sampling now. For a high-traffic site, it still does, but the threshold is higher than UA's was.

---

What UA Did Better: Session Reporting and the Speed of a Routine Answer

Set against those gains are several genuine losses, most of which cluster around the speed and ease of answering a routine business question.

Universal Analytics had been refined for 17 years to make a specific class of question fast to answer. "What were our top pages last week, by traffic source, on mobile, for new users." In UA, that was: Behavior > Site Content > All Pages, with a segment for mobile new users, secondary dimension source/medium. Three clicks, two dropdowns. The report rendered in under five seconds for most properties.

In GA4, the same question is harder. The closest report is Reports > Engagement > Pages and Screens, which does not accept a segment in the same way. To filter by mobile new users with source/medium overlay, the analyst opens Explore, builds a free-form table, drags in dimensions (Page path and screen class, Source / medium, First user source / medium, Device category), drags in metrics (Views, Active users, Engagement rate), applies a segment for "new users on mobile," and waits. The Explore interface is more powerful than UA's report builder, but it is also slower for the common case, and the learning curve is steep enough that several mid-market teams I worked with simply stopped trying to answer routine questions in GA4 and started forwarding them to whichever junior analyst had become the resident GA4 specialist. That is a workflow regression.

Krista Seiden, formerly Google's Analytics Advocate and one of the most public defenders of the GA4 transition, has been candid in public talks that the loss of the UA reporting interface speed was a real cost that Google underestimated, and that the Explore-centric model expects more from the average analyst than UA did. Avinash Kaushik, writing in his Occam's Razor newsletter during the transition window, was more pointed: the UA-to-GA4 migration was, in his framing, the first major case in which Google substantially raised the analytics-literacy bar for users of its free analytics product, with no compensating tier for users who had liked the old level.

Beyond the speed regression, several specific UA workflows are simply gone or materially degraded in GA4:

1. Content Groupings: UA allowed multiple content groupings per property (up to five), defined either by rule, by code, or by extraction from URL patterns. GA4 supports content_group as an event parameter, but the multi-grouping flexibility is reduced and the UI for managing the groupings is less ergonomic.

2. Custom Channel Groupings: UA allowed full customization of the default channel grouping, including the order of rule evaluation. GA4 introduced a custom channel grouping feature in 2023, but its rule editor is more limited and changes apply prospectively only (no retroactive recomputation), which constrains how it can be used.

3. View Filters: UA's views allowed exclusion filters (exclude internal IP, exclude bot traffic, exclude staging hostnames) at the view level. GA4 replaced views with "data streams," which support some filtering at the property level but with reduced flexibility, and several common UA filter patterns (regex-based hostname inclusion lists, IP-range exclusions with CIDR notation) require either tag-side filtering or post-hoc filtering in BigQuery.

4. Session-Level Reporting: This is the headline regression. UA reported on session-level metrics natively (pages per session, time on page, bounce rate). GA4 reports on user-level and event-level metrics by default, and several of UA's session metrics either do not exist (pages per session is reported as "views per session" which is computed differently) or have different definitions (bounce rate exists in GA4 but is defined as the inverse of engagement rate, not as single-pageview sessions).

The first three are minor irritations that a competent analyst learns to work around. The fourth is a category change that broke years of dashboards, reporting habits, and conditional logic in tag managers across the industry.

The table is composite, drawn from the same advisory engagement set as the earlier chart. The pattern matters more than any single row: GA4 is materially better at a few things (cross-device, BigQuery, real-time), comparable at several things, and meaningfully worse at the routine reporting tasks that constitute most analyst time.

---

The Attribution Model Change

Universal Analytics offered seven attribution models by default in its Attribution reports: last interaction, last non-direct click, last AdWords click, first interaction, linear, time decay, and position-based. The Model Comparison Tool let an analyst hold the conversion set constant and swap models to see how channel credit shifted. The methodology was transparent (rule-based weighting), and the analyst could reproduce the numbers in a spreadsheet.

GA4 removed several of these (the rule-based models for last AdWords click and first interaction were deprecated in 2023, with last non-direct retained) and made data-driven attribution the default for all properties with sufficient conversion volume. Data-driven attribution in GA4 uses a machine-learned model that distributes conversion credit across touchpoints based on counterfactual analysis, drawing on Shapley value approximations and Google's internal modeling for sparse-data accounts. The methodology is documented at a high level but is not reproducible by the analyst, because the model is trained on a pooled dataset that includes other Google accounts.

This is a philosophical change with operational consequences. UA's attribution was a tool the analyst used; GA4's data-driven attribution is a black box that the analyst consumes. For attribution-literate teams, this is a regression in transparency. For attribution-illiterate teams, it is arguably an improvement, because the default model is harder to misuse than last-click was. The trade-off splits along team sophistication lines.

Two operational consequences are worth naming. First, the data-driven attribution model in GA4 is not deterministic across reporting dates for the same conversion set, because the model is retrained periodically. A conversion that was credited 30% to paid search in January may be credited 25% in February, even with the same underlying touchpoint data. This makes year-over-year attribution comparisons more difficult and means that attribution-based budget allocations must be treated as moving targets rather than fixed numbers.

Second, the loss of the rule-based models removes a common diagnostic technique: comparing first-touch to last-touch credit by channel to identify which channels are demand-creating versus demand-harvesting. The Model Comparison Tool in UA made this a five-minute exercise. In GA4 you can still do it (last-click and first-click models remain available in some reports), but the workflow is fragmented across views.

Universal Analytics gave you attribution models you could argue with. GA4 gives you an attribution model you have to trust. For some teams that is an upgrade. For teams that learned to be suspicious of attribution numbers in 2015 because they had been burned by last-click, it is a regression.

---

The Data Retention and the Quiet Defaults

The least discussed and most operationally consequential change between UA and GA4 is data retention. Universal Analytics retained user-level and event-level data for 26 months by default on the standard tier, with the option to keep "user identifiers" indefinitely. GA4 standard retains event-level data for two months by default, with a maximum of 14 months. Aggregated standard reports retain longer (the basic reporting interface does not aggressively truncate), but anything that requires user-level or event-parameter granularity (most of Explore, most ad-hoc segmentation, most cohort analysis) is bounded by the retention setting.

For most operators, the default retention setting was the value they kept. Few mid-market teams reviewed the GA4 data retention configuration during initial setup, because the setup wizard does not prominently surface it. The result is that thousands of properties are running on the two-month default, which means any year-over-year comparison in Explore is impossible without BigQuery export, and most cohort analyses longer than 60 days are silently truncated.

The retention change is not framed in any of Google's migration documentation as a regression. It is framed as a privacy-aligned default consistent with GDPR principles of data minimization. That framing is defensible from a privacy stance. It is also a meaningful operational degradation for analytics teams that previously had two years of clickstream history available without leaving the Google Analytics interface. The workaround (enable BigQuery export, query historical data from the warehouse) is feasible, but it presumes the team did the BigQuery setup before the data was lost, which most teams did not in the first migration cohort.

A second quiet default is the "Google signals" toggle. Enabling Google signals improves demographic and cross-device reporting by leveraging signed-in Google user data, but it also introduces sampling and thresholding behavior that suppresses small-segment numbers (the well-known "(other)" row that appears when audiences are too small to report without de-identification risk). Several teams I worked with spent weeks debugging missing numbers in their dashboards before discovering that Google signals was the cause.

---

The Opportunity Cost Question

The forensic frame asks not just whether GA4 is better than UA, but what the same engineering investment could have produced if Google had iterated UA forward rather than retiring it and rebuilding. This is the question that is largely absent from public commentary, because it is unanswerable in any rigorous way, but it is worth raising because the answer informs how we should evaluate similar architectural retirements in the future.

UA had architectural debt. The session-first data model was awkward for mobile apps. The hit-type taxonomy was a legacy of 2005 web measurement. The free-tier sampling was punishing for high-traffic sites. The cross-device story required custom user-ID implementation. The BigQuery export was paywalled. These are real problems, and the case for rebuilding rather than iterating is not nothing.

But the case against rebuilding is also not nothing. The UA codebase had 17 years of refinement around the specific reporting workflows that the long tail of operators depended on. The interface had been tuned to the cognitive load of non-specialist analysts. The metric definitions had been stabilized across thousands of integrations (ad platforms, CRMs, attribution vendors, BI tools), and changing them meant breaking every downstream integration. The migration cost (estimated by multiple advisory firms to total over 100 million person-hours globally across all affected accounts) was borne by operators, not by Google.

The composite assessment above is impressionistic, drawn from conversations across advisory engagements during the transition window. The pattern that matters is the bimodal distribution: teams with engineering capacity and a real cross-platform use case benefited materially. Teams without engineering capacity and with web-only use cases paid migration costs without commensurate gains. Agencies were the worst hit because they bore the migration cost across every client in their portfolio simultaneously.

A counterfactual UA-iterated path is impossible to specify precisely, but the broad outlines are visible. Google had been adding GA4-style improvements to UA at the margin for years: enhanced e-commerce (2014) improved the e-commerce data model, the gtag.js wrapper (2017) unified the JavaScript snippet, the App + Web property type (2019, which became GA4) was initially positioned as an additive property rather than a replacement. A version of the world where Google kept iterating on UA, added the GA4 event model as a property option, kept the UA reporting interface for users who wanted it, and graduated cross-platform measurement and BigQuery export into the free tier without forcing a migration, is plausible. It is not what happened.

---

What Is Unchanged: The Underlying Problems of Web Analytics

It is also worth being precise about what did not change in the UA-to-GA4 transition, because the underlying problems of web analytics remain unsolved by either tool.

The deduplication problem is unchanged. Both UA and GA4 over-count users when cookies are deleted, browsers are switched, or private browsing is used. The user-ID feature in both tools helps for logged-in users but does nothing for anonymous traffic. Cross-device measurement remains hard, and the Google signals feature in GA4 is an improvement only for sites with high Google-account-signed-in traffic.

The bot problem is unchanged. Both tools rely on the IAB/ABC International Spiders and Bots List for known bot filtering, and both will miss sophisticated bots that mimic human behavior. The bot problem is currently estimated to constitute 15-30% of analytics traffic for many B2B sites and 5-10% for consumer sites, depending on the IAB methodology and the specifics of the site (see the IAB's 2024 Bot Traffic Study for current estimates). GA4 has marginally better default bot filtering than UA had, but the problem is structurally hard and neither tool has solved it.

The attribution problem is unchanged. Both tools attribute conversions to touchpoints that the tool can observe, which means they miss offline conversions, dark social, word of mouth, latent demand effects, and brand-driven baselines. GA4's data-driven attribution is more sophisticated than UA's last-click default, but it is still bounded by the observable touchpoint set. The marketing measurement gap (the gap between attributed touchpoints and actual incremental effect) is a structural feature of the measurement category, not a property of any specific tool.

The privacy and consent problem is unchanged, and arguably worse. Both UA and GA4 require consent management for European traffic under GDPR, and both lose meaningful measurement coverage when consent rates drop below 70%. GA4 introduced "consent mode" which uses behavioral modeling to fill in gaps when consent is refused, but the modeling is opaque and the methodology is not auditable. Several European data protection authorities have flagged both UA and GA4 as potentially non-compliant with Schrems II requirements for international data transfers, though the regulatory picture continues to evolve.

---

What This Means for the Next Vendor Transition

The GA4 transition will not be the last forced migration in the analytics category. Google is already signaling a longer-term shift toward server-side measurement, Privacy Sandbox-aligned attribution, and AI-assisted analysis surfaces that will likely require further architectural changes. Adobe Analytics, Mixpanel, Amplitude, and Heap have all gone through similar major version transitions in the last five years. The lessons from GA4 apply broadly:

1. The migration cost falls on operators, not on the vendor. When a vendor with effective monopoly distribution forces a rebuild, the total cost is enormous (millions of person-hours globally) but distributed across thousands of operators, each of whom pays a few hundred to a few thousand hours. The diffusion of the cost makes it invisible in vendor accounting but very real in operator economics.

2. Defaults matter more than features. The data retention default, the engaged-sessions default, the Google signals toggle, and the data-driven attribution default each had larger operational impact on most teams than the headline feature changes. Quiet defaults compound across thousands of accounts.

3. The flexibility tax is real. Tools that give analysts a blank canvas (GA4 Explore) cost more in cognitive overhead than tools with constrained templates (UA's report builder), even if the canvas is strictly more powerful. For routine work, constraint is a feature.

4. BigQuery export is the load-bearing improvement. Of all the changes in GA4, the one with the most durable downstream effect is the BigQuery export. It moved analytics from a closed product into a data source. The lesson generalizes: every vendor analytics product that does not expose event-level data to a warehouse is on borrowed time.

5. Forensic honesty matters more than vendor enthusiasm. The GA4 launch was accompanied by a wave of vendor-friendly content that minimized the regressions. Three years on, the regressions are still real, and pretending otherwise has cost teams that bought the marketing rather than diagnosing the actual trade-offs.

The Universal Analytics era was not perfect, and the nostalgia that some operators still express for it is partly displaced grief for the time they spent learning a tool that no longer exists. But UA did several things well that GA4 has not yet matched, and naming those things precisely is the only way to make sure the next iteration of measurement tooling preserves them rather than discarding them in the next rebuild.

There is one final observation worth making about the migration's downstream effects on the analytics labor market. Before the transition, "Google Analytics" was a baseline literacy that any marketing hire or junior analyst was expected to have, and the time-to-productivity on a new GA property was measured in days. After the transition, GA4 fluency is a specialist skill: agencies bill for it separately, junior hires need weeks of structured training, and the long-tail of small business operators have either outsourced their analytics entirely or stopped looking at it. The democratization of warehouse-grade event data (a real GA4 win) coincided with a re-stratification of who can actually do analytics work. Whether that net effect is positive depends on the position you occupy in the resulting labor market. For senior analysts and consultants, it has expanded the demand for specialized skill. For the broader operator population, it has raised the bar to entry. Both effects are GA4's downstream consequences, and both will compound over the coming decade as the muscle memory of UA fades and a generation of analysts grows up knowing only the GA4 paradigm.

---

Key Takeaways

1. The UA-to-GA4 transition is now far enough in the past for a forensic frame: what worked, what did not, what was unchanged, and what the opportunity cost looks like.
2. GA4 genuinely improved three things: the events-first data model, the cross-platform (web plus app) story, and BigQuery export democratization on the free tier.
3. UA was meaningfully better at routine reporting speed, session-level metrics, custom channel grouping flexibility, content groupings, and the cognitive load borne by non-specialist analysts.
4. The data-driven attribution change traded transparency (rule-based, reproducible) for sophistication (ML-based, black box), which is a regression for attribution-literate teams and an improvement for attribution-illiterate ones.
5. Several quiet defaults (data retention, Google signals, engaged-sessions metric) had larger operational impact for most teams than the headline feature changes.
6. The migration cost was borne by operators (estimated in the hundreds of millions of person-hours globally) while the strategic gains accrued mostly to Google. The asymmetry is structural to vendor-forced migrations.
7. The underlying problems of web analytics (deduplication, bots, attribution, privacy) are essentially unchanged. Neither tool has solved them.
8. BigQuery export is the load-bearing durable improvement. It moved GA4 from a closed product into a data source that the rest of the modern data stack can compose against.
9. The forensic frame should be applied prospectively to the next vendor-forced migration. The questions to ask are the same ones that should have been asked of GA4 before the migration, not after it.