Server-Side Tagging vs Client-Side GA4: What Actually Changes

How Client-Side Tracking Works

In a standard GA4 implementation, the Google Tag Manager container runs in the user's browser. When a user loads your page, their browser downloads the GTM script, executes it, and sends tracking data directly to Google's servers.

This architecture worked for over a decade, but three things changed: ad blockers now block 25 to 40 percent of tracking requests on many sites, browser privacy features such as Safari's ITP and Firefox's Enhanced Tracking Protection limit third-party cookie lifespans to seven days or less, and iOS 14.5+ App Tracking Transparency means roughly 75% of iOS users opt out of tracking entirely.

The result is that client-side tracking now misses a significant portion of user behaviour, particularly on mobile and among privacy-conscious audiences.

What Server-Side Tagging Changes

Server-side tagging moves the tracking logic from the user's browser to your own server, typically a Google Cloud Run container. The browser sends data to your domain, your server processes it, and then forwards it to Google Analytics and other destinations.

• First-party context: data is sent to your domain rather than google-analytics.com, so cookies are set first-party and can last far longer than the seven days browser restrictions allow.
• Ad blocker resistance: because the request goes to your own domain, most ad blockers do not block it. Data recovery rates of 15 to 30 percent are common.
• Data control: your server sees all tracking data before it leaves, so you can enrich it, redact personal data, or route it to several destinations.
• Reduced page weight: third-party scripts can come out of the browser entirely, with everything sent through one first-party endpoint.

What It Does Not Change

Server-side tagging is not a magic solution. It does not:

• Bypass consent requirements. GDPR and ePrivacy still apply: if a user does not consent to analytics, you cannot track them, server-side or otherwise.
• Recover iOS ATT opt-outs. Users who opt out at device level cannot be tracked through any web-based method.
• Fix bad data architecture. If your event taxonomy is inconsistent or your attribution model is flawed, server-side tagging will not help.
• Eliminate sampling. GA4 sampling happens at the reporting layer, not the collection layer, so it is unaffected.

The Real Business Case

Server-side tagging makes the most sense when your audience skews toward privacy-conscious demographics, you are running significant paid media and need accurate conversion data for optimisation, you want to send data to multiple platforms without adding more scripts, or you need EU data residency for the collection layer.

It makes less sense when your current tracking already captures more than 90% of conversions, your site is small with low traffic and no attribution complexity, or you do not have the technical resources to maintain the server infrastructure.

Implementation Costs

A typical server-side GTM implementation costs between €3,000 and €8,000 to set up depending on complexity, €30 to €150 per month for a Cloud Run container that scales with traffic, and two to four hours a month for monitoring and updates.

For most eCommerce businesses spending €10,000 or more per month on paid media, the improved conversion data alone justifies the investment within the first two to three months.

Getting Started

Before migrating, measure your current data loss. Compare GA4 session counts to your server logs or CDN analytics: if you are losing more than 20% of sessions, server-side tagging is worth investigating.

Start with your core conversion events such as purchases and sign-ups, and validate that server-side data matches your backend. Once you trust the data quality, migrate additional events and retire the client-side tags.