You Need Server-Side Tag Manager to Take Privacy Seriously

You Need Server-Side Tag Manager to Take Privacy Seriously

Google’s launch of Server-Side Tag Manager has us very excited. Not only because this tool gives us immense power when it comes to data collection, but also because it allows us to take the control we need to take in order to be respectful of our users’ privacy.

That last part is what I want to focus on in this short blog post.

The Default Google Tag Manager and Google Analytics Implementation

In order to understand why Server-Side tagging and the ownership of your own data collection endpoint is such a big deal, you first need to understand how a default implementation of Google Tag Manager and Google Analytics works.

In the schema below, I’ve created a schematic flow of a User that uses Google Chrome to load “” in the browser. The website then invokes Google Tag Manager from “” and in turn, gtm.js then invokes Google Analytics from “”.

So in this one browser hit that the user performed, in order to measure a simple page view in Google Analytics, the request information of your user (with, among others information, their ip-address) is being exposed to two external sources that are owned by Google. ( and

Default Google Tag Manager and Google Analytics Implementation
Default Google Tag Manager and Google Analytics Implementation

It is totally normal that this works this way, because how else could Google provide us with these (free!) solutions to load our tags and our analytics so easily? They provide you with a simple JavaScript, hosted on their fast sites, you implement it, and we’re done!

Unfortunately, whenever there is an opportunity and money can be made, there is usually somebody who will exploit it sooner or later. Regardless of ‘who exploited it’, the fact is that consumers and legislators are requiring better privacy preservation online. The basis of preserving privacy when it comes to digital data is to start restricting who has the data in the first place.

Regardless of Google promising us “we will not use the personal data in the requests you send us if you tell us not to”, we should opt for not sending them that data (or minimizing it) to begin with. (Same applies to every 3rd party data processor you deal with.)

And that’s where Server-Side Google Tag Manager comes into play!

Server-Side Google Tag Manager and Google Analytics Implementation

Server-Side Tag Manager allows us to create our own data collection endpoint which we can host on our own (sub)domain and which we can use to alter/obfuscate/delete/enrich data before we pass it along to it’s desired endpoint.

Server-Side Google Tag Manager and Google Analytics Implementation
Server-Side Google Tag Manager and Google Analytics Implementation

First of all, you get to host/load “Web Google Tag Manager” via “Server-Side Google Tag Manager”. This is usually confusing at first, but these two products work together and don’t replace each other.

This requires one change to the Script loaded. Instead of loading the script from, you’re loading it from your own server-side endpoint (in the example below:

<!-- Google Tag Manager -->
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
<!-- End Google Tag Manager -->

In Server-Side Google Tag Manager you want to make sure you create a Web Google Tag Manager client that is able to serve your gtm.js and allow it automatically server all dependent Google scripts (like GTM Zones for instance).

Make sure you create your GTM Client in Server-Side GTM and enable to server all dependent Google Scrip

The next step is to also make sure you send your analytics hit to your server-side end-point. You configure this within your Google Analytics 4 Configuration Tag within Web Google Tag Manager.

Send your Google Analytics hits to your Google Analytics Client in Server-Side Tag Manager

This also means that you have to create your Google Analytics 4 Client within Server-Side Tag Manager that is ready to server your analytics.js and gtag.js files and handle the collect hits you are sending towards it. Also, don’t forget to enable the ability to serve all Google scripts from your Server-Side environment again.

Create your Google Analytics 4 Client in Server-Side GTM and enable it to also serve dependent scripts from your endpoint.

Altering the Information you share with Google Analytics

The next step is the most important. We’ve now collected the information from our user’s browser, towards our own collection endpoint (Server-Side GTM). However, we still have to send the data to Google Analytics in order to get it processed and visible within our reports. From a privacy perspective, this is an important step.

Outgoing information will be handled by Tags within Server-Side Tag Manager. So for example, within the Google Analytics tag in Server-Side Tag Manager, you might want to (dynamically) enable the “redact visitor IP address” feature based on the consent asked and given by the user.

Setting to redact visitor IP in The Google Analytics 4 Tag in Server-Side GTM

Also, you can use the tag to alternate, add or edit the event parameters and user parameters. This all happens BEFORE the hit will ever reach the Google-owned analytics processing servers. (Think about hashing user ID’s, masking IP’s, etc).

Ability to edit/add/adjust event and user parameters in Google Analytics 4 Tag in Server-Side Tag Manager

Ownership of your Collection Endpoint

When setting up Google Server-Side Tag Manager you have two options:

  • Automatically provision your tagging server and deploy it on Google Cloud Platform.
  • Manually provision your tagging server somewhere else.
The two options you have available when creating a server-side tag manager container

Although it might feel strange, when you decide to go for the automatically provisioned tagging server hosted on Google Cloud Platform, you are still taking full ownership of that data as stated in the Google Cloud Privacy resource. So the endpoint that you are using to load scripts from and send data towards, is fully owned by you and can not be used by Google for any other purposes.

If you decide to go for your own manually provisioned tagging server (perhaps on AWS, Azure or on-premise) then the same principles apply, as long as you own the specific cloud instance you’re deploying it to.

In conclusion

Hopefully, this blog post demonstrates why having your own data collection endpoint (like Google Server-Side Tag Manager) is important and how it can actually help you with regard to data privacy.

By owning the data collection endpoint and introducing the ability to change the data before you forward it to its endpoint you suddenly create the ability to take your visitors’ privacy seriously and remove anything that should not be shared with any third-party vendor.

As always, if you have any questions or want to get some input on how this could work for you, don’t hesitate to reach out and schedule a call with me using the link below.

Read something interesting? Lets talk!