Many analysts who are familiar with the legacy versions of Google Analytics have a difficult time adjusting to Google Analytics 4. The purpose of this post is to introduce you to the new concepts that differentiate GA4 from its predecessors.

Overview

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

The prior version of Google Analytics (called Universal Analytics) was released in 2013. At the time, single page apps were extremely uncommon (React JS was released later that year), and people still navigated the Internet by loading 1 page at a time.

If you’ve attempted to install a previous version of Google Analytics on a single page web app (or use the old Google Analytics SDK in a native app), a piece of your heart already knows that these tools sometimes attempted to fit a round peg into a square hole. 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 or single page app.

As an example, if you’re a runner you might open an 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?

Google Analytics 4 simplifies the page view/screen view concept with a more flexible system of events and parameters because it is built on top of Firebase Analytics (in this blog I refer to this new design as the "event-driven data model"). The concept of a "hit type" has been removed. Instead, when something important happens you track it with an event.

Every event has a name, so you can choose to name an event "page_view" or "screen_view". As a result, the concept of a page view still exists and you can continue to use it when it makes sense, but it is no longer the fundamental building block 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 page view (or "screen view") to describe the experience a user is having within your app.

These benefits may sound insignificant 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 as apps. 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).

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.

Do you have a checkout flow without a thank you page? No problem, you can just fire the “purchase” event.

The event driven data model solves this problem by allowing you to create an event for any activity that you would like to record. Any information that describes the event is set as an event parameter, and any information that describes the user is set as a user property.

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 and authenticated to their Google account)… 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 subset of users on your site or application (those who meet the criteria above). 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.

By comparison, the legacy versions of Google Analytics did not do anything to repair the fragmented data collected by browsers that restrict cookies or other forms of storage. Using Google Signals and conversion modeling allows GA4 to respect user privacy without degrading the value of the Analytics reporting that marketers depend on.

If you're interested in learning more about this, take a look at my article above. Otherwise, let's move on to the third new technology that underpins GA4: the Global Site Tag (also known as "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 is why:

In legacy versions of Google Analytics, all websites shared the same javascript file known as Analytics.js. This was a static file that was loaded into your browser whenever you loaded a page with Google Analytics installed.

With GA4, rather than requiring every website in the world that uses Google Analytics to share a single javascript file, the global site tag dynamically builds a javascript file for each 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 change, and in many cases it greatly simplifies the work of installing GA4 while improving the quality of the data it collects. You can use the settings interface to flip on cross-domain tracking for sites that span multiple domains, or enable Enhanced Measurement features such as video tracking. When you do this, Google will automatically 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?

No. You cannot create Universal Analytics properties any more. But don't worry. It’s free, it's easy to install, and it provides better conversion reporting than any other Analytics tool currently available.

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.