Building a First-Party Tracking Pipeline Using Cloudflare GTG and sGTM

As a Marketing Data Analyst, one of the most frustrating challenges you face today is the aggressive degradation of data quality caused by browser tracking prevention. In my previous case study—where I reverse-engineered how ad blockers were skewing conversion data by over 36%—I concluded that modern attribution must evolve toward server-side architectures to survive.

While ad blockers create massive visibility gaps, they are only half the problem. Even a user who never installs an ad blocker still gets their data scrubbed by the browser itself.

The returning user gets logged as a brand-new visitor, and the campaign that actually drove the conversion gets zero credit.

The best solution is to move away from client-side JavaScript tracking entirely and build a first-party tracking pipeline. By using Server-Side Google Tag Manager (sGTM) paired with a Cloudflare reverse proxy, you can set your tracking cookies via secure HTTP response headers directly from your own domain instead of the browser. ITP respects HTTP-only first-party cookies, allowing you to extend their lifespan back to two years.

This guide breaks down exactly how I architected this pipeline, using the sandbox domain bestloadout.online as the testing ground.

The Architecture Overview

Before provisioning any servers, it's critical to map how the data will flow.

Step 1: Provisioning the Tagging Server Environments

To process data server-side, you need a server environment. There are two primary ways to approach this.

• Ensure your DNS nameservers are already pointing to Cloudflare.
• Create a subdomain for the server side: metrics.bestloadout.online.
• Open GTM, create a Server container, and copy the Container Config string.
• Create a Stape.io account, deploy a new container using the string, and add your custom subdomain in Stape settings.

On Cloudflare, create a CNAME record pointing metrics to the target provided by Stape. Crucial: Set the Cloudflare proxy status for this record to DNS Only (grey cloud) and leave it there permanently. Stape must be able to continuously ping the domain to auto-renew your SSL certificate. If you turn on the Cloudflare proxy (orange cloud), Stape's verification handshake will fail, and your tracking will eventually disconnect.

Once verified, update the Tagging Server URL in your GTM Server Container Admin settings to https://metrics.bestloadout.online.

Step 2: Configuring the Cloudflare Google Tag Gateway

The server is ready, but the actual GTM library (gtm.js) is still loading from Google's servers, leaving it vulnerable to network-level ad blockers. Cloudflare's Google Tag Gateway (GTG) solves this as a reverse proxy.

• In the Cloudflare dashboard, search for Google Tag Gateway.
• Enable the feature for your domain.
• Turn off the "Set up tag" automated injection toggle.

Automated injection causes duplicate container loads and fires tags unpredictably. A data analyst needs strict architectural control over their tag placements, so leaving this off is the best practice.

Step 3: Modifying the Client-Side Code

Because the auto-injector is off, the hardcoded GTM snippets on the website need to be updated manually to point to the new first-party gateway.

<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;
j.src='https://metrics.bestloadout.online/gtm.js?id='+i+dl;
f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');</script>
<!-- End Google Tag Manager -->

Locate the standard googletagmanager.com/gtm.js URL inside the script and replace it with your custom domain as shown above.

Optional but recommended: To avoid detection by privacy scanners parsing raw HTML, update the fallback pixel domain in the <noscript> tag too. Change it to metrics.bestloadout.online/ns.html.

Step 4: Routing the Web Container Data

With the script loading first-party, the GA4 tags need to be told to send their payloads (/g/collect requests) to the new server instead of Google's default endpoints.

• Open your Web GTM Container.
• Open your base Google Tag.
• Under Configuration Settings, add a new parameter named server_container_url.
• Set the value to https://metrics.bestloadout.online.

Step 5: Setting the Cookie — The Conversion Linker

To bypass ITP's client-side caps, the server has to explicitly write the cookie back to the browser using an HTTP header.

• Open your Server GTM Container.
• Ensure the GA4 Client is active to catch incoming requests.
• Create a new tag and select Conversion Linker.
• Set the trigger to fire on All Pages. Save and publish.

What happens: The server responds to the browser with a 200 OK status, attaching a Set-Cookie header. Because this originates from a genuine first-party interaction, the cookie isn't subject to ITP's JavaScript-cookie restrictions.

Step 6: Testing, Troubleshooting, and Live Validation

Validating the Success State

1. The Secure Response Header

Click the incoming /g/collect request and examine the Response Headers. You'll see a Set-Cookie command generating the FPID. This carries the HttpOnly flag—meaning ad blockers and browser extensions can't see it at all.

2. The Matching Timestamps

The traditional client-side _ga cookie and the newly minted FPID cookie will end in the same Unix timestamp. The matching timestamp confirms the server picked up the same session rather than minting a new one.

3. The Two-Year Request

Navigate to the Application Tab > Storage > Cookies. In Chrome, the Max-Age column will show exactly 730 days, or two years. Chrome, Firefox, and Edge will honor it in full.

Conclusion

Moving tracking infrastructure to a first-party, server-side model delivers real, verifiable gains. The pipeline survives ad blockers and network-level filtering that a client-side GTM script never would. The FPID cookie is HttpOnly, so client-side scripts can't touch it. And on every non-Safari browser, this pipeline delivers a full two-year attribution window.

On Safari, this architecture still beats a normal client-side setup, since Safari's JavaScript-cookie cap and its 24-hour link-decoration cap are both worse than its 7-day server-cookie cap.