3 Things I Wish I Knew Before Migrating to GA4

Google will soon end support for the current version of its popular analytics platform, Universal Analytics (UA). UA will be sunsetting on July 1, 2023, and all users will be required to migrate to Google Analytics 4 (GA4). The only exception being GA360 customers, who will receive an extended deadline that is currently set for July 1, 2024.

Since the introduction of GA4, I have had multiple opportunities to update Universal Analytics implementations to the new GA4 standard in preparation for this year’s cutoff. Some of those projects have gone smoother than others and I have learned much along the way. Here are three things I wish I knew before I began migrating UA implementations to GA4.

1. Replace Goals with Custom Conversion Events

Goals (and the rest of UA’s views) didn’t make the cut when Google’s developers were picking features for the GA4 dream team. In their place is the ability to mark specific incoming events as conversions. While UA provides controls to define additional conditions for when a goal is met, there are no such options in GA4. This might lead you to move goal conditions to your tag manager or website’s code, but there is another way. We can look to GA4’s custom events feature to achieve similar results.

As an example, let’s suppose we have a destination-based goal in UA that increments when a user lands on the checkout “thank you” page at www.mystore.com/thanks-for-ordering. We can track the same behavior in GA4 by creating a custom event. I’ll choose “checkout_thanks” for the name of my event. I’ll set the first condition to “event_name equals page_view”, and the second condition to “page_location equals https://www.mystore.com/thanks-for-ordering”. I’ll leave the “Copy parameters from the source event” checked so that my new event includes all the same information that comes in with the page_view event.

Now, the next time GA4 receives a page_view event for the “thank you” page, it will also log a checkout_thankyou event. The final step is to mark the checkout_thankyou event as a conversion so that it appears in your Life cycle > Engagement > Conversions reports. I find this pattern to be easier to set up and maintain than defining goals through GTM or other approaches.

2. GTM’s GA4 Event Tags Support the Universal Analytics Enhanced Ecommerce dataLayer

One of the most noticeable changes when it comes to implementing GA4 vs UA through Google Tag Manager (GTM) is that the structure of ecommerce event objects in the dataLayer has received a complete overhaul. For UA, a call to dataLayer.push when a user clicks on product might look like this:

In GA4, the new standard for product click events could like the following:

GA4’s emphasis on a more generic, scalable data structure is apparent in the new specifications, but it also presents a potentially sizable risk to users that need to update before the coming deadline to switch off of UA.

Fortunately, GTM’s GA4 Event tag can support the UA Enhanced Ecommerce dataLayer structure without needing to manually map all of the ecommerce dataLayer properties to GA4 item fields. For each ecommerce action you want to track, create a GA4 Event tag with the equivalent GA4 event name, enable the “Send Ecommerce data” option, and set the Data source to “Data Layer”. Google provides additional guidelines for this process in their official documentation.

I do recommend updating existing UA ecommerce dataLayers to the new GA4 specification, but this should at least make the approaching cutoff less of a threat to the seamless handover of your analytics data collection.

3. Turn On Your DebugView!

Universal Analytics does not have great tools for validating hits when they arrive at a Google Analytics property. While UA does offer some realtime reporting, it makes it difficult to isolate specific traffic. Additionally, only select dimensions are surfaced in the realtime reports.

GA4 introduces the DebugView feature that allows you to follow the events received from clients whose traffic is flagged for debugging. DebugView is accessible from the Admin settings screen and presented to the user as a timeline of events.

A similar timeline chart is visible when viewing GA4’s realtime user snapshots.

For events to appear in the DebugView, they need to include the “debug_mode” parameter. To mark all traffic for your site as developer/debugging data, set the debug_mode parameter to “true” in GTM’s GA4 Configuration/Event tags or through gtag’s “config” call.

GTM

gtag.js

gtag(‘config’, ‘G-12345ABCDE’, { ‘debug_mode’:true });

To disable debugging, omit the debug_mode parameter from your GTM tags and gtag configuration. Setting debug_mode to “false” will not disable debugging.

You can also enable debug_mode for only yourself by using GTM’s Preview mode or by enabling the Google Analytics Debugger Chrome Extension.

If you don’t want debug data to be mixed into your other reports, you should enable GA4’s Developer Traffic filter:

1. Navigate to GA4’s Admin settings screen
2. Click to open the Data Settings menu under the Property settings column and select Data Filters
3. Click the “Create filter” button
4. Select Developer traffic
5. Enter a name for your filter
6. Change the “Filter state” to active if you want to start excluding events in your GA4 reports that arrive with the debug_mode parameter. If you leave its state as “Testing”, the debug events will still be included in reports, but they will also include a dimension that you can use to filter them out from your reports

I’ve only covered a few of the lessons I learned so far on my journey with GA4, but I hope that you can take away something to ease your transition away from UA to Google’s new standard for analytics.