Google Tag Gateway for Advertisers, the thing everyone still calls First-Party Mode out of habit, moved out of beta and into general availability. The release notes on Google's Tag Manager support page were updated as recently as July 9, 2026, and the gateway now works for every GTM account, covering both client-side and server-side tags.
That's the headline. Three other changes shipped in the same wave, and one of them needs your attention before the others.
What actually changed
Four things, in order of how much they'll affect your setup:
1. General availability, all account types. The gateway is no longer gated to a subset of advertisers testing it. If you're running GTM, client-side or server-side, you can turn it on.
2. Custom domain selection at setup. Previously the domain configuration was more rigid. Now you pick both the domain name and the Google tag ID when you enable the gateway. If you're running server-side GTM through a subdomain like sgtm.yourdomain.com, this gives you more control over how that domain maps to the gateway config instead of accepting whatever default Google assigned.
3. Cloudflare rollback, simplified. Google merged the pause and delete buttons into a single delete function for Cloudflare-based gateway deployments. If a gateway setup misbehaves, breaks data collection, or you need to back out of a Cloudflare Worker configuration, you now have an actual rollback path instead of a pause state that didn't fully undo the deployment.
4. A new Tag Diagnostics tool. This lives in the Google tag settings panel and is built to help you find and fix tag firing issues before they become a data quality problem you find three weeks later in a client's GA4 property.
The change that isn't about infrastructure
Buried in the same update: Floodlight tags running in server-side Tag Manager will start transmitting unconsented requests server-to-server. Google's stated reason is to improve the accuracy of modeled conversions.
Read that again. Unconsented requests, sent server-to-server, specifically to feed conversion modeling.
This isn't the gateway feature. It's a separate consent-handling change riding in the same release, and it's the one that actually changes what data moves and under what conditions. If you're running Consent Mode v2 with Floodlight tags in your server container, the definition of what counts as "unconsented but still transmitted" just shifted. That's a data flow change that touches your legal basis documentation if you're operating under GDPR or similar frameworks.
Why this matters for your pipeline
The whole pitch of server-side GTM has been resilience against third-party cookie loss and ad blockers, by routing tag traffic through infrastructure you control instead of Google's third-party domains. Gateway getting to GA (not beta) is Google saying this path is stable enough for production traffic at scale. For agencies who've been running client-side GTM because server-side felt too early or too fiddly, GA status removes that excuse.
But GA status also means Google expects broader adoption, fast. Which means more advertisers turning this on without fully reading what the Floodlight change does to their consent-based data segmentation. If your GA4 or Google Ads conversion modeling relies on a clean split between consented and unconsented signal, and now unconsented Floodlight data starts flowing server-to-server by default, your modeled conversion numbers move for reasons that have nothing to do with your actual audience behavior.
What to do this week
Check your gateway configuration status first. If you're on GTM server-side and haven't touched the gateway settings since before July 9, go into the Google tag settings panel and confirm which domain and tag ID combination is active. Don't assume the old default still applies.
If you're running Cloudflare for your server container, test the new rollback flow in a staging environment before you need it in production. Pause used to leave things in a weird half-state. Confirm delete actually does what you expect on your specific Worker setup.
For the Floodlight change: pull your current server-side GTM container and find every Floodlight tag. Check whether they're firing conditionally based on Consent Mode signals, or whether they're now set up to fire server-to-server regardless of consent state under the new default. If your compliance posture depends on unconsented traffic never leaving the browser in identifiable form, this is worth a direct conversation with whoever owns your privacy policy language, not just a technical fix.
Run the new Tag Diagnostics tool against your production container regardless of whether you're touching gateway settings. It's free visibility into firing issues you may not have had a clean way to catch before. Ten minutes, no downside.
Last thing: if you're an agency managing multiple client GTM accounts, this is the moment to standardize. GA status means every client account you touch can now access gateway, custom domains, and Cloudflare rollback. Decide now whether your default build includes gateway from day one, or whether you're waiting for specific client requirements. Don't let each account drift into its own ad hoc configuration.
Sources
- https://support.google.com/tagmanager/answer/4620708?hl=en
- https://developers.google.com/analytics/devguides/collection/protocol/ga4/changelog
- https://support.google.com/google-ads/answer/12495138?hl=en
- https://support.google.com/analytics/answer/9164320?hl=en
- https://blog.google/products/ads-commerce/google-analytics-360-ga4-update/
- https://support.google.com/analytics/answer/11583528?hl=en