Update: October 5th. Google Tag Manager Server Side is officially out of Beta, as confirmed by Google, and has entered a new phase.
Announced in August 2020, Google Tag Manager Server-side is still a tool / theme unknown to most.
There are many doubts and questions on the subject and in this post I want to clarify a bit to better understand what it is.
The argument is related to what is happening in recent years on the limits to third-party cookies, concerning both the limitations that browsers are imposing and what Safari is carrying out with the ITP theme.
The main question is: can we save ourselves with server-side tracking?
Let’s try to better understand the working process and give an answer.
How does server-side tracking work?
To understand how server-side tracking works, let’s recap what a tipical architecture can look like in Google Tag Manager.
When I talk about “tipical” I mean a client-side container.
The information collected in Google Analytics, through GTM, are sent to the Analytics servers, according to this scheme:
With the new server-side mode I will always have a container in GTM on the client side, but we add an extra step that is a cloud with a first-party domain, which will host the GTM server-side container:
In practice, a part of the actions will always take place on the client side (in the user’s browser) and another part in the cloud server.
What is the process to follow to configure GTM server-side?
There are a number of steps to follow for the correct configuration of both the domain that will host the server-side container, and the client-side container tags that we want to communicate with the server-side GTM.
- Container creation and cloud project in the Google Cloud Platform. In addition to the client-side container, you need to create a new Server-side container directly in GTM, selecting the “Server” option
Then, create a new project within the Google Cloud Platform, entering directly from GTM:
2. Verify, map and connect the custom domain. As soon as the project is created, Google will provide us with a first domain (it is from Google because it contains appspot.com), with the aim of seeing if the first configurations will be correct. However, to have a first-party context to work within and leave the third-party context provided by Google, we will need to create our own domain. This means that, if our site is www.mysite.it, then we will have to create a subdomain like www.gtm.mysite.it which will host the server.
3. Create the Clients. Clients are the key tool for the server-side container. Let’s say they have the same importance that the data layer has in the development of client-side tracking. Clients process incoming requests and make the information available to server-side tags.
4. Update the tracking setting to send data from the site to the server. Set the first tags so that the information collected is not sent directly to third-party suppliers (eg: Google Analytics, Facebook etc.), but to the created endpoint (in our example gtm.mysite.it).
5. Test incoming requests. Once the first tags have been created, it is necessary to verify that the requests are received and processed correctly.
6. Send the information from the server-side container. The tags are set so that the information is sent to suppliers, directly from the server and no longer through the user’s browser. We can use multiple tags to process information arriving at a single Client.
7. Upgrade to App Engine Flexible and publish the changes. If you have developed everything through GCP, the most flexible solution is to switch from App Engine Standard to App Engine Flexible. Once this is done you can publish the changes in production.
8. Cost monitoring and optimization. Once everything has been published, some sort of audit has to be planned. We need to monitor costs and understand where to optimize. In practice, this means looking at the number of instances and seeing if there are enough or too many. Monitor responses from the server hosting the container and send what is needed. Optimize the tracking structure, for example by using a Client for multiple tags and not a Client for each individual tag (sometimes this is not possible because it depends on whether the tags support a certain type of Client).
9. Increase implementation. With constant monitoring of server-side and client-side activity and tracking, you can move on to increase the server-side implementation and create additional customizations such as, for example, loading the gtm.js and gtag.js from the first-party domain and not via GTM
Why use GTM Server-side? Pros and cons
There are several benefits with a server-side implementation.
- Reduced page load time. There will be fewer scripts that are loaded, because the main place where you can check the information will be the Server and not the Browser. While in the client-side implementation each tag needs a dedicated script;
- Greater control over the type of data sent to vendors. It will be possible to decide which data to send to the third-party tools, cleaning up some information, but also adding others (for example by allowing the CRM talk to the Clients);
- Greater control over PII (Personally Identifiable Information). Easier to control the collection of personal information and avoid its collection;
- Maggior controllo sulle PII (Personally Identifiable Information). Più facile controllare la raccolta di informazioni personali ed evitarne la raccolta;
- Extension of the expiration of cookies on Safari. By acting on a first-party context (the server hosting the server-side container), there will be fewer limitations on the cookie of iOS users;
- Reduction of the impact of ad-blockers. Often some ad blockers also stop requests to Google Analytics. The first part context allows us to reduce these blocks.
However, all that glitters is not gold and there are a number of drawbacks or perhaps possible limitations to this type of implementation:
- Know-how. The implementation of the first-party domain that will host the server-side container requires knowledge that often requires interfacing with the IT department;
- Costs. Depending on the volume that the website has, there are maintenance costs to be faced that can be around a ranging from € 50 to € 200 per month. A detail for the Google Cloud Platform part can be found at this link;
- Maintenance. It is not a solution that is put on its feet and walks by itself. This isn’t true for client-side implementation either, but with a server-side container it’s even more true. A step-by-step implementation process must be followed to understand how much it impacts on server maintenance costs and how to optimize costs. The effort of hours is to be taken into account!
- Solution in development. The package is not yet complete. Many vendors have not yet developed solutions for a server-side implementation. So until they do, it will be impossible to think about migrating 100% to a server-side container;
Parallel implementation: tips
When it comes to running the two implementations at the same time, in practice it is a question of having “double” tags.
Some tags set to collect the information that passes from the Browser and some others that collect the server-side data.
Using Folders in GTM
A good tool to organize this work is to use Folders in GTM and collect duplicate tags to have everything under control.
Identical Settings in the GA Properties
Number of Users
When we have some data, check the number of Users in the different GA Reports: be careful not to be frightened if the number of New Users is different and higher in the Property that collects the server-side data, compared to the Property client-side.
The number of Users must be almost similar between the two Properties. It is normal for the number of New Users to be higher in the Server-side Property, precisely because it has been running for less time and users are considered “new” by the cookie.
We will then need to check the Event metrics between the two Properties and see what the difference is.
Another check that I recommend is to download, in the dedicated Report, the URLs of the most viewed pages: on the one hand from the client-side Properties and on the other from the server-side one.
The purpose is to check that there are no pages that do not appear in either of the two Reports.
This can be useful for understanding why there are shortfalls on aggregate metrics.
Once you have done this implementation path, you can decide to stop the client-side tags, change the destination of the server-side tags to send the data to the main Property used and switch to the server-side implementation only.
But the question arises: does it make sense to move 100% to server-side GTM?
The answer for now is no. The tool is not yet structured to have a valid tracking like the one we know today (client-side).
Update 6th November: even if the version has been out of Beta since the end of September, at the moment not all vendors have tags that can be used for the tracking server. So, I remain of the idea that going 100% to server mode is not the best choise yet.
However, the sooner we know it, the sooner we master it.
So my advice is to approach server-side tracking and concretely understand all the potential it can offer us!
Share your opinion and tell me what you think!
You may also be interested by the following articles:
- Server-side Tagging: what is it?Update: October 5th. Google Tag Manager Server Side is officially out of Beta, as confirmed by Google, and has entered a new phase. Announced in August 2020, Google Tag Manager Server-side is still a tool / theme unknown to most. There are many doubts and questions on the subject and in this post I want […]
- Content Grouping in Google AnalyticsAnalyzing the contents of a website, has it ever happened to you that you want to know what are the performances of the main sections? Each website is divided into sections, which reflect the organization of its contents. This applies to all sites, from e-commerce, which have sections of product categories, type of articles, sellout […]
- Google Tag Manager: Lookup Table VariableThe Lookup Table variable in Google Tag Manager allows you to read the value of an input and, if this value matches certain requirements, it will return some output. There are several situations where this variable can help us: rename a web page, rename the Source dimension for a social (Instagram, Facebook LinkedIn etc.) and […]
- What Virtual Pages are in Google AnalyticsPageviews are one of the best known metrics, present in almost all web analytics reports. This metric is populated with pageview hits, which are sent to Google Analytics every time we view a page or refresh the page itself. However, in recent years a series of technologies have developed that improve user navigation on the […]
- How to track Virtual Pages: Google Tag Manager and Google AnalyticsIn this post, we see how to track Virtual Pages with the help of Google Tag Manager and Google Analytics. If you don’t know what Virtual Pages are and learn more about how they can help you especially if you are tracking a Single Page Application, I suggest you to read my dedicated post. To […]
- Google Analytics 4: Cross Domain TrackingIn this post I’ll show you how to implement cross domain tracking in the new version of Google Analytics 4. With GA4 cross domain tracking is much easier than the Universal Analytics version, in fact: in Universal Analytics you had to set everything up within Google Tag Manager In Google Analytics 4 you can do […]
- Google Analytics 4: Referral Exclusion ListReferral traffic is, generally, traffic from other websites that contain one or more links to your site. The new Google Analytics 4 allows you to measure this kind of traffic for your analysis, without the use of tags, triggers or variables. Proper implementation of referral traffic allows you to understand which other websites are bringing […]