Docs

Google Tag Gateway CDN Tracking

Google Tag Gateway now routes first-party tags through CDNs like CloudFront — what to track to confirm it's actually recovering lost conversions.

Acquisition

Google Tag Gateway extended its reach this quarter to route through content delivery networks including Amazon CloudFront, alongside a parallel update that joins server-to-server conversion data with browser-side signals — such as a present GCLID — so Floodlight and Google Ads can attribute conversions that used to be undercounted in pure server-to-server setups. The pitch is straightforward: instead of a tag firing from a domain browsers and ad blockers recognise as third-party, Google Tag Gateway serves it from your own first-party CDN edge, and now more CDN configurations qualify. For teams that have watched consent banners, Safari’s Intelligent Tracking Prevention, and ad blockers erode client-side conversion counts for years, first-party-served tags through infrastructure many teams already run — CloudFront being one of the most common — closes a large part of that gap without a full server-side tagging build-out.

The part that’s easy to skip is verification. “First-party-served” and “actually recovering conversions” are different claims, and only measurement proves the second. A tag served correctly from a CDN edge but pointed at a stale or misconfigured server container looks identical to a working one in a quick manual check, while quietly reporting nothing extra. The browser-signal-joining behaviour only activates when a GCLID is present and Google Signals is enabled — traffic lacking either falls back to server-only attribution, a meaningfully lower-fidelity path that’s easy to conflate with the improved one if you’re not tracking which path each conversion actually took.

Data Points to Track

  • Tag Gateway routing path per request — whether a given tag request resolved through the CDN-served first-party path or fell back to a direct third-party call, since browsers and networks can fail over silently
  • Conversion recovery delta — a before/after comparison of conversions attributed via the joined server-plus-browser-signal path versus the prior server-only baseline, isolated to traffic that actually qualifies (GCLID present, Google Signals enabled)
  • GCLID presence rate at the point of conversion — since the signal-joining improvement only applies when a GCLID survives to the conversion event, a low presence rate caps how much benefit this change can deliver regardless of CDN routing
  • CDN edge response latency for gateway-routed tags — confirming the first-party route isn’t adding meaningful delay to page or app load compared to the direct third-party call it replaces
  • Container version and config drift across CDN edges — flagging when a server container serving one CDN edge or region falls out of sync with the version deployed elsewhere

Setup Steps

  1. Confirm your CDN is on Google Tag Gateway’s supported list — CloudFront is now included — and enable the gateway routing option through Tag Assistant’s guided workflow rather than hand-rolling the CDN configuration.
  2. Tag every outbound conversion event with its resolved routing path (gateway-CDN versus direct) so recovery can be measured against a like-for-like baseline instead of an aggregate that blends both.
  3. Instrument GCLID presence as its own tracked field at the conversion event, independent of whether the conversion itself succeeds, to size the addressable opportunity for the browser-signal-joining improvement.
  4. Set up latency monitoring on the CDN edge specifically for gateway-routed tag requests, comparing against pre-migration baseline load times.
  5. Add a version-drift check across all CDN edges and regions serving your server container, since silent version mismatch is the most common way a “working” gateway rollout stops actually helping in some regions.

Actionable Insights

The conversion recovery delta is the number that actually answers whether this was worth doing — measure it only against traffic that qualifies for the browser-signal join (GCLID present, Google Signals on), because blending in traffic that never qualified will understate or overstate the real effect depending on your traffic mix. A low GCLID presence rate is worth fixing before investing further in CDN routing work, since it’s the ceiling on how much the newer attribution improvement can recover regardless of infrastructure. And treat routing-path tagging as a permanent field, not a migration-period diagnostic — CDN and network-level fallbacks to the direct third-party path can reappear after a config change, and without the field in place you’d have no way to notice.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert