Skip to main content

Implementing GA4

This is a high level summary of the steps required to implement Google Analytics 4 (GA4).

Note: these steps do not necessarily have to happen in this order. For example, most GA4 implementations will require a GTM container on the page, so unless your site is one of the few that will not use GTM, the developers can be implementing GTM whilst you figure out what data you want to collect.

Implementing GA4: step by step

Decide: What do you need to measure?

What sorts of metrics do you need? What user interactions on the site are relevant for your understanding of the site’s performance?

The ‘gold standard’ option is to run a performance framework, or use a recent performance framework, to make these decisions.

Alternatively, if you already have Universal Analytics (UA) tracking on your site and find those events and metrics useful, you can plan to ‘replicate’ this tracking in GA4. However, you should bear in mind that UA data and GA4 data are structured in quite different ways, so the data you are collecting may look quite different in GA4.

Decide: What do you want your data to look like?

The GA4 data structure allows for much more flexibility and customisation than the UA data structure did.

If you are working on a GDS site, it would be good to align where possible with the GOV.UK schema and naming conventions. This means that your GA4 analytics data will be easier for analysts across GDS to use, and will ensure data is (relatively) comparable across different GDS properties. The Analytics team and GA4 team members on GOV.UK can explain the GOV.UK GA4 implementation documentation and help you find relevant events for your site to emulate.

At this stage, you should consider: are there any risks associated with your data collection that you need to be aware of and mitigate? For example, will you need to ensure that strong PII redaction is in place, if users are able to input information to your site?

Decide: Where are you going to store this data?

In most cases, one site’s data will go into one GA4 property. However, it will be important to think about whether this is the most appropriate solution if your previous Universal Analytics data collection and sharing relied heavily on Views or other features of Universal Analytics that no longer exist in GA4.

Decision tree:

  • Do you require hard governance? If no, we can use custom reports/customise the interface to show different users different data. If yes, ask:
  • Do we need the data to be accessible via the GA4 user interface? If yes, you could consider using multiple trackers into different properties, or use sub-properties/a roll-up property to split out or join the data. If no, ask:
  • Are you comfortable with relying on the BigQuery data and spending the additional money that entails? If no, it is likely to be best to manage the data access restrictions via a BI solution running using the Data API. If yes, ask:
  • Are you comfortable working in BigQuery alone? If yes, you can rely on BigQuery and manage via a BI solution running on BigQuery. If not, the best option is likely to provide access to a dedicated BigQuery table which can be connected to Looker Studio and other reporting tools.

You can also have your GA4 data exported to BigQuery if the raw data is of use or necessary for more custom reporting.

Decide: How are you going to collect this data?

There are a number of ways you can get data from your site to GA4.

We recommend the use of Google Tag Manager (GTM) to collect data from your site and send it in the correct structure to GA4.

There are a few ways data can get to GTM and thus to GA4. These include:

  1. Data is explicitly pushed to the dataLayer when users interact with certain elements by developers (this is the approach used on GOV.UK)
  2. GTM ‘listens’ for user interactions with certain elements that have been tagged with data attributes by developers
  3. GTM ‘listens’ for user interactions with certain elements that are identified by GTM based on their pre-existing classes, IDs, and so on (‘DOM scraping’)

There are different pros and cons for each of these approaches. It is also possible to use a combination of the above approaches, for example using explicit dataLayer pushes to track core or complex interactions and using ‘DOM scraping’ in GTM for certain temporary or ‘extra’ bits of tracking.

Implement: GTM on site

In the vast majority of cases, developers will need to implement the two GTM code snippets (one in the , one in the on every page of the site.

In a small handful of cases this will not be required as either GTM is already present on the site or it can be easily installed via an add-on or CMS without the need for developer involvement here.

Implement: dataLayer pushes, data attributes

Depending on the approach chosen in step 4 above, there will probably be a certain amount of developer work required to implement the GA4 tracking.

If you use the govuk_publishing_components gem, some data attributes may already be in place (though they may need to be ‘switched on’ or the component version with the GA4 tracking attributes will need to be used). You can read more about this in the Developer docs.

Configure: GTM to receive data and send to GA4 in desired form

GTM will need to be set up with a Google tag and additional event tags to collect the data specified and send it, following transformations or clean-up, to the correct GA4 property.

The Analytics and GA4 teams can provide you with copies of the GOV.UK container or a ‘Single Data Environment’ container which can function as templates for this work, and can help you set up and test GTM.

Configure: GA4 to receive any custom attributes

If you do not already have a GA4 property set up, you will need to set one up.

There are a range of settings to be input at property set-up. Information on the settings used for the GOV.UK GA4 property can be found on the GOV.UK GA4 data source page. Most of these settings will not cause too much of an issue if they are incorrect and they can be changed later. The most important to get right for your site is probably the timezone (likely ‘United Kingdom Time’), as that being incorrect could cause the data to be misinterpreted (when trying to understand what times users are on your site, etc) later on.

As tracking is configured, you may also need to do some light configuration in GA4 itself to ensure the correct dimensions are picked up and available in GA4. If you are using custom dimensions, you will need to add these in the ‘Custom definitions’ tab in the Admin area.

Test: data being collected

Any tracking implemented should be checked to ensure the values in GA4 look as expected. Basic testing of tagged up events can be carried out with the following steps:

  1. On the site (after accepting cookies!), trigger an instance of the event in question
  2. Check that the right information is being pushed to the dataLayer after the event has been triggered. This can be done by entering ‘dataLayer’ into the console, and looking at the dataLayer push
  3. For the same event, check that the same values are showing attached to the event in Omnibug (or another debugger)
  4. Check if the data appears in Google Analytics. Data should appear relatively quickly in the ‘Real time’ report, but this is not always a perfectly reliable report so the data you see in ‘Real time’ should be taken with a pinch of salt

It’s good to test a variety of instances of the event in question, not just one click/page/event, to ensure different values come through correctly and that multiple instances of the tracking are working. Check: are the right values coming through? Consider how this information will be revealed in GA - does it make sense?

If you have comparable data in Universal Analytics, it may be interesting to look at and learn about any differences between the UA and GA4 figures. However, in many places the definitions of different fields and the structure of the data has changed, so you should expect that they may be quite different!