Unlocking Google Analytics 4

On 14th October 2020, Google announced a new version of Google Analytics, imaginatively titled Google Analytics 4. This new version of Google Analytics is centred on the way the ‘Web + App’ properties worked and is a better reflection of modern internet usage considering the explosion in mobile apps, and UI technologies such as react.js.

Instinctively, you might want to leap in and change to using GA4 immediately. In fact, Google is showing an “Upgrade to GA4” button in the admin panel for many Google Analytics properties already. Before you take the leap, what does this really mean for you and how should you proceed?

The first thing to be clear about is that upgrading to GA4 is not quite as simple as most of the guides, including Google’s, would make out. At least that is if your website is doing web security properly. Unless you use the Global Site Tag variant, the tracking code for GA4 utilises different URLs than that of Universal Analytics (GA3) and so it will be blocked if your site uses a Content Security Policy, as all modern websites should. If you track to GA4 using Google Tag Manager (GTM), the tracking code loaded for GA4 tags is different to that loaded for GA3 tags.

Additionally, you will need to check your cookies policy. It is a legal requirement in the UK to list cookies that are set, along with some details about them. The cookies set by GA4 are no different to those set by GA3 but as a best practice, you should review and confirm the accuracy your cookies policy any time you add or update tracking code to your site.

Furthermore, when you do get GA4 running, the reporting structure is incredibly different to that which you are used to from GA3. All the reports you have become familiar with are gone and are replaced with a much more flexible interface. That flexibility is long overdue in Google Analytics but the opportunity cost for that is a more confusing UI for the casual user. There will be a transition period in organisations where marketing teams are likely to need to lean on the skills of analysts more heavily in the short term in order to get even the most basic data from GA4.

These are the most striking differences between GA3 and GA4 that will hit marketing teams excited to upgrade quickly but to get a full understanding of what considerations there are, here is a deep dive into what you need to know about upgrading.

You can also contact us to get a GA4 measurement plan for your organisation.

Data collection methods

If you are familiar with how Universal Analytics and previous iterations of Google Analytics collected data, you will be familiar with there being different kinds of ‘hit’ that were collected. The different types of hit collected were page views, events, e-commerce transactions, and social interactions, and in addition, on app properties, screen views, exceptions, and user timings.

GA4 does away with these different kinds of hit, and sticks with a single flexible event hit. There are some specific kinds of event that are collected by default. You can also add any number of custom events to track other kinds of interaction.

This is a welcome update to the tracking methodology of Google Analytics as it adds consistency across a number of different types of tracking that were previously only possible through customisation.

However, it is not clear at the moment if the ten-million hits per month usage quota applies to GA4 properties in the same way it does for GA3 properties. It seems likely that there would be a similar limitation, but this is a notable concern as GA4 will send so many more hits by default.

User tracking vs device tracking

GA4 sets a user ID to distinguish users, and this value is relatively trivial to set in tracking code. This feature was also available in GA3, although in my experience it was rarely used. A best practice would be to set a user ID any time a user does an action that identifies to your web pap who they are. However, the user ID you set in GA4 must be a non-identifiable GUID (globally unique identifier) rather than, for example, an email address, or a user ID directly pulled from your CRM.

A good example of where you might implement this is where a user log-in occurs. You own app knows who the user is and so can set the user ID in tracking code while the user is logged in. Each time the user logs in again, even if on a different device, the same user ID would be set and so Google knows it is the same user. Even if the user doesn’t log in every time, so long as they have logged in at some point on that device, Google can link their sessions.

This is actually no different to how GA3 worked, although probably more straightforward to implement now.

If you do not ever set the user ID, Google will assume each device tracked is an individual user and so users who sometimes view your site on their phone, and sometimes view the site on their PC or tablet will be counted more than once.

Filtering

One key difference between GA3 and GA4 is that currently, GA4 does not support filtering.

In GA3, you might use filters to remove traffic from some of your data views. For example, it was common practice to use a filter to block tracking from your own organisation’s IP address (i.e. prevent tracking of ‘internal’ traffic.

A promised feature that is not yet available in GA4 is to enable flagging of internal traffic so it can be filtered. For this use case at least then, there is a solution. However, at Storm we use filters for so many other important purposes which there is currently no support in GA4. These include:

• converting all URLs to lowercase (to merge capitalisation errors in URLs on Microsoft servers onto the correct URL)
• create country-specific views for internationalisation of Google Ads activity
• inject hostnames into URLs when tracking from multiple domains (e.g. www.example.com and blog.example.com)
• exclude some third party agencies’ IP addresses
• remove some other platforms click tracking parameters (e.g. fbclid)

Much of these filter use cases are possible in Google Tag Manager, and it could be the best long term solution is to use Google Tag Manager for that.

Connecting to Google Ads and Google Search Console

It is possible to connect a Google Ads account to your GA4 property just like you can in GA3. However, at the moment it is not possible to join a Google Search Console property to GA4.

This is disappointing as there is a wealth of important data in Search Console that as a marketer you might want the wider business to access but without the risk of giving access to the full Search Console account itself.

Additionally, by having the Google Analytics frame around Search Console data, GA3 enabled an easy way to search through Search Console data using regular expressions, something that is sadly lacking in Search Console itself. For regex geeks like me, that is upsetting.

Cross-domain tracking

Cross-domain tracking is very different in Google Analytics 4 compared to how it was undertaken in previous versions. It is handled entirely through the Administration screens, unlike in GA3 which required customisations to tracking code to make it work.

Cross-domain tracking is necessary if your Google Analytics property spans multiple domains, e.g. www.mybrochuresite.com and www.mycustomerportal.com as in these scenarios, GA4 needs a mechanism to join the data from each site together.

Cross-domain tracking is rolling out to GA4 accounts and might not be ready in your account yet. However, it should be in everyone’s account options soon. Cross-domain support is coming, however, and it will be interesting to see how this differs from GA3.

About tracking errors

Exceptions (errors) can be tracked into GA4. This is a concept brought forward from tracking apps to help continuously improve them. However, the exception tracking is flexible enough that it could be used for tracking exceptions through tracking server error pages on web app also. This would require some work with developers to surface exceptions into tracking code.

At Storm, we have typically tracked website errors using Google Tag Manager to send virtual pageviews in the past, with page URLs in the form "/error/{404}/{the-requested-URI}". I intend to experiment with GA4 to see if this is still necessary.

Custom events, screen tracking and virtual page views

Earlier we mentioned that the various hit types in GA3 have been superseded in GA4 by a more flexible ‘event’ hit type. This provides considerable advantages for customising your own events.

Many of the customised events that we might previously have set up in GA3 are tracked automatically in GA4, although you can configure not to collect them on an individual basis. For example, GA4 can track scrolling and external links out of the box.

This is a great leap forward in comparison to what comes out of the box in GA3. We have created recipes to track all of these things in GA3 through Google Tag Manager as standard in the past and so the advantage here is that we should hope that over time GTM installations should become cleaner or less noisy for the same level of detail.

However, one disadvantage is that it is not as clear precisely what triggers a file download to be tracked, for example. Is it simply a link containing certain file extensions at the end of the URL, or are streamed document downloads also tracked? Only some testing and experimentation will answer that question and I expect to follow up this blog post in time with more detail.

You may also wish to track other things that are not included in this list above. A common scenario, for example, is the need to track clicks on mailto: or tel: links. The good news is that you can create any customised event you like, with the only real limitation being that you cannot use one of the reserved names used for the events Google gives you by default.

The downside is that the new flexible events in GA4 don’t use a default Category/Action/Label format like GA3, but in fact use any custom parameters you want to set up. You need to register your custom parameters in your GA4 setup, and you need to set up custom reports to view the data.

There is also another kind of event in GA4, which are called “recommended events”. These are not collected out of the box but are recommended as they are pre-registered in GA4 for use in certain scenarios (and therefore have prebuilt reports available). For example, here are the recommended events for e-commerce and retail.

E-commerce tracking

GA4 uses the same tracking code elements to send e-commerce data as did enhanced e-commerce tracking in GA3. This means that if you currently still rely on the standard e-commerce tracking code, then migration to GA4 will also require migration to enhanced e-commerce tracking as well. This in itself is not a bad thing – enhanced e-commerce offers much richer e-commerce reporting. However, the migration requires a good deal of developer input to ensure the right data is sent via tracking code at the right time. Even when utilising Google Tag Manager there is a considerable amount of dataLayer interaction to set up in code.

As indicated above, there are a series of recommended events that could be used for tracking e-commerce, and each of these requires dataLayer interaction.

See the Google Tag Manager guide for setting up e-commerce tracking in GA4.

Goals and conversions

In GA4, ‘goals’ are called conversion events. Any custom event that is set can be set as a conversion event. You can do this in one of two ways, either by creating or modifying an existing event and copying it as a new event name or by tracking a custom event using Google Tag Manager.

A conversion event is triggered on every instance of it firing, and therefore it is important to create the modified or custom events accurately to prevent false positives from occurring in your data. You must set the event you want to be marked as a conversion as so in the conversions admin, otherwise, it is just another normal event.

For example, you might create a custom event called “lead_generated” to send when users submit a valid contact form. You switch this on as a conversion, and now each time users submit the contact form, a new conversion is tracked.

Advertising features

Advertising features are, based on data collected by Google Signals.

Google Signals is an underlying feature of Google Analytics introduced in 2018 to improve cross-device tracking, ads reporting, demographics, interests and remarketing without the risk of exposing personal data in Google Analytics reports. This works by Google tracking users independently of your tracking code (as per GDPR, users will have opted into this). Where a user is recognised by Google, the demographic and interest data Google has on that users is shared into your aggregated reporting and the device is recognised as belonging to that user.

While thoughts of GDPR may cause some organisations to be uncomfortable with the idea of collecting demographic data about their users in Google Analytics, it is important to understand that you are not collecting this data yourself. Instead, you are being given a window onto the data consented to by Google’s own users where this crosses over with your users.

Google signals is enabled in Data settings > Data collection.

Our recommendations for you to do now

First of all, now is not the time to abandon your Universal Analytics implementation. The reporting in GA4 is quite different and you are likely to get frustrated in the short term trying to find the kinds of reports you are familiar with. That is not to say the reporting in GA4 is bad, in fact, it is way more actionable. However, many organisations have built their reporting functions around how they are used to seeing data coming from GA3 and so there will be some work needed to pivot to new ways of reporting.

Additionally, not all functions are available in GA4, for example, custom dimensions. There may be other functional elements of GA3 on which you have been relying.

Finally, your benchmark data is in the format of GA3 reports and metrics. To get the best value from data you need consistency.

On that basis, for the time being, our first key recommendation is to keep tracking into and reporting from GA3 for the time being.

However, that does not mean you should ignore GA4. You should absolutely look at building measurement plans for GA4 and planning for the future. Collect data now in GA4 and when the point comes for your organisation to transition you will have historic benchmark data in the right format.

Therefore our second recommendation is to look to track to GA4 in parallel in order to build a history of data that you will use later on.

When you are collecting data into GA4, take the time to learn the new reporting formats and familiarise yourself with them. The reports are intended to be more insightful and actionable than GA3’s reports. Learn them now and get an early adopter advantage for your organisation!

Contact us to get a GA4 measurement plan

To find out more about building a measurement plan for GA4, get in touch now.