As privacy regulations tighten and browser vendors implement aggressive Intelligent Tracking Prevention (ITP) protocols, traditional client-side analytics are becoming increasingly unreliable. Modern ad blockers and privacy-focused browsers (like Brave or Safari) actively block third-party tracking scripts—including the standard Google Analytics 4 (GA4) gtag.js library—from loading in the user’s browser. To restore data visibility and regain control over first-party data without violating user privacy legislation, enterprise marketing engineers must migrate from client-side pixel tracking to Google Tag Manager (GTM) Server-Side tagging containers.
The Client-Side Vulnerability
In a traditional GTM deployment, a JavaScript container is injected into the client’s browser. When a user completes a purchase, the browser executes the script, which fires HTTP requests directly to Google Analytics, Facebook Pixel, or TikTok Ads. Because these requests originate from the user’s browser and target known tracking domains (e.g., www.google-analytics.com), ad blockers easily intercept and drop the packets. Consequently, marketers lose up to 30% of their conversion data, wreaking havoc on algorithmic ad bidding strategies.
The Server-Side Architecture
Server-Side GTM fundamentally alters the data flow. Instead of the user’s browser communicating with dozens of third-party vendors, it communicates with exactly one endpoint: a secure, first-party server that you control (typically hosted on Google Cloud Run or App Engine).
When a user triggers an event, the browser sends a single, anonymized data stream to your sub-domain (e.g., metrics.yourcompany.com). Because this request targets a first-party domain, ad blockers and ITP mechanisms generally permit it. Once the data reaches your secure server container, the server processes the event, strips out Personally Identifiable Information (PII) or IP addresses to ensure GDPR compliance, and then the server securely dispatches the data to GA4 or Facebook via their respective backend APIs.
Deploying the Server Container
To implement this, you must operate two distinct GTM containers: your existing Web container and a new Server container.
- Navigate to tagmanager.google.com and create a new container. Select Server as the target platform.
- GTM will provide a provisioning string. You can automatically deploy the server environment to Google Cloud Platform (GCP) using the default App Engine configuration, or manually deploy it to AWS or Azure using Docker.
- Once deployed, map a custom subdomain (e.g.,
collect.example.com) to the GCP server instance using a CNAME DNS record. This custom domain is the critical component that bypasses ad blockers.
Configuring the Web Container Routing
Return to your existing Web container. You must instruct it to stop sending data to Google and start sending data to your new server endpoint.
- Open your primary GA4 Configuration Tag.
- Check the box for Send to server container.
- Input your new first-party endpoint URL (
https://collect.example.com).
Publish the Web container. Now, all GA4 event data originates from the browser but terminates at your secure cloud server.
Configuring the Server Container Processing
Finally, open the Server container workspace. You must set up a Client to receive the incoming data, and Tags to distribute it.
- Navigate to Clients. Ensure the default GA4 client is active. This client listens for the incoming HTTP requests from your Web container and parses the payload into an Event Data object.
- Navigate to Tags and create a new Google Analytics: GA4 tag.
- Set the trigger to fire on all events claimed by the GA4 Client.
- Input your GA4 Measurement ID.
When you publish the Server container, the architecture is complete. Your server now acts as a highly secure, privacy-compliant proxy. It successfully captures 100% of the first-party conversion data by bypassing client-side ad blockers, sanitizes the payload, and reliably transmits the analytics data via backend server-to-server APIs.