Server-side tracking, Part 1: How to Get Started with Cloud Run

There are several ways to deploy server-side GTM. You can run it on your own physical server or in your preferred cloud environment. The two most common approaches are to manually set up sGTM using Cloud Run in Google Cloud Platform (GCP), or to outsource the deployment and operation to another company that handles it for you, such as Stape.

^{*In the context of server-side tracking, “Cloud Run” is the place where server-side GTM runs. It is available on your own domain, runs your code when a request comes in, and stops it when it is no longer needed. No server “running idle”, no fixed capacity. You only pay for actual usage.}

‍

The Stape option

• It also runs on Google Cloud infrastructure, but the data does not pass through your GCP project. With very strict corporate security rules, this could be a problem, although Stape has SOC 2 / ISO 27001 certification and is therefore highly trustworthy.
• It will be cheaper for websites with up to 500,000 requests per month and one domain.
• With Stape, you do not need to understand the technical side too deeply. Setup is just a few clicks.
• The price is defined in advance based on event volume.
• Stape offers many additional services, but you cannot flexibly customize the service yourself.

Your own Cloud Run option

• Everything runs under your company. Where the data goes depends entirely on you, which means a high level of security and better compliance.
• For standard-sized websites, or when you have multiple domains, the price is the same or even better thanks to scaling. You only pay for the computing power you actually use.
• You configure everything yourself, from security to performance.
• You can use other Google Cloud Platform services, for example to enrich data before sending it to advertising systems.

We naturally prefer our own Cloud Run setup, because it reduces dependency on the operation and support of third parties.

‍

What do you need to run a server on your own Cloud Run?

1. Access to GCP, Google Cloud Platform, connected to a Billing account with a payment card. Other services will then also run within GCP, such as BigQuery, Monitoring, and Cloud Run itself.
2. Admin rights in Google Tag Manager. You need both frontend GTM, the classic web interface, and server-side GTM.
3. DNS access for setting up a new server subdomain.

‍

How to set it up

Setting up the entire Cloud Run environment is technically more complex. On top of that, an update comes out roughly every year that can change the process. However, you can find detailed guides from sources such as Simo Ahava, especially his course in Simmer, or Analytics Mania. In this article, we will go through the basic steps and focus mainly on practical tips and tricks.

‍

Step 1: Create a server-side GTM container

A server-side container is created in GTM in the same way as a web container, but with one important difference: it requires admin rights. When creating it, you will receive a Container Configuration string, which you will need when creating the server in the next step.

One or more server-side GTM containers?

You can have multiple frontend GTM containers and one server-side container. For example, domena.cz and domena.sk each have their own frontend GTM. Because their traffic is low and the differences between the websites are not significant, both domains can be mapped to one server running a single server-side GTM container.

Make this decision mainly based on how the work is organized. If each country has separate teams, separate budgets, or major differences in media activities, choose two servers and two sGTM containers. But keep in mind that you will pay double the operating costs just for running two servers.

‍

Step 2: Create two servers in Cloud Run

Server-side GTM needs two separate servers: preview and production. 

The preview server is used exclusively for debugging. It is configured with minimal capacity, typically 0 to 1 instance.

The production server is the one that actually processes data. It is configured with higher autoscaling, typically 1 to 10 instances, and has the environment variable PREVIEW_SERVER_URL pointing to the preview server.

Both servers are connected to the server-side GTM container using the Container Config.

Explanations and tips:

When setting everything up, you will come across terms that may not be immediately obvious. Here are a few of them.

‍

Server name - Use the project or client name, distinguish between preview and production, and, if relevant, include the region where you are renting the server from Google. Other services may also run in Cloud Run, so clear naming will help you keep things organized later. For example: server-side-tagging-europe-west1-project_name-production and server-side-tagging-europe-west1-project_name-preview

‍

Region - If you are collecting data primarily from Czechia, you should choose a region offering server infrastructure as close to us as possible, such as europe-west3, Frankfurt, or europe-central2, Warsaw. For compliance with data protection regulations, the location should be in Europe. To minimize data transport costs, it is also ideal to choose a region as close to Czechia as possible.

‍

Instance - An instance is allocated computing capacity. How many requests one instance can process depends on the available CPU capacity. What you pay for is how many instances run and for how long. 

‍

Autoscaling - For most websites, we use 1 to 10 instances, and that is more than enough. A minimum of 1 instance means that one instance is always ready and does not need to start up. If you set the minimum to 0, no instance is ready and the first request has to wait for a cold start. If your traffic fluctuates a lot and you need to react quickly, this is not ideal. If you have higher traffic and need to process more requests quickly, it is a good idea to keep two instances ready, meaning a minimum of 2 instances. However, that also means you always pay for two instances. Autoscaling means the server can start additional instances as needed, up to a maximum of 10 instances. On the other hand, if you were hit by spam traffic, you would not spend more than the cost of running 10 instances. Even that can still be expensive, so it is a good idea to have alerting configured. We will cover this in one of the next parts.

‍

Instance-based vs request-based billing

With request-based billing, you only pay for the time when an instance is actively processing a request. Between requests, the instance “sleeps”. The CPU does nothing and is not billed. You only pay for the memory of allocated instances, and for CPU only during active request processing. With a minimum of 2 instances, two instances are ready and start relatively quickly. However, if traffic arrives that requires more instances, waking them up takes more time than with instance-based billing. This can lead to higher request latency and, in extreme cases, server overload.

With instance-based billing, you pay for allocated instances. They are always ready and can react quickly to requests from the website. If the load is higher and continuous, it is better to keep instances constantly ready using instance-based billing. If traffic fluctuates, it is more cost-effective to pay based on requests.

With instance-based billing, a minimum of 1 instance costs roughly CZK 45 per day. Treat this only as an indicative figure. A minimum of 2 instances costs around CZK 90 per day, which comes to approximately CZK 1,350 to CZK 2,700 per month. In return, you get relative certainty that your website can handle traffic spikes and that requests will be processed reliably.
With request-based billing, you can get down to around CZK 300 per month at the minimum level, but during rapid changes in server load, the server may not always keep up.

‍

Debugging - When you debug, the browser sends a request to your production sGTM endpoint. The request contains the X-Gtm-Server-Preview header, and the production server uses this header to recognize that it is a preview request and forwards it to the preview Cloud Run instance.
So the production server receives the request, evaluates the header, and forwards it. This means the production server is always at least slightly loaded. You will mainly notice this when you forget to close the debugging window and receive alerts that request latency, meaning the speed at which the server processes requests, has significantly worsened.

‍

Application Load balancer - yes or no?

A load balancer is the entry gate to the server. Think of it as a company reception desk. Without it, the company, meaning the server, still works. But when a visitor, meaning a request, arrives, you have no way to pass on information about what company it is, direct the visitor in a specific direction, or decide where to place security in the form of Cloud Armor.

Technically, it is a reverse proxy. It sits in front of the server and receives all incoming traffic. The browser connects to the load balancer, which processes the request and forwards it to the correct server. It is “reverse” because, unlike a traditional proxy that protects the user, this layer protects and controls access to the server.

Setting up a load balancer is technically more complex and costs a few hundred crowns per month extra, but without it you lose many of the benefits that server-side tracking offers.

One of those benefits is that data from the frontend will flow to your own domain, which should ideally be mapped to the load balancer, instead of to the domain automatically generated when creating the production server, something like *.run.app. If you use the generated domain, you lose first-party context, the data becomes an easy target for ad blockers, and browsers such as Safari will shorten cookie lifetime to a maximum of 7 days.

So yes, you can live without it. But in our view, it is definitely better to have it.

Step 3: Create a load balancer and map your own domain to it

The process in brief:

1. Reserve a static IPv4 address in GCP IP addresses, under VPC Network.
2. Issue an SSL certificate through Certificate Manager.
3. Create a Load Balancer in Network services.
4. Configure the frontend and backend.
5. Add a routing rule for your own subdomain.
6. Send the DNS records to the client’s developers: “The A records for the new subdomain need to be updated. Use the IP address above.”

As mentioned earlier, detailed instructions can be found from Simo Ahava, especially his course in Simmer, or from Analytics Mania.

Server subdomain:

Ideally, create a subdomain that does not stand out. So not “tracking.yourdomain.com”, but something like “hub” or a random string. If you have, for example, a client zone that sits on a different domain, you need to create subdomains for both of your own domains. The main goal is to preserve first-party context, meaning data from the website should be sent to the same domain. You can then map both subdomains to one server and connect them through a single server-side GTM container. This saves costs for both operation and setup.

‍

When should you set up Cloud Run? 

If you want to launch server-side tracking now, confirm the server subdomain and go through the full process above.

Sometimes, however, you may also be adjusting your tracking setup, working with development on dataLayer pushes, or waiting for other actions, and the live launch of server-side tracking may only happen in a month.

There is a fee of roughly CZK 400 per month for reserving a static IP address and creating the load balancer, regardless of whether your tracking is already running or not. Be careful not to start paying Cloud Run costs too early.

‍

Step 4: Test that everything works correctly

Test 1 - Verify that the domain works and the SSL certificate is active

Enter the following in your browser: https://hub.yourdomain.com/healthy

If it returns ok, the server is running, SSL works, and the load balancer is routing correctly.

If it returns an error or an SSL warning, the certificate is probably still being provisioned. This can take up to 24 hours after DNS configuration.

‍

Test 2 - Verify that the preview server works

Open: https://hub.yourdomain.com/gtm/preview

It should return some kind of response, not a 404.