Server-Side Tracking with GA4 and GTM: Why Conversions Go Missing

Your GA4 conversions are missing because the browser no longer reliably delivers tracking hits: ad blockers stop requests to Google domains, Safari shortens the life of tracking cookies, visitors decline consent, and some requests simply fail on slow networks. Server-side tracking with GA4 and GTM routes those hits through a server container on your own subdomain, which recovers part of the lost data and gives you control over what each vendor receives. It does not bypass consent, and it does not bring back users who said no.

Why client-side tracking under-counts conversions

In a classic setup, every tag runs in the visitor's browser and sends data straight to Google, ad platforms and other vendors. Every one of those requests can be lost along the way. The most common causes we see on audits:

• Ad blockers and privacy extensions. They block scripts and requests to well-known tracking domains, so the purchase happens but the hit never leaves the browser.
• Safari Intelligent Tracking Prevention (ITP). Cookies created by JavaScript are deleted after 7 days without user interaction, and when a visitor lands from a URL with click identifiers, those cookies are capped at 24 hours. A customer who clicks an ad on Monday and buys the following week often looks like a brand-new, unattributed user.
• Consent rejections. With Consent Mode, a "deny" means no analytics or ads cookies. That is correct behavior, but it shows up as a gap between your orders and your GA4 numbers.
• Network and page failures. Hits fired on the thank-you page get dropped when the user closes the tab, the page redirects too fast, or a mobile connection drops.
• Tag sprawl. Ten vendor scripts on one page slow it down and compete for the same events, which leads to misfires and double counting.

The result is a familiar picture: the CRM or the store shows one number of orders, GA4 shows fewer, and Google Ads shows yet another figure.

What server-side GTM actually is

Server-side Google Tag Manager adds a second container that runs on a server instead of in the browser. The page sends one data stream, usually the GA4 tag, to that server. The server container then decides which tags fire and forwards the data to GA4, Google Ads and other destinations.

Three things make it useful:

• Your own subdomain. Google strongly recommends running the tagging server on a first-party domain, for example data.yoursite.com, before it handles production traffic. Requests go to your domain rather than to a vendor's.
• First-party cookies set by the server. The server can set longer-lived cookies over HTTP instead of JavaScript. One caveat: if the subdomain points via CNAME to a third-party host or resolves to unrelated IP addresses, Safari can still cap those cookies at 7 days. Hosting setup matters.
• Data control. As Google puts it, only you have access to the data in the server until you choose to send it elsewhere. You can strip IP addresses, remove query parameters with personal data, or keep a vendor from receiving fields it does not need.

The same container can also accept data from apps and back-end systems, which makes it a natural hub for end-to-end analytics that ties ad clicks to CRM revenue.

Hosting options and what they cost

The server container needs somewhere to run. There are two realistic paths, plus a legacy one.

• Google Cloud Run. This is now the default when Tag Manager provisions a server automatically. Google's own guide recommends at least 2 instances in production to reduce the risk of data loss during an outage, autoscaling up to about 10 for heavier traffic. Google estimates each instance (1 vCPU, 0.5 GB memory, CPU always allocated) at roughly $45 per month at the time of writing, so a minimal production setup lands around $90 a month before logging. Request logging above roughly a million requests a month can add significant charges, so it is usually turned down.
• App Engine. The older option. Existing deployments still run, but Google's documentation now points to Cloud Run and advises disabling the App Engine app after migration to avoid unexpected billing.
• Managed hosting such as Stape. These services run the container for you and add the custom domain, monitoring and extras. At the time of writing Stape prices by monthly request volume: a free tier up to 10,000 requests, then paid tiers at 500,000, 5 million and 20 million requests, plus custom plans, with a discount for annual billing.

Self-hosting on Google Cloud gives full control and a single bill in your own project. A managed host is faster to launch and easier to maintain for a team without DevOps capacity. Either way, the hosting bill is usually small next to the ad spend it measures.

Consent Mode v2: what server-side does not fix

This is where many vendors oversell. Server-side tagging changes where data is processed, not whether you are allowed to collect it. Consent requirements apply to the server container exactly as they do to the browser.

Consent Mode v2 uses four signals: ad_storage, analytics_storage, ad_user_data and ad_personalization. Google enforces the last two for advertising use of data from European Economic Area traffic, and many US sites with international visitors or state privacy obligations implement them as well. The consent state travels from the page to the server container with each hit, and Google tags in the server respect it.

What server-side tracking will not do:

• Recover users who rejected cookies. Their data stays limited, and GA4 fills part of the gap only through its own modeling.
• Make a non-compliant setup compliant. If your banner or defaults are wrong, the server forwards the same problem.
• Fix broken events. If the purchase event fires twice or with the wrong value, the server faithfully passes the mistake along.

Sending conversions to ad platforms from the server

Once the server container is live, ad platform tags can move off the page. For Google Ads, the setup is a Conversion Linker tag plus a Google Ads Conversion Tracking tag in the server container. The tag reads transaction ID, value and currency from the ecommerce data automatically.

Enhanced conversions add hashed first-party data, such as the email or phone the customer entered at checkout, to the conversion. You collect it in the web container as user-provided data and pass it along as user_data; the server tag then sends it to Google, which improves matching when cookies are missing. Only send it when you have consent and a privacy policy that covers it.

Most major ad networks now offer a similar server-to-server conversions API, and the server container is the natural place to connect them. The pattern is the same: one event from the site, mapped and filtered on the server, then sent to each platform with only the fields it needs.

Data quality checks and deduplication

The most common mistake we see after a migration is double counting: the old browser tags keep firing while the new server tags send the same conversion. Google's own guide says to remove the duplicate Ads tags from the web container once the server tag is verified. Beyond that:

• Use a unique transaction ID. GA4 deduplicates web purchase events with the same transaction ID. Never send an empty value, and never reuse one ID across different orders, or GA4 will undercount.
• Share event IDs across channels. When a platform receives the same conversion from both browser and server, a shared event ID lets it keep one.
• Reconcile against the source of truth. Compare weekly orders in the store or CRM with GA4 purchases and Google Ads conversions. A stable gap is expected; a sudden jump means something broke.
• Test in Preview mode. Check both containers in Preview, confirm which tags fired, and read the console for transmission errors before publishing.
• Monitor the server. Set a billing alert and an uptime check. A stopped container means zero data, not partial data.

Client-side vs server-side vs hybrid

A practical rollout plan and how to choose

We usually roll out in this order:

• Audit first. List current tags, events and conversions, and measure the gap between orders and GA4. Fix event and consent issues in the web container before touching the server.
• Launch the server container on Cloud Run or a managed host, map a first-party subdomain, and route GA4 through it.
• Move Google Ads conversions and enhanced conversions to the server, then remove duplicate browser tags.
• Add other ad platforms through their server-side integrations with shared event IDs.
• Run both views in parallel for two to four weeks and reconcile against store or CRM data before switching bidding to the new numbers.

The decision rule is simple. If you spend meaningfully on paid ads and optimize bidding toward conversions, a hybrid server-side setup usually pays for itself in better signals. If you run a small site with little ad spend, a clean client-side GA4 setup with correct Consent Mode is enough for now. Either way, start with a solid GA4 and GTM implementation; if the audit shows real losses, our server-side tracking setup builds on top of it without starting over.