Let me clarify in the beginning of this article that this is neither a “teach GA4” post nor a post meant to be a ‘checklist’ of GA4 and Google Tag Manager (GTM) activities to be done while migrating a large and complex website. This is a practical, experience-led approach in GA4 (and GTM) migration on a large website from real-world experience.
The website is of a hotel business that has presence in 2 different countries, with many pages that talk about the rooms, restaurants, art cafes inside, special offers and others.
When it comes to GA4 migration, it is often considered as a technical event – install the GTM tag (where the GA4 code is already published) on the new platform, recreate the events, test in preview mode and in real-time and then move on.
For large and complex websites, with many pages and events to track, the approach generally fails. It is not because adding the GA4 code is difficult to do, but it is because of many years of accumulated tracking debt, poor event logic used, and unrealistic expectations about what analytics can actually measure and what it should measure.
This article will talk about how GA4 migration should be handled properly on a large and complex website, based on the hands-on experience working through the high-risk CMS migration of a complex hotel website and the subsequent analytics clean-up.
GA4 migration on large websites often fails because it is treated as a setup work and not as measurement work. Setting up GA4 on the new migration platform is often considered a simple procedure of adding the GA4 code or the GTM code on the website.
But the following make large websites more complex:
During the launch day, you can test all the events and see that they are firing and collecting data in GA4. You often get into the false impression that everything is working fine. But errors start to show up weeks later as:
That’s when questions arise on the accuracy of the numbers and the general trust on GA4 is lost. Therefore, the idea must be to plan the GA4 migration judiciously so that it can provide trustworthy data in the long run.
One of the most common, yet costly mistakes that is done while doing GA4 migration is copying the old tracking setup completely to the new platform. The problem is that the legacy GA4 and GTM setup often contains events that were created a long time ago, which may have lost its relevance and purpose.
There could also be redundant or duplicate triggers, multiple low-value events being considered as conversions, and tracking tied to outdated page structures – particularly as the new platform will have different coding models being used from the legacy platform.
When this old tracking setup is blindly copied to the new CMS platform, obsolete events will stay on, non-working triggers will remain, reporting noise increases, and thus analytic numbers become hard to interpret.
As someone who has done the tough work of GA4 migration for a complex hotel website, I can confidently say that more tracking does not always mean better tracking. It is exactly the time when you must look to remove tracking that isn’t necessary, to make GA4 tracking lean and robust.
Another mistake a lot of businesses make is looking at GA4 migration as an implementation issue alone. It is an over-simplification of a complex process. A robust GA4 migration process must start with making decisions on what needs to be tracked. If you track all the events, it would be difficult to manage and if you would fail to track important events, then it would affect marketing decisions your business would take in the future based on GA4 numbers.
Before a single tag is created on GTM to track an event, you must have clarity on
For our website, which is a complex website in the hospitality industry, engagement with the content was not always intent to buy, browsing more pages wasn’t a sign that conversion has happened, and volume of visit wasn’t equal to value.
You should have only a very limited number of events that are considered as key events in GA4 (which is like conversions in UA analytics). This step alone will eliminate a lot of confusion in the post-migration phase.
On the hotel website I was working on with GA4 migration, many low value, unimportant events were shown as key events that were not important for the business on the revenue front.
Marking them as key events will dilute the effectiveness of conversion tracking in GA4. You must consider GA4 migration as the perfect occasion to make sure that you have only events that result in revenue generation be marked as key events in GA4.
During the website migration of the above-mentioned hotel website, we noticed that pagespeed wasn’t where it should be, even after we did frontend optimization. We did a deeper investigation and found that one of the contributing factors was overloaded Google Tag Manager container.
Over time, a large number of tags and triggers had accumulated on the container – many of which were no longer relevant to reporting. To study the impact of the GTM container on pagespeed, we temporarily disabled all GTM tags on the staging site and tested page performance. Then we compared the pagespeed with that of the live website, where all tags were firing.
The difference made it clear that excessive and unprioritized tag execution was adding to the unnecessary load on the website. The fix wasn’t to optimize individual tags, but to remove non-essential tags and to control when the essential tags must fire during page load. Reducing non-essential tags not only improves data clarity but also contributes to better page speed and performance.
We had to spend a lot of time on testing this and fixing the issue. The better process was to plan and include only essential tags from the start of the project itself. So, if you are doing website migration, or you are starting to track events on a new website, the best possible method is to plan and list down only events that are essential for performance tracking.
When you migrate to a new platform, there will be a change in the way a page is built. For our website the change was from a static HTML site to an AEM CMS. The change will have a bearing on the event triggers we set on GTM because:
GTM setups that rely on brittle selector or page-specific logic rarely survive CMS migrations. There are often triggers that are based on texts, which could change during migration and may not work on the new setup. CSS selectors used in the old platform may have changed on the new CMS platform. Therefore, any triggers based on these old texts and CSS selectors may not work in the new GTM.
A proper GTM setup build based on the new CMS platform must focus on:
The goal of rebuilding GTM on the new platform must be to keep the tags firing for the long term and not to fire them only on the preview mode on GTM.
Be careful while using click text as trigger – One of the common mistakes in GA4 implementation (and migration) is relying on click texts as trigger conditions. Text labels often change during content updates, A/B testing, or CMS migrations (in our case, there were multiple occasions where the client wanted content changes after approving initial content). This makes click text triggers fragile and prone to breaking. A more reliable approach for triggers is to use CSS selectors or stable attributes, which are less likely to change. Use click text as a trigger only if other options aren’t available; but you must use due diligence.
Form tracking logic – Another mistake that happens often is using submit button clicks of an online form as the trigger. This can often lead to inaccurate data as there could be users who click on the submit button without completing required fields. The event will be fired though the form was not successfully submitted. A more dependable method is to trigger the event based on the “thank you” page or the success message, ensuring that only completed forms are triggering the event.
Ensure CSS selectors used are accurate – If there is a change from one CMS to another (or from a static site to a CMS), underlying HTML structures and CSS selectors often change, even if the frontend appears visually identical. This can silently break CSS based triggers in GTM. You have to revalidate all trigger conditions post-migration and update them wherever necessary, rather than assuming all existing tracking will continue as expected.
One of the issues with GA4 migration is that it is often difficult to realize as data failure is often silent. Real time data may look fine, but many other issues may occur, which are difficult to notice. There could be:
It is critical to do proper validation by spending considerable time and effort. You must test real user journeys and ensure GA4 is collecting data of events that are important for the business. Use DebugView in GA4, test and validate that right triggers are firing, right tags are activated, needed values are passed on to GA4.
The digital marketing team or the team that handles GA4 migration must verify behaviour of GA4 and GTM before and after the deployment. It is also important to document known limitations instead of hiding them.
The documentation is important so that all the stakeholders understand and agree upon the limitations of the data collected via GA4. If you are working for a client, such documentation can also help in clarifying information that could help in future communication with the client regarding GA4 data.
Not using correct UTM parameters in campaign URLs and subsequent misattribution of traffic to ‘Unassigned’ source is not always a GA4 migration issue. It can happen even when you are using a legacy system for collecting data, if the right UTM parameters are not used.
But GA4 migration is a great time to revisit the use of UTM parameters in campaign URLs. You are anyways looking for a reset with the migration, and you can use the occasion to reset your campaign measurements with the use of proper UTM parameters.
A GA4 migration generally exposes:
You must keep in mind that GA4 is stricter than the UA platform and it doesn’t guess. If it is unable to attribute traffic to the right sources, it will assign all such traffic to ‘Unassigned’ source. Means, if your campaign discipline is weak, GA4 will expose it and attributing most of the traffic to ‘Unassigned’ doesn’t make anyone wiser.
Fixing campaign URLs using the right UTM parameters is less about GA4 migration and configuration and more about standardising how campaigns are tagged.
Many websites use external platforms to complete transactions, particularly in the hospitality industry. It is a common practice for websites, including the one where I was working on, to just use the brand website to showcase the facilities, while using external booking platforms for completing transactions.
This makes it imperative that we add cross domain tracking in GA4. During migration, this factor poses many challenges as well, like:
GA4 cannot magically solve these issues. The GA4 practitioner must spend time and energy to analyse the issues and find the right solutions. It involves a lot of testing in the DebugView of GA4. You must ensure that the session ID that is passed on to GA4 is the same while the user is on the property website and when the user moves on to the external booking platform.
In a realistic GA4 migration, when cross domain linking is present, the final revenue truth lies elsewhere and not on the property website. Making sure that the session continues from the property website to the booking platform is imperative to ensure right attribution of revenue to traffic sources. This is a crucial step as your future marketing plans and advertising budget allocation depend on realising which traffic source gives you the best result.
Now the pertinent question is what is a safe GA4 migration framework? There is no doubt that a safe GA4 migration is critical to any website migration, and as a natural extension, to the success of the business.
Here is the disciplined framework for GA4 migration.
Audit what exists before migration – One of the most important steps is to audit and make a document on what exists before GA4 migration. This step is very important so that you don’t forget to add any event that is critical to the business post-migration. It is worthwhile to create an excel sheet that maps all tags, their subsequent triggers and the variables that each tag is passing to GA4.
Define what is important to track going forward – As mentioned earlier, GA4 migration is a perfect time to take a re-look at what is important to track and what is not. It is not always about copy-pasting all the earlier tags and triggers to the new platform. Analyze and decide on the important events that need to be tracked and remove events that are not important to be tracked. It is critical that you discuss this step with all the stakeholders. They will have the best idea about what is important to track and what is not.
Implementing the new platform in mind – Implementing the new triggers and tags with the new platform in mind is perhaps the most critical aspect of GA4 migration. Here you must ensure that the events that are being tracked have the right triggers to fire the tag. With the change in platform, the triggers that were used earlier would have gone obsolete. You must create new triggers with the new platform in mind. On the website I worked on, with the AEM as the platform, I had to get the help of developers to find and implement the correct triggers for each event. When you do it practically, it is true that there would be triggers that don’t need change.
Validate and test the new GTM setup – Now that the tags and triggers for the events to be tracked are created on GTM, you need to test and validate them. It is critical to create a staging environment on GTM and deploy the code in that environment and test. You must validate each tag separately and ensure they are triggering at the right conditions. While doing so, also ensure there are no duplicate firing of the tags. (Expert tip: create separate environments in GTM for staging, testing and QA, so that you don’t accidentally publish tags and triggers to the live website).
Document decisions and limitations – Document every step in the GA4 migration process from audit in the beginning to the result of the testing and validation done on the staging environment in GTM. What are the events being tracked, why are they getting tracked, what are the triggers used for specific tags, the variables that are used and values that are passed to GA4 – all these factors must find a mention in the document. The document must also mention the limitations of GA4 and GTM and the reasons for it. This document will be the source of truth for all future references on GA4 and GTM, hence try to be as comprehensive as possible.
During website migration, it would be a mistake if you think that you can simply move your existing GTM setup to the new website.
When I started working on the website migration of the hotel website, the GTM container had accumulated a lot of tags, triggers and variables over time. Many of those were made for outdated campaigns, obsolete website elements or legacy analytics requirements (like the old UA analytics code).
Looking at the GTM container was overwhelming and trying to migrate everything blindly without documentation would have created unwanted risks.
Before building anything or migrating any tags, I started with a detailed spreadsheet that mapped all tags, triggers and variables. It contained
The spreadsheet helped me in classifying tracking into the following categories.
Obsolete tags that needed to be removed – For example, legacy Universal Analytics tracking that had no place in the new setup.
Tags that could be carried forward as-is – These were still relevant and worked without requiring major changes.
Tags that needed re-evaluation – These required new triggers, updated logic, or adjustments based on the new website architecture.
This spreadsheet saved significant implementation time later as I had complete control over the tags and triggers used for event tracking in the website.
On reading this article you might wonder if all GA4 migration is a complex process. Having worked on GA4 migration for many websites, I can confirm that it is not the case for all website migrations. This approach is not for:
However, with websites that have more pages and cross domain linking, GA4 migration framework becomes more complex. The process explained in this article is for:
If analytics accuracy is important for your business, its revenue generation and for marketing decision making, then this approach is essential.
Now the question arises, why work with a GA4 and GTM migration specialist for your website. The answer lies in the fact that there is a difference between installing GA4 and migrating GA4 to another platform for a complex website.
For GTM and GA4 migration on a complex website, the person needs judgment, restraint, comfort explaining limitations to the stakeholders, and above all, the experience to handle failures and errors in GA4 migration.
For a business, bad data costs more than expert help, though it can often hide the loss.
If you are planning for GA4 migration for your hospitality industry website, or you’re questioning the integrity of the post-migration GA4 data, then the first step to take is an audit.
An audit can identify what should be kept, what should be removed, what has the probability of breaking and what stakeholder expectations need resetting. Only after doing such a thorough audit, can you think about or plan for the implementation of the GA4 migration.
GA4 migration is often considered as a technical process. But it is a measurement reset. If done poorly, it will create confusion that will last for many years. However, if done properly, it can create confidence that supports effective decision making.
0 Comments
Add a comment
By using form u agree with the message sorage, you can contact us directly now