Differences between Traditional Google Analytics and Google Analytics 4

UPDATE (Oct 22, 2020):
This post has been updated to include additional features announced this week.

Since you’re reading this guide, it’s likely that you have spent quite a bit of time working with legacy versions of Google Analytics, and it’s also likely that you’re feeling intimidated by how different Google Analytics 4 (or GA4) appears to be.  The purpose of this post is to introduce you to the new concepts that differentiate GA4 from it’s predecessors, and also give you confidence that it a big step forward from what you are familiar with.

From Universal Analytics to Google Analytics for Firebase


Google Analytics 4 is a completely new version of Google Analytics that builds on top of three technologies that Google has been developing for the past few years:

  1. Firebase Analytics, which leverages the event-driven data model to better describe behavior, measure user engagement, and seamlessly roll-up data across websites and mobile applications.
  2. Google Signals, which allows you to use Google’s identity software to recognize users who are not logged-in. 
  3. The global site tag, which allows you to enable features that require code changes to a website without modifying tags.

Each of the three items above is designed to solve a problem with the legacy versions of Google Analytics, so lets talk through each of them:

The Problem that Firebase Solves

If you’ve attempted to use the old Google Analytics mobile SDK or even install traditional Google Analytics on a single page web app, a piece of your heart already knows that these tools sometimes attempted to fit a round peg into a square hole.  The fact is, apps are more variable than traditional websites, and the assumptions that we make about how users experience the web do not always hold true for how users experience a mobile app. 

As an example, if you’re a runner you might open a mobile app to track your speed and let it run in the background for hours.  How many sessions should that create?  Should every time you unlock your phone to check your pace be counted as a screen view?

Because it is built on top of Firebase Analytics, Google Analytics 4 simplifies the page view/screen view concept with a more flexible system of events and parameters.  I refer to the new design as an event-driven data model.

Hit types like custom event and pageview are are consolidated into events

Yes, you can still use page views and screen views where it makes sense, but these are no longer the fundamental building blocks that they used to be.  This is important because mobile apps are made up of a series of “activities” (things you can do) rather than “pages” (things you can see), and it can be unintuitive to try and use the concept of a screen view to describe the experience a user is having within your app.

These benefits may sound unclear at first, but once you start going down this rabbit hole you’ll begin to notice ways that this approach actually works better on traditional websites as well.  Think about the way we would track a purchase with traditional Google Analytics.  The standard approach is to wait for a thank you page to load, set all of the transaction data as dimensions/metrics, and then fire a page view tag to pass all that data along (as demonstrated below). 

A traditional ecommerce hit

But there are really two events happening in this scenario that are being crammed into one: the purchase event, and the thank you page view event. 

Also, the transaction data really only describes the purchase event, whereas the typical page information (page title, etc) really only describes the page view event.  Separating this into two events with their own parameters would be a more accurate representation of the actual activity occurring on your website.

Google Analytics for Firebase sets two events where Universal Analytics would have combined them into a single pageview

The event driven data model solves this problem by allowing you to create an event for any activity that you would like to record, and then attach the parameters to that event that are necessary to describe it. 

Unlike Universal Analytics, GA4 can batch multiple events into a single hit. As a result, GA360 users do not necessarily need to worry about the cost of sending a high volume of events to GA4 properties, and there is no need to cram multiple actions into a single event.  Building on the example above, if you happen to have a checkout flow without a thank you page this is no problem, you just fire the “purchase” event.

As you will see, this event and parameter approach is an improvement for both traditional websites and mobile apps.  And, bonus, since GA4 uses a common data schema on websites and mobile apps you can roll up that data into nice dashboards for reporting purposes!

While we’re on the subject of cross-device reporting, let’s also discuss the next technology that Google Analytics 4 leverages: Google Signals.

The Problem that Google Signals Solves

I’ll keep this section short because I’ve already written a lengthy post about Google Signals and Privacy in Google Analytics 4, but the tl;dr is:

With the integration between Google Signals and Google Analytics 4, all of the reports in your GA4 property can leverage Google’s ability to identify users who visit your website or app multiple times from different devices (as long as they have enabled ad personalization)… even if they are not logged in.

This is a big deal because it means that you can get a very accurate picture of the behavior of a small subset of users on your site or application (those who are signed into Google and have opted-in to Ads Personalization). Google’s ML can then apply machine learning against the behavior of this subset to fill the data gaps that we know exist in the larger population, with a process they’re calling conversion modeling.

The legacy versions of Google Analytics did not handle the recent moves by browsers to restrict cookies. Using this solution, Google is able to embrace privacy without degrading the value of the work that we do as Analysts.

If you’re interested in learning more about this, take a look at my article above. Otherwise, let’s move on to gtag.

The Problem that gtag Solves

I was in the audience at the 2017 Partner Summit when Google announced the release of the global site tag, and many of us in the room that day were confused. After all, isn’t Google Tag Manager the recommended way to install Google marketing tags?

Three years later, with the release of Google Analytics 4, it’s starting to make sense. Here’s why:

The Analytics.js file that we used with early versions of Universal Analytics was a static file. It was identical for every website in the world that used Google Analytics. The global site tag, however, dynamically builds a javascript file for a measurement ID.

This means that Google can add features to in the user interface that actually change the code that is installed on your site… like this:

That’s a big deal, because it means that you can flip on cross-domain tracking or Enhanced Measurement features like video tracking in the interface, and automatically Google will deploy code to your site without the need for new tags.

This is why Google can claim that GA4 reduces the time that Analyst’s need to spend collecting data.

So those are the three big differences between traditional Google Analytics and Google Analytics 4, but I’m sensing that you have one final question:

Can I just use GA4 properties on my mobile apps and keep traditional GA on the web?

Google sort of forced us all to migrate our mobile apps to Firebase Analytics and GA4 from the old mobile app SDK back in October 2019, but you still have a choice on the web.  By now you can probably guess that I’m going to recommend that everyone add Google Analytics 4 to your website.  Even if you do not have a mobile app, you should install GA4 on your website simply because: it’s free, it’s better, and you’re going to need to familiarize yourself with it because the industry is moving in that direction.

However, you don’t have to pull the plug just yet.  Keep your traditional Google Analytics tracking up and duplicate your data to a new GA4 property at first.  Use this guide to help you set up reports and start digging into the data, and send me suggestions on how to improve this content.

13 Replies to “Differences between Traditional Google Analytics and Google Analytics 4”

  1. Thanks for the article. Very helpful. Regarding the comment “Unlike GA360, GA4 can batch multiple events into a single hit. As a result, there is not necessarily a cost for sending a high volume of events to GA4 properties”.

    What is the current “cost” of sending a lot of event data to regular Google Analytics?

    1. Cormac, that sentence should actually read “Unlike Universal Analytics…” (updating that now). I was referring to GA360 users who need to keep hit counts low to avoid expensive charges.

  2. If you’re setting up a brand new property but still want to use old Google Analytics (Universal Analytics) is there a way to do that? Seems like you’re forced into GA4 by default.


  3. Hi,
    thanks for your article.

    I have no idea about this stuff, own a website and we always had GA (universal). Now we got GA4 and now I am seeing the data in GA4 but universal ha stopped showing data. I see users, seassons, etc in GA universal until 19th January, and from that onwards I see no data al all. And I see it in GA4. But I would like to keep seeing it on universal as I am used to the tools and reports.

    Would appreciate any thoughts,

    1. David, you’ll need to make sure your tags are configured to send data to both properties (the new GA4 and the old UA). If you’re using a CMS plugin to add Google Analytics to your site then you’ll need to make this request from them.

  4. Hi Ken, thank you for this detailed and useful guide on GA4. I think it will be quite difficult to switch form session logic to hit logic.
    I have a question for you, but related to firebase analytics (same of ga4 more or less). I hope you can help me anyway.
    I have created a custom parameter dimension that fire with sreen_view event, but I need this custom dimension available acorss all the events, e.g add to cart, purchase .. in universal analytics I could use ga settings variable and use it in all the events. How can replicate this behavior with firebase analytics?

    1. Eleonora – I’m assuming that you’re using Google Tag Manager for web since you previously used the ga settings variable. You can think of the configuration tag as a combination of the old ga settings variable and a page_view event. Parameters that you set with this tag will be set with all subsequent events that fire on the page.

      1. Thank you Ken for your reply.
        Yes, I’m using GTM for web, but I have the same issue with an APP.

        If a use ga4 configuration tag there isn’t the possibility to add custom parameters.
        It is possible only in the GA4 event tag, right?
        Thank you 🙂

        1. This isn’t very clear in GTM, but to set event parameters in the GA4 configuration tag you add them under “Fields to Set”. You can verify that they are setting as event parameters by enabling preview mode looking for them in the network request. If they’re working properly you will see them with the prefix “ep.”.

    1. The current recommendation (from both me and Google) is that you run both side by side for at least 6 months or so. This will give you time to learn the new tool, wait for some upcoming releases to come out, and continue month over month reporting before you fully make the switch.

Leave a Reply

Your email address will not be published.