An understanding of website visitor behaviour always starts with an understanding of the pages they view. The critical reports in any Web Analytics tool for this are the pages reports and any form of pathing reports.
The new Google Analytics GA4 is clearly a work in progress. It’s content and pathing reports are not currently usable due to the limited dimensions they work with.
But I have a workaround. The Page Title dimension is readily available in these reports but does not provide any value. It can instead be overwritten in your tracking with useful and user-friendly page names. So while there are still limitations, the GA4 content reports become usable.
Page Dimensions in GA4
My first issue with the GA4 Pages reports is they refer to Pages and Screens. I understand the desire to make GA4 obviously a solution for both websites and apps but I believe companies with both are in the minority. If you only select Web as a Data Stream, all references that relate to apps should be dropped (and vice versa).
There are four dimensions available in the GA4 Pages report:
- Page title and screen class
- Page path and screen class
- Page title and screen name
- Content group
Two of these dimensions are available in the Path exploration technique within GA4 Explorations:
- Page title and screen class
- Page title and screen name
Given the app dimensions are pointless, this leaves us with Page Title, Page Path and Content Group as dimensions for the Pages report and Page Title for the Pathing Exploration.
Useful Page Names
My requirements over many years now for useful page names within web analytics are:
- Each page is recorded against only a single page name
- A logical and hierarchical structure is defined for page names
- The page name is intuitive so anyone in the organisation can identify a page on the website based on the page name
The simplest example of this is to name the website homepage “/homepage”. For other examples and using the UK Selfridges website as the test case, do you agree these page names pass those three requirements?
- /department/bags
- /product-list/bags/mens-bags
- /product/bags/mens-bags/messenger-bags/gucci-star-brand-print-leather-cross-body-bag
- /checkout/process/sign-in
- /information/delivery/uk-delivery
- /error-page/404-error
It would be a rare website where the Page Title doesn’t fail all three requirements as a useful page name. That means the Pathing Exploration is useless for page navigation and we are down to two dimensions for the Pages report.
The Page Path can meet requirement 2, generally meets requirement 3 for only part of the website and very rarely meets requirement 1. These requirements are more difficult for GA4 to meet vs Universal Analytics (which uses Page Path as the default page name) due to less functionality. UTM campaign parameters are automatically removed from the UA Page Path and there is functionality to exclude other URL query parameters. The GA4 Page Path allows none of this functionality, meaning we again don’t have a useful page name here.
The Content Group dimension can be populated with any value you use in the GA4 tag. This dimension can therefore be useful as long as you do the work to populate it with something meaningful.
The Solution
As I have made clear, my priority is getting the Page Name right, for both the pages report and the pathing explorer. My second priority is recording the Page Type in another dimension, as this information is useful in many ways. It is also handy to record the Page URL as useful for identifying the issue for 404 Error pages and QAing campaign tracking.
We could capture all this information as event parameters, passed with the “page_view” event. These can then be recorded in GA4 as Custom Dimensions. That is fine if using BigQuery for analysis and reporting but no good if you need to rely on the GA4 UI.
My recommended solution is to overwrite the Page Title field with a user friendly and useful page name. Ideally this is designed by the analyst and coded into the Data Layer by the developer. It is easy to then pass this to GA4 via GTM. Otherwise, you can use JavaScript to create this page name logic, as I have done with the ZHS Orchards website.
This means you have user friendly page names for your Pages report – yay. Bonus, the pathing functionality actually becomes useful. You can use either of the Page Title dimensions and trace visitor paths through pages on the website.
I recommend using the Content Grouping field to record the Page Type. This will then be available in the Pages report. It should be automatically available for GA4 upgrades to content reports e.g. add as a dimension to the Pathing Explorer.
I recommend leaving the Page Path as it is. It contains the same information as the Page URL, only missing the domain name. That’s close enough for our purposes.
The Page Name, Page Type and Page URL should also be captured as parameters with the page_view event and recorded as custom dimensions in GA4. We don’t know the direction GA4 will develop in and that allows us more flexibility in case something weird happens e.g. Content Grouping dimension is deleted.
This solution can be seen in the GA4 tracking on this ZHS Orchards website.
Migrating to GA4
As I said at the start, GA4 doesn’t feel like a viable Web Analytics tool currently. I would not recommend using as your sole source of data, whether by migrating over or as a new installation. If Google Analytics is your tool of choice, continue to use your existing UA set-up and to create new UA properties as required.
It is worthwhile running GA4 in parallel though. Collect historical data as soon as you can, using workarounds like overwriting the Page Title to make the tool half useful and tricks like using standard event parameters names to minimise the work at this stage.
If you want some help setting up GA4 properly from the start, either as a migration or using this opportunity to design a proper Web Analytics set-up, please get in touch. The event + event parameters approach of GA4 matches the Data Layer structure I developed years ago so my techniques are already proven across multiple years and clients.
