Millions of organizations around the world rely on Google Analytics to better understand their online visitors and create optimal experiences for them. So it is no surprise that when Google announced Google Analytics 4, (formerly known as Google App + Web) marketers and analysts had some big questions.
Google Analytics has been evolving since its genesis, and with the rise of mobile apps, shifts in consumer behavior, and the introduction of privacy regulations, this transition in the way we collect and analyze data is timely and warranted.
Google Analytics 4 offers a more complete cross-channel view of the customer – combining the insights we all know and love from Universal Analytics with the data model of Firebase to deliver seamless insights and data-informed decision making.
One of the primary questions on the minds of marketers, analysts, and developers is: What’s the difference? We’re going to break down the top 15 differentiators between the two platforms with an aim to give you a clear understanding of the new platform for better migration preparedness.
The most important change is at the heart of the platform: the data model. Universal Analytics has a session-based data model; within these sessions are various hit types. Most Google Analytics data is sent in the form of pageview hits and event hits, with some basic ecommerce data sent as transaction hits.
All data sent to Google Analytics 4 has adopted the Firebase data model in the form of events. Each event is distinguished with the event_name parameter, with additional parameters to describe the event.
In GA4 you’re no longer looking for the built-in Event Category/Action/Label taxonomy. Instead, the parameter will start with event_name, and you’ll add other parameters to describe the interaction. The following table illustrates how you might capture a newsletter signup in GA4 vs. GA Universal:
| Google Analytics Universal | Google Analytics 4 |
| Event Category: form Event Action: submit Event Label: newsletter-signup | event_name: generate_lead lead_type: newsletter-signup |
Because the GA4 event-based data model is more agnostic and flexible, each parameter can serve a more specific and meaningful role. Whereas Event Action and Event Label values typically rely on the Event Category value to be understood, the lead_type parameter is inherently more descriptive. Pageviews themselves are considered a type of event in GA4, with page_view as the event_name parameter.
For more on GA4 events and parameters, see About Events in the Google help docs.
Due to stronger regulations such as GDPR and CCPA, many organizations have had to sacrifice data to respect those who opt-out of tracking.
Google has released consent mode to allow you some level of tracking while still achieving compliance. It won’t help you target or identify users, but you can continue reporting content, conversions, and attribution.
In Universal Analytics, each tracking event is sent as an individual image beacon to Google servers. An Ecommerce website that sends data on all pageviews, interactions, product impressions can be a significant load on Google servers so Google has historically imposed hit limits on the free version of Google Analytics.
Example limits for the free tier UA include:
As of right now, these limits do not apply to GA4 properties.
GA4 utilizes a queuing system that Google developed so multiple events can be bundled together in the same network request which means less of a load on Google servers.
However, there are other limitations to be aware of in GA4. Google has imposed various limits on the number of distinct events you can track and the number of parameters per event, and the length of characters on those parameters. A full list of limits are documented here.
The enterprise level of Google Analytics Universal (GA360) offers higher data collection limits than the free version, and in the future we expect Google may introduce limit differences between the free and enterprise version of GA4.
Configuration Limits
GA4 lets you track an endless number of parameters with events but you will not be able to access each one from the interface. You will need to cherry-pick your top 50 text parameters to map as custom dimensions persisted in the reporting UI.
You can also map 50 numeric parameters as custom metrics, but most implementations need a far greater number of text parameters than numeric parameters, so you’re probably more likely to reach the limit of custom dimension slots than custom metric slots.
In any case, all event parameters, even beyond the limit of 50 text and 50 numeric persisted in the reporting UI, are passed through to BigQuery, where you can take full advantage of them for analysis, modeling, audience building, and more.
As you migrate to GA4, careful planning is needed to prioritize which parameters are going to be available in the reporting UI, and which will be available out-of-the-box. More on custom dimensions later in this post.
One trick for getting beyond the parameter limit is to concatenate multiple values in a single parameter. The sections below demonstrate how you would achieve this in a gtag or Google Tag Manager implementation of GA4
| gtag(‘event’, ‘product_interaction’, { ‘interaction_value’: ‘size selector:small’ // interaction type + interaction value }); |
Sites that have a high volume of traffic and high cardinality will eventually trigger “sampling” when you make a request that combines dimensions and metrics in a way that cannot be pulled from pre-aggregated tables. Sampling serves to balance Google’s ability to calculate complex reports while preventing excess use of computation resources.
The sacrifice that sampling entails is the size of the sample itself. Google Analytics Universal sometimes bases its on-the-fly calculations on as little as 1% of your actual data. If this 1% of data is not really representative of the full data capture, your reporting the data will present a highly skewed view of reality.
With GA4’s event-based data model and UI restrictions, sampling should be less of an issue, but more details on GA4 sampling will roll out over the course of the year.
A common problem in data accuracy in Google Analytics Universal has been spam referrals. With just the Google Analytics Universal property ID, it’s easy for bad actors to populate someone’s Google Analytics property with spam data using the Measurement Protocol.
Google has now made this virtually impossible with GA4 by forcing Measurement Protocol hits to include a secret key that is visible in the GA4 web data stream settings but is not available publicly. Only hits with a valid key can send data to a GA4 property.
User Identification has undergone an amazing update. In the current Universal Analytics property, a default view reports on anonymous/unknown traffic which was identified with the anonymous Client ID, which is read automatically from the _ga cookie.
If your website includes a logged-in state, you could then create a separate view that reconciles users based on the User ID value exposed in your data layer and populated into Google Analytics for authenticated users.
This somewhat either/or approach is not ideal in that it does not provide a single view of your data to take advantage of the multiple identifiers that can be used to unify separate sessions across individual users. The views based on User ID don’t recognize Client ID and sometimes don’t yield a lot of data.
GA4 instead takes advantage of a “fallback” approach with multiple methods to identify or dedupe unique users.
Note: Don’t be alarmed if your GA4 is reporting fewer Users than Universal: it’s doing a better job at deduping users across multiple devices – and across multiple data streams.
The new approach to sessions is another welcome change with GA4.
Currently, Universal Analytics will increment a session with any of these scenarios:
In GA4, a session_start will trigger on each new session. If 30 minutes have elapsed without the user generating any events, the next event that the user does generate will automatically generate a new session_start event.
This approach for calculating sessions in GA4 is comparable to the basic session calculation logic in Universal, but the other factors in Universal that also trigger a new session – namely, change in day or traffic acquisition dimensions – no longer apply. For this reason, GA4 may display fewer sessions than GA Universal for the same user interactions.
In our recent Google Analytics 4: Ask Me Anything webinar, we had a lot of questions about GA4 Custom Dimensions. Below, I’ve outlined each type of Custom Dimension and how you can map these from Google Analytics Universal.
Each type is illustrated with gtag and Google Tag Manager examples.
Hit-Scoped – these have been replaced by event parameters. Here is an example of setting a login method:
| gtag(‘event’, ‘login’, { ‘method’: ‘Google’ }); |
Be sure to register the parameter as a Custom Dimension so it can be used in the interface.
Session-Scoped – there is no direct equivalent but could be replicated by passing the value as an event parameter on all hits via the “config” command.
| gtag(‘config’, ‘MEASUREMENT_ID’, { ‘currency’: ‘USD’, ‘country’: ‘US’ }); |
Another option is to do analysis outside of the interface and build a custom “SQL like” statement with BigQuery.
User-Scoped – these have been replaced with custom User Properties for the benefit of creating audiences.
| gtag(‘set’, ‘user_properties’, { favorite_composer: ‘Mahler’, favorite_instrument: ‘double bass’, season_ticketholder: ‘true’ }); |
Be sure to register the User Property so it can be used in the interface in audience creation, report comparisons, and the custom report templates.
Product-Scoped – these are likely replaced by item parameters but not officially supported.
Content groupings reporting is not available in GA4. This reporting feature corresponds very closely with hit-scope custom dimensions in Google Analytics Universal. In Google Analytics 4 you can take advantage of event parameters and custom dimensions to basically replicate the content groupings that we know from GA Universal.
In Google Analytics Universal, you can capture custom metrics directly, meaning that you send numeric data with an event or pageview hit explicitly as a custom metric.
Similar to GA4 custom dimensions, it’s the mapping of an event parameter that determines if it will be treated as a custom metric. For instance, in the example below, we’re tracking the 25% milestone on a video as a numeric event parameter.
| gtag(‘event’, ‘video_progress’, { ‘milestone_25’: 1, ‘video_title’:”cat playing with yarn” }); |
From within the All Events report, you can map this event parameter as a custom metric to be incremented each time a user generates a GA4 event containing this parameter:
GA4 does not offer specialized view functionality. Reporting occurs at the property level, which is essentially your master view. For example, there is no equivalent method to isolate your blog traffic from your main site. I generally agree with this approach; views often distort the data and in most cases you only need a single view anyway.
However, there are certain things that views were good at like being able to fix data issues, lower casing values, rollup views, and stripping parameters – all capabilities that are missing in GA4. This means that, as of right now, data collection code (or tag manager) needs to fulfill this function for GA4.
Google is expected to address views through a new set of features, but that may only be offered to those using the paid version.
Many organizations have regional domains, language differences, or different departments that require rollup reporting. There is currently a bit of uncertainty around this feature in GA4, particularly in regards to the equivalent of the rollup capability in Google Analytics Universal 360, which allows you to integrate multiple website properties through an admin setting only, without having to actually deploy the same tracker across those properties.
Here are a few factors to consider when deciding what sort of property or rollup structure is best for your organization:
As the rollup capabilities in GA4 continue to evolve, data-stream-based, property-based, or admin-based approaches may emerge. For now, refer to the account architecture guidance from Google, and stay tuned for a detailed dive into global rollup reporting in future articles from Cardinal Path.
Cross-domain tracking has proven to be a bit challenging to set up in Google Analytics Universal, in part because it required changes at both the tracking and admin levels. As a change that will surely be welcomed by many, cross-domain tracking in GA4 promises to be a much simpler proposition. It is configured through admin settings only and without changes to the on-page tracking.
As an important note, the alert on the page informs us that if we are maintaining dual tagging for GA Universal and GA4, we must specify the same domains for cross-domain tracking.
Also note that since GA4 cross-domain tracking is still in beta, and will likely benefit from future refinements to the feature.
Jumping into GA4 is going to take some getting used to! The interface will look familiar but replicating specific tasks that you performed in Universal will initially come with a bit of a learning curve. You may also find that some Universal reports have no direct equivalent in GA4. While GA Universal emphasizes built-in reports, GA4 is more oriented towards custom reporting templates and analyzing and activating the datasets on other platforms (particularly BigQuery).
While some standard reports are available, you may find yourself abandoning them for something custom. The Analysis Hub has some great features but there is only one visualization for each tab, so it might be challenging if you are used to the custom reports within Universal.
The alternative for the time being is to export data to Big Query or use Data Studio to transform the data in a way that is more comfortable to you.
GA4 has made the most common tracking available out-of-the-box with little to no configuration required. In Universal Analytics, enhanced measurement tracking typically required custom GTM configuration, but is now standard for all GA4 properties. While this should be plug-in-play for most websites, you do have the option to disable.
Be sure to review the events that populate with this feature.
With the data model driving the key differences between the two platforms, transitioning to Google Analytics 4 is not merely an upgrade, but a brand new way of collecting and analyzing the data.
While the platform continues to evolve, we are currently recommending that you implement dual tagging across your websites to start collecting GA4 data alongside your Universal property, taking advantage of the unified data model and user identification across web and mobile apps. There are already so many essential insights that GA4 offers, and we look forward to the continual roll-out of features that lead up to the full transition from Universal Analytics.
Now is the time to start planning and activating your migration and ramping up your team’s skills and knowledge. Explore our GA4 services to ensure your team is getting the best start on this new platform, and stay tuned to our blog and quarterly Google Analytics 4: Ask Me Anything webinars to stay up-to-date on changes.
As consumers become increasingly digitally savvy, and more and more brand touchpoints take place online,…
Marketers are on a constant journey to optimize the efficiency of paid search advertising. In…
Unassigned traffic in Google Analytics 4 (GA4) can be frustrating for data analysts to deal…
This website uses cookies.