They already have a counter move, to an extent. One of the deployment models for GA is via Google Tag Manager. One of the deployment models for GTM is this[1] server-side mode deployed to an App Engine container in Google Cloud. The only browser-visible communication happens between your browser and the App Engine instance, and then you send server side calls from that to the downstream systems based on those events (GA, Facebook Conversion API, etc).

It can also be used like the traditional GTM model, where it loads the primary GTM script browser-side, then that loads additional browser-side scripts based on the tags you implement (GA, Facebook, chat systems, map widgets, whatever). But the default GA support built into it avoids loading anything from Google's domains directly by the browser. And it's not even subject to the CNAME cloaking protections[2] that ITP have implemented, since it's not using the "CNAME to third party" technique that's typically common for these sorts of things to get first party access/privileges and is instead actually running on your infrastructure.

[1] https://developers.google.com/tag-manager/serverside

[2] https://webkit.org/blog/11338/cname-cloaking-and-bounce-trac...

Integrating with Google Analytics on the server-side as opposed to the client-side has always been available. Developers just rarely do it because it is easier to add a JavaScript snippet to the page.

It gives much more detailed data like how long a user keeps a page open, and browser fingerprinting data that's not available server-side like querying fonts or viewport size.

All of that stuff can still run as 1st party js on your site, then use your own server to proxy it all back to GA if you want to.

Yeah. But it's much easier to copy paste a script.

How do they provide that? Doesn’t that require you to use a proscribed server stack?

Does the server-side integration allow cross-site tracking? I don't see how it possibly could.

Not familiar with the particulars, but server-side GA, has the same theoretical ability as the current Javascript-based GA. The only difference is that the client code is served by the first party, and not the Google servers.

GA can compare fingerprints from different websites, so that should work.

What's really clever is that at the scale that GA is deployed, it's really really hard for Google to willy-nilly break API just to get around this because a lot of webmasters will simply not bother updating their scripts, and if Google forcefully pushes a breaking change, people might stop using GA, or worse, they get an avalanche of bad PR for breaking half the web.

I don’t think this is true. GA has at least 2 versions it doesnt support in the past decade.

I imagine the opposite is true, in that they hold so much power they can do as they please.

My understanding is they are veeery careful around rolling out changes and deprecations. The cleverness is that there's a huge asymmetry in how fast Firefox can globally deploy updated shims vs how fast Google can change GA API.