Google has released a new feature, First-Party Mode (FPM), into public beta.
First-Party Mode seeks to make it easier to wrap Google’s measurement and advertising technologies in a first-party, same-origin context.
This means that the user’s browser, when visiting a website running FPM, would no longer communicate directly with Google’s domains when fetching measurement libraries such as Google Tag or Google Tag Manager.
Instead, the requests would be sent to a subfolder of the website itself. A server process would then take these requests, forward them to Google’s servers, and finally return the response (typically a JavaScript file) back to the web browser.
This would also apply to analytics and advertising pings.
Here’s the distinction:
- Regular setup (cross-site): User navigates to
https://www.simoahava.com/; requests are sent tohttps://www.googletagmanager.com/. - First-party serving (same-site, cross-origin) with subdomain: User navigates to
https://www.simoahava.com/; requests are sent tohttps://sst.simoahava.com/. - First-Party Mode (same-site, same-origin) with subfolder: User navigates to
https://www.simoahava.com/; requests are sent tohttps://www.simoahava.com/metrics/.
With First-Party Mode services, (3) above, the browser only ever communicates with the domain of the website. Read on to understand why this can be significant.
This article is an overview of First-Party Mode, as well as a discussion starter on the (relative) benefits and (potential) risks involved.
If you want to jump over the technical stuff and go straight to my thoughts on the matter, follow this link.
X
The Simmer Newsletter
Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!
How does it work?
With First-Party Mode, the website reserves a subfolder like /metrics that is not used for any other purpose (this is important!).
For FPM to work, the website infrastructure itself should support rerouting specific requests and modifying their request headers.
This infrastructure could comprise a load balancer, a CDN, an edge service, or a proxy server, for example.
This technology is then configured to route requests collected at a specific path (e.g. /metrics) to a Google host reserved for the tagging container of the website.
Google receives the request, processes it, and finally returns a response back to the browser using the same channel.
Server-side Google Tag Manager
If you’ve been using server-side Google Tag Manager, you’ll know that you have already had the capability to do something like this.
Loading Google dependencies from your own server is baked into the application, and if you’ve deployed with a same-origin setup, you already have “first-party mode” in use.
However, server-side GTM is a fully-fledged application service that is designed to do powerful data pipeline tasks. It’s not necessarily best suited for transporting potentially large scripts and files. That’s what a dedicated content distribution network (CDN) service is for.
You can actually combine First-Party Mode and server-side Google Tag Manager. Set up FPM for library requests, and use the server_container_url field in Google Tag to collect analytics and measurement pings to server-side GTM.
It’s a pretty smooth setup. If you configure the Google Tag Manager web container to load through FPM, then any subsequent Google Tag library loads (Google Analytics 4, Google Ads, for example), will automatically load through FPM, too.
How to set it up
Google has detailed instructions for setting up FPM using Google Cloud load balancing or Cloudflare.
Note! If you want to use Cloudflare, you need an expensive Enterprise subscription to manage this setup.
Remember that the main requirement is that your website domain points to this service, too.
It’s not enough to set up a load balancer just for First-Party Mode. All of your website traffic needs to flow through this entry point – the routing rules then redirect the subfolder traffic to the Google host.
If your site uses some other CDN or load balancer than Google Cloud or Cloudflare, you can follow the steps outlined in the documentation.
- You need to add an origin or backend to your setup that points to
.fps.goog - For requests to this backend, override the
Hostheader to be equal to.fps.goog - Add a route rule that forwards
/metricstraffic to this backend. - Configure this route rule to have the highest priority.
- Important! Update your tag snippet(s) to load the respective library from
https://www.yoursite.com/metrics/rather than from Google’s domain.
To test the setup, browse to https://www.yoursite.com/metrics/healthy. If the page shows the text ok, it means that First-Party Mode is working.
So, what’s the point?
Advertisers, businesses, data companies, brokers, publishers, and hobby websites alike are facing data loss and quality degradation like never before.
Content Security Policies, browser tracking protections, and ad (and content) blockers all target third-party services in an attempt to squash the data collection free-for-all that’s been rampant over the past decades.
This is why First-Party Mode (and similar technologies) might sound tempting.
Additional layer of control
First of all, routing traffic through an upstream service point that you control is potentially a huge net positive for your compliance and data validation practices.
This is my main justification for server-side tagging – it gives you an incredible amount of control to prevent data-hungry vendors from leeching data from the user without restriction.
FPM gives control, too, but not to this extent. Many CDNs and Load Balancers allow you to remove information from the forwarded request, such as the user’s original IP address.
Dropping the user’s IP address is particularly important if using Google’s Advanced Consent Mode, as the IP address is considered personal data in the European Union.
But that’s about it – they don’t let you selectively strip personal data from the request, and doing conditional blocking when the request lacks consent signals might be difficult to do.
So while FPM does give you some control, it’s not the same as a fully-fledged application service like server-side Google Tag Manager.
There’s also a big risk involved with forwarding all cookies to the Google host. There’s a lot of information stored in browser cookies that a third party should not have access to, ranging from the innocuous but privacy-sensitive (e.g. vendor IDs) to data security risks (e.g. incorrectly stored authentication tokens).
I received word from Google that they already have internal filters in place, automatically dropping non-Google cookies from the data that is processed. They are working on making this more transparent to users and audit trails.
Circumvent ad blockers
First-Party Mode addresses the “problem” (see below why I put this word in quotes) of data loss due to ad blockers. Many ad blockers still rely on blocklists that have domain-matching patterns as their main heuristic.
Google’s domains are invariably in these blocklists, as they are so deeply entrenched in the world of advertising technologies.
Since the browser no longer communicates with Google’s domains directly, ad blockers have a tougher time blocking these requests.
However, ad blockers aren’t stupid. Some lists evolve at a glacial pace, but others are quicker to make a note of domain masking as a blocker workaround.
For example, EasyPrivacy looks at paths (/gtm.js) and even query parameters (.js?id=GTM-) to determine blockable requests.
In this case, just switching the domain from https://www.googletagmanager.com/ to https://www.yoursite.com/ isn’t enough, because the request path and query string is still matched by the blocklist.
Unless your first-party serving completely obfuscates the request path and query parameters so that they no longer resemble the original, ad blockers will catch up sooner rather than later.
WebKit’s first-party cookie expiration
Another “benefit” that FPM introduces is a lifeline for first-party cookies whose expiration the WebKit browser engine has tried to cap. WebKit runs the Safari browser and (still) many iOS and iPadOS browser apps.
With First-Party Mode, the tracking requests share the exact same domain as the website itself. They are, in fact, same-origin requests relative to the website. This means that WebKit’s tracking protections do not apply, as they require at least a whiff of third-party in the request chain.
FPM moves the logic of data transfer (between the user and Google) from the browser to the web server, and web browsers do not have visibility to what goes on in the server.
Content Security Policy
Yet another benefit of First-Party Mode: by communicating with the website instead of with Google’s domains, the Content Security Policy (CSP) of the website can be made stricter.
This is because origins like https://www.googletagmanager.com can now be added to the CSP, as the browser no longer needs to send data to them.
While a stricter CSP is definitely a good thing, this benefit can be considered largely superficial.
Even though the browser no longer communicates with Google’s services directly, it still ends up loading them – just via the website’s domain rather than Google’s CDN. So while cross-site scripting (XSS) risks are mitigated, the issue of loading unreliable content is largely left unaddressed.
This means that if the purpose of the CSP is to prevent potentially harmful scripts from being loaded in the browser, FPM doesn’t really change this risk profile at all. The scripts are still loaded, just through a more obscure pathway than before.
Many discussions around First-Party Mode revolve around misunderstandings and knee-jerk reactions. I’m often guilty of these, too.
Here’s my attempt to address some of these comments that have been circulating online.
Same-site vs. same-origin
A subdomain setup such as that often used with server-side Google Tag Manager is much easier to configure than a subfolder setup.
This is because a subdomain can be mapped with just DNS – the website itself can use a completely different technology stack.
A subfolder needs the website itself to be running through the same service that does the routing. You can’t configure DNS for a subfolder – the “D” in DNS stands for “Domain”.
A subdomain is same-site and cross-origin. A subfolder is same-site and same-origin. This is the main distinction.
This has been done before
This is not new technology. Reverse proxies have existed for ages, and the aforementioned server-side Google Tag Manager has supported first-party serving for years.
Similarly, it’s been trivial to configure transparent request forwarding with Cloudflare Workers.
First-Party Mode wasn’t introduced as a novelty or a game-changing technology paradigm. Google released FPM to make it easier to configure first-party serving without having to invest in more complicated (and expensive) tech like server-side Google Tag Manager.
Google’s goal is to level the playing field for all their customers, not just those who have the resources to build complicated machinery for data pipelines.
Even though FPM is out of reach for many of Google’s customers due to lack of access to the kind of technology that request routing requires, it’s likely that they will add even more support for different hosting and CMS systems in the future.
Cat and mouse game
Using FPM to get longer cookie lifetimes in WebKit browsers is, for lack of a better expression, totally lame. It’s boring. It’s unreliable. It lacks vision. It’s a waste of time and money. It can even be downright risky.
Why unreliable? Well, WebKit has been known to make bold moves. If WebKit notices that a significant number of sites are circumventing their CNAME cloaking mitigation with a same-origin workaround, they’ll do something about this.
However, what they can do about it remains unclear. As it’s same-origin, the browser can’t distinguish between tracking requests and “normal” website requests, at least on the DNS level.
WebKit would need to start doing pattern matching against a list of known tracking patterns, perhaps using Tracker Radar as they already do in private browsing mode.
But this would be trivial to circumvent by encoding the path and query string patterns and decoding them before the request is routed.
If I had to place my bets on a bold move, I’d imagine WebKit would shift towards capping all first-party storage access without exception. This would certainly prevent workarounds.
Or perhaps as a compromise they’ll revitalize the discussion around the isLoggedIn API, allowing some first-party storage access, if it can be proved that the user is logged in to the website.
Ad blocker heuristics
If using FPM to circumvent WebKit’s protections is lame, then using first-party setups to circumvent ad blockers is even more so. It’s also ethically questionable.
Users have the right to block whatever resources they like. It’s their browser. It’s their agency. Some users might use ad blockers to prevent data harvesting, some might use them for data security, and some might use blockers to enjoy a faster browsing experience. It’s their right, and you can never know what the user’s motivation for using a blocker was.
If you want to start a debate with me about an advertising-fuelled open web being at risk, then take it elsewhere. Recalibrate your argument to be about the broken state of ad tech rather than about users taking back control.
There’s also a tangible risk with a same-origin setup. Ad blockers might flag your website domain as a tracking domain if it’s prominent enough and if it clearly and visibly circumvents ad blockers with a same-origin workaround.
It wouldn’t be nice to have your website blocked globally.
Legal and regulatory context
From a legal or regulatory point-of-view, at least in the European Union, FPM doesn’t really change anything.
You still need a legal basis to process the user’s personal data (GDPR). You still need consent to access storage on the user’s device (ePrivacy Directive).
First-Party Mode is about organizing the technology stack of the website to act as an upstream router for marketing signals. Vendors still end up receiving the same data they would receive without FPM in use. The compliance requirements, the applicable legal frameworks, the responsibilities of involved parties – they all remain the same.
My summary review of First-Party Mode
First-Party Mode is quite obviously a first step in a more comprehensive collection pipeline overhaul that Google is planning. What the next steps are remains uncertain, but it’s clear this isn’t the last we’ll hear about FPM.
In its current shape, it’s still out of reach for many of Google’s customers. Same as a same-origin setup for server-side Google Tag Manager, it requires a certain type of website infrastructure to already be in place.
Not all websites are hosted on (or behind) a service that allows you to create additional routing and origin rules.
As such, it’s an interesting proposition by Google. It’s also quite a bit of work (and potentially expensive) for just a few benefits.
Circumventing ad blockers and getting longer cookie lifetimes on WebKit’s browsers isn’t worth the investment in my opinion.
This is also one of the reasons I’m a strong proponent of a subdomain setup over a subfolder setup for server-side GTM. It’s just common sense to separate the volatile and potentially risky marketing data flow from the website’s network routes.
So there has to be more to this. What’s Google’s big plan with FPM? What’s so special about it that incentivizes Google to push their customers to it instead of towards server-side Google Tag Manager?
Will Google soon offer a setup similar to Meta’s Conversions API Gateway, where they’ll allow customers to make use of first-party serving at scale and at low cost?
Time will tell.
Right now, if your website infrastructure supports the type of routing that First-Party Mode requires, maybe it’s worth giving it a spin. Perhaps you’ll recover enough data to make it worth the investment.
If your website is hosted in a way that does not support a same-origin setup for your marketing data, I’m not sure if you should migrate given that the benefits of First-Party Mode are as few as they seem to be.