GA4: Events, and Parameters, and Bears, Oh My!

by Ricardo Cristofolini

As promised in our last post, 8 Key Differences between GA360 and GA4 we’re (Ricardo and Rob) back to talk about Events and Parameters in GA4.

So far we mentioned a couple of times the new Data-Model (event-based) and how that is different compared to Universal Analytics (Session-based). Here, we’re going to dive deeper to understand what are those events and parameters, a couple of examples, and types.

Events and Parameters

Event is data that represents a user interaction that your site or app sends to Google Analytics. For example, button click or form completion. Parameters are additional pieces of information that can further specify the action the user took, or add further context to the event. It’s a similar concept to custom dimension in Universal Analytics. For example, a parameter can be used to describe the value of purchase, or to provide context into where, how, and why the event was logged.

It’s important to note that some parameters such as page_title (web), are sent automatically. In addition to that, you can log up to 25 parameters with each event. Certain parameters, while automatically collected on your website, may not be automatically collected in your app, and vice versa.  For example, while page_title will be collected on both your app and website automatically with each hit, ad_click is only automatically captured in your apps.

Practical Example

For a Lead Submission we would have the following Data Model when dealing with Universal Analytics:

Hit – Event

Category – Lead Submission

Action – Referrer

Label – High Potential Value

Custom Dimension – October 2020

Now, in GA4, there is no set hierarchy and you’re not limited to only three built-in descriptions on Event Category, Action, and Label. With GA4, the only requirement is the Event Name. The structure will be:

Event – Lead Submission

Parameter – Referrer

Parameter – High Potential Value

Parameter – October 2020

Parameter – Viewed Demo

Where Parameter is the default name provided by Google or whatever name you want – keeping in mind that, if that’s a custom name, it will count towards the 25 limit mentioned above.

Is the Data Layer going to be affected by this change?

The answer is: It depends. Are we looking into a long or short-term solution?

Let’s take a look at the two Data Layer structures.

Universal Analytics:

dataLayer.push({    ‘event’: ‘gaCustomEvent_leadGeneration’,    ‘eventCategory’: ‘Onsite Lead’,     ‘eventAction’: ‘Get a quote’,    ‘eventLabel’: ‘Success’,    ‘userID’ : ‘[USER ID]’,    ‘userLanguage’: ‘[USER LANGUAGE]’  });

This structure works fine with both Universal Analytics and GA4, so if you don’t have the development resources, time or money to start working on these modifications, you don’t have to worry about that. Also, it’s important to highlight that, for a Dual Deployment (where you are going to run GUA and GA4 in parallel) this is the best Data Layer approach.

Now the specific GA4 structure would be like this:

dataLayer.push({    ‘event’: ‘gaCustomEvent_leadGeneration’,    ‘parameter’: ‘Onsite Lead’,    ‘parameter’: ‘Get a quote’,    ‘parameter’: ‘Success’,    ‘parameter’: ‘[USER ID]’,    ‘parameter’: ‘[USER LANGUAGE]’  });

And following our previous example, the GA4 specific Data Layer would look like this:

dataLayer.push({    ‘event’: ‘lead_generation’,    ‘location_lead’: ‘Onsite Lead’,    ‘action_taken’: ‘Get a quote’,    ‘quote_status’: ‘Success’,    ‘user_id’: ‘[USER ID]’,    ‘user_language’: ‘[USER LANGUAGE]’  });

Of course, the actual name of the parameters will depend on your reports in GA4. Just keep in mind that GA4 has a standard on the event names, so you should use user_language instead of userLanguage, for example.

This is the new structure that Google is providing based on the Event base Data-Model. In order to update your Data Layer to this new structure, you have to keep in mind that some KPIs and previous implementation may not translate perfectly into this new code model.

The Data Layer where you have Event Action, Category, and Label will work for either property, Universal Analytics and the new GA4.

Now, the new Event-Based Data-Model Data Layer structure may work with GUA as well, but keep in mind that the GUA Data Layer has Event Action, Category, and Label and GA4 are strictly Parameters.

So, I’ll just use the latest one, right? It’s the latest… should be the best

Well, not quite. Using one specific Data Layer model won’t solve all of your problems at once. Each one of those has a specific configuration you have to keep in mind. For example, if you decide to use GA4 modeled Data Layer, GUA won’t know what is the Event Action, Category, and Label. That means you will have to configure GTM to pass those values somehow to GUA.

However, one nice approach to that is to use the GUA Data Layer and add an “event” custom dimension in the GUA Data Layer that can be used in GA4.

How that will end (which Data Layer you will choose), is up to you, but we recommend the first option.

Does that mean that I have to update my Data Layer values?

At the moment, no. The information we’re providing here is for you to be aware of the changes and the new build. Your current Data Layer structure can be used in either GUA and GA4 properties. However, the GA4 Data Layer structure can only be used in the GA4 property so, unless you’re planning on going full GA4 without a GUA backup, this may not be the best approach for the moment.

Still, this is what you will have to consider in the future.

Event Types and User Property in GA4

Event Types and User Property in GA4

Within the new GA4 property, four event types were introduced.

  • Automatically Collected Events divided into:
    • App and Web (i.e. first_visit)
    • Only Apps (i.e. first_open)
    • Only Web – (i.e. video_start)
  • Enhanced Measurement Events (web only)
    • Collected automatically if enabled when creating a new stream in GA4. Those are, scroll, page_view, outbound click, video engagement, file download, and site search)
  • Recommended Events
    • Implemented by yourself, but that have Google-predefined names and parameters based on specific markets, for example. Jobs, Education or Real Estate.
  • Custom Events
    • Events that are named and implemented by you

Regarding User Properties, those are sticky properties that don’t change once they are set. Those are divided into:

  • Default User Property
    • Attributes that can be used to describe segments of your user base, such as language preference or geographic location. Once you have the SDK or gtag.js in place, those are automatically logged.
  • Custom User Property
    • For additional data collection, it’s possible to set 25 extra custom user properties.

What about Google Tag Manager and GA4?

If you’re looking to start or keep using your current GTM container to track events for the GA4 property, there are a couple of things you will have to consider before having all the data.

Tag Configuration

Some configuration in the tags will be necessary as, before, there were two types of tracking: Page View and Event. Both would use the Google Analytics: Universal Analytics tag. Furthermore, custom dimensions and metrics would have to be passed with the GA Settings variable.

Now, for the GA4 tagging, there are not tracking types anymore, but tag types. Those are GA4 Configuration and GA4 Events. Custom dimensions and metrics now are being passed with the tags as Field to Set in the Configuration one (for page load) and Parameters for Events (for custom events).

For more context on the latest configuration image, what we are going after is the following structure:

gtag(‘event’, ‘select_item‘, {  items: [{    item_id: ‘SKU_12345’,    item_name: ‘jeggings’,    coupon: ‘NAPKYN_SUMMER_FUN’,    discount: 2.22,    index: 5,    item_list_name: ‘Related Products’,    item_list_id: ‘related_products’,    affiliation: ‘Napkyn Store’,    item_brand: ‘Napkyn’,    item_category: ‘pants’,    item_variant: ‘black’,    price: 9.99,    currency: ‘CAD’,    quantity: 1  }],  item_list_name: ‘Related products’,  item_list_id: ‘related_products’});

Triggers are still the same so, no comments here.

How does GUA handle that?

If we look at GTM configuration for GUA, we would be dealing with a Tag that looks into a Google Analytics Setting variable that would hold all the custom dimensions and metrics.

Handling User ID

As mentioned before, GA4 brings a new perspective in order to understand the real user journey cross-devices. From an implementation and GTM perspective, userID still needs to be passed into a variable to be used later on in the reports. The most important thing here is, when aligning user ID implementation between Web and Apps, you have to make sure that the implementation is consistent. The same identifier needs to be used in both, so you can’t have a string in the web (i.e. “555321”) and an integer (555321) on the app.

Wondering about what all of this means for your historical data? Then stay tuned, that’s our next topic. 

In this Dual Deploy Checklist e-Guide we share 20 lessons we learned while drafting a measurement plan for one of the first dual-deployments of GA360 and GA4. You can treat this guide as a CHECKLIST when you go over your strategic measurement planning session to avoid inconsistencies between the platforms and KPI tracking. 


Ricardo Cristofolini

Implementation Specialist

I’m passionate about what I do. If you meet my manager or co-workers, they would say I’m a team player, engaged and always excited to learn something new. Like everyone else I have some flaws. However I’m not afraid to work around those to bring the best in myself and for the company.

See more posts from Ricardo