The Benefits and Limitations of Server-Side Tagging in Google Tag Manager (GTM)
Google Tag Manager has recently released Server-Side GTM into public beta, which promises a shift in the current digital analytics landscape, in ways more than one. In this blog article, I will be covering how Server-Side GTM differs from traditional GTM, how it works, and its potential benefits and limitations.
Note: I will get into some of the more technical aspects of this new feature. If you're looking for a more basic take, check out our Beginners Introduction to Server-Side Tagging in GTM.
How Google Tag Manager currently works
If you are reading this, you probably have a fair understanding of how GTM currently works but it is still worth explaining, in order to better understand how it differs to Server-Side GTM. Current GTM configuration without server-side works by first loading a GTM container onto a webpage, which then injects configured GTM tags into the page.
The different tags are fired in response to different events that happen on page, sending data from the browser client-side directly to different vendors such as Google Analytics, Google Ads and Facebook Ads etc.
What is Server-Side GTM?
In comparison to traditional GTM, Server-Side GTM works by running a GTM container on a provisioned cloud server which you have control over. Currently this is limited only to Google Cloud Platform App Engine instances, but Google Tag Manager may eventually push out Server-Side GTM support onto other cloud providers such as AWS and Azure but there is no official announcement on this yet.
Each Server-Side container setup on a GCP App Engine server instance provides its own custom HTTP endpoint. The App Engine endpoint acts as a proxy between an incoming request sent from a user’s browser/app server and the actual vendor endpoints (Google Analytics, Facebook etc) where hits are sent to.
In layman terms, a proxy can be explained as a middleman or gateway where all incoming HTTP requests come through to be processed by the Server-Side GTM container, before being sent to a vendor endpoint. Using the server as a proxy means that you can have full control over how data is shaped and sent to vendor endpoints. It is also important to note that the implementation of a Server-Side GTM container does not mean that a traditional GTM web container is no longer required. A traditional GTM web container is useful for sending requests from a user’s browser/app to the Server-Side GTM container.
The flow for a ServerSide GTM implementation is generally:
- A User’s browser/app sends a HTTP request to the Server-Side endpoint. This can be sent via either traditional web GTM, as a client-side HTTP request, or even as a HTTP request directly from a site/app’s server.
- The Server-Side GTM container will then receive the incoming request and transform this request into different events, using a Client (which is a new component specific to Server-Side GTM). An event is essentially an object which contains different keys and values that can be used by GTM tags.
- Each event is then processed by the Server-Side container’s tag, triggers and variables similar to how it currently works for traditional web GTM. The event model is what is passed from a Client to the virtual GTM container and is used to hold data when communicating from a Client and the Server-Side container.
- Tags in the Server-Side GTM container then map values in the event object to construct a new outgoing HTTP request, and this new request is then sent to one or more vendor endpoints.
The Client entity is a new GTM component which was introduced alongside Server-Side GTM. The Client is an adapter which sits between the incoming HTTP request from the User’s browser/app and the Server Container. Each Server-Side container can contain one or more Clients.
A Client is responsible for capturing an incoming HTTP request, transforming the request data into one or more events, then passes each event onto the rest of the Server-Side container for tags and triggers to run. Once the tags and triggers have all finished doing what they need to do, the Client is then responsible for sending a response back to the original browser/app informing them whether or not the hit succeeded.
When there are multiple Clients in a Server-Side GTM container, each client is configured with a unique path in a Priority Order. Clients higher in the priority order will check whether they can process the incoming HTTP request, before other Clients lower in the priority order. A Client checks if it can process an incoming HTTP request by matching the HTTP request with the configured path for the Client. If it matches, then the Client will claim the request.
If the Client doesn’t claim the request, the next Client in the Priority Order will then continue to check and so forth, until a Client has claimed the request. When a Client has claimed a request, this means that the HTTP request will be processed by the Client and this also informs other Clients lower in the Priority Order to stop running and not check the incoming HTTP request at all.
The Benefits of Server-Side GTM
The introduction of Server-Side GTM into an analytics implementation promises to bring with it a number of large benefits including:
1. Faster Site Performance with reduced Client Load:
2. First-Party Context for Cookies
As mentioned earlier, each Server-Side GTM container offers its own endpoint which is where all HTTP requests are sent to, to be processed by the Server-Side GTM container. This endpoint can be mapped with a custom subdomain, sharing the same domain as your site. This means that any cookies set by Server-Side GTM will be in first-party context, which drastically changes how browser-tracking protections treat the cookie. Additionally it also helps prevent issues with the blocking of 3rd party scripts which is becoming increasingly common in today’s world of user privacy.
3. Content-Security Policies
Many sites today have a content security policy (CSP) in place which allows sites to control which resources a user agent is allowed to load for a given page. With current GTM, a site may have to exclude every vendor domain (i.e Google Analytics, Facebook) from their CSP in order to send hits to a vendor. This of course reduces the overall effectiveness of having a CSP in place.
As each Server-Side GTM container can be mapped to a custom domain and is responsible for sending outgoing hits to vendors, only the GTM subdomain endpoints needs to be whitelisted from a CSP with all other vendor endpoints disallowed from being loaded on a site.
This contributes to both an improvement in CSP effectiveness and a reduction in the maintenance of a CSP when different vendors are introduced into an analytics implementation.
4. Full Control over the data
With the introduction of the Client entity, the Server-Side GTM container has complete control over the incoming measurement data as well as the outgoing HTTP requests to different vendor endpoints. Every request can be processed differently, modified and cleaned for sensitive information before being sent to a vendor collection endpoint. Furthermore a single incoming HTTP request can be split into multiple events and then sent to different multiple vendors, helping to streamline the overall analytics implementation.
5. Hide Tracking IDs and Secret API keys
As the Server-Side GTM container runs in the Cloud, tracking IDs and API keys no longer have to be exposed on the Client-Side which can help prevent analytics spam from arriving in a vendor. For example, currently with Google Analytics each hit to Google Analytics includes the GA tracking ID in the outgoing request which can easily lead to issues with spammers sending bad data to your GA properties.
The Limitations of Server-Side Tagging in GTM
While Server-Side GTM does bring with it a number of benefits, there are bound to be a few limitations and disadvantages to it.
Since the Server-Side GTM container needs to be run on an App Engine instance(s), you will need to pay for the provisioning of the server infrastructure. This differs from traditional GTM containers where there is virtually no cost to hosting and running the container. The actual cost for Server-Side GTM will differ from project to project, depending on the volume of incoming data, the type of provisioned server and the number of instances spun up. By default, if an instance is automatically provisioned when first creating a Server-Side GTM container, a single Standard App Engine instance is created.
2. Vendor Endpoints Availability
Since no third-party libraries are loaded on the Server-Side GTM in order to be able send data to a vendor via an outgoing HTTP request, the vendor needs to offer a HTTP collection endpoint. While this is already true for vendors like Google Analytics and Facebook Ads, a number of vendors only collect data using their third-party libraries and currently for these vendors, there is simply no way for a Server-Side GTM container to send data to them. We can however foresee that with the wider adoption of Server-Side GTM, more vendors will implement HTTP endpoints.
3. Technical Skills
Interested in learning more?
To wrap things up, in this article, we have shown you what Server-Side GTM is, how it differs from traditional GTM and given a brief outline of its benefits and limitations. While Server-Side GTM is still in Public Beta, it is expected to rapidly gain adoption, lead to new standards being set for analytics implementation and a change in the global digital analytics landscape.
While Server-Side GTM will not totally replace your traditional web GTM implementation, the possibilities and potential Server-Side GTM offers and facilitates is simply endless and another step up from traditional GTM. With this article, we hope to have shown you a glimpse of what Server-Side GTM promises to offer.
If you need help better understanding if Server-Side GTM is a good fit for your business, Internetrix can help. Internetrix are Google Analytics 360 and Google Marketing Platform Certified Partners of 13+ years so get in touch today.