Measurement Changes in Google Analytics 4

What GA4’s new measurement framework means for marketers

This is the third blog in our seven-part Google Analytics 4 Migration Guide series. The series focuses on how businesses can accelerate their move to GA4 ahead of looming sunset deadlines — to gain a competitive edge by mastering the GA4 platform’s next-generation data-driven marketing capabilities. You can read the full Guide here.

In the first two installments, we covered how to create a framework for migrating to GA4 and how to actually create properties and add data streams. Now, we will cover some big changes between Universal Analytics and the new GA4 platform.

GA4 is based on a new data schema, meaning its measurement framework differs from the one being used by UA. Until now, best practice was to deploy the code for UA and keep the same — or a fragment — of code to feed a GA4 instrumentation. The complexity of the migration would depend on the tagging method.

Data Collection Planning

Before instrumenting your GA4 tagging, you must create a comprehensive measurement plan specifying what data you’re going to collect and how it will be collected. If you plan to migrate all UA tracking to GA4, you should pay close attention to the following:

• Pageview or virtual pageview tracking
• Events
• Custom dimensions
• eCommerce data
• Other parameters (e.g., user ID)

The type of questions being asked will depend on the data type you’re going to migrate. With pageviews, for example, you must determine if only default URL parameters are being used, if they’re being modified (e.g., page title, page URL, etc.), or if virtual pageviews are being tracked with any associated custom parameters. 

Measuring events in GA4

Event measurements differs in GA4, requiring additional consideration to determine whether the event is captured automatically or via Enhanced Measurement; and whether it belongs to the list of recommended events or if it will be a completely custom one. According to what we know about the new data model, recommended events should be prioritized, since this approach will enable greater flexibility in populating reports and/or featuring associated parameters. 

For example, a typical decision-making flow for finding an equivalent of a UA event will look like this:

After composing a list of events to be captured and their proposed method of implementation, the next step is to review their standard parameters (i.e., Event Category, Event Action and Event Label), skip redundant ones (if event category and action are the same), and match the rest of them to the new data model. 

Most likely, you’ll want to capture one of them as an event name in GA4 (e.g., event action from UA would be the event_name) and map two others to custom parameters in GA4. Those could be generalized “event_category” and “event_label” dimensions or dedicated event-specific parameters. 

For instance, in the below example of the UA-based event-tracking taxonomy, it would make sense to track the “event_name” as “product_image_click” and pass the name and SKU of the clicked product as either “event_label” parameter (which would work for all other UA events as well) or create an event-specific one (e.g., ‘product_name_clicked”).

Mobile app owners linking one or several Firebase projects to their GA4 property have one additional step: If you’re tracking the same events for web and app users, you need to make sure that these events are consistent in namings, associated parameters, have unified taxonomy of parameter values, and consistent data format. For example, the “ecommerce_purchase” event in the app should be aligned with the “purchase” event on the web to benefit from detailed Monetization reports and possible future updates. 

GA4 offers greater flexibility in managing automatic and custom events using the Modify Events and Create Events features in the data stream settings. If you wish to create a new event based on an existing one and any associated parameter values, you don’t need to instrument this event in the code or in GTM additionally. 

Instead, this can be done directly from the GA4 interface. It’s also possible to reconfigure an event to be used with particular parameters or in particular scenarios. For example, creating a form_submission_success captured when your key website form is submitted: 

Data mapping for ecommerce tracking 

Data mapping for ecommerce tracking is a top priority for every revenue-generating business. The new GA4 ecommerce schema provides pre-defined (recommended) events for each funnel step and is enriched with additional product-related information. The majority of this information is comparable to Enhanced Ecommerce feature details in UA. You can choose to maintain the existing taxonomy — or take advantage of the updated and enhanced GA4 reporting capabilities.

The difficulty of migrating ecommerce tracking depends on the tagging method. The below table illustrates how UA enhanced ecommerce actions (analytics.js, GTM) map to GA4 recommended events:

Once you analyze the current Analytics events, you can determine which GA4 events they should be translated into — and then ingest those into the measurement plan accordingly.  

Custom dimensions and metrics

One final important measurement consideration is to include custom dimensions and metrics for collecting additional attributes of users, pages or interactions. Replicating them as corresponding custom definitions in GA4 is pretty straightforward. However, GA4 does not currently allow you to set session- or product-scoped custom dimensions in the new tool. You may want to convert some of those into user properties or event-level parameters. Otherwise, future updates to GA4 will almost certainly replicate this functionality. 

Some standard event parameters, such as event category and label, can also be considered custom dimensions in the new tagging plan — either by creating two new dimensions for all events (“event_category” and event_label”) and/or registering them as event-specific dimensions for particular events (e.g. translating an event label for the “button click” event to the “clicked_CTA” custom parameter that will only be used with this event). You should be mindful that this approach may impact your quota of custom dimensions/metrics.

Tracking a custom dimension of an automatically collected event may require you to revisit the tagging plan and instrument a custom event instead. Please be sure to check a list of automatically collected events and their associated default parameters. When you need to collect any of these captured data parameters, you don’t have to implement them additionally, but rather create a new custom dimension in the interface.

Code instrumentation

Once again, the difficulty of migration here largely depends on the tagging method. There are significant differences between how GA4 can interpret GTM/dataLayer code, analytics.js or gtag.js syntax.

If your website is tagged with the gtag.js code syntax, implementing GA4 will require adding the new measurement ID in the code or connecting GA4 to the existing UA property (with some limitations). However, doing this will not provide you the full-fledged capabilities of the new tool as the UA-based syntax of gtag.js still differs from the one being used in GA4:

• UA events will get translated to GA4 events according to a set of rules (event action from Analytics will become event_name in GA; the rest of the event-related dimensions will be converted into custom parameters);
• UA e-commerce events will mostly translate into GA4 e-commerce events, with a few exceptions; selecting a product from the list, and some checkout tracking events will not work in the new platform;
• UA product-related data will translate into GA4 product information, but your implementation will lack some GA4 capabilities if you use the UA schema (product-level affiliation, currency, discount, list, category hierarchy, location);
• UA custom dimensions and metrics will translate into GA4 custom parameters — except session-  and product-scoped ones, which don’t have an equivalent in GA4;
• Configuration settings (user ID, cookie settings, disabling ad personalization, etc.) will not work with default settings in GA4.

Using GTM as a tagging solution

If you plan to use GTM as a tagging solution, it will give you greater flexibility to deploy both analytics solutions in parallel. It is possible to keep the dataLayer intact and to continue sending data to a Universal Analytics property. 

It’s also possible to repurpose the data to stream into GA4. The basic measurement (pageviews) is provided with out-of-the-box GTM tag setup, while some custom (events) and advanced measurement (ecommerce) can be adjusted with additional configuration in GTM. There will be some limitations as well:

• Product-related data in the dataLayer will translate into GA4 product information but the code implementation will lack some GA4 capabilities (product-level affiliation, currency, discount, list, category hierarchy, location).
• Session- and product-scoped custom dimensions and metrics will not be reported in GA4.

Essentially, your GA4 tracking will be working based on the UA measurement framework. You may consider replacing the code syntax in the future to comply with the GA4 schema once you have development resources available. 

If you can’t currently deploy the dedicated GA4 schema, there is also an option to enrich your dataLayer implementation with some GA4-specific parameters to fully benefit from the new tool capabilities (e.g. item_category parameter hierarchy, discount, affiliation, and item_list parameters in the ecommerce implementation).

For website owners still relying on analytics.js or ga.js in their Analytics tracking, the path to implement full-fledged GTM or gtag.js code is rather resource-intensive. This approach requires using two versions of the code running simultaneously until UA is sunsetted. Some of the analytics.js interactions can still be captured by GA4 automatically, but this doesn’t cover the necessary minimum of the data that should be collected in Analytics.

As a summary, the table below is provided to give a high-level action plan for each scenario of UA instrumentation:

UA Measurement Improvements

As the switch-off of UA nears, it makes less sense to invest in the UA measurement infrastructure. The rule of thumb would be deploying all tracking enhancements to both platforms concurrently, as you’ll be left with only GA4 by 2024. Fortunately for Tag Manager users, there will be very little extra effort to deploy new tracking to UA and GA4 concurrently. 

However, complications do arise if you plan to use GTM or gtag.js only for GA4 while your existing UA implementation is using a legacy syntax such as analytics.js.

Regardless, some businesses might want to enhance their current UA tagging despite having analytics.js because:

• They need additional measurement in the short-term while their GA4 setup isn’t ready;
• The requested use case isn’t available in GA4 or can only be used to widen UA data;
• Collected data needs to be activated in other tools that still depend on UA.

Should you adjust your UA measurement — or just focus on GA4?

Although there is no single recommendation here, you’ll need to weigh the benefits you’re getting from this initiative. If the time of the implementation is longer than the possible duration of usage, it’s likely a waste of resources. Likewise, if the business value of the incremental data is low, you may have to give up this idea as well. Yet in many cases, a 15-month period is considerable enough to enrich and leverage your UA data foundation before the full turn-off.

Next Up: Linking GA4 to Google Marketing Platform Products

In the next installment of our seven-part series, we’ll provide detailed guidance on how you can link your GA4 properties to other Google Marketing Platform products — effectively leveraging Google’s ecocystem to gain greater context on user journeys across the web. We encourage you to check out the full Google Analytics 4 Migration Guide here: