Server-Side Tagging: Architecture, Setup, and Use Cases

Why Server-Side Tagging Exists

Traditional client-side tagging loads JavaScript in the user's browser, which means every tag competes for bandwidth, ad blockers can strip tracking scripts, and browsers increasingly limit cookie lifetimes. Server-side tagging moves the data collection endpoint to infrastructure you control, solving three problems at once:

• Performance -- fewer third-party scripts in the browser means faster page loads and better Core Web Vitals
• Data quality -- server-to-server requests bypass ad blockers and Intelligent Tracking Prevention (ITP), recovering 10-30% of lost events
• Privacy control -- you see and filter every data point before it reaches third-party vendors, making consent enforcement reliable

Client-Side vs. Server-Side Architecture

In a client-side setup, the browser sends requests directly to Google Analytics, Meta, LinkedIn, and every other vendor. Each vendor loads its own JavaScript, sets its own cookies, and makes its own network requests.

In a server-side setup, the browser sends a single request to your first-party endpoint. Your server processes that request and fans it out to vendors on the backend:

Client-Side:
  Browser -> google-analytics.com
  Browser -> connect.facebook.net
  Browser -> snap.licdn.com

Server-Side:
  Browser -> collect.yourdomain.com (your server)
    Server -> google-analytics.com
    Server -> graph.facebook.com
    Server -> api.linkedin.com

The browser only talks to your domain. Third-party vendor scripts never load in the browser at all.

GTM Server-Side Container Setup

Google Tag Manager's server-side product is the most common way to implement this pattern.

Infrastructure

A GTM server-side container runs on a server you provision. Google offers three deployment options:

1. App Engine (GCP) -- managed hosting on Google Cloud. Automatic scaling, simplest setup. Costs roughly $40-120/month for moderate traffic.
2. Cloud Run (GCP) -- containerized, scales to zero when idle. More cost-efficient for low-traffic sites.
3. Manual Docker deployment -- run the container image anywhere (AWS, Azure, your own servers). Full control, more operational overhead.

Provisioning Steps

1. In GTM, create a new container and select Server as the target platform.
2. In the container settings, click Manually provision tagging server.
3. Copy the container config string.
4. Deploy the server image with the config string as an environment variable:

docker run -d \
  -p 8080:8080 \
  -e CONTAINER_CONFIG='YOUR_CONFIG_STRING' \
  gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable

The server will listen on port 8080 and process incoming measurement requests.

Custom Domain for First-Party Collection

For server-side tagging to bypass ITP and ad blockers effectively, the tagging server must run on your own domain. Set up a subdomain like collect.yourdomain.com or sst.yourdomain.com and point it at your server via a CNAME or A record.

collect.yourdomain.com  CNAME  your-server.a]pp.run

When the browser sends data to collect.yourdomain.com, the request is treated as first-party. Cookies set in the response get the full first-party lifetime instead of being capped at 7 days by Safari's ITP.

How the Client-Server Flow Works

1. The browser loads a lightweight GA4 or custom tag that sends data to your first-party endpoint (collect.yourdomain.com).
2. The GTM server-side container receives the HTTP request.
3. A Client in the server container parses the incoming request. The GA4 Client parses Measurement Protocol hits. You can build custom Clients for other formats.
4. The Client creates an event data object -- a standardized representation of the hit.
5. Tags in the server container read the event data and forward it to destinations: Google Analytics, Meta CAPI, LinkedIn CAPI, ad platforms, data warehouses, or any HTTP endpoint.

Common Server-Side Use Cases

GA4 Server-Side

The most common setup. The browser sends hits to your first-party domain instead of directly to google-analytics.com. The server container's GA4 tag forwards the data to Google. Benefits: first-party cookies with longer lifetimes, reduced ad blocker impact, and the ability to enrich or filter events before they reach GA4.

Meta Conversions API

Instead of running the Meta Pixel in the browser, send events from your server to Meta's Conversions API endpoint. The server container strips unnecessary data, adds hashed user identifiers, and posts to graph.facebook.com. Use deduplication with event_id if you still run the browser pixel as a fallback.

Ad Platform API Events

The same pattern works for LinkedIn CAPI, TikTok Events API, Pinterest API for Conversions, and Snapchat CAPI. Each has a server-side tag template available in the GTM Community Template Gallery.

Data Warehouse Streaming

Add a tag that sends event data to BigQuery, Snowflake, or your own API. This gives you a raw event stream that is not subject to platform sampling or retention limits.

What You Can Do on the Server

The server-side container sits between the browser and vendors, which lets you:

• Redact PII before it reaches third parties (strip email from URL parameters, remove IP addresses)
• Enrich events with server-side data (user segment, LTV, CRM data) that you would never expose in the browser
• Enforce consent by only forwarding events to vendors the user has consented to, regardless of what the client-side code does
• Set first-party cookies with HttpOnly and Secure flags from the server response, giving you control over cookie attributes

Cost Considerations

Server-side tagging adds infrastructure cost that client-side does not have:

The cost scales with request volume, not page views. Each event your browser sends to the server is one request. A page that fires 5 events generates 5 requests.

When to Use Client-Side vs. Server-Side

Stay client-side when:

• Your site has low traffic and the infrastructure cost is not justified
• You need rapid deployment of new tags without server changes
• The tags you run are lightweight and not blocked by browsers

Go server-side when:

• Ad blockers are causing significant data loss (check by comparing server logs to analytics counts)
• You need to comply with privacy regulations that require data filtering before third-party transmission
• Page performance is suffering from too many third-party scripts
• You want first-party cookie control to extend cookie lifetimes in Safari and Firefox

Hybrid approach (most common): Keep a minimal client-side GTM container that sends data to your server-side endpoint. The browser loads one script and makes one request. The server fans out to all vendors. This gives you the best balance of implementation speed and data quality.