Introduction to Google Tag Manager Server-side Tagging

Updated: January 24th, 2023.

When Google launched the public beta of server-side Google Tag Manager (SGTM) on August 12, 2020, the audience split into several groups. Some people were cheering and shouting, “THIS IS HUUUUGE” while others were confused and asked, “Do we really need it”. This is understandable because server-side tagging is not an easy topic.

That’s why the goal of this blog post is not to give you the “ultimate definitive” guide to how to work with Google Tag Manager server-side tagging. Instead, I wanted to provide an introduction for beginners (on the server side) and those who have no idea why this might be useful.

So if you are looking for something like “GTM server-side tagging for beginners” or “Google Tag Manager server-side tagging tutorial for beginners”, you’ve come to the right place.

However, remember that in this context, the word “beginner” refers to someone who does not know what server-side is. You will still need to have a good understanding of how website tracking with GTM works in general.

If your clients ask whether they need to adopt server-side tagging, you would be better able to answer their questions after reading my guide and/ or watching the video.

Table of Contents

– Hide table of contents –

• The usual way how GTM is used
• The server-side way
• Why would you need this?
• Benefits of server-side tagging
• Drawbacks
• How to configure server-side tagging in Google Tag Manager?
  • Create a server-side Google Tag Manager container
  • Configure tags, triggers, variables (if needed), clients in the server container
  • Send data to the server-side Google Tag Manager container
  • Time to test
  • Connect your custom domain
  • Move from the testing environment to the production
  • Publish your GTM changes
• Things to keep in mind
• Final Words

 

Video tutorial

If you prefer video content, I have also recorded a tutorial/introduction that complements this guide. In it, I give a simplified overview of the possibilities, benefits, drawbacks, etc., and also show how to configure your first test setup to support the Google Analytics 4 setup.

 

Want to learn more? Take a look at this course.

This blog post explains just the very first steps of server-side tagging. If you are serious about using this technology, many more things await you ahead.

If you want to learn the topic properly, I have a lot of content about it in my Intermediate/Advanced Google Tag Manager course. You will learn crucial topics like how to send data to Google Analytics and Facebook Conversions API, optimize the cost of SGTM (because it’s not free), and more.

 

The usual way how GTM is used

To explain how server-side tagging works, first, let’s look at the setup/process that most of you are already familiar with deploying. If you want to install Google Tag Manager on a site, you need to add the web container’s JavaScript snippet to the source code of your site.

When the page loads, the GTM snippet loads along with the rest of the webpage and fires tags based on your configuration. The Google Analytics 4 tag is one of them. All this activity happens client-side (read: in the user’s browser). JavaScript codes load, collect data and then send it somewhere else. For example, the GA4 snippet sends the data to google-analytics.com.

In addition to the data you instructed Google Analytics to collect (e.g., the click URL of the button), tracking codes usually gather additional information about the page, device, etc.

Some codes are more privacy-friendly, while others are pretty aggressive and do the fingerprinting, use first-party cookie info, and other shady things for cross-site tracking.

 

The server-side way

With server-side tagging, you are introducing an additional layer to the data collection chain – your own server (or servers) that hosts a server-side GTM container.

In that server, Google Tag Manager receives data from the client-side tracking codes, processes it, manipulates it (if needed), and then sends it to the 3rd party vendors or maybe even in-house analytics tools you are using.

Therefore, we have client-side tracking, but also we have some server-side parts. If it makes sense, you don’t need to add client-side tracking for certain tasks. You can just get data from one server to your GTM server-side setup and send it to some marketing/ analytics end-points.

 

Why would you need this?

You are probably thinking now: why would you want to add an additional step to the data collection process? Why should you bother having a server(s) in the cloud where another GTM container is loaded that sends the data to other vendors?

This is a very legit question, and we’ll dive right into the benefits.

 

Benefits of server-side tagging

There are many benefits you can get from server-side tagging. I will mention only the relevant ones in my opinion.

 

Reduced load on a page

When a web page loads, it has to download and process a lot of resources. As my experiments proved, the JavaScript snippets you add for analytics/marketing purposes can significantly slow down your site, especially if you add new scripts more often than Buckethead releases new albums).

Even if the script is loaded asynchronously (which is pretty much the standard these days), it can slow down your site.

Imagine this: instead of loading dozens of different scripts on your website, you could have just one. That script would send data to your server-side GTM container. From there, the container would modify the data according to your configurations and then send it further to more tools/platforms you are using (analytics, marketing, CRM, you name it).

However, configuring a server-side container adds another level of complexity because you will need to configure how to transform the data, etc.

At the moment, that is not an easy task — you will need to learn how to code JavaScript, understand how server-side tagging works from a technical perspective, be familiar with cloud platforms, etc.

But the community keeps creating new plug-and-play templates that will do the hard work for you, and you will need to click some buttons/checkboxes, etc., and launch without too much hassle.

 

Control what data is sent to vendors

As I have mentioned in one of the previous chapters of this blog post, JavaScript libraries loaded on a site will, most likely, track more than what you instruct them to do. These libraries also collect details related to the device (for example, screen size), page details (page URL, page title), etc.

Libraries related to advertising and cross-site tracking will collect everything they can to identify visitors with higher precision. Data collection involves various techniques, including fingerprinting, cookies, etc.

From a privacy standpoint, you would want something other than that as it increases the risk of leaks of personally identifiable information (PII). With server-side tracking, you control what reaches those vendors.

Here’s an example:

• You have some custom-built JavaScript library that is collecting data about visitor behavior on your site
• That library sends the data to your server-side Google Tag Manager container
• You configure that container to send the received data to:
  • Google Analytics
  • Facebook Pixel
  • Google Ads

In this case, these 3 analytics/advertising platforms can only get additional data about the visitor if you send it to them. If you send the user ID, then that ID is delivered. But optional data that standard JavaScript libraries could have accessed on a website are now out of reach.

Why? Because Facebook Pixel in this setup is communicating with your cloud server. It cannot capture data from the visitor’s browser.

If your custom JS library on the site collects some PII, you can process the requests in the server-side container and remove/hash them.

Reduce the impact of ad blockers

Here’s a situation: you got consent from a visitor for analytics tracking, but that visitor is using some adblocking extension. The extension blocks all the requests to google-analytics.com/collect, as it blocks ads. Your standard Google Analytics tags send data to the server using this method.

Because the request was blocked, the browser will not send any data collected by the various tags on your website to Google Analytics.

With server-side tagging, you could create a custom subdomain to which you can send the data, e.g., analytics.yourdomain.com. A GTM server-side container is waiting for the data at the other end. Once it is received and processed, the container sends the data further to Google Analytics.

Currently, most ad blockers do not block requests sent to domains like analytics.yourdomain.com. Who knows what will happen in the future, but this solution works now.

 

Extend the cookie expiration on Safari (ITP)

Intelligent Tracking Prevention (ITP) is a collection of privacy-enhancing features in the Apple Safari browser (but it also affects more browsers on iOS). Unfortunately, many things are affected/limited to prevent cross-site tracking, but my concern for this blog post is cookie expiration.

If the 1st party cookie (meaning that it can only be accessed on your site) is stored in a visitor’s browser by JavaScript, that cookie will expire in 7 days (in some cases, the limit is 24 hours).

Even if that JavaScript is entirely custom, built in-house, and is not related to any 3rd party vendor, that cookie will expire in 7 days (unless a visitor keeps revisiting your site and that cookie gets updated).

For the time being, you can avoid this 7-day limit if you store the cookie on the server side. In other words, if a server (accessed via your domain) stores a cookie in a visitor’s browser, its expiry date is whatever you configured it to be (e.g., 2 years).

I explain how to extend cookies with SGTM in my Intermediate/Advanced Google Tag Manager course.

Update: Apple announced that they will soon implement a solution that severely limits this workaround of extended cookies. If the website server’s and your SGTM server’s IP address’s first two numbers don’t match, the cookie extension will not work.

If the website server’s IP address is 1.2.3.4 and SGTM server’s IP address is 44.55.6.7, the first two numbers (1.2 vs 44.55) do not match, thus, cookies set from the server will still expire in 7 days.

It is unknown (yet) when this change will go live.

 

Drawbacks

However, not everything is perfect here. There are several drawbacks as well. Or maybe they should be called “Things to keep in mind”.

In fact, I already have a separate section for “things to keep in mind,” and it contains more notes. Keep reading.

 

Paid solution

Don’t get me wrong. GTM server-side container is free, and you will not incur any costs in most cases in the testing configuration. The testing configuration is an App Engine F1 instance class in the Standard environment.

But if you want to run it on a live website that is getting decent traffic, you will need to open your wallet.

No, that’s not because the GTM container requires some premium GTM subscription. However, you need to host that server-side container somewhere. And that’s where you spend the real $$$ on the Google Cloud Platform.

Each server costs approximately $40 / month (USD) in the production configuration. Each server is an App Engine instance with 1 vCPU, 0.5 GB memory, 10 GB disk in the Flexible environment. Google recommends running a minimum of 3 servers to reduce the risk of data loss in case of a server outage. Hence, that’s at least $120/month.

The more data you track/process, the higher the price is.

You can also use other servers (by doing a manual setup).

 

Not for everyone

To start working with server-side tagging in Google Tag Manager, you will need to become even more technical (or hire someone experienced in analytics development).

If you thought that GTM already requires a lot of technical topics (spoiler alert: it really does), then from now on, the rabbit hole goes deeper.

That is why I’m positive that many businesses will not start using the server-side soon. Some due to complexity and lack of access to technical skills, others due to increased costs (while not understanding/seeing the possible benefits).

 

How to configure server-side tagging in Google Tag Manager?

Now, let’s dive into your first setup. I’ll try to keep things as simple as possible (even though, in reality, they are more difficult).

Here’s what the process looks like in a nutshell:

• Create a server-side Google Tag Manager container + cloud project
• Configure tags, triggers, variables (if needed), clients (I’ll talk about them a bit later) in the server-side container
• Send the data to your GTM server-side container
• Test and check

 

Create a server-side Google Tag Manager container

Login to your Google Tag Manager account, go to Admin, and click the Plus icon.

Then enter the name (for example, Demo Server Side Container) and choose the type “Server”.

Then you will need to create a new project in the Google Cloud Platform (because you need to host the new container somewhere). Luckily, the process here is pretty straightforward. You will need to enter certain information and follow all the steps to finish the task.

First, the window will ask if you want to automatically get a new server for the container or manually create it. The first option involves a much simpler process; choose that.

If you are new to the Google Cloud Platform, you’ll need to create a billing account ad enter your credit card details. When you see the option “Create a billing” account”, click on it.

And then, follow all the steps the platform asks you to complete. Once your account is ready, you will be redirected back to GTM.

Previously, it automatically resumed the server creation process. But if you are back to GTM (but don’t see anything related to the new server), open your new SGTM container, click the Container ID and then Automatically provision the server once again.

The loading process might take several minutes, be patient.

Once complete, you will see the information about the created server (including the Google Cloud Platform Project ID, default URL, etc.)

 

Configure tags, triggers, variables (if needed), clients in the server container

The concept of tags, triggers, and variables is also available in the server-side containers too, but there is one new thing that you need to become familiar with.

Client.

No, this is not a customer.

Clients are responsible for getting and processing/adapting the data received by the GTM server-side container. Then it makes the data available to tags, triggers, and variables in that container.

For example, the data is usually available in the regular web container because some code pushes it to the data layer. In this case, the server-side container receives the data from *somewhere*. The client then catches, adapts, and makes it available in the container.

When you create a new server container, it creates two clients automatically. One is called Universal Analytics, and the other one is GA4.

You can additionally create more clients if you need. Still, the number of client templates available is limited now (however, in the future, we should expect more because the community should build something).

Also, you can create your own clients, but this requires good JavaScript knowledge + becoming familiar with the APIs available in the Client Templates.

We don’t need to create or code clients for your first setup. Instead, we will be using the existing Google Analytics 4 client. Every time GA4 sends data to the GTM server container, this client will catch it and make it available for use to tags, variables, etc.

Note: if you want to learn much more about server-side tagging, you should check out my Intermediate/Advanced GTM Course.

When that happens, we need to activate a Google Analytics 4 server tag that will send the data further to Google Analytics servers.

To do that, go to Tags > New > Google Analytics 4. This tag will forward all the data from a Google Analytics 4 client.

In the regular web GTM Container, you are accustomed to creating different tags for different interactions:

• One tag for pageviews
• One for purchases
• One for outbound link clicks, etc.

In the server-side case, it’s enough to have one GA4 tag (at least in the early stages of your SGTM setup). This tag will receive data about GA4 events, pageviews, purchases (from your website), etc., and will forward them to Google Analytics’ servers.

When does it make sense to create multiple GA4 tags in the server container? Sometimes, certain Google Analytics 4 events may require you to override settings. Then it makes sense to create a separate tag for X events.

But in this first setup, we don’t need to make any tag configuration changes. Instead, let’s now move to the trigger by navigating to the “Triggering” section.

You will see just three pre-built triggers, just like with the client-side setup – Custom, Custom Event and Page View. For our particular case, we need to create a trigger when GA4 appears as the Client name for the associated event. Here, what you need to do is select the Custom trigger.

Custom means “A request was sent to the GTM server container”. If you’re not concerned about which requests are sent to Google Analytics, you can keep using “All events”, but it would be better if you were more specific.

What if we have in the future multiple clients in use (which is very likely)? If this is your case, you could limit this trigger to activate only when the default Google Analytics 4 client catches the request.

That’s why you should enter the following condition: Client Name contains GA4

P.S. Client Name is a built-in variable you must enable in the Variables section of the server container.

Save all these changes. It’s time to enable Preview and Debug mode. The preview mode will open in a new tab and looks quite similar to the one you are used to seeing in the Web container. However, there are several new things/differences. I’ll mention them a little later.

At the moment, you won’t see any data there (because nothing has been sent to this container yet).

But that’s about to change soon.

 

Send data to the server-side Google Tag Manager container

There are several ways how to send data to the GTM server-side container:

• A developer can edit gtag.js code snippets added to your site’s source code
• A developer can write some custom code/library that prepares and sends the data to the server container itself
• You can configure a Google Analytics 4 tag in Google Tag Manager’s web container.

To no one’s surprise, I’ll use the third option right now.

Let’s say you have a website where a regular GTM web container has been added. You are already firing a GA4 tag on every pageview. Most likely, you also have some additional event tags.

All of them are sending data (by default) to google-analytics.com/collect (or /r/collect, etc.). Now, we should change that destination URL and forward all requests to your fresh new server-side container.

How do you do this? There is a field in the Google Analytics 4 tag (of your web container) called Send to server container. Enter the server container URL in this field. You can find it right under the measurement ID field of your tag.

That’s where we will need to enter the URL.

You will likely want to send ALL GA4 requests to the server-side container. What URL should you enter? Let’s go to the server container and click the container ID:

In the popup, you will see the Default URL, copy and paste it to the Server Container URL in your web container.

Time to test

Refresh the preview mode in your server-side container (by clicking the “Preview” button in the GTM interface once again).

Enable the Preview mode in the GTM container.

Firstly, a Pageview tag in your web container will fire (if you have set it to fire on All pages).

You can also check the Network tab of your browser developer tools. Enter “/collect” (without quotation marks) to find the request. For example, suppose you can’t refresh the page once again (while /collect is still in the search bar). You should see the request sent NOT to google-analytics.com but to your container’s domain (should contain […]appspot.com). If the status of this request is 200, that’s good.

Then you need to go to the preview mode of the server GTM container and see if the request was received. If yes, it will display on the left side of the preview mode.

Click it and check whether the GA4 tag in your server container fired. You can click the tag and see what kind of data was sent further to Google Analytics.

Also, feel free to explore other tabs of the preview mode, e.g., Event Data. Think of this tab as a cousin to a Data Layer tab in the web container’s preview and debug mode. Both of those tabs show raw-ish data that is at your disposal.

Finally, go to your GA4 real-time reports and check whether the data is visible (because it should 🙂).

If you struggled in any of these steps, please watch my video tutorial on this very same topic.

 

Connect your custom domain

The request to the GTM server container we sent now was thanks to a 3rd party domain ([…..].appspot.com). Hence this is still considered as a 3rd party tracking. But because we already know that browsers are constantly tightening the rules around web tracking, I recommend you use your own custom domain (as the endpoint) instead.

In other words, you should send requests not to […..].appspot.com but to your own subdomain, e.g., analytics.yourdomain.com. That way, website measurement will be happening in the first-party context.

I have a separate segment in my video tutorial that explains how to do that (check the video player below). Fast forward to 31:47 to get right into this segment.

If the player does not work, you can click the link here.

 

Move from the testing environment to the production

Everything we have done so far happened in the testing environment of the Google Cloud. But if you want to start using this on your live website, you need better resources (read: upgrade).

Simo has created a video where one of the things he teaches is how to deploy the project to a production environment. You can watch that part here.

Google’s documentation also has some info about it.

 

Publish your GTM changes

Once your setup is ready, publish changes in both GTM containers (web and server). The web container will start to send your GA4 data to the server-side container, and the server container will then begin to accept the incoming data and forward it to GA servers.

 

Things to keep in mind

Next to all the benefits and drawbacks mentioned in the previous chapters, here are more things/concerns to keep in mind.

 

This DOES NOT make your knowledge of web tracking with GTM obsolete

GTM server-side does not completely replace the usual website tracking that you have been doing to this day. You still need to understand how the data layer works and how to configure tags, triggers, and variables in your web container.

Server-side tagging is an additional level of features that you *can* use in your stack. Of course, you can move entirely to the server side, but I still see many cases where the server container works hand in hand with the web container.

As the entire industry is shifting towards pure(-ish) 1st party tracking, the need for server-side will definitely increase. But you will still need to send that data from your website (and the web container in GTM is one of the options).

So if you have doubts about reading/ watching current GTM tutorials, don’t worry, and feel free to dive in. If you are in a hurry and want to get up-and-running FAST, you can check my premium GTM courses.

 

Bad/shady actors

With great possibilities comes great responsibility. And since many things are about to move to the server-side, bad actors can also do that. This talk is about businesses that might/will utilize this new suite of features to avoid ad blockers, etc., and track more information without consent.

But, I guess that’s the price of progress, plus I think that the industry (and privacy guards) will continue to find ways to circumvent/limit this. Somehow.

 

Server-side does NOT make you automatically GDPR/CCPA/etc. compliant

Modern privacy regulations are not about technology. They are about consent. If a visitor did not give you consent for tracking, it does not matter how you collect data — client-side, server-side, whatever.

 

More difficult debugging

Debugging will become more complex. It will not be as simple as checking browser extensions or network requests in your browser (especially if you are debugging someone else’s setup without having proper access to the GTM container).

You WILL need access to the server-side container to debug what is happening inside.

This step is the most painful for those who want to pitch new clients and showcase their expertise beforehand. Regular website tracking allows you to check what data is sent, identify issues + impress the lead. Server-side, however, is a black box that can be opened only with the proper access to the container.

 

Just starting with GTM? Don’t jump into server-side just yet

First, get familiar with the regular (website) GTM container and how it works. When you get confident in that, start learning more about server-side tagging.

Otherwise, you might feel overwhelmed by a knowledge gap that’s too large.

If you want to start with GTM website tracking, grab this free ebook.

 

GTM server-side tagging: Final Words

Should you start implementing server-side tagging right now in your projects?

The answer is classic “it depends”. If you want to be in control of what data is collected by marketing/analytics vendors, invest in server-side tagging.

If you want to reduce the impact on page loading speed (while doing the heaving lifting in your server), choose server-side tagging.

If any other benefit (mentioned in this article) resonated with you. SGTM is for you.

But if your analytics/marketing needs are very basic and you mainly check your data to see what are the most popular pages or where are you getting most of your traffic from, server-side GTM might be too much of an investment because it will induce additional costs.

Google Analytics and GTM have been free for years, thus many businesses got used to the fact that their tracking should be free. Spending at least 3-4 digits per year on server-side tagging might be too expensive for many of them.