Four phases to consider when migrating to GA4
The exploration phase is where the migrating to GA4 begins. It’s the moment when you start exploring your future needs and defining new requirements. If your business is active on multiple markets, it’s important to define your KPIs and listen to the demands of local teams. This phase is also relevant if your business is small and located in one country, as there might be multiple stakeholders and product owners that use Google Analytics data on a daily basis. By now, you’ll be familiar with every stakeholder’s needs; this will help you evaluate how data will be used in the short and long terms. Based on the outcome of your exploration, it is vital to decide whether to have a centralised or decentralised approach to your data collection framework. Questions you should ask yourself include: “Are my business KPIs and requirements similar across every market?”, and “How much personalisation should we allow for each market when setting up new GA4 properties?
Once the exploration phase is complete, it’s time to move to the core of your migration: the design of GA4. This is the ideal time to rethink your data and redesign your analytics, if needed. A fresh start with a new tool represents a perfect opportunity to improve your data maturity. In addition, redesigning your analytics strategy is also a chance to enhance the way you collect, analyse, and act on data. Ensuring that your data infrastructure is scalable is also essential to ensure you can effectively handle migration to a new tool and the subsequent growth of your data collection. More details about this phase are in the section below.
During the adoption phase, it’s important to build a community of trust to encourage people to adopt GA4. Some important consideration to keep in mind:
Once adoption is widespread enough within your organisation, it’s time to start collecting feedback from your community and main stakeholders. The objective is to enhance your data collection framework, make adjustments and find areas of improvement.
This phase should be used to update the events you’re collecting, or create new explorations and customise the GA4 interface. A regular review will also help in understanding when to add new features that will help you take full advantage of GA4 modelling, by implementing Consent Mode, for example.
Customisation and naming conventions
When migrating to GA4, you can bring added value to your business by adopting standardisation while also providing flexibility to customise your setup.
Standardisation and flexibility are important considerations for your data. On the one hand, standardisation helps ensure that data is collected and analysed consistently, allowing for more reliable and accurate insights. It minimises the risk of errors or inconsistencies in data, helps advance the organisation’s data maturity and brings uniformity into your reports.
On the other hand, flexibility is equally essential for incorporating new data sources and adapting to changing needs and goals. Flexibility is vital for ensuring that an organisation’s data management processes remain relevant and effective over time.
Striking the right balance between standardisation and flexibility is necessary for the future of your data.This should be taken into account when allowing multiple GA4 properties to have slightly different setups and events, or when helping local agencies implement their own events and parameters.
Best practices for event structuring
To allow scalability to your new setup, it’s crucial to keep a flexible approach when designing your event structure. This means allowing for some customisation in the use of parameters, or defining a naming convention that takes different scenarios into account. For example, at Artefact, we use an approach where we include the action taken by users as a verb at the end of the event name; this can change based on the interaction.
Another point worth mentioning is that parameters in Google Analytics can be reused for multiple events. In the example above, the parameter form_type, could simply become type, which will allow it to be added to other events. This parameter then can be configured as a custom dimension and its value will dynamically populate the relevant event.
High cardinality affects reports in different ways: default reports are designed for smaller tables (up to 50K rows), while explorations have higher limits (up to 10M events in the standard version of Google Analytics, and 1B events for the enterprise version), thus reducing the possibility of reaching the row limit.