“I’m sure GA4 should be showing more visits than this.”
And what usually follows is not a question about tracking. It is a question about confidence.
Can I still trust the data I am seeing in GA4?
More marketing teams are telling us that GA4 numbers feel harder to defend internally. Traffic looks lower than expected, and certainly not what many teams were used to seeing in the Universal Analytics days. Conversions do not always match what sales or enquiries suggest. Reports take longer to explain, and conversations with senior stakeholders become more cautious.
It feels like there is a growing data gap, and instead of focusing on performance, marketing teams find themselves justifying the numbers.
In this article, I want to explain why that is happening, and what you can do about it.
I will cover:
- why more real user activity never reaches GA4
- why this problem is becoming more common
- how server side Google Tag Manager helps restore trust in your data
This is not about fixing a broken setup or blaming GA4. The way data is collected has changed, and many teams are still relying on an approach that no longer gives them the confidence they need when reporting to the wider business.
By the end of this read, you should have a clearer understanding of why your GA4 data feels harder to trust, and how moving tracking server side can help you report with confidence again.
So what is actually happening to your tracking data?
At this point, the obvious question is what is actually happening to your data.
Most websites still rely on client side tracking. That means analytics and marketing platforms collect data directly in the browser and send it straight to tools like GA4, Google Ads, and Meta.
For a long time, that worked well enough. Today, it helps to think about client side tracking like this. It is like a busy burger restaurant where:
- Customers place orders
- The kitchen serves the burger
- Money changes hands
But the order details are shouted across the restaurant to the bookkeeper, instead of being logged into the EPOS system.
In a loud, busy environment:
- some details are missed
- some are misheard
- some are not allowed to be shared
- and some never reach the books at all
At the end of the day, the restaurant feels busy, but the numbers do not fully reflect what actually happened.
Modern browsers are far more aggressive about blocking scripts. As a data reliant marketer, you are now up against consent tools that control what can be sent and when, network conditions that quietly drop information, and ad blockers that interfere unpredictably. All of this happens before GA4 ever sees the data.
The key problem is not knowing what you don’t know.
When data is lost before it reaches GA4, you have no visibility of what is missing. You only see what made it through. From a reporting perspective, this is where trust starts to break down. You are expected to explain performance, justify spend, and make decisions based on numbers that look complete, but are not.
The issue is not that GA4 is failing. It is that client side tracking is no longer reliable enough to capture or send everything that matters.
This is where server side GTM changes the picture
Instead of relying on the browser to send data directly to GA4 and other marketing platforms, server side GTM changes where that data is captured. Events are sent to your own server first, where they can be checked, structured, and forwarded on more reliably.
By routing events through a server side container, tracking no longer has to compete with everything else happening in the browser. It is essentially putting your tracking at the front of the queue.
That brings some immediate and practical benefits.
- First, data becomes more consistent. When events pass through one controlled environment, naming, structure, and timing are easier to manage. You see fewer unexplained drops and fewer surprises in reports. That makes it easier to validate tracking and troubleshoot issues.
- Second, pages become faster. With less work happening in the browser and fewer third party scripts loading on page view, performance improves without changing the user experience.
- Third, you regain control. You decide which platforms receive which data, and under what conditions. Consent rules can be enforced centrally, rather than relying on each individual script to behave correctly in every browser.
- Fourth, it supports better privacy and compliance. Because data passes through a single server side layer, consent rules can be enforced consistently and data sharing can be limited deliberately. This does not remove your compliance obligations, but it gives you far more control over how and when data is shared with third parties.
You are not trying to recover data after it has already been lost. You are changing the system so important data has a far better chance of being captured and recorded in the first place.
What moving to server side GTM actually involves
At this point, it is reasonable to wonder how big a change this is.
For most websites, this is not a rebuild or a big bang change. Moving to server side GTM is usually introduced alongside an existing setup and rolled out gradually. Teams often start with GA4 or a small set of critical events, validate the results, and expand from there.
From a reporting point of view, very little changes day to day. The main difference is improved consistency and confidence in the numbers being reported.
Most importantly, this is a controlled change. It can be tested, validated, and adjusted before anything is fully switched over.
A practical guide to setting up server side GTM
This section is not intended to be a full tutorial, but it does reflect the real steps involved in moving to server side GTM. The aim is to show what is involved and where the complexity sits.
1. Create a server side GTM container
The first step is to create a server side container in Google Tag Manager.
This is a separate container type that sits alongside your existing web container. Your current GTM setup continues to collect events in the browser. At this stage, nothing changes on the website itself.
When creating the container, you define basic details such as:
- the server name
- the region it will run in
- that this container is server based rather than web based
This container becomes the point where tracking data will arrive before being forwarded on.
2. Provision a server environment
A server side container needs somewhere to run.
For many teams, this means provisioning a tagging server using Google Cloud, which provides a managed option designed specifically for server side GTM. This avoids the need to build and maintain infrastructure manually, but still requires correct setup and configuration.
Other hosting approaches are possible, but the key point is that you now have a dedicated server endpoint ready to receive tracking data.
3. Route browser data to the server
Once the server container is live, your existing tracking needs to be updated so that data is sent to the server endpoint instead of directly to GA4 or other platforms.
This is done by changing where the browser sends its tracking requests. From the website’s point of view, events are still firing in the same way. From GA4’s point of view, data is still arriving as expected. The difference is that it now passes through your server first.
At this stage, preview and debug tools are essential to confirm that data is flowing correctly.
4. Configure GA4 and other platforms server side
Inside the server side container, clients and tags are configured to receive incoming events and forward them on to GA4 and other platforms.
This is where server side GTM starts to add real value. Data can be:
- validated
- cleaned up
- enriched
- limited based on consent
This can now all happen before it reaches your analytics and advertising tools. Done properly, your GA4 reporting becomes more consistent and reliable.
5. Integrate consent and enforce privacy rules
Server side GTM does not remove the need for consent management. Consent signals still need to be respected, but server side GTM allows them to be enforced centrally. Rather than relying on every client side script to behave correctly, rules can be applied at the server level to control what data is shared and when. This makes it easier to align tracking behaviour with privacy requirements across different regions and platforms.
6. Validate, monitor, and refine
Before fully switching over, you’ll definitely want to validate the setup and the results you’re getting carefully.
Events should be tested end to end. Check Consent preferences are behaving as they should. Review and compare your GA4 reports with previous data to ensure everything makes sense.
Server side setups also require ongoing monitoring. Changes to websites, tags, or consent rules can affect data flow, so regular checks are important, particularly after major updates.
Why teams often get help with this
On the surface, these steps look manageable. In practice, the complexity sits in understanding data flow end to end, enforcing consent correctly, and troubleshooting issues when platforms behave differently.
This is why many teams choose to work with a partner for server side GTM, even when they understand the process. If you’d like support with server side GTM, we’re always happy to talk through your setup and help you move forward with confidence.