GA4 vs Universal Analytics: Everything That Actually Changed

Short answer: Universal Analytics and GA4 are not two versions of the same product — they are built on fundamentally different data models. UA counted sessions and pageviews; GA4 counts events and users. That single shift changes how sessions are defined, why your numbers dropped after migrating, what "bounce rate" even means, how you build reports, and what you can legally do with your raw data. Universal Analytics stopped processing data on July 1, 2023 (July 1, 2024 for the paid GA360 version), and Google permanently deleted all remaining UA data in July 2024 — so today GA4 is the only Google Analytics property you can actually run. This guide covers every difference that matters, verifies the code you need, and tells you what to do about each one.

The core change: sessions vs. events

Universal Analytics was a session-based model. Everything hung off a session — pageviews, events, transactions — and Google bolted an event model on top later as an afterthought. GA4 inverts the hierarchy: everything is an event. A pageview is an event (page_view). A scroll is an event (scroll). A purchase is an event (purchase). Even a session is just an event (session_start) plus the grouping of events that follow it under a shared ga_session_id.

This is not cosmetic. It is the root cause of almost every downstream difference in the two tools:

• Reports are built around events and parameters, not the rigid "hit types" UA shipped (pageview hit, event hit, transaction hit, social hit, timing hit). GA4 has one primitive.
• You define custom tracking by sending named events with parameters, instead of cramming meaning into UA's three fixed text fields — Category, Action, and Label — and then reverse-engineering what past-you meant.
• The same event schema works across web and app. GA4's engine is Firebase Analytics grown up, so cross-platform measurement is native rather than a bolt-on with two incompatible SDKs.

If you learned analytics on UA, this is the mental model you have to rebuild first. Every section below follows from it.

session_start

First event, stamps ga_session_id

page_view

Each page or screen

Custom events

scroll, click, form_submit, purchase

Key event

Flagged event = conversion

Session grouping

All events sharing the session id

Why your numbers changed after migrating

The single most common panic after a UA-to-GA4 migration is "our traffic dropped." Almost always, it didn't — the two tools simply count differently. Understanding exactly why keeps you from chasing a problem that does not exist and from "fixing" a setup that is working correctly.

Sessions. UA started a new session in three situations: at midnight (property time zone), on a new campaign source mid-visit, and after 30 minutes of inactivity. GA4 kept only the inactivity rule and dropped the midnight and campaign-change resets. So one user browsing across midnight is one GA4 session but was two UA sessions; a user who arrives via one campaign and clicks a second campaign link mid-visit is now one session instead of two. Fewer sessions in GA4 is the expected result, not a bug. (The 30-minute inactivity window is still the default and is still adjustable under Admin → Data Streams → Configure tag settings → Adjust session timeout.)

Users. UA's headline "Users" leaned on Total Users (anyone who visited in the range). GA4's headline metric is Active Users — users who had an engaged session. Different definitions, different numbers, no reconciliation possible.

Bounce rate is gone, then came back inverted. UA's bounce rate was "single-page sessions with no interaction." GA4 replaced it with Engagement Rate — the share of engaged sessions, where an engaged session is one that lasted 10+ seconds, fired a conversion (key event), or had 2+ pageviews/screenviews. GA4 later re-added a metric literally called "Bounce Rate," but it is now defined as 1 − Engagement Rate. That is a genuinely different definition from UA's, so comparing the two number-for-number is meaningless — a page could show a "high" GA4 bounce rate while performing well by UA's old logic.

The takeaway: stop expecting the numbers to match. They can't, by design. Rebuild your baselines in GA4 and judge trends going forward, not against a UA ghost you can no longer even open.

Metric-by-metric: what maps to what

Three rows deserve extra attention.

Goals became Key Events. Google renamed "Conversions" to "Key Events" in the GA4 UI in 2024 — "conversions" is now reserved for what actually imports into Google Ads. Because any event can be flagged as a key event, you have far more flexibility than UA's handful of goal types, but also far more room to mismeasure (double-counted purchases, key events firing on page load, etc.).

Reporting Views are gone entirely. Teams that relied on filtered UA views — a "US only" view, a "staging excluded" view — now have to reproduce that with GA4 explorations, comparisons, audiences, or a second property with a different data filter. There is no drop-in equivalent.

Data retention is shorter and it bites in a specific place. For standard (free) GA4 properties, user- and event-level data can be kept for 2 months (default) or 14 months; the extended 26/38/50-month options exist only on the paid GA360 tier. Crucially, retention only limits Explorations (funnels, path analysis, custom segments over the raw event data). Standard aggregated reports — Traffic Acquisition, Pages and Screens — persist beyond the window. This is the single most common reason a team panics that "our historical data is gone" when it isn't; they just hit the Exploration ceiling. The permanent fix is the BigQuery export, covered below.

What GA4 does that UA never could

Migration was not only loss. GA4 genuinely unlocks capabilities UA could not touch:

• Free BigQuery export for everyone. In the UA era, the raw-hit BigQuery export was a GA360 (paid, enterprise-only) feature that cost five figures a year to unlock. GA4 gives every property — free tier included — a native daily and/or streaming export of every raw event into BigQuery. This is the single biggest upgrade in the whole migration: you get unsampled, row-level data you own and can join to anything.
• Event-driven flexibility. Custom events with parameters replace UA's cramped Category/Action/Label, so your tracking can model your actual business (plan_selected with plan_tier and billing_cycle) instead of contorting to fit three text fields.
• Native cross-platform. One event schema spans web and app, with users stitched across devices via User-ID and Google signals.
• Predictive audiences and modeling. GA4 can model purchase probability and churn probability and build predictive audiences from them — capabilities UA simply did not have.
• Privacy-first architecture. GA4 was designed for a consent-driven, cookie-restricted web, with Consent Mode and conversion/behavioral modeling built in rather than bolted on.

Custom tracking, then and now: a worked example

Nothing makes the model shift concrete faster than the same tracking in both tools. Suppose you want to track when someone selects a pricing plan.

In Universal Analytics, you had exactly three string fields to work with, and you memorized a naming convention so your reports stayed legible:

// Universal Analytics (analytics.js) — everything squeezed into 3 fields
ga('send', 'event', 'Pricing', 'Select Plan', 'Growth');
//                     ^Category    ^Action        ^Label

In GA4, you send a named event and attach as many parameters as the meaning requires (up to ~25 event parameters), then register the ones you want to report on as custom dimensions:

// GA4 (gtag.js) — a named event with structured parameters
gtag('event', 'select_plan', {
  plan_tier: 'growth',
  billing_cycle: 'annual',
  price_usd: 4800,
  currency: 'USD'
});

The GA4 version needs no clever encoding of three fields — plan_tier and billing_cycle are their own dimensions, and price_usd is a real number you can sum. To make select_plan a conversion, you flag it as a key event in the GA4 UI (Admin → Events, or Configure → Events); there is no separate "goal" object to define.

For Consent Mode (see next section), the one rule that trips people up is ordering: you must set consent defaults before the GA4 config command loads, so the tag knows whether it may write cookies on the very first hit:

// 1) Defaults FIRST — before gtag('config', ...) and before GA4 loads
gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  wait_for_update: 500
});

// 2) Later, when the user accepts, update the granted signals
gtag('consent', 'update', {
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted',
  analytics_storage: 'granted'
});

Get that order wrong — config before defaults — and GA4 can write cookies before consent is known, which is exactly the compliance gap regulators care about.

Consent Mode and server-side tagging: the modern layer

Two things that barely existed in the UA world are now central to running GA4 well.

Consent Mode v2. If you have EEA or UK visitors and run Google Ads or remarketing, Consent Mode v2 is effectively required — without it, Google restricts your ability to add new EEA users to audiences and to attribute conversions. Version 2 added two mandatory signals, ad_user_data (may user data be sent to Google for advertising) and ad_personalization (may it be used for personalized ads), on top of the earlier analytics_storage and ad_storage. UA had no equivalent framework at all.

A 2026 change worth knowing about: as of June 15, 2026, Google made ad_storage the single control that decides whether advertising data flows from GA4 into a linked Google Ads account. The old dual-gate — where the Google Signals admin toggle and consent both had to agree — is retired. Google Signals now only governs whether signed-in user data enriches your behavioral reporting; it no longer gatekeeps Ads data sharing. Practically, that means if your consent banner doesn't set ad_storage correctly, conversions, remarketing audiences, and Smart Bidding signals can go dark with no Signals fallback to catch the gap. If you migrated fast and never revisited consent, this is a live risk right now. If you're implementing or re-checking it, read our practical Consent Mode v2 guide.

Server-side tagging. GA4's event model pairs naturally with server-side Google Tag Manager, where tags fire from a server container instead of the browser. It improves data quality, page performance, and first-party control — but to be unambiguous, it is optional, not a requirement of GA4. Plenty of solid GA4 setups run entirely client-side. Server-side is an upgrade you choose when accuracy, ad-blocker resilience, or ITP/cookie-lifetime problems justify the added infrastructure and cost — most relevant for e-commerce and higher-traffic sites. Expect real hosting and maintenance overhead, not a free win.

A migration checklist that actually holds up

If you migrated in a hurry when UA sunset (many teams did), it is worth re-auditing. The setups that quietly leak data usually miss the same handful of things:

1. Key events reconciled — every UA goal has a deliberate GA4 key-event equivalent, firing once, with the right parameters, on the right trigger.
2. E-commerce re-implemented — GA4's e-commerce schema (view_item, add_to_cart, begin_checkout, purchase with an items array) differs from UA Enhanced Ecommerce; a lift-and-shift almost never maps cleanly.
3. Data layer validated — events fire once, with correct values and types, and not on stray page loads.
4. Consent Mode wired before tags fire — region-scoped defaults set before the GA4 config, v2 signals present, modeling on, and ad_storage behaving correctly under the June 2026 rules.
5. Internal traffic and bot filtering configured — GA4 handles both differently from UA (define internal-traffic rules, then activate the filter).
6. BigQuery export enabled — even if you don't query it yet, start banking raw history now; it's free, unsampled, and unrepeatable once a day passes unrecorded.
7. Cross-platform reconciliation — GA4 key events roughly agree with Google Ads conversions and with your own backend order data.

Get a straight read on your setup

If any of the above made you wince, you are not alone — most GA4 properties we see were migrated fast and never re-audited, and the June 2026 consent change just widened the gap between "looks fine" and "is fine." You can start free: our instant audit checks your GA4, GTM, consent signals, and Core Web Vitals in seconds. For the parts a tool can't see — whether events fire once with the right parameters, whether your key events reconcile with your ad platforms, whether your e-commerce schema is actually correct — that's a hands-on GA4 audit, and it's where the real money leaks get found. If you're standing up a fresh, correct implementation from scratch, our onboarding process sets consent, key events, and BigQuery up right the first time. Prefer to talk it through? Book a call and we'll tell you exactly what your setup is getting wrong.

FAQ

Is Universal Analytics still available in 2026?

No. Universal Analytics stopped processing new data on July 1, 2023 (July 1, 2024 for the paid GA360 version), and Google permanently deleted all remaining UA data in July 2024. There is no way to access historical UA data now unless you exported it beforehand. GA4 is the only Google Analytics property you can run today.

Why are my GA4 numbers lower than my old UA numbers?

Because the two tools count differently, not because you lost traffic. GA4 removed UA's midnight and campaign-change session resets, so cross-midnight or multi-campaign visits collapse into fewer sessions. GA4 also reports Active Users rather than Total Users. Expect the numbers to differ and rebuild your baselines inside GA4 rather than comparing against UA.

What happened to bounce rate in GA4?

UA's bounce rate (single-page sessions with no interaction) was replaced by Engagement Rate — the share of engaged sessions (10+ seconds, a key event, or 2+ pageviews). GA4 later re-added a "Bounce Rate" metric, but it is defined as 1 − Engagement Rate, which is not the same as UA's bounce rate. Don't compare the two directly.

Do I need BigQuery to use GA4?

No — GA4 works fully on its own. But the free BigQuery export (which used to require paid GA360) streams every raw, unsampled event out of GA4 with no 14-month Exploration ceiling. Even if you don't query it yet, enabling it early banks raw history you can't recreate later, so most serious teams turn it on immediately.

Is server-side tagging required for GA4?

No. Server-side Google Tag Manager is an optional upgrade that improves data quality, page speed, and first-party control, but it adds real hosting and maintenance overhead. Many GA4 setups run entirely client-side and work fine. Consider server-side when ad-blocker resilience, cookie lifetime, or e-commerce accuracy justify the extra infrastructure — typically for higher-traffic and e-commerce sites.

How much does a GA4 audit cost?

A focused GA4 audit generally runs about $1,500–$3,000, and a comprehensive audit (data layer, cross-platform tracking, consent, and roadmap) around $4,000–$8,000, depending on scope and site complexity. See our audit pricing for how we structure ours, or start with the free instant audit first.