- Discover why ad blockers and browser privacy rules leave conversions missing from your reports.
- Learn six steps to implement server-side Google Tag Manager tracking on your own domain.
- Compare hosting options and avoid tracking mistakes involving consent, duplicate conversions, and bot traffic.
Your ad platform says 80 conversions. Your store says 100 orders. Your analytics tool says 70 sessions ended in a purchase. All three are "right", and none of them is the full picture.
A large part of that gap comes from the browser. Ad blockers, privacy extensions, and built-in browser rules stop tracking scripts from loading or from sending data. The result is missing conversions, shorter attribution windows, and ad campaigns that learn from incomplete data.
Server-side tagging with Google Tag Manager (GTM) is the most common fix. This guide explains why the data goes missing, how server-side tagging works, how to set it up, and what to watch out for.
Start with free Canva bundles
Browse the freebies page to claim ready-to-use Canva bundles, then get 25% off your first premium bundle after you sign up.
Free to claim. Canva-ready. Instant access.
1. Why Ad Blockers and Browsers Drop Your Conversion Data
Classic tracking is client-side. The visitor's browser loads a script from a third-party domain, runs it, and sends events straight to Google Analytics, Google Ads, Meta, and other platforms. Every step happens on a device you do not control.
1.1 Ad blockers match known tracking domains and file names
Most ad blockers and privacy extensions work from public filter lists. Those lists contain the domains and paths that tracking tools use, such as googletagmanager.com/gtm.js, gtag/js, and the GA4 collect endpoint. When the browser tries to load or call one of them, the request is cancelled. Nothing reaches your analytics, and no error shows up in your reports. The visit simply does not exist.
1.2 Browsers shorten the life of tracking cookies
Even when the script loads, the browser can limit what it remembers. Safari's Intelligent Tracking Prevention caps cookies that JavaScript sets in the browser at seven days, and less in some cases. Firefox and Brave apply their own protections. If a customer clicks an ad on Monday and buys ten days later, the click and the purchase may never connect.
1.3 Bots inflate the numbers you do see
The opposite problem also exists. Crawlers, scrapers, and automated tests run your tracking code and create sessions that never had a person behind them. So your reports lose real visits and gain fake ones at the same time.
2. What Server-Side Tagging Changes
With server-side tagging, the browser no longer talks to every vendor directly. It sends one stream of events to a server that you control, on a subdomain of your own site, such as data.yourstore.com. That server runs a GTM server container. The container receives the events, cleans or enriches them, and forwards them to Google Analytics 4, Google Ads, Meta's Conversions API, and any other platform you use.
This changes three things:
- Requests go to your own domain. A call to
data.yourstore.comis a first-party request. It does not match the third-party domains on blocker filter lists. - Cookies are set by your server. A cookie set by your own server on your own domain is a first-party cookie. It is not subject to the same short limits as cookies set by a third-party script.
- You decide what leaves. The server container sees every event before the vendors do. You can remove personal data, add data from your own systems, and drop traffic that is clearly automated.
One point is important: server-side tagging is not a way around a visitor's consent. If a visitor says no to marketing cookies, the server container must respect that choice. Keep Consent Mode and your consent banner connected to the server setup.
3. How to Set Up Server-Side Tagging in Google Tag Manager
The setup has six steps. Plan for a few hours if this is your first time.
3.1 Step 1: Create a server container
In Google Tag Manager, create a new container and select Server as the type. GTM gives you a container configuration string. You need it to start the server.
3.2 Step 2: Choose where the container runs
A server container is a small application that must run somewhere, around the clock. You have two main options:
- Host it yourself on Google Cloud. Google's default path deploys the container to Cloud Run. You manage the project, the scaling settings, the logs, the billing, and updates.
- Use a managed host. A managed host runs the container for you. You paste the configuration string, pick a region, and the host handles servers, scaling, and updates.
Self-hosting gives you full control. Managed hosting removes the maintenance work, which matters more for small teams and agencies with many client sites.
3.3 Step 3: Put the container on your own subdomain
Create a subdomain such as data.yourstore.com or t.yourstore.com and point it at the server with a DNS record. This is what makes every request first-party. Do not leave the container on the host's default domain: that removes most of the benefit.
3.4 Step 4: Serve the GTM script from your own domain
Many teams stop after step 3 and still lose data. The browser still downloads gtm.js from googletagmanager.com, and that is exactly the file blockers stop first. If the script never loads, no event reaches your server.
Serve the GTM loader through your own subdomain instead. Some hosts go a step further and serve it under a random file name, so filter lists that match common paths do not catch it.
3.5 Step 5: Send events to the server container
In your web container, set the Google tag's server_container_url to your subdomain. GA4 events then go to your server container first. In the server container, the GA4 client receives them, and you add server tags to forward them:
- a GA4 tag for Google Analytics,
- a Google Ads conversion tag for your purchase and lead events,
- a Meta Conversions API tag for Meta ads.
If you also keep the Meta pixel in the browser, send the same event_id from both, so Meta removes the duplicates.
3.6 Step 6: Test and compare
Use the server container's preview mode to watch events arrive and leave. Then compare one week of conversions in your ad platforms with your order system, before and after. The gap will not close to zero, but it should shrink, and your attribution should become more stable.
4. Self-Hosting vs. Managed Server-Side GTM Hosting
Here is how the two options compare for most teams:
| Self-hosted (Google Cloud) | Managed hosting | |
|---|---|---|
| Setup time | Several hours, cloud knowledge needed | Minutes to an hour |
| Ongoing work | Updates, scaling, monitoring, billing | Done by the host |
| Cost model | Pay per cloud resource; varies with traffic | Fixed monthly plans by request volume |
| Custom loader and bot filtering | Build it yourself | Often included |
| Best for | Teams with in-house cloud engineers | Marketers, small teams, agencies |
A managed option is sGTM - Server Side Tracking Google Tag Manager, from sGTM.space. It runs your server GTM container on a subdomain of your own site, with no servers to manage, and it is usually live in about ten minutes. Its Better Loader serves GTM from your domain under a random script name on every plan, including the free one, and paid plans add edge bot filtering, so clearly automated traffic is turned away before it reaches the container. If you already run a server container somewhere else, moving it is a DNS change. The free plan covers one container and 15,000 requests a month, which is enough to test the setup on a small site.
5. Common Mistakes to Avoid
- Keeping the GTM script on Google's domain. The server container never sees the events that blockers stop at the first step. Serve the loader from your subdomain.
- Using the host's domain instead of your own. Requests to a shared third-party domain are not first-party. Always map your own subdomain.
- Ignoring consent. Server-side tagging must follow the same consent rules as browser tagging. Pass consent state to the server and respect it there.
- Sending duplicate conversions. When both the browser and the server send the same event to Meta or another platform, deduplicate with a shared event ID.
- Forwarding bot traffic. Moving bad traffic to the server does not make it real. Filter clearly automated requests before they reach your tags.
- Never checking the numbers again. Compare platform conversions with your back-end orders every month. A sudden drop usually means a broken tag or an expired setup.
6. Final Thoughts
Missing conversions are not only a reporting problem. Ad platforms optimize on the conversions they receive, so every lost purchase makes your bidding a little worse.
Server-side tagging with Google Tag Manager moves your tracking to your own domain, gives you control over what each vendor receives, and recovers much of the data that blockers and browser rules drop, while still respecting consent. Start with one container on your own subdomain, serve the GTM script from that domain, forward your key conversions, and compare the numbers after a week.
