Last updated: April 2026
If you are running Google Ads or Meta Ads and relying entirely on client-side tracking, a significant portion of your conversion data is disappearing before it ever reaches your ad platform.
Ad blocker penetration on desktop now exceeds 40%. Marketing teams relying solely on client-side tracking see 20 to 40% fewer conversions than actually occurred. The campaigns you think are underperforming may simply be under-reported.
Server-side tracking is the fix. This guide explains what it is, why it matters for your ad performance, and how to set it up using Google Tag Manager and TAGGRS, the infrastructure Coby Agency uses for every client setup.
What Is Server-Side Tracking and Why Does It Matter?
Standard tracking works like this: a visitor lands on your website, JavaScript fires in their browser, and that code sends conversion data to Google or Meta. The problem is that the browser has become an unreliable messenger.
Safari limits first-party cookies to seven days. Firefox blocks cross-site tracking by default. Ad blockers strip tracking scripts before they fire. iOS App Tracking Transparency has made mobile attribution unreliable for a large portion of users. Each of these restrictions removes another slice of your conversion data.
Server-side tracking removes the browser from the equation. Instead of firing tags in the visitor’s browser and hoping they reach Google or Meta, your website sends the event data to your own server. Your server then forwards that data directly to the ad platforms via their APIs. Ad blockers cannot block a server-to-server request. Browser privacy settings have no effect. The data arrives reliably regardless of what the visitor’s browser is doing.
A simple way to think about it: client-side tracking sends many small packages directly from the visitor’s browser to every platform simultaneously, with no control over what gets lost in transit. Server-side tracking sends one package to your own server, where you control what gets forwarded, to whom, and in what format.
The Business Case for Server-Side Tracking in 2026
The performance implications are direct. Marketing teams often discover 20 to 40% more conversions when they implement proper server-side tracking alongside their existing pixels. That additional data feeds directly into Smart Bidding on Google and Advantage+ on Meta. Both platforms optimise based on the conversion signals they receive. More complete signals produce better campaign performance.
Server-side tracking adoption has reached 67% among B2B companies in 2026, and data quality improves by an average of 41% after migration. Cookie lifetimes extend from seven days under Safari’s Intelligent Tracking Prevention to first-party durations of 90 to 400 days, and ad blocker bypass rates approach 95% because requests originate from your own domain rather than a known tracking domain.
Beyond performance, server-side tracking gives you control over your data. You decide what gets sent to each platform. Sensitive data can be hashed or removed before it leaves your server. Consent signals can be enforced at the server layer rather than relying on client-side scripts that users can circumvent.
What You Need Before You Start
Before setting up server-side tracking, you need the following in place:
A Google Tag Manager web container already configured on your website. This is where your existing client-side tags live and where you will make changes to route data through the server.
A GA4 property set up and sending data through your GTM web container. GA4 is the bridge between your web container and server container. Events flow from your website to GA4, and the server container intercepts that flow.
A TAGGRS account at taggrs.io. TAGGRS hosts your server-side GTM container, handling the cloud infrastructure so you do not need to manage your own Google Cloud or AWS setup. It is the infrastructure Coby Agency uses across all client accounts.
A custom subdomain on your website (for example, gtm.yourwebsite.com). This is where your server container will be accessible, making tracking requests appear to come from your own domain rather than a third-party tracking service.
Coby’s Server-Side Tracking Setup Process
This is the exact process we follow when setting up server-side tracking for a new client.
Step 1: Create a TAGGRS Account and Project
Go to taggrs.io and create an account. Inside your dashboard, click “Add new setup” and configure your project. You can choose between automatic setup via Google Sign-In or manual setup. The automatic option is faster and connects directly to your Google account, pulling in your existing GTM containers.
Give the project a clear name linked to the client or website. Everything related to that tracking setup lives inside this project.
Step 2: Create a Server GTM Container
Inside Google Tag Manager, go to your account and create a new container. Under “Target platform”, choose Server. Then select “Manually provision tagging server”.
GTM will display your container configuration code. Copy this, you will need it in the next step.
Go back to TAGGRS and paste the configuration code into your project setup. TAGGRS uses this to provision the server infrastructure that will host your GTM server container.
Step 3: Configure Your Custom Subdomain
In TAGGRS, navigate to the domain routing section of your project. You will create a CNAME record pointing your subdomain (for example, gtm.yourwebsite.com) to your TAGGRS server address.
Add this CNAME record in your DNS settings, which you can access through your hosting provider. For Coby Agency clients on mijn.host, this is done through the DirectAdmin control panel under DNS Management.
Once the DNS propagates, typically within a few hours, your server container will be accessible via your own domain. This is what makes server-side tracking resistant to ad blockers. The tracking requests appear to come from your own domain, not from google-analytics.com or a known tracking service.
Step 4: Update Your GA4 Tag in the Web Container
In your GTM web container, open your existing GA4 Configuration tag (or Google Tag). You need to add one parameter that routes events through your server container.
Add a configuration parameter called server_container_url with the value of your TAGGRS subdomain (for example, https://gtm.yourwebsite.com).
This single change tells GA4 to send its events to your server container first, rather than directly to Google Analytics. The server container then processes the events and forwards them on.
Save the tag and publish your web container.
Step 5: Configure the Server Container
Inside your GTM server container, you need to set up the tags that will receive and forward events. TAGGRS provides pre-built templates for the most common setups, available directly in the server container’s template gallery. For ecommerce companies, there are ready-made templates for GA4, Google Ads, and Meta Conversions API with ecommerce event mapping already configured. For lead generation companies, templates cover form submission events, phone call tracking, and CRM integration. Using these templates cuts setup time significantly compared to building tags from scratch.
The key tags for most accounts are:
GA4 Server-side tag: receives events from your web container and sends them to Google Analytics. Add your GA4 Measurement ID and configure it to fire on all GA4 events.
Google Ads Conversion tag: receives conversion events and sends them to Google Ads. Add your Conversion ID and Conversion Label for each conversion action you are tracking.
Meta Conversions API tag: receives purchase, lead, and other conversion events and sends them to Meta via the Conversions API. This is the server-side equivalent of the Meta Pixel, and it fires even when the Pixel in the browser is blocked.
Use constant variables in GTM to store your Measurement IDs, Conversion IDs, and Pixel IDs so you only need to enter them once and can reference them across multiple tags.
Step 6: Test Your Setup
Before going live, verify that data is flowing correctly.
Open GTM Preview mode on your web container and trigger some events on your website. Then open the Preview mode on your server container in a separate tab. You should see the same events appearing in both containers, confirming that your web container is routing events to the server.
Check that the tags in your server container are firing correctly and returning 200 success responses. Any 400 or 500 errors indicate a configuration issue that needs resolving before you publish.
Compare the events appearing in your GA4 DebugView with what you see in the server container. They should match.
Step 7: Publish and Monitor
Once testing confirms everything is working, publish your server container. Your tracking is now live.
In the first two weeks after going live, compare your Google Ads conversion volume against the previous two-week period. For most accounts, you will see an increase in recorded conversions as the server-side setup captures events that client-side tags were missing.
Set up a monthly audit to check that server container tags are still firing correctly, that your subdomain CNAME is resolving properly, and that conversion volumes remain consistent with your CRM data.
Client-Side vs Server-Side: Running Both in Parallel
An important clarification: server-side tracking does not replace client-side tracking. It runs alongside it.
Your GA4 web tag and Meta Pixel continue to fire in the browser for visitors who have not blocked them. The server-side setup catches the conversions that those browser-based tags miss. The two systems together give you the broadest possible coverage.
One thing to watch for: event deduplication. If both your browser-based Pixel and your Conversions API tag fire for the same conversion, Meta will count it twice unless you pass a consistent event ID to both. Configure your web container to generate a unique event ID for each conversion and send the same ID through both the Pixel and the CAPI tag. Meta uses this to deduplicate and count the conversion only once.
Google handles this automatically through the GCLID parameter, but verify in your Google Ads account that you are not seeing unusual spikes in conversion volume after enabling server-side that might indicate double counting.
Frequently Asked Questions
Is server-side tracking difficult to set up? It is more complex than adding a standard GTM tag, but it is manageable with a clear process. The main steps, creating a TAGGRS project, setting up the server container in GTM, configuring your subdomain, and updating your GA4 tag, take a technical marketer one to two days to complete correctly. The ongoing maintenance after that is minimal.
Do I still need the Meta Pixel if I have server-side tracking? Yes. Run both the Meta Pixel in the browser and the Meta Conversions API through your server container in parallel. The Pixel fires for users who have not blocked it. The CAPI captures conversions the Pixel misses. Use event deduplication with consistent event IDs to prevent double counting. The combination gives you significantly better coverage than either approach alone.
Will server-side tracking affect my website speed? It improves it slightly. Client-side tracking loads multiple third-party scripts in the visitor’s browser, each adding page weight. Server-side tracking consolidates those requests into a single data stream sent to your own server, reducing the number of scripts loading in the browser. The performance improvement is typically small but measurable.
Is TAGGRS the only option for hosting a server container? No. You can also use Stape.io, your own Google Cloud setup, or other cloud providers. Coby Agency uses TAGGRS because it is designed specifically for GTM server container hosting, has a clean dashboard for managing multiple client setups, and handles the technical infrastructure without requiring cloud engineering knowledge.
Does server-side tracking comply with GDPR? Yes, when configured correctly. Server-side tracking does not bypass consent requirements. It gives you more precise control over consent enforcement. You can configure your server container to only forward data to ad platforms when the user has given the appropriate consent. Consent Mode V2 integrates directly with server-side containers, allowing cookieless pings to be sent for modelling purposes when a user declines analytics cookies, without sending personal data.