GTM Server-Side – what it is, how it works, how to implement it, and common questions arising in Google Tag Manager Server-Side implementation projects. In today’s article, we will discuss GTM Server-Side, how to use this tool in online marketing, and answer some of the most frequently asked questions regarding its implementation.
Google Tag Manager as the foundation of marketing
Differences between GTM Server-Side and Client-Side
GTM Server-Side – advantages
How to implement GTM Server-Side?
How much does GTM Server-Side cost?
Does GTM Server-Side differ from measurement protocol?
What is needed to implement GTM Server-Side?
What tools can be implemented using GTM Server-Side?
How does GTM Server-Side affect data collection?
Can GTM Server-Side be implemented outside Google Cloud Platform?
How long does it take to implement ssGTM?
Does GTM Server-Side work for mobile applications?
Summary
Google Tag Manager is an extremely important tool in online marketing. Effective online marketing is based on data. Data consists of scripts and tools that we install and implement within online marketing.
These tools are most often implemented using scripts and tags embedded in the source code of our website. An alternative to implementing source code for individual tools is using GTM, which is a content management system for scripts. Effective marketing should be based on Google Tag Manager (GTM). After implementing scripts via GTM or directly in the site’s source code, when a user visits our site, its content loads. These scripts interact with external tools, gathering data from the browser, system, and user interactions on the site. This data is then sent to third-party servers.
By visiting any website, we can see what information is being gathered and sent to third parties. Using developer tools available in the browser menu, in the “Network” tab, we find a summary of all scripts, especially JavaScript scripts, that are loaded. As part of online analytics, we can monitor what scripts are loaded in the browser. For example, by using the Collect function, it is possible to see what information is sent from the browser to third-party tools. This data allows for generating metrics related to user behavior and optimizing marketing efforts.
In the case of GTM Client-Side, all scripts implemented on the client-side send information directly from the browser to third-party tools.
On the other hand, the Server-Side container is a tool installed on a server. The browser communicates with this container in a way that instead of sending multiple requests to various tools, a single packet of information is sent to the server.
On the server, data is divided into portions, and the relevant information is forwarded to third-party tools. All the load, which was previously handled by the computer and the browser, is taken over by the server. Naturally, we will incur costs for maintaining the server, as it needs to perform operations to distribute the information to all implemented tools. Thanks to the server configured with GTM Server-Side taking over the interaction load, the performance of our site has improved.
In the browser console, one can notice that many scripts are loaded, consuming the computer and the browser’s computational power. After implementing GTM Server-Side and sending a single packet of information from the browser to the server, dozens of other communications are eliminated. The entire load is taken over by the server, which then distributes the information further.
As a result, our website’s performance improves since the computer has more resources available to load content. The content is delivered to the user faster, positively affecting the Core Web Vitals metrics. This, in turn, has a favorable impact on rankings in organic searches.
Additional benefits of utilizing GTM Server-Side include the ability to enrich the data sent to the server with information that we may not want to reveal to the user at the browser level. This could include information about margins or the cost of purchasing a product. Enriched data, along with user information, is sent to tools like Google Ads, allowing for ad optimization criteria based on more advanced data, such as product margin.
Besides adding information at the server level, we can also remove certain data. Suppose we do not want to send personally identifiable information to third-party tools, following GDPR compliance. In that case, we can remove it from the data packet before distributing it to other tools.
Since the packet of information is sent to a server, usually configured on our subdomain, there is a lower level of blocking these requests by ad blockers and various tools. These tools operate by identifying where the individual signals are going. If the signal is on the list of things to block, it is not forwarded. Implementing GDPR increases the number of registered conversions, as ad blockers do not act on these types of information sent to our server.
The process can be divided into three steps:
In practice, within implemented projects, we check the server load to optimize costs. Basic tools from Google Platform for setting up the server container include App Engine and Cloud Run. Before choosing the first step and configuring the server container, we analyze the traffic to estimate container handling costs and optimize them.
The second step, post-container implementation, involves assessing its resistance to ad blockers. GTM Server-Side is generally resistant to ad blocker operations, but this can still be refined. Therefore, we conduct analyses to evaluate this resistance. If it is at an appropriate level, we leave the configuration unchanged.
Additionally, we optimize client-side tracking, as not everything needs to be tracked through client-side solutions. Companies that implement GTM Server-Side often have duplicated tracking, meaning the same information is being sent from both containers. When implementing GTM Server-Side, we are always mindful of this. Along with configuration, consider the possibility of enriching the data. Clients often need this enrichment, adding information about the product manufacturing cost. This way, campaigns can be optimized based on actual margin and direct product profit, not just revenue. Different products can have varying margins, which is critical information.
For larger organizations with many containers, we conduct analyses to optimize their number. Often, it turns out that a large number of containers is unnecessary. This is especially true for organizations with many websites, where the Client-Side container structure was often not well thought out.
One of the most common questions clients ask about GTM Server-Side is the cost of such a solution. This cost should be divided into two factors.
The first aspect is the implementation cost, and the second is the maintenance cost.
Maintenance costs include managing the implementation of new tools and operating the server hosting the container. With a request rate of about 4-5 requests per second, the cost is around 100 euros. For smaller services, these costs can be at most 250 euros and often close to 25 euros per month.
It is also essential to consider the cost of implementing and maintaining new tracking.
Measurement Protocol is a feature of Google Analytics that allows sending data to GA4 without the user being present on the site. If we have devices that do not support browsers or are not mobile applications, such as kiosks in physical stores, we can send information directly to GA4 using Measurement Protocol. Measurement Protocol is often used to deliver transactions that would not normally be recorded by GA4.
Google Tag Manager (GTM) is not solely for GA4. GTM is used to send data to various tools. GTM acts like a pocket that gathers information from the browser and then distributes it to the appropriate tools. Whether the data needs to go to GA4, Google Ads, or another tool, GTM can send it to the chosen system. Measurement Protocol will not replace Google Tag Manager Server-Side and vice versa, as these are two completely different tools.
First and foremost, a configured server is needed. This means having the space to install the server container. Clients typically choose space within the Google Cloud Platform, using tools such as App Engine or Cloud Run.
Cloud Run is increasingly chosen due to its greater scalability, allowing better cost control. With App Engine, we must determine the number of machines to handle traffic in advance. Cloud Run offers scaling options, meaning the machines will automatically adjust to demand.
Other environments like Azure or AWS can also be chosen. From our experience, the biggest challenge is creating the appropriate space. Other issues, such as server-side configuration and redirecting data from GTM Client-Side to Server-Side, can be handled by us or the web analyst responsible for the implementation.
At one client’s site, we have a list of about 36 tools, some of which will be implemented via GTM Server-Side. Google offers many solutions, such as Analytics, address tracking, Floodlight, and other Marketing Platform tools.
These include pixels for Criteo, Pinterest, TikTok, Twitter, LinkedIn, and others that rely on implementing scripts sending information directly to these tools. Everything we implement on the client-side can also be implemented server-side, i.e., Server-Side.
This can be summarized in two aspects. Firstly, it increases data collection. Tracking performed using GTM Server-Side is more resistant to ad blockers, increasing the level of recorded data and conversions. Secondly, it modifies the data. This can mean both enriching data by adding additional information and removing information we do not want to pass on to third-party tools.
Absolutely. An alternative in the case of Microsoft Azure is Azure App Service. With Amazon’s AWS, it’s Elastic Beanstalk, which is very similar to App Engine in Google Cloud Platform. Elastic Container Service corresponds to Cloud Run. This way, other clouds can be used to handle the server-side container.
The process can be divided into two parts. The first concerns configuring the server and the container on that server. The second part relates to moving the track from the client-side to the server-side and depends on the current GTM Client-Side configuration.
The more complex the configuration and the more data you transmit, the longer this stage will take. On average, such implementations last from 3 to 6 months, including switching tracking from Client-Side to Server-Side.
Currently, no, although this may change in the future. Within the next 1-2 years, ssGTM will become the standard in online marketing tracking.
The sooner you implement ssGTM, the faster you will benefit from its advantages, such as faster website performance and enhanced data transmission. ssGTM also allows for the registration of more data, avoiding, for example, ad blockers. Therefore, it is prudent to delve into this topic as soon as possible.
Implementing GTM Server-Side offers many advantages and positively impacts many aspects of online marketing, such as Core Web Vitals and GDPR-related issues. I am convinced that ssGTM is the future of tracking and data collection on the internet. Hence, it is worth ensuring proper implementation now and improving data collection activities on your site.
Tags:
Success stories
Ostatnie wpisy na blogu
