Do you want to collect more and more accurate data?
Do you want to have full control of the data you share?
Do you want to (re)target larger audiences with a more relevant message?
Do you want to make your site faster?
If you answer “yes, I do” for at least one of these questions, then you may be interested in learning more about GTM server-side…
Since its public release in August 2020, FIRST has been advocating for implementing GTM Server-Side as we believe it will become a key success factor to collect more and more accurate data, deliver a better user experience, while allowing a stronger control on data collection and sharing.
We have implemented GTM server-side to handle GA4, Universal Analytics and Facebook Conversion API tags across different verticals (retail, finance, food and consumer products) and the results certainly offset the cost.
Server-side tagging means executing tags from a server-side environment (such as Google Cloud Platform, Amazon Web Services, Microsoft Azure, etc.) as opposed to a client-side solution which relies on the browser to send HTTP requests. In August last year, Google released its server-side solution as a new type of container in Google Tag Manager. In this post, we will come back on the differences between server-side and client-side tagging, why it matters and what are the requirements to get it up and running.
GTM Web vs. GTM Server-Side
With GTM Server-Side (GTM SS), you still have your GTM Web container implemented on your pages*, but then some tags within GTM Web can be sent to GTM SS, where a client will be able to receive and transform the data before sending the request to the final endpoint (the vendor). This way, you have full control over how that data is shaped, and where it is routed from the server.
*If for some reasons, you don’t have GTM web container implemented but call Google Analytics directly from on-page tracking code, you can still send the analytics.js or gtag.js request to GTM SS by setting the transportUrl (for analytics.js) or transport_url field (for gtag.js) to your tagging server domain.
Benefits of GTM Server-Side
Faster Page Loading Times
Migrating tags server-side means fewer requests for the browser to handle, which leads to faster page loading times.
Better Organic Ranking
This is related to the faster page loading benefit above. Indeed you can get higher ranking on Google organic search results pages by reducing page load speed since Google is adding the page experience as a ranking signal for Google Search this June. This page experience is based on Core Web Vitals, among which loading time is a key element.
Visitor data is better protected by collecting and distributing data in a customer managed server-side environment. GTM server-side acts as an extra layer where incoming requests can be edited to remove or redact some data you don’t want the vendor to receive, such as PIIs.
More Accurate Data Collection
GTM server-side also allows tracking visitors using ad blockers since tags using requests in a first party context (incoming and outgoing requests) are not blocked. Note that it doesn’t take away the obligation to respect the level of consent given by the user (if any)!
Higher ROI from (Re)Marketing Campaigns
Server-side tagging will help you generate more accurate and larger Audiences, which should improve your (re)targeting messages and help save money. Indeed with client-side tracking (either from GTM Web or directly implemented on-page), you may be targeting the same user more than you should. This means, you may actually be spending more money on remarketing to the same user over and over without conversions!
What Do You Need to Configure GTM Server-Side
GTM SS can be deployed on Google Cloud Platform (GCP) using App Engine or any other server environments (e.g. AWS, Microsoft Azure, etc.) as long as it supports docker.
There are few considerations to take into account when selecting your server-side tagging environment:
- Dev Resources
- Google Cloud Platform using App Engine
This is the tagging server provisioning option by default, where you create a GCP project, select the most suitable data centre region and configure your App Engine.
For a production (flexible) environment, a minimum of 3 app instances is recommended to avoid data loss and latency, with a maximum of 6 with auto scaling on. At approximately NZ$80 / month per instance, it will cost you about NZ$240 per month. But you are free to reduce your minimum instances to 2 or even just 1. Cost will also depend on the volume of requests you expect to send to the server, traffic spikes and the settings you choose (e.g. CPU). For your information, an App Engine server can roughly handle 50 requests per second. The cost also depends on the data centre region you have selected for your GCP project. As of May 2021, Sydney is the second most expensive 🙁 (https://cloud.google.com/appengine/pricing?hl=fi#flexible-environment-pricing)
|Google Cloud Data Centers Location||Region||vCPUper core hour||Memoryper GB hour|
|SALT LAKE CITY||us-west3||0.063||0.009|
GTM server-side is still in Public Beta, meaning that APP Engine’s SLAs don’t apply. There is no support (e.g. help line) from Google nor SLAs dedicated to GTM server-side. However you can find guidelines from the official documentation or from GTM experts such as Simo Ahava.
IT requirements with the App Engine option are very light. The IT department would only need to create the subdomain for the tagging server (that is if you want to be able to set server-side first party cookies) and add DNS records required for ownership verification and custom domain mapping. Then the App Engine configuration can be done directly from the GCP UI by anyone having at least an Editor role. One prerequisite though is to have the GCP project linked to a Google Billing account.
Similarly to the other types of GTM containers, Google provides built-in clients and tags templates for Google’s products, starting with Universal Analytics and GA4 (including Measurement Protocols). Support for Google Ads and Floodlight tags is surely not too far away.
Other vendors will certainly get onboard and propose their own templates, as Facebook did for its Facebook Conversion API tag.
This is valid whether you chose to run GTM server-side with GCP or using your own server provider.
However with GCP, we should also expect further integrations between GTM server-side and other GCP products like BigQuery and Cloud Functions to run real-time ML models for instance.
- Other server environments (AWS, Microsoft Azure, Cloud Run, etc.)
GTM server-side can be implemented on any cloud or on-premise server solution as long as Docker is supported.
In that case, no charge from App Engine of course and no need to create a Google Billing account either. The cost will be the cost of handling additional requests from your own servers. You can start by estimating your needs by calculating your current hits sent to Universal Analytics and / or GA4. Then multiply by the number of vendors you’re expecting to use GTM SS for (e.g. Facebook, Google Ads, etc.). Another option is to create a separate UA and/or GA4 property and serve them from GTM SS for a trial period so that you have a better idea of servers’ requirements and ultimately cost.
From your current server provider, if any, or from the community, e.g. Mark Edmonson wrote a great article on how to configure GTM SS on Cloud Run.
Running GTM SS from your own server requires provisioning
- A server-side tagging cluster
- A server-side tagging preview server
Read more about GTM SS’s manual setup guide: https://developers.google.com/tag-manager/serverside/manual-setup-guide
Apart from these factors mentioned above, the decision may ‘simply’ be down to the ability or ‘political’ will of adding another tech stack to the business’ data architecture.
Preliminary Results: Better Tracking of User Type (new vs. returning users)
One of the benefits of GTM server-side is the ability to set first party cookies from the tagging server as long as it’s hosted on a subdomain using the same TLD than your site (e.g. gtmss.example.co.nz for www.example.co.nz). One outcome is that cookies are not capped to 7 days only on Safari, bringing you a more accurate picture of your new vs. returning audiences.
The charts below demonstrate how this translates for a NZ online retail site: while ‘browser-side’ GA4 identified Safari as the first browser for new users (45%), it dropped to 37% when tracked with ‘server-side’ GA4, while tracking more users. This ‘updated’ information allows the business to take more accurate decisions regarding their acquisition campaigns, among other outcomes.
First_visit event count per browser from GA4 via GTM client-side:
First_visit event count per browser from GA4 via GTM server-side:
GTM server-side does incur some cost to run your tagging server but it is certainly worth it, especially if your product/offer requires a certain level of engagement, which typically translates into long conversion paths (multiple visits before the conversion). Server-side tagging will also most likely become a must-have for many businesses who are under increasing pressure to better govern their data, for compliance with security standards and/or data privacy regulations.
The good news is that GTM server-side is relatively straightforward and affordable to configure so don’t hesitate to reach us for more information and we will help you stay ahead of the curve.