Google Tag Gateway - CDN & sGTM

We found the Google Tag Gateway setup using Cloudflare to be a straightforward process.

/scripts

Cool. So, now we serve Google scripts from first party, same origin, same site, etc etc.

/dugadataftwbbq is our "/scripts" path. We choose mild obfuscation when it comes to paths and subdomains for analytics.

What about the /metrics path for data collection?

/metrics

We have sst.dugadigital.com for www.dugadigital.com hosted on Addingwell so we could easily spin up a new container and work through a reverse proxy for this test. But this is too easy by far! We like a challenge. We want to push our capabilities to show what's possible.

Embrace the challenge

We want to use the existing server container for the gtg testing but we don't want to break data collection on the "main" site.

Why?

Consider a global multi-brand scenario. A large number of brochure sites, all doing the same thing, with consistent analytics being collected - compare apples with apples and all that. Use one container for multiple domains.

Super efficient but how do you manage the first party domain mapping?

Interesting challenge - glad you asked.

Subdomain?

First, we spin up a subdomain for our gtg test domain, and register that with Addingwell:

But that's not same site, same origin so what gives? We configure a worker in Cloudflare to handle requests where the path starts with /dugaddingwell

See what I did there? I should work in marketing - Duga + Addingwell = DugAddingwell neat, huh?

Now we configure the Google Tag on the client container like so:

And like so, our /metrics path (/dugaddingwell if you please!) is first party, same origin, same site:

THIS IS A KEY QUESTION

How do requests for https://gtg test domain/dugaddingwell end up getting handled by the server container on Addingwell behind sgtm.gtg test domain then?

Back to the functionality of the Cloudflare route. When requests for /dugaddingwell are received, we will re-route the request to the subdomain. The devil is in the detail though.

The test site is on gtg test domain so we need to carefully manage headers and cookies. The worker has to:

• Strip the /dugaddingwell path and leave everything else

  • /g/collect etc etc

• Set the Host as the sgtm.gtg test domain

• Send the request to sgtm.gtg test domain

We have to make a config change to the server container too so that it knows what URLs it will serve:

localhost? Good question - Here's a cool project by Justus Hämäläinen that was featured on Simo Ahava's blog recently.

Right, back to the GTM config.

We can see that works a treat as we can see in the response and the data:

event: message

data: {"response":{"status_code":200,"body":""}}

But what about Preview Mode? Sending /dugaddingwell requests to the gtg test domain like so doesn't work for the server side preview:

Sad face - but why? When proxying sGTM through a Cloudflare Worker, the biggest hurdle isn't the data, it's the authorisation. Because browsers protect cookies across subdomains, your preview mode stays silent even when hits are successful.

Solution

We need to use Tip 132 from the Simo Ahava blog - we add the X-Gtm-Server-Preview header in the Cloudflare worker.

Grab the value from the server side preview:

Add it to the client side preview mode:

But now we need to carefully handle it in the Cloudflare worker proxy:

if (!previewId) {
        const referer = request.headers.get('Referer');
        if (referer) {
          try {
            const refererUrl = new URL(referer);
            previewId = refererUrl.searchParams.get('gtm_preview');
            if (previewId) console.log(`> Found ID in Referer: ${previewId.substring(0, 10)}...`);
          } catch (e) {}
        }
      }

      if (previewId) {
        newHeaders.set('X-Gtm-Server-Preview', previewId);
        
        targetUrl.searchParams.delete('gtm_preview');
        targetUrl.searchParams.delete('ep.gtm_preview');

If it's there, use the value but then the last two lines make the request nice and clean - don't pollute data with the gtm_preview value as an event parameter:

By 'scraping' the preview ID and injecting it into a X-Gtm-Server-Preview header, we bridge that gap, keep our URL parameters clean, and ensure our debug session stays connected without compromising data privacy.

Conclusion

Google Tag Gateway is no longer just a 'nice to have'; it’s becoming the bedrock of durable, privacy-centric analytics. By moving from third-party scripts to a first-party, same-origin setup via Cloudflare, we aren't dodging ad blockers - that's not the motivation, we are taking full ownership of our data stream.

This setup proves that while the technical hurdles (like header management and preview mode authorisation) are real, they are solvable.

The result? A leaner, more efficient architecture that scales across global brands without breaking the bank or the user experience. If you aren't thinking about same-origin data collection yet, you're already behind the curve.