Intro
In our last article, we talked about how Google Analytics 4 (GA4) is different from Universal Analytics (UA) and what are its benefits/drawbacks, taking into account both the standard Universal Analytics and 360 account holder.
With the arrival of GA4 many are concerned about the radical changes within the tool, one of the most commonly raised concerns being that, for smaller businesses who don’t necessarily have dedicated analysts, the accessibility of reporting is now significantly more challenging when compared to Universal Analytics.
However, while this might be true in one sense, we have to consider that, on the other hand, accessibility to certain reporting has increased for these smaller businesses, as GA4 has reduced reliability on developers for certain basic reporting, through features like: being able to set cross domain tracking in the interface, having some automatically collected events, and being able to generate or adjust some events from within the interface. All of these actions used to require changes in the Tag Management System and often the involvement of a TMS developer.
One of the features that we find very beneficial, to smaller or larger businesses alike, is the ability to modify/create events directly within the interface. This article will focus on detailing how the event modification functionality can be used to both enhance your reporting capabilities and improve your data quality.
The Why and How of Event modifications
As we’ve previously mentioned, one of the goals of Google Analytics 4 (GA4) is to enable businesses to gain a harmonised view of their users across both app and web. GA4 was built with bundled app and web tracking in mind. However, if you already had a Universal Analytics (UA) implementation for web and for app:
- you might not have designed your tracking with bundled reporting in mind (given that at the time Google was recommending tracking in different properties).
- you have most likely not accounted for custom metrics in your initial Firebase implementation. As the implementation would have been via a Tag Management platform, where custom metrics would have been created based on other parameters of the event.
If you have a Universal Analytics implementation for your app, using Firebase + GTM (Google Tag Manager) implementation, the set-up used to be like this:
App developers would implement the Firebase events, those would then be intercepted and processed through GTM and sent from there, in the right format, in Google Analytics. The Tag Management System was a mandatory step in this process. There was no bypassing it. However, with GA4, the data pulls through straight from Firebase into the GA4 interface:
The Tag Manager System has been made optional. It can still be used to modify/create/block events (based on the existing ones and their parameters), but it has essentially been rendered useless since these functionalities have also been made available directly within the interface, meaning analysts can now shorten the path to:
- setting up a custom metric,
- splitting an event into multiple events (based on parameter values),
- fixing mistakes in parameter names/values or
- adjusting naming conventions to match between web and app.
Let’s go through some example scenarios where the modify events functionality would come in handy, either for adjusting app events or web events:
When you created the Firebase Events for Universal Analytics, you did not specify a parameter that would be incremented by one, in order to use it in a custom metric. That’s because in UA:
-
- you had the option to create a goal based on the event category/action/label which could then be used as a standalone metric in any report
- given that the implementation was done in GTM, you would create a custom metric in there rather than asking the app developer to pass extra firebase events.
Now, in GA4, that becomes challenging because, even though you can mark events as conversions, you can’t actually use them as standalone metrics in Explorations (if you mark them as conversions they can only be used as standalone metrics in standard reports.
In exploration, unfortunately, there is currently only a general “Conversions” metric that would include all of your events which were marked as conversions.
You, therefore, need to create a custom metric for it and that’s where the modify event functionality comes to the rescue. Let’s say you already had a sign_up event firing in your app and you’d like to create a metric based on that event (see screenshot below):
NB: this modification is done per Stream, therefore, if you have an IOS and an Android app you’ll have to create this modification rule in each stream separately.
Once you have created the parameter, all that’s left to do is create the metric which will be based on this parameter and you’ll then be able to use it in your explorations:
This method significantly shortens the process, especially considering how long it can be to get changes made in an app and then into production.
If you track transactions on your website but you have products which are available only to new customers and other products which are available only to existing customers. When the transaction event occurs you have a custom parameter showing the type of customer that made the purchase. If you don’t want to only report on total transactions in your explorations, then based on that parameter you can create 2 separate modification rules in order to generate separate custom metrics which can then be used individually in your reports.
If you already have a Firebase implementation in your app, then you must account for app & web alignment across metrics, dimensions, event names. Given that in GA4 the Firebase events (alongside their parameters) pull through directly into GA4, in most cases it will make more sense to adjust your web implementation to align to the app, especially since the web implementation will have to be redone anyway.
However, there will be some edge cases when you’ll need to adjust values inside the app instead. And for those cases, Modify events will be a blessing, especially when we consider go live time frames for apps.
Moreover, If a mistake was made in one of the parameter values or you find that the naming convention is not aligned between web and app, the Modify Event functionality could easily be used to adjust the incorrect values. In this use case, the Modify Event functionality is similar to the “Search and Replace” filters in Universal Analytics. It’s important to note that there is a limit to the number of modifications you can make, and this shouldn’t be seen as a fix for a poorly architectured implementation.
Mistakes to avoid when using both the modify and the create events functionalities
Keeping in mind scenario 2 mentioned above, the trap you don’t want to fall into is using the create event functionality to split the event into 2 new unique events, while also modifying the event in order to create a custom metric.
What I mean by it is that if you have a purchase event with a customer_type parameter you can use the Create Event functionality to create 2 news events: new_customer_order and existing_customer_order. You would do that by leveraging the parameter which shows the type of customer.
Why would you want to do that?
Most likely because you wanted to mark each event as an individual conversion, so you could then use it as a standalone metric in STANDARD reports (sorry for the caps, but I want to reiterate this is the only place you can use them as standalone metrics. In order to have then as metrics in Explorations you’d need Custom Metrics).
As mentioned earlier, if you also want them as standalone metrics in custom reports, then you have also used the Modify Event functionality (as shown above) in order to create customer parameters (which would then be turned into custom metrics).
But the trick is, if you do both (create events and modify the original event to add the parameters) you will be duplicating the custom metric.
That is because, according to Google’s documentation, event modifications are executed before event creations. Therefore, the purchase event is first modified to send the additional custom parameter (which feeds the custom metric and increments it by 1 with each new event), then, off the back of the purchase event, a new_customer_order event is created which carries the same parameters as the original purchase event, meaning it will also have the new_customer_order parameter, which will increment the metric again by 1, leading to a duplicate count.
This is one scenario when the ability to remove parameters comes in handy. When you use the create event functionality and check the box of “Copy parameters from source event” (which in this case you should do because there are other relevant parameters you’d surely like to carry over) be sure to also add a rule to remove the custom parameter which feeds the metric. That is done by adding the parameter name and leaving the “New Value” field blank.
Conclusion
To conclude, the Modify events and Create Events functionalities are welcome additions to Analytics, given that they reduce reliance on developers and GTM, however, can pose an important threat to the accuracy of your reporting if the processing order is not understood properly.