GA4 vs Universal Analytics — What You Need to Know as an Analyst

Universal Analytics stopped collecting data in July 2023, but I still regularly run into the same problem: analysts try to read GA4 through UA glasses and get confused when numbers "don't match up" or something that used to be obvious no longer works the same way. The truth is that GA4 isn't "UA with a new interface" — it's a fundamentally different data model, a different event-collection philosophy, and different reporting logic. If you're auditing tracking or explaining to stakeholders why session count dropped 20%, you need to understand these differences at the foundation, not just at the UI level.

Data model: sessions vs. events

In UA, everything revolved around the session as the central unit — pageview, event, transaction, these were all "hits" attached to a specific session with a clearly defined start and end (30 minutes of inactivity, midnight, campaign change).

GA4 flips this hierarchy: absolutely everything is an event, including the session itself. session_start is just a regular event with a session_id parameter, page_view is an event, purchase is an event. Sessions in GA4 are derived secondarily from these events — they are not the primary unit.

This has concrete practical consequences:

• Bounce rate disappeared (it actually came back recently, but calculated differently) — GA4 defaults to talking about "engagement rate" (sessions lasting >10s, with a conversion event, or ≥2 page_views). This is a completely different definition than UA's bounce rate, so comparing these two numbers year-over-year doesn't make sense.
• Session counts will differ for the same traffic, because GA4 counts a new session on a UTM change mid-visit differently than UA did, and it doesn't close sessions at midnight.

E-commerce tracking changed from the ground up

This is the section where I see the most errors in audits. UA had Enhanced Ecommerce as a separate layer (ecommerce.js / analytics.js plugin) with events like add, detail, purchase sent via ec: parameters. GA4 has this built in as standard, recommended events with a specific items[] structure:

// GA4 recommended ecommerce event via GTM / gtag
gtag('event', 'add_to_cart', {
  currency: 'PLN',
  value: 149.99,
  items: [{
    item_id: 'SKU_12345',
    item_name: 'Midi dress',
    item_category: 'Dresses',
    price: 149.99,
    quantity: 1
  }]
});

The most common issues I see in GA4 e-commerce audits:

• missing currency on the purchase event — GA4 then doesn't count revenue in reports at all
• duplicated transaction_id on confirmation page refresh — GA4 itself doesn't deduplicate as aggressively as UA used to
• inconsistent item_id between view_item and purchase — this breaks purchase-path reports and attribution

Attribution and reporting: a different default model

UA defaulted to counting conversions with a "last non-direct click" model. GA4 defaults to data-driven attribution (DDA) — a machine-learning-based model that distributes conversion credit across all touchpoints in the path, not just the last one.

This means the same raw data will produce different conversion numbers per channel in UA versus GA4 — and that's not a tracking error, it's a difference in methodology. On top of that, the default channel groupings (Default Channel Group) differ between the two systems — GA4 has more granular categories (e.g., it splits "Paid Social" and "Organic Social" differently than UA did). If you're building a year-over-year comparison report across the migration point, flag this to stakeholders in advance — otherwise you'll get questions like "why did channel X suddenly lose 30% of its conversions?"

Historical data: what you won't carry over

UA didn't auto-export anywhere — after the deadline, the data simply disappeared from the UI (unless someone had already set up a BigQuery export or pulled reports manually). GA4 has built-in BigQuery Export integration, but it has to be consciously enabled:

• the free GA4 UI tier has data retention of 2 or 14 months (configurable under Admin → Data Settings → Data Retention) — this is not the same as "data is stored forever"
• BigQuery Export, if enabled, keeps raw event data indefinitely (in your own GCP project, you pay for storage/query)
• if you're running a migration project and someone asks "can we compare against UA data from 2 years ago" — the answer is: only if there was an earlier export, because UA data is now irreversibly gone from the UI

Practical recommendation: if you're configuring a new GA4 property (or auditing an existing one), the first thing to check is whether BigQuery Export is enabled and running as streaming (not just daily export) — after that, you can run any SQL analysis directly against the raw data.

-- Quick check in BigQuery: purchase events missing currency (a tracking-error signal)
SELECT
  event_date,
  COUNT(*) AS purchase_events,
  COUNTIF(
    (SELECT value.string_value FROM UNNEST(event_params)
     WHERE key = 'currency') IS NULL
  ) AS missing_currency
FROM `project.analytics_XXXXXXXXX.events_*`
WHERE event_name = 'purchase'
  AND _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'
GROUP BY event_date
ORDER BY event_date;

Practical checklist for migration or GA4 verification

• [ ] Check that all key e-commerce events (view_item, add_to_cart, begin_checkout, purchase) have a complete set of parameters, especially currency and value
• [ ] Verify item_id is consistent across the entire purchase path
• [ ] Set data retention to the maximum (14 months) right at project setup
• [ ] Enable BigQuery Export (streaming) before you need it for historical analysis
• [ ] Redefine conversions (Key Events) from scratch — nothing migrates automatically from UA
• [ ] Rebuild remarketing audiences in Google Ads — old UA lists don't migrate on their own
• [ ] Warn stakeholders that year-over-year comparisons across the migration point will have methodological noise, not just business noise

TL;DR

• GA4 is a different data model than UA — everything is an event, sessions are derived, not primary
• E-commerce tracking requires the items[] structure and complete parameters (currency, value, consistent item_id) — a missing currency on purchase silently breaks revenue reports
• The default attribution model is data-driven attribution, not last non-direct click — per-channel conversion numbers will differ from UA not due to error, but due to methodology
• Historical UA data doesn't migrate automatically — if there was no prior export, it's irreversibly lost from the UI
• Enable BigQuery Export immediately and treat it as your primary source for deeper SQL analysis, not just a backup