Server-Side Tagging for a Hospital Site on Cloud Run: Setup, Cost and Pitfalls

This article is for the engineer or technical marketer who has decided that a hospital or health tech site needs a server-side Google Tag Manager container and now has to build one. It assumes you already know why: the existing post on server-side tracking and consent mode for healthcare covers the reasoning and the consent side. This one is narrower. It walks through the Cloud Run build, a worked cost estimate and the failure modes that cost teams days.

A server container is not a compliance fix by itself. It gives you one place to control what leaves your domain, which is useful, but it only helps if the web container sends sensible data in the first place and if consent is respected upstream. Treat it as plumbing.

What you are building

Three pieces:

1. A server container in Tag Manager, which holds clients, tags, triggers and transformations.
2. A tagging server, which is a Cloud Run service running Google's container image and answering requests from your site.
3. A preview server, a second small Cloud Run service used by Tag Manager's preview mode.

The browser sends events to your own subdomain, for example metrics.yourhospital.example, instead of directly to Google. The server container's GA4 client receives them, and tags forward the permitted fields to GA4 and to ad platforms.

Step 1: create the server container

In Tag Manager, create a new container of type Server. Choose between automatic provisioning and manual provisioning. Google's Cloud Run setup guide describes both. Automatic provisioning creates the Cloud Run services for you in a Google Cloud project you name. Manual provisioning gives you the container configuration string, and you deploy the image yourself.

For a hospital, prefer manual provisioning or a project under your organisation's own billing and access controls. Create a Google Cloud project owned by the hospital, not by an agency's account, and give the agency scoped IAM roles. When the agency changes, the infrastructure stays.

Step 2: deploy the tagging and preview servers

The manual route has a clear order. Deploy the preview server first, because the tagging server needs its URL.

• The preview service uses the same Google-provided image, deployed as a separate service using the exact command in the guide. Its URL is passed to the tagging server in an environment variable, PREVIEW_SERVER_URL.
• The tagging service gets the container configuration string in CONTAINER_CONFIG.
• Pick an Indian region such as Mumbai (asia-south1) so requests from users in India stay close and so data-location questions have a simple answer. Google's guide does not specify a default region; the choice is yours.

Two settings matter. Google's guide recommends a minimum of two instances to reduce the risk of data loss during an outage, and it uses CPU-always-allocated billing, with CPU throttling turned off in the sample deploy command. Teams that save money by setting the minimum to zero find that a cold start drops the first hits. For a hospital that is paying for ads, losing the first request after a quiet period is a bad trade.

Once deployed, open the tagging server URL with /healthy appended. A working server returns the text ok.

Step 3: map a first-party domain

A server on a default Cloud Run address runs in a third-party context relative to your site. Google's custom domain documentation states that for server-set cookies to be durable, the tagging server and website should share a domain, and that serving it under your main domain is a best practice. A subdomain also works and gives full access to server-set cookies. The default domain cannot set server-side cookies.

For most hospitals the subdomain route is the one that is practical:

• Map the custom domain in Cloud Run and add the DNS records it asks for.
• Wait for the managed certificate to be issued; until then requests fail.
• In Tag Manager, open Admin, then Container Settings, and add the server container URL.
• If you map several domains to one server, all URLs must use the same path.

If you run a CDN or load balancer in front of the main site, same-origin serving under a path such as /metrics is cleaner, but requires routing rules and more care with caching. Do not cache responses from the tagging path.

Step 4: point the web container at the server

In the web container, the Google tag needs to send events to your server rather than to Google directly. Use the Google tag's server_container_url setting with your subdomain. Then, in the server container:

• Add a GA4 client to claim incoming GA4 requests.
• Add a GA4 tag that forwards to your GA4 property.
• Add ad platform tags only for events you have approved. Server-side transformations can enforce that; the principle is that the server should forward an allow-list, not everything it receives.

Test using Tag Manager's preview mode on both containers. In the server preview, each incoming request appears with its event data. Confirm you can see the incoming event, the client that claimed it and the tags that fired.

Cost: a worked estimate

Google's setup guide puts each tagging server at roughly USD 45 per month, assuming one Cloud Run instance with 1 vCPU and 0.5 GB of memory, and its infrastructure planning page gives a slightly different figure of about USD 50 per instance per month. Both pages describe the same method: the minimum instance count times the per-instance price is your baseline; the maximum instance count times the price is a worst-case ceiling.

A hypothetical example, clearly not a quote. A 200-bed hospital in Pune runs the tagging server with a minimum of two instances and a maximum of ten, using the USD 45 figure:

• Baseline: 2 instances × USD 45 = about USD 90 a month.
• Worst case: 10 instances × USD 45 = about USD 450 a month, reached only if traffic forces Cloud Run to scale out fully.
• Add the preview server, which is small and idle most of the time.
• Add network egress and logging, which are not in the per-instance figure.

Google's planning page points out that network egress counts both the requests going out to tags and the responses returned to browsers, and that serving larger JavaScript libraries raises it. Use the Google Cloud pricing calculator with your own traffic figures and agree a budget alert, because the planning page also warns that reaching a budget threshold with billing set to disable stops linked services.

The setup guide says autoscaling between two and ten servers should handle roughly 35 to 350 requests per second depending on your tags. Compare that with your own peak, including days when a campaign or a health awareness day lifts traffic. Most hospital sites will sit near the bottom of that range, but check your analytics rather than guessing.

Logging: the line item people miss

Cloud Run writes request logs, and the console receives container output. The planning page notes that storage costs can become substantial once requests exceed the Cloud Logging free tier, and recommends filtering incoming requests, sampling log entries or excluding the health-check requests. Do this before launch with Logs Router exclusion filters.

There is a second reason to care. Request logs can contain the full request URL, including query strings. If a URL carries something it should not, your logs become another copy of it. Decide the retention period and who can view logs, and keep sensitive parameters out of the request in the first place.

Pitfalls we would check for

• Minimum instances set to zero. Cold starts drop hits. Keep at least two.
• Container image never updated. The server runs a fixed image revision until you deploy a new one. Put a quarterly update on the calendar and read the release notes.
• Preview server URL missing. Preview mode silently fails to connect.
• Wrong or stale container config. If you re-create the container, CONTAINER_CONFIG changes and the old service keeps answering with the old container.
• Different path on mapped domains. All mapped domains must share one path.
• Ad blockers and browser restrictions. A first-party server improves cookie durability and control, but it does not guarantee that every request arrives. Measure the gap between server-side and browser-side counts for a few weeks rather than assuming it.
• Consent ignored. Server-side forwarding must respect the consent state the browser passes. A server that forwards everything because it can is worse than none.
• Everyone is owner. Keep IAM tight; the tagging project can see traffic metadata.
• No alert for downtime. Add an uptime check on the /healthy path.

Launch checklist

1. Hospital-owned Cloud Run project with scoped access for vendors.
2. Preview server and tagging server deployed in an Indian region, minimum two instances, no CPU throttling.
3. Custom subdomain mapped, certificate issued, server URL added to Tag Manager.
4. /healthy returns ok, and an uptime alert exists.
5. Web container sends to server_container_url; server preview shows events.
6. Only approved tags and events forward.
7. Logs Router exclusions and a budget alert are in place.
8. A named owner and a quarterly update date.

For the broader measurement set-up, see our analytics and tracking service, the GA4 glossary entry, and, for the legal background, what the DPDP Act means for healthcare marketing.