Case Study: Migrating to GA4 Before UA Stops Working

As Universal Analytics (UA) will stop taking in new data starting 1 July 2023, many eCommerce businesses rushed to get their data tracking setup migrated to Google Analytics 4 (GA4). And scandiweb saw a large influx of eCommerce stores all wanting to migrate at the last minute. This was far from the ideal scenario for us because we had to juggle multiple UA-to-GA4 migration projects at the same time, but we’d like to give you a peek at how we handled it and what happened during the migration process—so you can prioritize migrating to GA4 now if you haven’t already!

Why you need to migrate to GA4 now

Why the rush when it’s not until next year that the big shift is happening? Because it takes time to collect data.

To ensure that proper year-over-year (YoY) data is received in GA4, you ideally should have migrated your data tracking setup to GA4 prior to 1 July this year. That’s why we started encouraging eCommerce stores to migrate to GA4 as soon Google announced that UA was going to stop working next year.

But if you haven’t done so, don’t panic. What matters now is that you start the migration as soon as possible. If you need to learn more about GA4 before you can feel confident about migrating, our free Google Analytics 4 ebook is the resource you need.

Also read: The Future of Analytics: 10 Key Benefits of Google Analytics 4

The challenge

You must have seen this message when navigating to Google Analytics: “Universal Analytics will no longer process new data in standard properties beginning July 1, 2023. Prepare now by setting up and switching over to a Google Analytics 4 property.”

The scandiweb Analytics Team made sure this information reached all of the projects that did not have GA4 set up yet. And that’s how the influx of last-minute GA4 migration projects started flowing—eCommerce stores wanting to migrate all at the same time.

It was quite a challenge to tackle all the GA4 migration requests we received and had to implement in such a short window of time. For two months and even in July, the team pushed on to migrate projects of all shapes and sizes to GA4. What emerged, nonetheless, was a refined process for doing GA4 setups, configurations, QA, and monitoring—essentially a more efficient way to do GA4 migrations.

Our approach

We learned many things along the way, and so each subsequent GA4 migration was more streamlined and consistent than the last. 

There were a lot of setbacks for sure, but we turned them into an opportunity to improve our process by creating a new health-check report that helped ensure that the next GA4 setup we did was completed successfully and more efficiently.

The process: GA4 migration

The first part of any migration is understanding where you are and where you want to end up. With this in mind, no project was excluded from an initial data tracking audit to understand the current landscape of data tracking: dataLayer, GTM scripts, GA, and site structure. Any large gaps we identified in this step were highlighted and addressed individually if the resources allowed for it. 

1. Initial data tracking audit

With each project, we kicked things off by looking at the overview of the GTM container to get a better understanding of the Universal Analytics (UA) tags that are within the tag management system. This helped us have a better idea of the project scope and what underlying system the scripts relied on to collect data: dataLayer events, custom selectors for clicks or visible elements, page views, and so on. After a meeting with the project representatives where we define the project’s scope, the migration could begin.

2. Configuring GA4

The next step was to get our hands on the Google Analytics 4 (GA4) property itself. Creating one was fairly straightforward, but the bulk of the work in this stage was ensuring that the property was configured properly: accounts were linked, correct currency and timezones were applied, Google Signals was enabled, and so on.

3. Duplicating UA tags

We then returned to the GTM container and picked out the UA tags that needed to be duplicated and turned into GA4 ones. If the goal was to migrate the setup exactly as it was in UA (no trigger adjustments or improvements needed), then the same conditional rules could be applied as they were for Universal Analytics scripts. Let’s say an addToCart event was pushed to the dataLayer when something was added to the cart. In this case, two analytics tags would be fired: one was the UA tag, and the other would be the new GA4 one. This had to be done for all analytics scripts.

4. Launching the setup

After the GTM container had been configured, it was time to launch the setup and start collecting data. To ensure that data collection was accurate, we monitored the data harvesting and GA4 KPI reports for two weeks after the initial GTM launch.

5. Reviewing data for accuracy

Once enough GA4 data was collected, it was compared against its UA counterpart and the ERP system.

Since GA4 is a different medium and its data tables are updated differently from UA, some level of inconsistency is to be expected between the two, which can be accounted for as slippage. As long as the GA4 conversion tracking is about 95% accurate when compared to the ERP system, and no other custom events are misreported, the migration can be considered successful.

6. Creating custom dashboards

Linking the GA4 system to custom dashboards made with Google Data Studio was also part of the migration process for some projects.

Download our free GA4 ebook and start your UA-to-GA4 migration journey today. It will guide you through creating a migration plan and the basic configuration of GA4.

If you need expert help to migrate from UA to GA4, reach out to us at [email protected] and our Analytics Team will get everything set up in 2 weeks.

Share on: