Fastly on April 8, 2026, announced the launch of Fastly Ad Tag Gateway, a product built in collaboration with Google that enables advertisers to serve Google tags from their own domains rather than from Google's infrastructure. The feature extends the Google tag gateway for advertisers programme to Fastly's content delivery network, adding the company to a roster of CDN and cloud providers - including Cloudflare, Google Cloud Platform, and Akamai - that now support the architecture.

The announcement, published on Fastly's blog by Product Manager Guy Nir, cited a 14% uplift in observed signals for advertisers who configure the Google tag gateway. That figure is drawn from Google data covering a seven-day period between April 9 and April 16, 2025, and is defined as a trailing median comparing tags operating in Google tag gateway against tags that are not. The metric refers specifically to Google tag script loads, not to conversion volume or revenue.

How the routing works

At its core, Fastly Ad Tag Gateway reroutes Google tag traffic through a path on the advertiser's own domain. Instead of loading scripts from a Google domain, the browser fetches them from a customer-controlled path - for example, yourdomain.com/metrics. Fastly then forwards those requests to Google's measurement endpoint via proxy routing at the network edge.

Because the traffic originates from the advertiser's domain, browsers treat the tag as a first-party resource. This distinction matters. Safari and Firefox both impose stricter restrictions on third-party cookies and scripts than on same-origin ones. By operating in a first-party context, the gateway can maintain longer cookie durations and reduce signal loss caused by browser tracking protections. The Google tag gateway feature has been documented on PPC Land since its May 2025 general availability launch with Cloudflare, where an 11% signal uplift was reported at that time for early adopters.

The technical implementation relies on Varnish Configuration Language (VCL) snippets deployed at the Fastly edge. Two separate VCL snippets are required - one for vcl_miss and one for vcl_pass - using identical code. Each snippet attaches the advertiser's Google Tag ID via a custom request header (X-Gtg-Tag-Id) and transmits the client's geolocation data through three additional headers: X-Forwarded-Country, X-Forwarded-Region, and X-Forwarded-Geolocation. The geolocation header carries latitude, longitude, and city values derived from Fastly's client.geo variables.

Routing itself depends on a Fastly condition that matches requests whose URL path begins with the configured measurement path - for example, ^/metrics. A backend host entry pointing to fps.goog is created and attached to that condition, with an override host field also set to fps.goog. This combination ensures that qualifying requests bypass normal content delivery and are instead proxied to Google's first-party serving infrastructure.

Two setup paths, one beta caveat

According to Fastly's documentation, there are two ways to enable the integration. The first uses Google Tag Managerand is designed for operators who want to activate the gateway on specific domains rather than across an entire Fastly service. The second involves manual configuration directly in the Fastly control panel, which applies to an entire service and is appropriate only when all domains on that service should use the gateway.

The Google Tag Manager route is currently in beta. According to Fastly's documentation, operators must contact Fastly support before following the GTM-based setup instructions. The manual configuration path, by contrast, is available without a support prerequisite.

For the GTM-based setup, the process begins inside Google Tag Manager. After selecting the Admin tab and opening the Google tag gateway section, operators scan their domain to detect the CDN automatically or select Fastly from a list of supported providers. Once Fastly is detected, a sign-in step grants Google permission to access Fastly domain configurations and manage first-party tags on selected domains. An optional step allows customisation of the measurement path, which defaults to a random alphanumeric string to prevent conflicts with existing Fastly behaviours.

Google's own help documentation notes that the measurement path confirmation triggers a validation step: the system checks that the Google tag is correctly routing data through Fastly before the setup is marked complete. Domain statuses displayed in the Google tag gateway screen can be "First-party" (active), "Not started," "Paused," or "Pending" (enabled but awaiting diagnostic data).

Limitations and access requirements

Several constraints apply. Only domains that are already added to a Fastly service, are active, and have valid TLS certificates can be used with the integration. A Google Tag Manager account can be associated with only one Fastly account. Only users with the superuser role in Fastly can use the GTM-based setup path.

The Google tag gateway on Fastly supports only one Google tag configuration per service. According to Google's documentation, configuring multiple tags directly may cause the gateway to malfunction and creates a vulnerability to script injection attacks. Operators who need multiple tags have two options: use the self-service setup path, or consolidate all website tags into a single Google Tag Manager container and configure the gateway from there.

Fastly's documentation also notes that enabling the integration may affect Google tag firing behaviour. If existing tag behaviour is tied to user consent actions, operators are advised to adopt Consent Mode and review consent settings before activation. This requirement aligns with the broader compliance context: European privacy regulations impose stricter requirements on third-party data collection, and routing through a first-party domain shifts some of those obligations.

Context: a growing list of CDN integrations

Fastly's integration is the latest in a series of CDN and infrastructure partnerships that Google has built around its tag gateway. The tag gateway for advertisers feature moved to general availability on May 8, 2025, initially supported only by Cloudflare. At that point, Google's announcement referenced Fastly and Google Cloud CDN as planned future partners. Google Cloud Platform support followed in early January 2026, using the External Application Load Balancer in a beta configuration accessible through GTM and Google tag settings. Akamai was added in late January 2026, documented in Google Tag Manager release notes dated January 29, 2026.

The underlying architecture predates general availability. Google Tag Manager's First-party Mode beta launched with Cloudflare integration in October 2024, and an earlier iteration of first-party mode for GTM was described by PPC Land in July 2024, when industry observers including Simo Ahava raised questions about whether the primary purpose was privacy enhancement or circumvention of ad blockers. That debate has continued as the product has moved through successive integrations.

The Fastly integration is notable for what it represents in terms of market coverage. Fastly operates as a significant edge cloud platform used by large media companies, e-commerce operators, and technology firms. Adding Fastly to the supported list means a class of high-traffic publishers and retailers who would not have considered Cloudflare or Akamai their primary CDN now have a native setup path.

Signal uplift figures and their basis

The 14% uplift figure in Fastly's announcement is higher than the 11% figure cited at the May 2025 Cloudflare launch. Both numbers come from Google's internal data and carry the same methodological caveat: they measure script load recovery, not business outcomes. The April 2025 Google dataset that underpins the 14% figure covers a single seven-day window and reflects a global, performance-weighted trailing median. Neither Fastly nor Google has published cohort data or controlled studies isolating the effect of the gateway from other measurement variables such as consent rate, geography, or browser mix.

What the figure does represent, however, is the proportion of tag loads recovered when the gateway intercepts requests that would otherwise have been blocked or degraded by browser privacy mechanisms. Ad blocking extensions maintain blocklists of known advertising and analytics domains. When scripts load from an advertiser's domain instead, blocklist rules require domain-specific targeting rather than pattern matching against known third-party origins. This shifts the balance in favour of the tag firing.

Why this matters for measurement infrastructure

For marketing teams, the operational significance of the Fastly integration lies in where measurement breaks down. Attribution models depend on consistent signal collection across user sessions. When browsers impose cookie expiry limits, or when content blockers suppress tag loads, the result is incomplete conversion data - undercounting of assisted conversions, degraded bidding signals for automated strategies, and wider confidence intervals in attribution reports.

First-party tagging addresses this at the infrastructure level rather than the data modelling level. By operating from the advertiser's domain, tags inherit the browser's trust in that domain. Cookies set by gateway-served scripts are treated as first-party cookies, which most browsers handle with far less restriction than third-party cookies. For businesses relying on Google Ads' smart bidding - which uses conversion data as a real-time optimisation input - any reduction in signal loss translates directly into more accurate bid adjustments.

The Fastly integration also introduces the secure OAuth authorisation flow as a feature in its own right. When a marketer initiates setup through Google Tag Manager, Fastly handles backend configuration automatically: verifying domain access, establishing routing, and provisioning VCL snippets without requiring the marketing team to understand edge computing infrastructure. According to Fastly's blog post, this is designed to bridge the gap between marketing operations and platform engineering - two teams that often operate on different timelines and with different toolsets.

One aspect that operators should understand carefully is the relationship between the gateway and consent settings. The Google Analytics help documentation specifies that enabling the feature "affects Google tag firing behaviour." For deployments where tags are suppressed pending user consent - a common pattern in European markets under GDPR - the gateway does not override consent. Tags that are configured not to fire until consent is granted will continue to behave that way. What the gateway changes is how those tags load and where measurement events are sent once consent conditions are met.

This distinction is relevant for publishers and advertisers operating under ePrivacy Regulation requirements in the EU. The gateway routes data through the advertiser's domain, which can simplify data processor agreements and clarify the chain of responsibility for data in transit. It does not, however, change the legal basis for processing or remove the need for consent banners in jurisdictions that require them.

Deactivation and management

Deactivating the integration requires selecting "Delete" in the Google tag gateway configuration screen within Google Tag Manager, which detaches Fastly from the container and removes the gateway configuration. According to Google's documentation, deleting the configuration disables the feature for all active domains simultaneously. After deletion, the gateway can be re-established with a new Fastly account, but not with the same one without going through the setup process again.

Domain management after activation is handled through a "Manage domains" button in the Google tag gateway configuration screen. Domains are grouped into three categories: tagged (already carrying the current tag), untagged (not yet tagged - Google will add the missing tag automatically if selected), and other active domains (already using the gateway via a different tag, via direct Fastly activation, or via self-service).

Timeline

Summary

Who: Fastly, an edge cloud platform provider, and Google, in a joint product collaboration. The integration is accessible to Fastly CDN customers who also run Google Ads and have a Google Tag Manager container on their website. Only users with the Fastly superuser role can configure the GTM-based setup path.

What: The launch of Fastly Ad Tag Gateway, which routes Google tag traffic through advertiser-owned domains via Fastly's edge network. The product is built on top of Google's tag gateway for advertisers architecture, using VCL snippets and condition-based routing at the Fastly edge to proxy measurement requests from a first-party path to Google's fps.goog endpoint. The GTM-based setup is in beta; manual service configuration is available without a beta prerequisite.

When: Announced on April 8, 2026, with Fastly's blog post authored by Product Manager Guy Nir. The supporting signal uplift data (14%) derives from a seven-day trailing window in April 2025.

Where: The product is available globally to Fastly customers. Setup is initiated through Google Tag Manager or the Fastly control panel. Domains must be active on Fastly, have valid TLS certificates, and already be added to a Fastly service.

Why: Browser privacy protections - including Safari's Intelligent Tracking Prevention and Firefox's Enhanced Tracking Protection - restrict third-party cookies and tag loads, reducing the volume of conversion signals available to advertising platforms. By serving tags from first-party domains, the gateway aims to recover signal loss, extend cookie lifespans in restrictive browsers, and reduce the impact of ad blocker blocklists. The broader context is the ongoing shift in digital advertising infrastructure toward first-party data architectures as reliance on third-party cookies becomes less viable.

Share this article
The link has been copied!