Google Tag Manager Server-Side : The Complete Guide

The aim of this article is to give you all the keys you need to determine whether implementing a GTM server-side solution is a good fit for your business, and also the steps you need to take to implement it.

Before we dive in, you may be interested in a more specific guide:

• Google Ads Server-Side Tracking with Google Tag Manager
• Matomo Server-Side Tracking with Google Tag Manager

What is Google Tag Manager Client-Side? #

In its client-side version, Google Tag Manager collects data on your website and sends this data to marketing platforms such as Google Analytics, Google Ads or Facebook Ads through the browser.

flowchart LR
    subgraph Browser
        A[Your website]
        subgraph I[Google Tag Manager]
            F(Tracking code GA4)
            G(Google Ads tracking code)
            H(Facebook Pixel)
        end
    end
    C[Google Analytics Server 4]
    D[Facebook Ads server]
    E[Google Ads server]
    A --- I
    Browser -- google-analytics.com/collect --> C
    Browser -- www.facebook.com/tr --> D
    Browser -- googleadsservices.com/pagead/conversion/ --> E

The browser then sends requests directly to the marketing platforms you work with. Thanks to tracking codes, these platforms can deposit first-party or third-party cookies in the browser to identify the same visitor across multiple visits and/or link a visitor to an ad click.

Advantages of GTM Client-Side

1. relatively simple to set up (the biggest complexity lies in manipulating the Data Layer)
2. the community has developed numerous tag and variable templates to make your life easier
3. there are many tutorials on the web to help you
4. it’s what’s been done for a long time, so it’s easier to find these skills on the market (whether to recruit or outsource)
5. Google Tag Manager Client-Side is completely free

Drawbacks of GTM Client-Side

1. allows the use of third-party cookies which are blocked on Firefox, Safari and Brave but not on Chrome
2. tends to increase page load times, as you need to add one tracking code per marketing platform
3. you have very little control over the data you send to marketing platforms (data is collected automatically, it’s either all in or all out)
4. requests sent to marketing platforms may be blocked by ad blockers (most of them are, ad blockers are doing a pretty good job)

What is Google Tag Manager Server-Side? #

Instead of sending requests to each marketing platform’s servers, you’ll only send requests to your own server. Your server will then communicate with the marketing platforms.

flowchart TD
    subgraph Browser
        A[Your website]
        subgraph I[GTM Client-Side]
            F(Tracking code GA4)
        end
    end
    subgraph J[Your server]
        subgraph K[GTM Server-Side]
            R[GA4 Client]
            L[Google Ads tag]
            M[Facebook Ads tag]
            N[Google Analytics tag]
        end
    end
    R --> L
    R --> M
    R --> N
    Browser <-- HTTP --> J
    L -- googleadsservices.com --> O[Google Ads API]
    M -- graph.facebook.com --> P[Facebook Ads API]
    N -- google-analytics.com --> Q[Google Analytics API]

Advantages of GTM Server-Side

1. reduces your website loading time (especially if you need to send data to a lot of marketing platforms).
2. gives you total control over what data is sent to marketing platforms, as your server acts as an intermediary (dictating what data gets through and what doesn’t).
3. you’re less prone to ad blockers (with specific configuration), as GTM and GA4 javascript libraries can be downloaded from your server with unique paths.

Drawbacks of GTM Server-Side

1. you have to pay for cloud hosting of your server.
2. managing a server in the cloud requires additional skills (setup, monitoring, scaling, etc.).
3. few tag templates are currently offered by the community.

Client-Side VS Server-Side skills #

mindmap
  root[Skills <br>Client-Side <br>vs Server-Side]
    [Client-Side]
      (Javascript)
        (Variables)
        (Functions)
        (JSON)
      (Cookies)
      (CSS selectors)
      (HTML DOM)


    [Server-Side]
      (HTTP)
        (Requests and responses)
        (Cookies)
        (JSON)
        (Logs)
      (Cloud)
        (DNS)
        (Load balancing)
        (Monitoring)

Create a server container in GTM with Cloud Run #

Provision a new server container

In Google Tag Manager, create a new container and choose Server as the target platform.

Once your container has been created, Google Tag Manager will ask you how you’d like to configure your server. You can do this either automatically (this will configure a server for you in Google Cloud) or manually (this gives you the option of configuring your server yourself).

To make things easier, we’re going to choose automatic provisioning.

At this stage, if you don’t have a billing account in Google Cloud, you’ll need to create one.

Once that’s done, select your billing account and create your server.

Creating the server will take a few minutes…

Once the server has been created, two important pieces of information are displayed:

1. The Google Cloud project in which your server is located
2. The default URL for sending requests to the server

Link your domain name to the server container

Linking your domain name will allow you to deposit cookies in a first-party context. This is one of the advantages of server-side tracking, so this step is important.

Go to your Google Cloud project then Cloud Run.

This takes you to the overview of your Cloud Run services.

Here we see that there are two services:

1. the tagging server
2. the preview server

With this configuration, test requests will be sent to the preview server and real requests will be sent to the main tagging server.

To link your domain name, click on the main tagging server service:

Then go to the Integrations tab.

Click on Add integration then select Custom domains.

Then enter your subdomain and activate the necessary APIs.

Once the APIs have been activated, you can click on the SUBMIT button.

Add your DNS record

In the Customized Domains integration you’ve just created, a window shows you the configuration to be performed on your DNS records.

For my part, I’m going to do this configuration on Cloudflare but this depends on the domain name host you’re using.

Depending on your DNS host, the link of the domain name with your Cloud Run tagging server and the generation of the SSL certificate can take between 10 minutes and 24 hours.

Once this is complete, the integration status will change to Active.

Test the server with your domain name #

Before testing your domain name, you need to modify the server container configuration to indicate the new URL of your server.

To do this, go to Admin then Container settings. Here, change the server container URL.

Then activate preview mode in your GTM server container.

At the same time, enter your server’s domain name (here https://sst.data-marketing-school.com) in your browser. You should get an error 400.

Even if you get an error at this stage, this means that the server has responded and is working. You can check this in GTM Server-Side’s preview mode.

Congratulations, you’ve completed your server’s Cloud configuration.

Enable logging #

On Google Cloud, go to the Load balancing section and click on the backends tab. Here you should see your server.

Click on the backend service that corresponds to your server, then on Modify.

Scroll down to the Daily section, then modify the settings like this.

Then click on the Update button.

Congratulations, you’ve enabled logging.

Deploy Cloud Run server #

Once you’re happy with your Server-Side configuration, you need to put your server into production before sending it any traffic.

Go to the settings of your Cloud Run instance and scroll down to the Autoscaling section.

The default settings are as follows:

Google’s recommended settings to go live are between 2 and 10 instances. Cloud Run instances will be added or removed according to traffic load.

Then click on Deploy.

Delegate cloud management #

It may seem paradoxical, but one of the main advantages sold with GTM Server-Side is ad-blocker bypass, but this is not natively available when you go through Google Cloud Platform.

To take full advantage of GTM Server-Side, I strongly advise you to delegate your cloud management. I’m going to introduce you to 3 tools that manage the entire infrastructure/cloud side of a GTM Server-Side implementation from A to Z.

• Set up your server with Addingwell (free plan up to 100,000 requests)
• Set up your server with Stape (free plan up to 10,000 requests)
• Set up your server with Taggrs (free plan up to 10,000 requests)

Send your data to the server #

To send data to your server, we’ll use GA4 as a carrier.

On the client-side, you need to tell the Google Tag to send the data to your server. To do this, you need to add the server_container_url parameter to the configuration parameters.

The value should be the URL of your server.

If certain event tags are triggered before the Google tag, they will use the default configuration and send requests directly to GA4 without going through your server. This will lead to data accuracy problems later on.

To avoid this, it’s best to add the server_container_url parameter as an event parameter for all your GA4 event tags.

What is a Client? #

A client listens to requests arriving on your server. If it recognizes a request as its own (for example, the GA4 client recognizes /g/collect requests) then it will “claim” it.

Only one client can claim a request. In other words, one given request cannot be claimed by several clients at the same time.

A client has a priority. The client with the highest number has the highest priority.

Once a client has claimed a request, it will parse the information inside to extract an event name and event data that can be used by tags or triggers.

Configuring the GA4 client #

The GA4 client is available by default in a new GTM Server-Side container.

Default GA4 paths

This checkbox is checked by default. It allows the GA4 client to listen for /g/collect requests.

If you uncheck this checkbox, the client will no longer Claim GA4 event requests.

Default gtag.js paths for specific IDs

This checkbox enables gtag.js files (e.g. the GA4 library) to be delivered from your server.

Cookies and client ID

When you’re in Client-Side, the cookie used by GA4 to identify a user is _ga.

When you switch to Server-Side, the cookie used by default (initial GA4 client configuration) to identify a user is FPID for First-Party IDentifier.

In the configuration you can choose to keep on using the _ga cookie, to use the FPID cookie or a mix of the two.

Javascript managed #

The _ga cookie will always be used even if you’re in Server-Side.

Server managed #

The FPID cookie will be used.

When in server-managed mode, you can also check the Migrate from JavaScript Managed Client ID checkbox. This will continue to use the _ga cookie for existing users, but will also drop the FPID for new users.

Configuring the GA4 tag #

Since we’re using the GA4 data standard to send data to the server, configuring the GA4 tag is pretty straightforward, as it will pass the data through to your GA4 property.

To simply send the data to GA4, you can create the tag and leave the configuration empty.

Consent Mode management #

If you have configured Consent Mode on the client-side and are using the GA4 standard to send data to your server, server-side tags will automatically take Consent Mode into account.

Consent Mode values are sent in the GA4 request via the gcs and gcd parameters.

These values are then extracted by the GA4 client, which will put them in the event data in the x-ga-gcs and x-ga-gcd parameters. The gcd parameter can also be found in x-sst-system_properties.gcd.

With these parameters, Google Tags (GA4, Google Ads and Floodlight) will adapt the behavior on the server side.

Preview tabs #

Requests

Here you can see which client has claimed the request, as well as incoming and outgoing requests from your server.

Tags

As in the Tag Assistant on the client-side, here you can see which tags have been triggered and which have not.

Variables

As with GTM WEB, there are built-in variables and also user-defined variables on the server side.

As a reminder, built-in variables are pre-existing variables that you can enable or disable in your container.

User-defined variables are variables you have to configure yourself. For example, the Event Data variable type will be useful on the server side for fetching a specific parameter from event data.

Event Data

Event data are all parameters that have been extracted from the incoming GA4 request.

As a reminder, this event data is generated by the GA4 client.

Console

The console displays messages sent by tags when they are triggered.

These messages can be information, warnings or errors.

Transformations #

With transformations, you can add, modify or exclude parameters in event data.

As soon as a transformation is applied, tags must use the transformed parameters, rather than the original event data.

FAQ #