The 11% measurement uplift almost nobody switched on

There is a Google feature that recovers roughly 11% more measured conversions, requires no change to your on-page code, and takes a competent developer under a day. Most Australian mid-market accounts have not switched it on, usually because nobody told them it existed.

Google Tag Gateway serves your Google tags from your own domain through your CDN instead of from Google's servers. The snippet on the page stays exactly as it is. Nothing in GA4 or Google Ads needs rebuilding. The change happens at the network layer.

Why it recovers data

Two mechanisms, and they are worth understanding separately because they fix different losses.

The first is blocking. Browser extensions, DNS-level blockers, corporate networks and some mobile carriers match on the hostnames and paths that Google tags load from. That matching is what stops the tag executing. When the same tag is served from a path on your own domain, most of those pattern-based blocks do not fire, because the request is indistinguishable from any other asset on your site. This is not a trick to defeat privacy tools, and browsers that block on behaviour rather than hostname still block it. It recovers the losses that were incidental rather than intentional.

The second is cookie lifetime, and this is the bigger one in a market where over half of mobile browsing happens in Safari. Intelligent Tracking Prevention caps first-party cookies written by JavaScript at seven days, dropping to 24 hours when the visitor arrived through a link carrying tracking parameters from another site. Cookies set server-side with an HTTP response header are not subject to that cap. Serving through your own domain means the identifier can be set that way, so a returning visitor stays the same person instead of appearing as a fresh acquisition.

Put those together and you understand what the uplift actually is. It is not new customers. It is the same customers, correctly joined to the sessions they already had.

What it takes to deploy

You need a supported CDN in front of your site. Cloudflare, Akamai, Fastly and Google Cloud CDN are the main paths, and Cloudflare's implementation is the simplest of them.

The work is:

1. 1.Choose a path on your own domain to serve tags from.
2. 2.Configure the CDN rule that proxies that path through to Google's tag servers.
3. 3.Verify in the browser network tab that the tag now loads from your hostname and returns a 200.
4. 4.Confirm in GA4 realtime and in Google Ads tag diagnostics that events are still arriving.
5. 5.Leave it a fortnight, then compare conversion volume against the two weeks before.

That last step is the one people skip and then argue about later. Note the exact deployment date somewhere visible, because your conversion numbers will step up and someone will attribute it to a campaign.

What it is not

It is not server-side tagging, and treating them as the same thing is how this gets sold badly.

Full server-side tagging gives you a container you control: you can inspect the payload, strip fields you do not want to send, enrich events with data from your own systems, and fan a single event out to multiple platforms. That is a real capability and it costs real money and maintenance, in hosting, in monitoring, and in the person who has to own it.

Tag Gateway gives you first-party serving and nothing else. The data still goes to Google in the same shape it always did. You get the collection benefit without the control benefit.

For most mid-market businesses that is the correct trade. You want the measurement recovered; you do not want another piece of infrastructure with an on-call rotation. Do the gateway first, run it for a quarter, and only build the full server-side container if you find a specific requirement it cannot meet.

The compliance point, said plainly

First-party serving does not change your obligations. The same consent rules apply, the same data is collected, and consent mode signals travel exactly as before. Anyone selling this as a way to collect data from people who declined is describing something you should not buy.

What it does change is that the technical means of collection stops being at the mercy of a blocklist that had nothing to do with your visitors' actual preferences.

Do it before the expensive things

There is a hierarchy of measurement work by return on effort, and it is almost always ignored in favour of whatever is newest.

Fix consent so the signals are correct. Serve tags first-party through the gateway. Send enhanced conversions with hashed customer data. Stitch first touch into the CRM so long cycles survive. Then, and only then, look at modelling, warehouses and custom pipelines.

The first four are days of work each and recover data that is currently being thrown away. The last one is a project with a budget line and a steering committee.

A day of network configuration is a strange place to find double-digit measurement recovery, which is exactly why it is still sitting there.