Understand the GOV.UK GA4 data structure
This page contains information on the different events being captured as part of the GOV.UK GA4 implementation.
GA4 data is structured around events. Although default GA4 event names and dimensions have been used wherever there is a clear fit to the data being captured, in many places the custom GOV.UK tracking differs from standard ‘Enhanced measurement’ events and parameters. More information about the data collection and GA4 settings can be found on the GOV.UK GA4 data source page.
Please note that the GA4 tracking on GOV.UK has been developed and evolved over time, so you may find inconsistencies or deviations from the below. If you spot anything in the GOV.UK GA4 data that appears to be broken, wrong, or unhelpful, please report it to the GOV.UK Analytics team.
GOV.UK GA4 events
There are a few primary categories of events implemented on GOV.UK:
- page views
- navigation events
- form events
- other user interface events
- ecommerce events
Page view and and ecommcerce events do not have a ‘type’ value. Other events can be broken down by the ‘type’, which typically groups events by their function, location, or the component they are associated with.
There are a few GA4 events which are also collected as standard as part of any GA4 implementation. These are the session_start
, user_engagement
, and first_visit
events.
Page views
Page view events on GOV.UK use the standard page_view
event name, and come with most of the standard dimensions that would be expected with a page view - including the URL (or ‘page location’), page title, and page referrer.
Personally Identifable Information (PII) redaction is applied to the URL, title and referrer.
Page view events are also sent with a wide range of custom dimensions to provide further information about the page. A list of these can be found in the Implementation Record.
Navigation events
Navigation events fire when a user clicks on a link to navigate to another page. Not all link clicks on GOV.UK fire a navigation event; the tracking has only been applied to outbound links and other links deemed to be of particular interest.
The types of navigation event you will find include:
- generic link: clicks on outbound links that are not covered by another type
- email: clicks on email links
- contents list: clicks on contents list links
- previous and next: clicks on previous and next navigation links
- attachment: clicks on attachment links
- homepage: clicks on links on the GOV.UK homepage
The dimensions collected with navigation events that are likely to be of particular use are whether or not the link is ‘outbound’, the link domain and URL, and the link text.
Form events
Tracking on forms all follows a rough pattern:
form_start
events: fired when a user ‘starts’ a form (only on long forms with start buttons/pages, such as smart answers)form_response
ORform_submit
events.form_response
events are used to record users’ responses where the user is submitting an answer that we are capturing, whereasform_submit
events are used simply to capture the act of a form submissionform_change_response
events: fired when a user clicks the link to change one of their responses (only available on smart answers, simple smart answers, and licence transaction forms)form_error
events: fired when a user triggers an error on the formform_complete
events: fired on the completion or results page of the formform_start_again
events: fired when a user clicks the link to start the form again (only available on smart answers and simple smart answers)
On the ‘larger’ forms on GOV.UK, note that form_response
or form_submit
events will fire whenever the user clicks (or presses enter) to submit the form or response in question, even if they have triggered an error.
form_response
or form_submit
events should not therefore be taken as an indication of a successful submission.
To calculate the number of successful responses, you will want to subtract errors or rely on the form_complete
event.
form_complete
events will fire on any view of the ‘results’ page.
This means that multiple form_complete
events can be triggered by the same user if they refresh the page or navigate away from it and back to it.
Also, it is possible that some users could trigger a form_complete
event without having actually responded to or submitted the form themselves, if they are sent the link to a results page.
The above are not the case on feedback form submissions and survey banner form submissions, as these are smaller forms using different components where the user does not navigate between different pages as they complete the form.
The survey banner only has form_submit
and form_complete
events - no error tracking - and feedback form submissions only have submit events.
The values collected on form events are summaried in the following table.
event_name | type | ui_text | response | outcome | section | action | tool_name |
---|---|---|---|---|---|---|---|
form_start | smart answer, simple smart answer | <button text> | start page | start | <form name> | ||
form_response | smart answer, simple smart answer, email subscription, contact | <response text> | <question text> | <button text> | <form name> | ||
form_submit | smart answer, simple smart answer, local transaction, special route, licence transaction, place, feedback, email subscription, survey banner | <button text> | <question text> | submit | <form name> | ||
form_error | smart answer, simple smart answer, local transaction, special route, licence transaction, place, email subscription, contact | <error text> | <question text> | error | <form name> | ||
form_complete | smart answer, simple smart answer, local transaction, special route, licence transaction, place, email subscription, survey banner, contact | <result/completion response text> OR <outcome number> (simple smart answer) OR undefined (smart answer) | <heading text> OR undefined | complete | <form name> | ||
form_change_response | smart answer, simple smart answer, licence transaction | <link text> | <question of response to be changed> | change response | <form name> | ||
form_start_again | smart answer, simple smart answer | <link text> | <question text> | start again | <form name> |
A sample exploration showing form data can be found in the GOV.UK GA4 property.
Other user interface events
There are a range of other events which capture information on users’ interactions with the user interface. These will have distinct event names and often use additional custom dimensions to capture useful information.
These include the below.
select_content
events
These events track interactions which show or hide pieces of content on GOV.UK (for example, user interactions with accordions).
Video events
Video events (named video_start
, video_progress
, or video_complete
) track users’ progress through videos.
Our video tracking uses dataLayer pushes implemented by developers, using the GA4 video tracker script.
We use the standard GA4 video event names and parameters suggested by Google to capture information like the video_duration
(in seconds), video_current_time
(seconds through the video), video_percent
(percentage through the video), video_title
, and video_url
.
A sample exploration showing video data can be found in the GOV.UK GA4 property.
Scroll events
scroll
events track users’ scrolls, using different fields to track scroll depth depending on the type of scroll tracking implemented.
Ecommerce events
Ecommerce tracking has been used on GOV.UK finders to better track usage of site search. It has also been applied to a couple of smart answer results pages to determine which results users are seeing and which they are then selecting.
These events are:
view_item_list
events: fire on views of search results pagesselect_item
events: fire when a user clicks on a search result
Each ecommerce event can have up to 200 items sent with it. When searches return more than 200 items, the items sent with each event will be truncated.
In some cases, we have had to limit the number of items sent with each event further, as the number of bytes being sent with each event was too high and was triggering error 413 (Payload Too Large). The maximum amount of bytes we can send to GA4 per event appears to be 16KB, so we have implemented a limit to cut off the ecommerce items array at 15KB, to ensure our events are small enough to send (the additional KB may be needed for other information sent with the event).
GOV.UK GA4 naming conventions
There are a number of common naming conventions used in the GOV.UK GA4 data. These rules are followed to make the data cleaner and easier to understand, and to reduce potential issues stemming from high cardinality dimensions. Some of these are broader GA4 conventions, and some are GOV.UK-specific.
This table details some of these conventions:
GA4 field name | Parameter name | Rule | Notes |
---|---|---|---|
Event name | event_name | Event name is lowercase, with underscores separating words | Following wider GA4 event naming rules |
Type | type | Type is lowercase, with spaces separating words | GOV.UK specific, to tidy the data and reduce cardinality |
Action | action | Action is lowercase, with spaces separating words | GOV.UK specific, to tidy the data and reduce cardinality |
Method | method | Method is lowercase, with spaces separating words | GOV.UK specific, to tidy the data and reduce cardinality |
Search term | search_term | Search term is lowercase, with spaces separating words and special characters and extra spaces removed | GOV.UK specific, to tidy the data and reduce cardinality |
Per cent scrolled | percent_scrolled | Percentage as a whole number, without a percent symbol | Matching standard GA4 ‘enhanced measurement’ data collection |
GA4 imposes a number of limits on data collection, such as on the lengths of field names and values, which also impact the data collected.