Server-Side Google Tag Manager for Healthcare: Configuration Guide

Kaiser Permanente's $47.5 million settlement started with tracking code that had been running for seven years. The code did exactly what it was designed to do: send data to Google, Meta, Microsoft, and X. The problem wasn't a misconfiguration. It was the architecture itself. When tracking runs in the browser, every page view, search term, and form interaction is visible to every third-party script on the page. That is the model server-side Google Tag Manager was built to replace.

Server-side GTM (sGTM) has become a popular recommendation in healthcare compliance circles. It moves tag execution from the visitor's browser to a server you control, reducing the surface area for data leakage. That is a meaningful improvement. But "reducing" and "eliminating" are different words, and in healthcare compliance, the gap between them can be worth millions of dollars and years of regulatory scrutiny.

This guide covers how server-side GTM works, how to set it up for a healthcare environment, where it falls short of full compliance, and what you need to pair it with to close the remaining gaps.

How Server-Side GTM Changes the Tracking Model

Standard Google Tag Manager runs entirely in the visitor's browser. When someone visits your website, the GTM container loads a JavaScript bundle that fires tags for Google Analytics, Meta Pixel, LinkedIn Insight, and whatever else your marketing team has added. Each of those tags makes its own network request from the browser to the respective platform. The browser is doing all the work, and it is doing it in plain sight.

This means every tag has access to the full browser environment: the URL (which may contain condition names or appointment types), cookies, form fields, referrer data, and the DOM itself. In a healthcare context, this is the root of the problem. A URL like /providers/oncology/schedule-appointment combined with an IP address creates a data combination that regulators and courts have treated as protected health information.

Server-side GTM introduces a middle layer. Instead of the browser sending data directly to Google, Meta, and other platforms, it sends a single request to a server container you operate. That server container then decides what data to forward to each destination and what to strip out before forwarding.

Here is what changes:

• Browser network requests drop significantly. Instead of 8 to 15 outbound requests to third-party domains, the browser makes one request to your server endpoint.

• Third-party JavaScript is removed from the page. Meta, Google, and other vendors no longer execute their own code in the visitor's browser.

• You gain a transformation layer. Before data reaches any destination, your server container can strip URL parameters, redact form values, remove IP addresses, or block the request entirely.

• Cookie control shifts to you. Server-set cookies on your domain replace third-party cookies, giving you control over duration, scope, and content.

What does not change: the data still reaches Google. The server container forwards events to Google Analytics, Google Ads, or other endpoints. Google still receives the data. The difference is that you now have an opportunity to filter it first.

Setting Up Server-Side GTM on Google Cloud Run

Google offers two hosting options for the server container: App Engine and Cloud Run. For healthcare organizations, Cloud Run is the better choice. It runs in a dedicated project you control, supports VPC networking, and integrates with Google's compliance-scoped infrastructure.

Step 1: Create a Dedicated GCP Project

Do not run your sGTM container in the same GCP project as your production applications. Create a new project specifically for tag management. This isolates the billing, IAM permissions, and audit logs.

Name it something clear, like yourorg-sgtm-production. Enable the Cloud Run API and the Secret Manager API.

Step 2: Deploy the Server Container

Google provides a pre-built container image for sGTM. Deploy it to Cloud Run using the Google Cloud Console or the gcloud CLI:

The CONTAINER_CONFIG value comes from your GTM server container settings in the Tag Manager UI. You will find it under Admin > Container Settings after creating a server-side container.

Set the minimum instances to 1 to avoid cold start latency. For production healthcare sites, set the maximum to at least 10 and configure auto-scaling based on request count.

Step 3: Map a Custom Subdomain

This is a critical step many teams skip. By default, Cloud Run assigns a URL like sgtm-server-abc123-uc.a.run.app. That domain is clearly a Google endpoint, and requests to it will be visible in browser DevTools as third-party traffic.

Map a subdomain of your primary domain instead:

Use Cloud Run's custom domain mapping or place a load balancer in front of the service. The load balancer approach gives you more control over SSL certificates, caching, and request routing.

With a custom subdomain, all tracking requests appear as first-party traffic. Browser DevTools will show requests going to your own domain, and ad blockers are far less likely to interfere.

Step 4: Configure the GA4 Client and Tags

In your GTM server container, add a GA4 client to receive incoming events. This client parses the GA4 measurement protocol requests sent from your web container.

Then configure server-side tags for each destination:

• GA4 tag: Forwards events to Google Analytics. Enable the "Remove client IP" option. Under event parameters, exclude any fields that could contain PHI (page path patterns, search queries, custom dimensions with health data).

• Google Ads Conversion tag: If you are tracking conversions, configure this tag to send only the conversion event name and value. Do not forward the full page URL or any user-scoped parameters.

Step 5: Update Your Web Container

Your existing web GTM container needs to be reconfigured to send data to your server endpoint instead of directly to Google. In your GA4 configuration tag, set the transport_url to your custom subdomain:

Remove all tags that send data directly to third-party endpoints. The entire point of the server container is to be the only destination the browser communicates with.

The Compliance Gap That Server-Side GTM Does Not Close

Here is where many healthcare organizations make a costly assumption: they believe that moving to server-side GTM solves their HIPAA compliance problem. It does not. It solves one layer of the problem (browser-side exposure), but it leaves several others open.

Google does not sign a BAA for Google Analytics or Google Tag Manager

This is the most important point in this entire article. Google offers BAAs for certain Workspace and Cloud Platform products, but Google Analytics 4, Google Tag Manager (client-side or server-side), and Google Ads do not fall under those agreements. When your server container forwards event data to GA4, that data arrives at a Google service that is not covered by a Business Associate Agreement.

Without a BAA, any data that qualifies as PHI under HIPAA has been disclosed to a non-covered entity. That is the same violation at the center of the Kaiser, Sutter Health, and Henry Ford Health settlements, which totaled over $81 million combined.

Data transformation is manual and fragile

Server-side GTM gives you the ability to strip data before forwarding it, but it does not do this automatically. You have to write the transformation logic yourself using custom templates or variables. If a new developer adds a custom dimension that contains a medical condition, or if a URL structure changes to include appointment types, the server container will forward that data unless someone has written a specific rule to catch it.

Sutter Health ran Google Analytics and Meta Pixel on its MyHealthOnline patient portal from 2015 to 2020. The tracking was not the result of a single mistake. It persisted because no ongoing monitoring system flagged the data flowing to those platforms. Server-side GTM without continuous auditing creates the same risk: you might configure it correctly today, and a routine change six months from now reintroduces the exposure.

You still need consent management

Server-side GTM does not inherently gate data collection on patient consent. The server container processes every request it receives unless you build consent logic into the pipeline. With state privacy laws expanding (and patient expectations rising alongside them), consent-gated data flows are becoming a baseline requirement, not a differentiator. A compliant architecture verifies consent server-side before any data is forwarded to any destination.

Pairing Server-Side GTM with a Compliant CDP

Server-side GTM is a useful component, but it is not a complete solution. To close the compliance gaps, healthcare organizations typically pair it with a purpose-built customer data platform (CDP) that provides the layers sGTM lacks.

Here is what a compliant CDP adds to the architecture:

A real BAA that covers the data pipeline. A healthcare-grade CDP signs a BAA that covers data collection, processing, storage, and transmission. This means data flowing through the CDP to downstream destinations is covered, unlike data flowing through GA4.

SOC 2 Type II with all five trust criteria. Most analytics vendors certify only the Security trust criterion (1 of 5). A proper healthcare CDP holds SOC 2 Type II across Security, Availability, Processing Integrity, Confidentiality, and Privacy. That is the difference between an audit checkbox and a genuine compliance posture.

Server-side architecture by default. Rather than retrofitting a client-side tool with a server layer, a compliant CDP is built server-side from the start. The visitor's browser never communicates with third-party endpoints. Data collection happens on your domain through a first-party SDK, with no vendor fingerprint visible in the page source.

Consent-gated dispatch. Data only flows to downstream destinations after consent has been verified server-side. This is not a JavaScript consent banner check. It is a server-side gate that ensures no data reaches Google, Meta, or any other platform until the patient has explicitly consented to that specific use.

Continuous web scanning. Marketing teams add scripts. Plugins update. Tag managers accumulate tags over time. A web scanner crawls your site on an ongoing basis and detects every cookie, script, localStorage entry, and tracking pixel across every page. It flags which scripts lack a BAA, which cookies are third-party, and which tracking pixels are sending data to ad platforms. Without this layer, you are relying on the hope that nothing changed since your last manual review. Every major enforcement case involved tracking that ran for years before anyone noticed.

If you are evaluating this kind of architecture, Ours Privacy provides a server-side CDP, tag manager, consent management platform, and web scanner built specifically for healthcare. The platform is designed so that the compliance gaps described in this article do not exist in the first place.

Common Misconfigurations in Healthcare sGTM Deployments

After reviewing sGTM setups across healthcare organizations, certain mistakes appear repeatedly. Each one creates a compliance exposure that undermines the reason you moved to server-side in the first place.

Keeping client-side tags alongside the server container

The most common error. Teams deploy the server container but leave existing client-side tags (Meta Pixel, Google Analytics, LinkedIn Insight) firing in the web container. The browser is now sending data both to the server container and directly to third parties. The server-side layer provides zero protection for data that bypasses it entirely.

Fix: Audit your web container and remove every tag that sends data to a third-party endpoint. The only destination in your web container should be your server container's custom subdomain.

Using the default Cloud Run URL instead of a custom domain

When the server endpoint is sgtm-abc123-uc.a.run.app, requests are visibly going to Google infrastructure. Ad blockers will flag it. Privacy-conscious patients will notice. And you lose the first-party data collection benefits that make server-side tracking valuable.

Fix: Always map a custom subdomain before going to production.

Not stripping IP addresses

By default, the GA4 server-side tag forwards the client's IP address to Google Analytics. In a healthcare context, an IP address combined with a health-related page URL is exactly the data pattern regulators have flagged. Henry Ford Health's $12.2 million settlement involved this kind of data combination flowing to Meta and Google from 2020 through 2023.

Fix: Enable the "Remove client IP" option on every server-side tag that forwards data to a Google endpoint.

Forwarding full page URLs without sanitization

Page URLs on healthcare sites often contain clinical context: /departments/cardiology/schedule, /patient-resources/diabetes-management, /find-a-doctor?specialty=psychiatry. Forwarding these to Google Analytics gives Google a map of patient health interests tied to device and session identifiers.

Fix: Create a custom variable in the server container that rewrites URLs to remove clinical path segments and query parameters before forwarding.

No alerting or monitoring on the data flowing through the container

Your server container is processing every tracking event for your entire website. If a new tag starts sending sensitive data, or if the container begins forwarding unexpected parameters, you need to know immediately. Most healthcare sGTM deployments have no monitoring layer. Data flows through without anyone inspecting what is actually being sent.

Fix: Implement logging and alerting on your server container. Better yet, pair it with a platform that provides continuous compliance monitoring so that data governance is not dependent on a single engineer remembering to check the logs.

Frequently Asked Questions

Does server-side GTM make Google Analytics HIPAA compliant?

No. Server-side GTM changes where tag processing happens, but the data still reaches Google Analytics servers. Google does not sign a BAA for GA4 or GTM. Without a BAA, forwarding any data that could constitute PHI to Google Analytics is a compliance risk, regardless of whether the processing happened client-side or server-side. If you need compliant analytics, you need a platform that signs a healthcare-grade BAA covering the full data pipeline.

Can I use sGTM to strip PHI before sending data to Google?

You can, and you should if you continue using Google's tools. Server-side GTM supports custom variables and transformation logic that can remove IP addresses, sanitize URLs, and redact form values before forwarding. The challenge is that this protection depends entirely on manual configuration. New pages, new URL patterns, new custom dimensions, and marketing team changes can all introduce PHI that your transformation rules were not written to catch. Automated, ongoing auditing is the only way to maintain confidence that your rules are keeping up with your site.

How much does a server-side GTM deployment cost?

Cloud Run pricing is based on CPU, memory, and request count. For a mid-size healthcare website handling 5 to 10 million events per month, expect $200 to $800 per month in Cloud Run costs. Add the engineering time for initial configuration (40 to 80 hours), ongoing maintenance, and compliance auditing. The infrastructure cost is modest; the operational cost of keeping it compliant is where most organizations underestimate the investment.

Should I run sGTM on Google Cloud or a different cloud provider?

Google's pre-built container image is designed for GCP and works best on Cloud Run or App Engine. You can run it on AWS or Azure using Docker, but you lose the native integration and will need to manage more of the infrastructure yourself. For healthcare, the cloud provider matters less than the data governance layer on top of it. Whether the container runs on GCP or AWS, you still need to solve the BAA gap, the consent gating, and the ongoing monitoring problem.

Is server-side GTM enough to pass a HIPAA audit for our website?

On its own, no. A HIPAA audit will evaluate whether PHI is being disclosed to entities without BAAs, whether consent is being obtained and documented, whether you have ongoing monitoring for compliance drift, and whether your vendors hold appropriate certifications. Server-side GTM addresses one narrow piece of this: it reduces browser-side data exposure. The audit will still ask about your downstream data recipients, your BAA coverage, your consent management process, and your ongoing scanning and monitoring. You need a broader compliance architecture to satisfy those requirements.