There has been a lot of noise around the migration to GA4 (Google Analytics 4) from UA (Google Universal Analytics) and what this means for businesses and your website & application analytics. What’s not quite known for sum is how this new platform is set up, how it works and what is best for your digital assets in terms of tracking. The simplest explanation is that it sometimes requires some thinking and customisation to get it right. I admit, it took me a while to work it out over the last 3 years properly, but after many implementations later, I understand the process a whole lot better and how this can be fully utilised.
But this isn't all bad news.
You can now configure your analytics to do specific event tracking and cater it towards your needs, but in order to do so, you need to establish a plan and a goal in mind as it’s an investment of time now to implement, so the consideration of return on investment is top of mind. But having a custom report that tracks your desired pathways is now available. Secondly, your data is only stored for a maximum of 14 months, so having exported reports is vital if you’re not storing your data on Google BigQuery or an external data storage system.
Implementation in practice
A recent project I have been working on worked across a NODE.JS and Vercel tech stack to deliver a custom site that required tracking across all elements of the site to determine best pathways for users to funnel into conversion points. The website had a number of key items that the UX (User Experience) funnelled users into and then some specific CTAs (Call to Actions) that would then need to be traced as a user pathway through the website to determine what elements of the site the readers were viewing in order to reach the lead capture and contact detail conversions. The site was a stage 1 deployment which further stages to be built out from the collection of data to determine what works on the initial stage and what needs to be improved. These would then be reported on through a lens using Looker Studio or the custom reports inside GA4.
The scope
We needed to work off an IA (Information Architecture) initially and plan out how the series of events would occur and then what events were native in the platform compared to custom events and the custom parameters we needed to track in each event. This would determine the most used pathways and if users were funnelling through the site as expected and what areas were dropping off and to what level the content was being read.
The approach
First we created the plan which consisted of a rollout plan of each event and what we needed to highlight for the developers to implement on the site creation that matched up with key features of the site. There were a number of dynamic carousels, selection boxes and sliders that needed variables collected through data layers and link detections across class and ID parameters that would pull in the necessary labels on these links that would then allow for an event flow report and what sections worked best.
Once we had the mapped out plan of what needed to be tracked and traced, we had to look at the variables so the custom parameters could be deployed in a simple method that can be measured neatly for each component using these labels so they can be consolidated at the reporting level. We had to keep reporting in mind for when these events were pushed into GA4 they could be compatible with filters and also with pivotable tables.
By doing this, we created a simple naming convention for the labels and deployed them on each link, but also declared different events with the same parameters that would declare how much of each module was being utilised in the user pathway. There were a number of ways users could reach the information, but to determine the best user flow, we wanted to track each module type individually. This leads to an identifiable event with a destination name from each module.
This then allowed us to look back and determine these event parameters by declaring them in GA4 and then running a custom report in Looker Studio once completed.
Why does this matter?
By allowing the custom parameters and individual event names to be tracked, we can consolidate the custom parameters being the same on each event to create pivot tables where you can determine the click paths to each page from different modules. Although the initial page layouts are simple, as the site grows and there being more than one module on each page, we can highlight what the best performing modules are for drawing traffic into the particular page by pivoting the table onto the custom parameter labels.
This then can provide us the best pathways into content and also ultimately towards the conversions for a proper conversion optimised website.
If you’re interested in GA4 Setups and Google Tag Manager, please reach out.