Proper tag implementation is a critical component to maintaining accurate data and pulling in the information you need. While you may have already dabbled in client-side tagging solutions by deploying tags on the website itself (via Google Tag Manager (GTM) or manual implementation of Google’s global site tag), a newer option has risen to the top in Server-Side Tagging (sGTM).
sGTM takes the concepts of Google Tag Manager from the client-side and brings them directly to the server, allowing customers to run a Tag Manager container in the cloud. While there are a host of benefits to working with sGTM, there are many requirements and considerations that need to take place before making the full move to a sGTM setup.
Whether you’re wondering if you should consider making the move, not sure where to start, or just plain curious, this multi-part blog series has you covered. We’ll dive into everything you need to know, from the basics of server-side tagging to the costs, benefits and challenges of sGTM. So read on and learn all you need to know about sGTM.
What is Server-Side Tagging?
Server-side Google Tag Manager is an intermediary server between the data being collected from the browser (or any other online connected device) and the vendor’s endpoint (Google Analytics, Google Ads, Facebook, etc). When you are using a sGTM container, the data that would have typically been sent straight to the vendor’s endpoint via a tag or pixel is now routed to your own cloud infrastructure. You can then modify it as needed and use tags within your sGTM container to dispatch that data to the specific vendors that require it. There are several benefits to having this intermediary location for data collection. There are also many considerations before deciding to use server-side tagging.
Privacy and Data Security
Using a server-side proxy enables you to modify the outgoing requests to vendors so that only the data you truly mean to send to them makes it into platforms like Google Analytics and Facebook. For example, using server-side tagging you can hash emails, redact IP addresses and remove the user agent string from the hit if needed. Server-side tagging also minimizes data leakage, specifically from pixels that can traverse unsecured networks on their way to vendors’ platforms.
When you route data through your own servers, you have complete ownership of that data. You can use it within the Google Cloud Platform (GCP) or whichever cloud provider you are using, however you want to.
Efficiency in Data Collection
Having redundant network requests sent from your website to multiple vendors can put a lot of strain on your site and negatively impact its performance. If you have ten vendors that all require the same detailed data, that many large requests can add up and cause slower load times. With sGTM, you are able to take an event data object created by a Client and configure an sGTM tag to send that data off to several vendors that require the same data. This means that there is only one, or perhaps a handful of, requests necessary within the browser, and then the server does the rest of the work.
Optimal browser performance can have several benefits. First and foremost, quick load times lead to a better experience for the end-user, and therefore likely better engagement. Additionally, Google recently announced that page experience will become an organic ranking factor starting in mid-June of this year and will roll out through August. This means that improving site speed and focusing on Core Web Vitals will also be an important part of SEO programs moving forward.
A conversation about sGTM must start with a conversation about resources. Since hits are collected into your own cloud server, the process of data collection itself incurs a cost. Known as a network egress, this cost is essentially a fee for moving your data out of the cloud. It incurs a cost in your GCP project every time the Client you have set up responds to a request and each time a tag or Client sends a request to a vendor’s server.
Optimizing how many requests are sent from your server can help to greatly mitigate costs. There is also a process called logging (that will be discussed in more detail later) that also incurs a cost. Logging is a useful tool for debugging, but unchecked, it can be a source of significant expense.
It is also important to consider the cost of management of your cloud infrastructure. sGTM is not a “set it and forget it” implementation. Continually monitoring network egress and logs, consolidating your data streams so you aren’t pinging your server with the same data redundantly, and monitoring your use of instances to ensure your setup can handle the traffic being sent at any given point are all critical pieces of managing a server-side setup.
Google has enabled a method to route the data we normally send to Google Analytics’ servers directly to our own server end-point instead via a parameter called a transport URL (more to come later in our blog series). Facebook has developed their Conversion API that enables the same process. Though these media giants are ahead of the curve, not all media partners have adopted compatibility with a server-side endpoint. If you are eager to fully migrate to a server-side implementation, time-cost will become a factor. You may need to wait on certain vendors to release their own templates or invest more time and money on technical services to help develop, update, and maintain custom template solutions.
Are you ready to use sGTM?
How do you know when it’s a good time to move to sGTM? Here are a few foundational requirements to consider.
- You need to have a solid client-side tagging setup (think the web GTM container we all know and love) supported by a solid data layer implementation. This data is still being collected and sent from your website. The only difference for server-side tagging is where you are sending that data and how.
- You need to have the necessary resources to pay for the cloud technology costs associated with your server-side instance, as well as the resources to support the cloud infrastructure management required for cost, data collection and server instance optimization.
- It is important that you have considered the reasons for moving to sGTM. Is it site performance? Privacy concerns? Do you want more ownership and control of your data? Because the leap to sGTM requires much more intention than that of a web implementation, it is worth having these key conversations beforehand.
- You have communicated with your end-user about the privacy and transparency of their data and are clear that just because you can collect their data and send it on to vendors without their permission, you are dedicated to respecting their consent.
A Word of Caution
Since your data is being sent to your own server that lives on your own subdomain — which sets this data collection to be done in a first-party context — it may be tempting to use server-side tagging as a way to get around some of the more restrictive legal regulations and browser policies. It is important to remember that you still have to follow relevant laws and respect user consent for data collection. sGTM is not a way to circumvent ad blockers or collect data without users knowing and without their consent. Finally, it is important to ensure you have the proper resources coordinated before taking the leap to sGTM. An implementation not fully supported can end up costing more in the long run.
How Does sGTM Work?
Components of an sGTM Container:
In sGTM, you will see all of the components you know and love from a web container. There are tags, triggers and variables, which are used much in the same way as they are in our web containers. The new addition is an entity called a Client. The client is an entity that constantly listens for incoming HTTP requests, creates the event data object, runs the server container and responds to the request. This new component is essential for sGTM, which is why we will dive deeper into this topic in the next blog post in this Server-Side Tagging Series.
How sGTM Works at a High Level:
As mentioned, the Clients in the Server Container play a big role in how sGTM works. They are configured to accept, parse and respond to HTTP requests in a specific format, but what does that look like at a high level? One example is the simple task of sending your data to Google Analytics via the new Google Analytics (GA4) tag.
Here, the GA4 Client accepts HTTP requests that come from pings to your server from a GA4 tag that resides in your GTM web container (or code on your website, if you are using a hard-coded gtag implementation).
Tags built from template APIs are then configured using triggers and variables to take the data available within an event data object (created by the Client when they parsed the data from the incoming HTTP request) and send it forward to a vendor’s endpoint in the format required by that specific vendor.
Incoming HTTP requests can come from any online connected source, including measurement protocol requests from online point of sale systems, but the simplest setup, that will likely align strongly with what you are already doing in your data collection efforts, will be to send HTTP requests via web tags that reside in your GTM web container to your own server-side endpoint.
We’ve talked about all the basics you need to know about whether the move to server-side tagging is right for you. From the benefits and challenges to the key conversations you need to have, there’s a lot to consider. It’s more of a technical setup with the Cloud instance and is more resource-intensive, but the benefits can set you up for greater future success.
That said, if you’ve gotten through this article and realize that you’re more interested than ever in sGTM, read on! Part 2 in this blog series dives deeper into sGTM’s most important component, the Client.
Adswerve has been a part of the initial Alpha testing group for sGTM where we've learned and helped shape the product. Our experts are always available to help with any questions or consulting advice. Contact us for more information.