Isn't the whole point of this new change that it runs server-side, using a proxy that you install on the website so it uses the same domain?
> Regardless, I use a DNS based ad blocker
But it's the same domain name isn't it?
Isn't the whole point of this new change that it runs server-side, using a proxy that you install on the website so it uses the same domain?
> Regardless, I use a DNS based ad blocker
But it's the same domain name isn't it?
Some processing happens on the server, but event data must still be sent to the server-side container first. For now, the "standard" deployment of a server-side is that it receives hits directly from the browser, orchestrated by a traditional client-side container. So the client-side script is still there, just less bloated.
The server-side container has built-in facilities for serving up the client-side container script. Meaning that domain-name blocking will not prevent this. DNS-based also has some issues: Server-Side Containers run in App Engine, blocking them basically means blocking anything running on GCP.
gtm javascript loads, pulls down the config, injects tracker X javascript into the browser
new gtm:
gtm javascript loads, pulls down config, streams events to google servers to fan out to tracker X as configured
So blocking gtm.js off tagmanager.google.com / www.googletagmanager.com / the various other domains still blocks all gtm injected tags.
The tl;dr is they're become much closer to segment -- which does the data fanout internally to segment. But they should still be straightforward to block.
[1] https://developers.google.com/tag-platform/tag-manager/serve...