Google Tag Manager Server-Side Tagging: Tutorial

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

Before going any further, you might 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 via the browser.

flowchart LR
    subgraph Browser
        A[Your website]
        subgraph I[Google Tag Manager]
            F(GA4 tracking code)
            G(Google Ads tracking code)
            H(Facebook Pixel)
        end
    end
    C[Google Analytics 4 server]
    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 a click on an ad.

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 Internet 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 you’re recruiting or outsourcing)
5. Google Tag Manager Client-Side is completely free

Drawbacks of GTM Client-Side

1. cookies deposited via JavaScript are subject to restrictions in most browsers
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 collected automatically)
4. requests sent to marketing platforms may be blocked by ad blockers

What is Google Tag Manager Server-Side? #

Instead of sending requests to each server of the marketing platforms you use, 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(GA4 tracking code)
        end
    end
    subgraph J[Your server - Hosted on GCP or Addingwell or Stape]
        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 in particular can be downloaded from your server with unique paths.
4. cookies deposited by the server will be less subject to browser restrictions and will have a longer lifespan.

Drawbacks of GTM Server-Side

1. cloud hosting of your server has a cost and is complex to maintain (facilitated by Addingwell or Stape)
2. requires more skills to set up (mastering GTM Client-Side is not enough to be operational with GTM Server-Side)

Client-Side VS Server-Side skills #

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


    [Server-Side]
      (HTTP)
        (Requests and responses)
        (Cookies)
        (JSON)
        (Logging)
      (Cloud)
        (DNS)
        (Load balancing)
        (Monitoring <br>of resources)

Delegate cloud management #

It may seem paradoxical, but the main benefits that come with GTM Server-Side (bypassing ad-blockers, extending cookie lifetime) are not natively available when you go through Google Cloud Platform (GCP).

=> To take full advantage of GTM Server-Side, I strongly advise you to delegate your cloud management.

To this end, I’m going to present 2 solutions (Addingwell and Stape) that manage the entire infrastructure/cloud of the server-side implementation from A to Z. This will enable you to choose the solution best suited to your needs.

Before getting started, here’s a table comparing the 2 solutions.

Set up Addingwell #

Container creation #

Once you’ve created your Addingwell account, you’ll be asked to create a container. This container will host GTM Server-Side.

The next screen asks for a Container Config, which we’ll find in the next step in GTM Server-Side.

Creating a GTM Server-Side container #

Go to tagmanager.google.com, then on the account of your choice create a Server container.

Select Server as Target Platform.

Then click Create to create your server container. You will then come to a popup where you must select the Maunally provision tagging server option. As soon as this option is selected, the Container Config appears.

Copy the Container Config and paste it into the Addingwell interface. Then click Next.

Congratulations, at this stage you’ve made the link between the Addingwell infrastructure and your server container on Google Tag Manager.

Creating the custom domain #

In this section, we’ll link a sub-domain of your main domain to your Addingwell container. Since my main domain is data-marketing-school.com, the sub-domain I’ll choose is aw. The access URL to my tagging server will therefore be https://aw.data-marketing-school.com.

Fill in this information in Addgingwell then click Next.

The Addingwell container is now waiting for DNS configuration.

DNS configuration #

As specified on the Addingwell interface, here are the two DNS records I need to configure:

The configuration of these records must be done on your DNS host. As far as I’m concerned, my website’s DNS records are managed on Cloudflare.

Congratulations, your custom domain is now configured.

Finalizing Addingwell configuration #

On the Addingwell side, the server is now being provisioned.

A few minutes later, your server is ready to use.

All that’s left is to specify your server URL in GTM Server-Side in Admin > Container Settings.

Congratulations, you’ve finished configuring your server with Addingwell, you can now open the preview on GTM Server Side and start sending requests to your server.

Set up Stape #

Container creation #

Once your account is created, go to your Dashboard and click on Create sGTM container.

Next, give your container a name and specify the location of the servers. At this stage you can leave the Container Config field empty, as we’ll fill it in later.

Stape will then offer you their prices, so you can start with the free plan.

Creating the GTM Server-Side container #

Go to tagmanager.google.com, then on the account of your choice create a Server container.

Select Server as Target Platform.

Then click Create to create your server container. You will then come to a popup where you must select the Maunally provision tagging server option. As soon as this option is selected, the Container Config appears.

Copy the Container Config and return to the Stape interface. In the Container settings section, click on Edit.

Fill in the Container Config then click Save.

Congratulations, after a few minutes your Stape container is now in Running state. We can now move on to creating a custom domain.

Custom domain creation #

In your Stape interface, click on the Add custom domain button.

Enter the URL you want for your tagging server, choose manual connection and click Next.

Stape now offers you to configure a DNS record.

DNS configuration #

As specified on the Stape interface, here’s the DNS record I need to configure:

The configuration of this record must be done on your DNS host. As far as I’m concerned, my website’s DNS records are managed on Cloudflare.

Return to the Stape interface and click Verify. A few minutes later, your server is ready to use.

Congratulations, your custom domain is now configured.

Finalizing Stape configuration #

All that remains is to specify your server URL in GTM Server-Side in Admin > Container Settings.

Congratulations, you’ve finished configuring your server with Stape, you can now open the preview on GTM Server Side and start sending requests to your server.

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 settings.

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 passing through your server. This will lead to problems in the data stream 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 and the same request cannot be Claimed by several clients at the same time.

A client has a priority. The client with the highest priority will claim a request before other clients.

Once a client has Claimed a request, it will retrieve the information inside to extract an event name and event data that can be used by tags to send this data and/or get triggered.

Configuring the GA4 client #

The GA4 client is present 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 it, 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 continue 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 propose 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.

It is these parameters that will adapt the behavior of Google tags (GA4, Google Ads and Floodlight) 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 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 retrieved 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 and no longer the original event data.

FAQ #