If you’ve been running Google Analytics 4 or any ad tracking on your website, you’ve probably noticed something troubling: your conversion data looks lower than it should. Users are bouncing from your funnel even though your ads seem to be working. Attribution is broken. And you have no idea why.

The culprit is almost always the same — short-lived cookies that browsers like Safari, Firefox, and even Chrome are aggressively trimming down to as little as 1–7 days.

The fix? Setting up a GTM server-side custom domain cookie lifetime — setting that extends your tracking back up to 400 days — restoring accurate attribution and stopping your tracking from leaking data.

In this guide, I’ll show you exactly how to do it, step by step, and why it matters more than ever in 2026.

Why Browser Cookies Are Dying — and Taking Your Data With Them

For years, marketers relied on client-side JavaScript cookies to track users across sessions. When someone clicked your Google Ad, a cookie was set in their browser. When they came back a week later and purchased, the cookie was still there, and the conversion was attributed correctly.

That era is over.

Apple’s Intelligent Tracking Prevention (ITP) — built into Safari since 2017 and updated aggressively ever since — now caps JavaScript-set cookies at just 7 days in most cases, and as little as 24 hours for cookies set via document.cookie if the referrer is a known tracker.

Firefox’s Enhanced Tracking Protection does something similar. And even Chrome, which controls roughly 65% of desktop browser market share, has been moving toward more aggressive privacy defaults.

The result? If your customer journey spans more than a week — which is true for most B2B companies, higher-ticket e-commerce, and SaaS businesses — your GA4 data is almost certainly underreporting conversions and misattributing sessions.

Studies from server-side tracking vendors consistently show that businesses lose between 20% and 40% of their conversion data purely because of cookie restrictions. That’s not a rounding error. That’s a significant portion of your ad spend flying blind.

What is a GTM Server-Side Custom Domain — and Why Does It Fix This?

Google Tag Manager Server-Side (sGTM) moves your tracking from the browser to a cloud server that you control. Instead of your website sending data directly to Google Analytics, Meta, or TikTok from the visitor’s browser, it sends data to your own server, which then forwards it on.

This is powerful for many reasons — but the cookie lifetime extension is one of the most immediately impactful benefits.

Here’s the key insight: cookies set by your own server (via HTTP Set-Cookie headers) are treated as first-party cookies by browsers. And first-party cookies from a server are far less restricted than JavaScript-set cookies.

In most browsers, server-set first-party cookies can last up to 400 days (the maximum allowed by browsers today).

But there’s a catch. For the cookie to truly be “first-party,” your GTM server-side container needs to live on a subdomain of your own website. That’s where the custom domain setup comes in.

If your website is example.com, your sGTM tagging server should be hosted at something like track.example.com or metrics.example.com.

When cookies are set from this subdomain, browsers treat them as first-party — meaning they get the full 400-day lifetime, aren’t stripped by ITP, and persist through multiple sessions.

Step-by-Step: How to Set Up GTM Server-Side with a Custom Domain

Step 1: Create Your Server-Side GTM Container

First, you’ll need a Server container in Google Tag Manager. If you only have a Web container, here’s how to add a Server container:

1. Go to tagmanager.google.com
2. Click the three-dot menu next to your account name
3. Select “Create Container”
4. Choose “Server” as the platform
5. Name it something descriptive like “Example.com — Server”

During setup, GTM will offer you two hosting options: Automatically provision tagging server (hosted on Google Cloud Run) or Manually provision tagging server (for self-hosting). For most users, the automatic option on Google Cloud Run is the easiest starting point. You can always migrate later.

Step 2: Note Your Default Tagging Server URL

After provisioning, your container will have a default tagging server URL that looks something like:

https://server-xxxxxxxxxxxxxxxx-uc.a.run.app

This is a run.app subdomain — it’s NOT on your own domain. This means cookies set from here are still technically third-party from the browser’s perspective. This is the URL you’ll be replacing with your custom domain.

Step 3: Choose Your Custom Subdomain

Pick a subdomain for your tagging server. Best practices suggest using something that doesn’t obviously look like a tracker. Good examples:

• metrics.yourdomain.com
• data.yourdomain.com
• t.yourdomain.com
• analytics.yourdomain.com

Avoid names like tracking.yourdomain.com or gtm.yourdomain.com as these are more likely to be caught by ad blockers.

Step 4: Configure the Custom Domain in Google Cloud Run

1. Go to Google Cloud Console
2. Select the project your sGTM is running in
3. Navigate to Cloud Run → your sGTM service
4. Click “Edit & Deploy New Revision” → go to “Custom Domains”
5. Add your custom subdomain (e.g., metrics.yourdomain.com)
6. Google Cloud will provide you with DNS records to add

Step 5: Add DNS Records at Your Domain Registrar

Add a CNAME record at your DNS provider:

• Type: CNAME
• Name: metrics (or whatever subdomain you chose)
• Value: ghs.googlehosted.com

DNS propagation typically takes 15 minutes to 48 hours. Google Cloud Console will show a green checkmark once your domain is verified and the SSL certificate is provisioned.

Step 6: Update Your GTM Server Container Settings

1. In GTM, open your Server container
2. Go to Admin → Container Settings
3. Under “Tagging Server URL,” add: https://metrics.yourdomain.com
4. Save the settings

Step 7: Update Your Web GTM Container Tags

In your GA4 Configuration Tag in the Web container, find the “Transport URL” or “Server Container URL” field and enter your custom tagging server URL: https://metrics.yourdomain.com.

This tells the browser to send analytics hits to your own domain — which is what enables the first-party cookie behaviour.

Step 8: Verify Cookie Behaviour in DevTools

After publishing your changes, open Chrome DevTools → Application → Cookies and look for the _ga cookie. You should see:

• The cookie domain matches your custom subdomain or root domain
• The expiration is set to 400 days rather than 7 days
• The SameSite and Secure attributes are properly set

Common Mistakes That Break Custom Domain Cookie Tracking

Using a different root domain than your website. If your website is example.com but your tagging server is on example.io, browsers will still treat those cookies as third-party. They must share the same root domain.

Forgetting to update the Transport URL in the Web container. Your sGTM server is ready, but if your web container tags are still sending data directly to Google/Meta/TikTok, you’re not getting the benefit.

Not configuring the GA4 client correctly in sGTM. In your server container, you need a GA4 Client that knows how to receive and parse the data coming from your web container. Check that the “Activation Priority” is set correctly.

SSL certificate issues. If your custom domain SSL certificate isn’t provisioned correctly, browsers will block requests to your tagging server entirely. Verify the certificate is valid before deploying to production.

GTM Server-Side Custom Domain Cookie Lifetime: What Changes After Setup?

Better attribution in GA4. Users who return within 400 days will be properly recognised as returning visitors. Sessions will be stitched together correctly across longer conversion windows.

Improved ROAS measurement. Your conversion data will be more complete, giving bidding algorithms better signals to optimise against — which often improves actual campaign performance.

More accurate funnel analysis. Multi-step funnels that span weeks rather than days will show the full picture. You’ll see where users actually drop off, not where they appear to drop off due to cookie expiry.

Compliance benefits. First-party server-side tracking is more defensible under GDPR and CCPA than third-party client-side tracking.

How This Fits Into a Full Server-Side Tracking Strategy

Extending cookie lifetime is one piece of the server-side tracking puzzle. A complete sGTM setup also includes:

Server-side GA4 event tracking — sending events from your server to bypass ad blockers and browser restrictions entirely.

Conversions API (CAPI) for Meta Ads — sending conversion signals directly to Meta’s Conversions API, deduplicating with browser events for a complete picture.

TikTok Events API — similar server-side event forwarding for TikTok campaigns.

BigQuery integration — forwarding raw event data from your sGTM server to BigQuery for long-term storage and advanced analysis that GA4’s interface doesn’t support.

The custom domain setup is the foundational layer that makes all of these work properly. Without it, your first-party cookie tracking is still subject to browser restrictions.

Is This Worth the Effort?

For a small blog with no ad spend, probably not. But if you’re spending more than £2,000–£3,000 per month on paid advertising, the answer is almost certainly yes.

If you’re losing 25% of your conversion data due to cookie restrictions — a conservative estimate — and spending £5,000/month on ads, restoring that data could improve your ROAS by 10–20% purely through better bidding optimisation. That’s £500–£1,000/month in recovered ad efficiency, every month.

The one-time setup cost is typically a few hours of developer time, and the ongoing hosting cost for a Cloud Run sGTM instance is usually under £20/month for most small-to-medium businesses. The maths is straightforward.

Next Steps

If you want to get this set up correctly without the headache of troubleshooting DNS records and GTM container configurations, reach out to Analytigrow.

We set up server-side tracking infrastructure for businesses that need accurate data — and we’ll make sure your custom domain is configured correctly, your cookies are persisting as long as they should, and your GA4 and ad platform data is clean.

Tracking that actually works starts with the foundation. And the foundation starts with first-party cookies on your own domain.