Things to watch out for when migrating from Universal Analytics to Google Analytics 4
As everyone is aware of by now, Universal Analytics will be bidding us farewell in July 2023 and anyone using Google Analytics should be upgrading to GA4, or perhaps considering their options.
Having now performed this process several times for our clients, we thought it would be worth compiling a list of things to watch out for.
Note: Google are making regular improvements to GA4 so it’s possible some of the information in this blog could become out-of-date over the next 12 months. Certainly, we’re hoping that is the case for some of these items!
There is no way to get your historic UA data into GA4
This one may seem obvious to those that are familiar with GA, but it’s a question our clients ask often. The answer is that no, you cannot import your historic UA data into GA4.
If you want to get trended historic data or year-on-year comparisons between UA and GA4, the recommended method is to connect both tools to BiqQuery, align the data and create some dashboards in something like PowerBI or Tableau. This is not a particularly straightforward task, so we recommend it’s something that is done sooner rather than later, while you’re still running the two tools in parallel. If you do it now, you also have the additional benefit of having a place to compare the data from the two tools and check that GA4 is consistent with your current UA data.
Data Collection Limits
This probably deserves a blog in itself, but data collection limits apply to both the free and paid (360) versions of GA4.
See here for the differences but it’s worth calling out some key ones:
- The free version has a maximum data retention limit of 14 months, which is significantly shorter than the maximum available period for the free version of UA.
- You are limited to 50 event-scoped dimensions and metrics on the free version and 125 event-scoped dimensions or metrics on the 360 version.
- The 100 character limit on dimensions can be a particular issue if you’re looking to capture long strings such as full URLs, User Agents or particularly long query string values.
Limitations on Product metadata
GA4 only supports specific fields for product metadata as part of its ecommerce tracking. As of this blog being published, you can pass custom product-scoped dimensions via the web tags (suggesting this feature well be added at some point in the future, see below), but they will not be collected and they will not be available in any reporting method, including BigQuery. The fields documented here are the only ones that you can collect. The same also applies to the Data Import feature if you’re thinking that will provide a work around.
To get around this, you can load your custom product metadata into BiqQuery and join on the `item_id`, but that extra data will only be available for reporting via BigQuery and not via the GA4 interface.
Google have recently added a tooltip to the interface that says these features are on the roadmap, but there’s little information beyond this as Google do not publish an actual roadmap for the product.
Linking web and app tracking via Firebase
One of the big new benefits of GA4 compared to UA is that you can combine web and app traffic in a single GA4 property. However, this does come with an important limitation depending on how you have your apps arranged in Firebase: You can only link one Firebase project to one GA4 property. So, while Google’s documentation says you can connect up to 30 app data streams to a GA4 property, these apps must all be in the same Firebase project.
This has a particular implication if you want to separate your development and production data into different GA4 properties, which is a sensible thing to do, especially if you’re on the free version of GA and cannot make use of subproperties. To achieve this, you must arrange your Firebase apps so that your development and production apps are in separate projects.
Views no longer exist in the free version
In Universal Analytics, you could create views within a property and use them to filter out or separate data. For example, filter out data from development environments or internal IP addresses, or create separate views for different country versions of your site. This is sadly no longer a feature of free GA4, which only has the concept of accounts and properties, without any ability to filter that data into views.
This lack of views also affects user management as you can no longer restrict access to certain datasets using this feature, as user management is only available at the property level in free GA4.
GA4 360 does include the new subproperties feature, which does allow you to create filtered ‘views’ that are a subset of the main property. However, there is still a catch, in that these subproperties come with additional costs! The cost of events in each subproperty is one half the cost of the events in the source property.
Cardinality or, why do I see “(other)” rows in reports?
In GA4, if you have dimensions with lots of unique values, this can cause Google to group up those dimensions under “(other)” in standard reports. Google will start to do this in dimensions that hit 500 unique dimensions in a day.
For example, this client is on the paid 360 version but in only a 3-month date range, “(other)” is top of their pages report as they have over 3,000 unique page names:
The key issue with this is that once you have cardinality issues in one dimension, you can start to see “(other)” appearing in reports that do not themselves have excessive number of unique values. This is because GA4 calculates cardinality based on the entire base table. So, if there’s even a single dimension that has high cardinality, then any reports built from the base table will suffer from it, even if this dimension isn’t included in the report.
The problem is such that Google warns you about this when creating a new custom dimension:
If you want to get around this, you have two options. Firstly, you can avoid cardinality at the point of data collection by not tracking high-cardinality items like full URLs or query parameters. And avoiding setting user IDs in custom dimensions. Or you can avoid using the standard Reports part of GA4 entirely and instead use Explorer (which can still be affected by cardinality but to a lesser degree) or BigQuery (which is not affected by cardinality).
In Conclusion
Hopefully that’s been a useful list of things to watch out for when migrating to GA4!
With a mandatory reimplementation and these limitations in mind, now is probably the right time to perhaps give some consideration as to whether GA is still the best analytics tool for your use cases. Particularly if you are on the paid version of GA,
Watch this space for further blogs on how the paid version GA4 compares to some of its competitors!