Making the Move to Server-Side GTM Part Two: What Is a Client?

Reader Note: To help maintain consistency across supporting technical documentation, any refference to the New Google Analytics in this article will reflect its current naming convention in GTM (GA4).

Where We Left Off

As a quick recap to Part 1, server-side Google Tag Manager (sGTM) is an additional way to send measurement data from websites, servers and any end user’s device to the respective vendor analytics endpoint. You can send data from the browser using image tags or Javascript, or directly using HTTP GET/POST requests. This is possible due to a new entity within sGTM known as a Client.

What is a Client?

Depending on your background, the term Client can be misinterpreted in many different ways. 

Multiple contexts of Client

• Technical: Client is a service requester within the client-server architecture
• Non-Technical: Client is a customer or organization that hired you to work on a project.
• Digital Analyst: Client is a web browser visiting your website
• sGTM: Client is a component that listens to GTM Server requests.

From now on, whenever I reference a Client, I will use the context of sGTM.

What a Client Does

The Client is a component that listens for HTTP requests with a specific url path to your server endpoint (“https://subdomain.domain/g/collect?v=...”). Then, depending on the utility of the Client, it will run its functionality. 

For this reason, the Client is the most important component of sGTM and acts as a gatekeeper that validates and directs event data to the right place. You can think of the Client's role as much like that of a transportation safety agent in the real-world activity of passing through TSA in order to catch a flight at the airport.

Here, the TSA Agent (sGTM Client) evaluates you (the event data object) and your boarding pass (url path: https://subdomain.domain/g/collect?v=…). Once everything has been validated, the TSA Agent will then allow you to go to your gate (the tag that sends data back to your platform ex. GA4 Tag), which will then take you to your destination (platform endpoint, ex. https://google-analytics.com).

How do you create a Client?

Clients are all built with sandboxed JavaScript that provides a safe execution environment. You can build your own Client by creating a custom template (using sandboxed JavaScript) and using all the available APIs specifically for a GTM Server Container. 

This blog post will not go into the details of creating your own custom template, but after some progress, the API instructional documents are now pretty straight forward and there are plenty of examples online. Simo Ahava wrote a great article on how to build a custom Universal Analytics Client that you might want to check out. Fortunately, Google also provides a few Clients that are available to use right out of the box.  

Utilities of a Client

Not all Clients are the same and have different utilities. Looking at Figure #1 above you can see there are five Clients, however, you can sort these clients into two types depending on their purpose.

Purpose #1: Build Event Data Object

The first utility of a client is to create the event data object from the incoming request. As mentioned above, we have five different Clients but only "Google Analytics: GA4", "Google Analytics: Universal Analytics", "Measurement Protocol" and "Measurement Protocol (GA4)" build the event data object and run the container. Here are the Client steps that build the event data object:

Build Event Data (Run Container)

1. Receives the request
2. Claims the request
   • Builds the event data object
   • Pass the event data object to the container
   • Run the virtual container
3. Return a response back to the origin

The figure below shows the sGTM preview mode and you can see the event data object created by the GA4 client from the incoming page_view request. These clients run the virtual container so triggers are activated to determine which tags are fired. You can customize your triggers based on the event data.

After creating a GTM Server Container (via automatic deployment for App Engine or Manual Deployment) there is already a GA4 Client and Universal Analytics Client ready to listen for incoming requests. The "Google Analytics: GA4" and "Google Analytics: Universal Analytics" Clients are the easiest to use and should be used with incoming requests from Global Site tag (gtag.js) and GTM Web API (from your website). Make sure to set the default path.

If you want to send Measurement Protocol Requests to your GTM Server, then you can use "Measurement Protocol" and "Measurement Protocol (GA4)" Clients. Check out our blog post on Adswerve's Python and Typescript Measurement Protocol libraries. Make sure to configure it correctly by adding an activation path. 

Purpose #2: API/Loader

It is not necessary to run the virtual container for every incoming request to your GTM server. You can use a Client as an API or an Asset Loader. This means you can use an available API to send a request to your GTM server endpoint and then the request can be rerouted to an API (via sendHttpRequest) and return the response back to your website. This reduces your reliance on a third-party domain and allows you to tighten up your content security policy (CSP). When you run the "Google Tag Manager: Web Container" Client, it will fetch the GTM library (gtm.js) from Google and then serve it back to the browser that requested it. This enables a first-party relationship, not only with gtm.js but also analytics.js and gtag.js. 

API/Loader (Does Not Run Container)

1. Claims the request
   • Dispatch HTTP request
2. Return a response (status, header, body) back to the origin

If you want to use the "Google Tag Manager: Web Container" Client, follow this guide to update your client-side (website) configuration properly.

Best Practices

Priority Setting

"Priority determines the order in which clients will run. Higher numbers run first, and the first client that matches the incoming request will become the active client for that request."

from Google's Server-side GTM Guide

This is relevant if you have multiple clients that are listening for similar requests. Since only one Client can claim a request, you'll need to make sure you set a high priority number in the Client that you want to take precedence over.

Google Analytics 4 Client - Data Consolidation

One of the many benefits of using Google Analytics 4 with sGTM is the ability to consolidate your data stream. Sending multiple network requests with redundant data to different vendor analytics endpoints can affect your site performance. Using the publisher-subscriber pattern with a one-to-many relationship (aka fan-out), the GA4 Client (publisher) will create (publish) the events and your tags (subscribers) will listen (subscribe) and wait for them to trigger. 

This publish-subscribe pattern will be useful for Google Ads Conversions, Floodlight tags, and other analytics vendors like the Facebook Conversion API (CAPI) tag. Again, Simo has created a detailed blog for utilizing GA4 and the available FB CAPI Tag found in the Template Gallery. We will revisit this topic in a later blog post. However, it is important to note the FB CAPI Tag is missing some functionality, such as the Data Processing Options and custom parameters, and you should understand that there will be some customization necessary.

Another important note is that currently, the Google Ads Conversion Tag (via sGTM) sends a response message to the GA4 client to send back to the browser, which then fires the Google Ads Conversion ping in order to work with third-party cookies (doubleclick.net and google.com) since the GTM Server cannot access third-party cookies. Once third-party cookies are removed from Chrome, the client-side ping will be removed. Although currently, this doesn't reduce the number of requests, it does reduce loading javascript assets (conversion_async.js) which can help site performance.

Loading Google Scripts With CDN Reverse Proxy

It is important to note that your CDN caches static content to improve site speed. Assuming you've correctly mapped your subdomain to your sGTM, your CDN might proxy your HTTP requests for the "Google Tag Manager: Web Container" Client. 

If you've properly configured the Google Tag Manager: Web Container Client, you can verify if your CDN is proxying your Google Tag Manager: Web Container HTTP request by opening your GTM Server in preview mode, open up a new browser window and enter your source URL for the gtm.js (ex. https://<SUB DOMAIN NAME>/gtm/js?id=<G-XXXXXX>"). If you are receiving a 400 status code in the network tab in your Chrome Dev Tools and see the incoming request is not claimed by the Google Tag Manager: Web Container Client and your logs in the Cloud Log Explorer shows that the request URL has no query parameter for the container id, then your CDN is proxying your requests.

Chrome DevTools: Network Request Tab

GTM Server Preview

Cloud Log Explorer Logs

Make sure that your CDN is not proxying your HTTP requests to your GTM Server or else it will cut off the parameters in the HTTP request. There are a couple of workarounds, depending on your CDN Provider, to properly proxy the requests and efficiently cache the google scripts to improve site performance.

Next Up...

In closing, we've learned that GTM servers come with a new entity called a Client. They can be used to 1) build event data and pass to the server container and 2) serve as an API/Asset Loader. Looking ahead, there is another very important component of the GA4 Client and Universal Analytics Client that I have not yet covered in this blog. This is the server-managed cookie. I will dive deeper into this topic in my next post. Stay tuned!

Additional Resources:

Questions about server-side tagging? We can help! Please contact us for answers to your sGTM questions.