05 February 2024
5 expert tips for seamless server-side Google Tag Manager implementation
In summary
- The adoption of server-side tagging is becoming more enticing as privacy legislation continues to decrease the reliability of existing client side tagging.
- The most popular server-side solution is Google Tag Manager (sGTM), which will be the focus of this article, however many of the tips below can be applied to other solutions.
- There are a variety of things to consider when implementing server-side tagging in order to ensure that your setup is future proof and ready to measure from the outset.
What is server-side tagging?
Server-side tagging, as the name suggests, involves the transfer of your website tags from the browser (client) to a server environment. The benefit is four fold:
- Improves user privacy
- Increases the longevity of your tagging accuracy alongside the rollout of privacy legislation
- Enhances the quality of data sent to analytics and advertising platforms
- Improves your website’s performance
Huh, you must be thinking, seems like a win-win solution.
It would be, however, server-side tagging can also be a large undertaking and the amount of effort to consider when implementing can feel overwhelming at first. To help clear through the fog of informational uncertainty, Louder has listed below the 5 most important factors to consider and discuss when beginning your journey into a server-side future.
1. Server infrastructure
The most important aspect to consider when thinking of how you should implement server-side tagging, is of course, what server infrastructure to use. Luckily, there are a number of solutions available which allow you to tailor the tagging solution that best works for you and your business.
Before proceeding, it is important to clear up that server-side Google Tag Manager (sGTM) works not as a replacement for client side tag manager, but instead as a complementary layer - providing further control over the flow of data between your business and advertising/analytical platforms.
As mentioned previously, when it comes to sGTM implementation there are a variety of hosting environments available which can be divided into three categories:
- Native Google Cloud
- Non Google Cloud hosted
- Independently owned server environments
Google Cloud hosted
Google Cloud hosted is generally the default method for sGTM implementation. It is the easiest to implement in terms of user experience due to it being native to the service. As such, even with limited knowledge of the Google Cloud platform, users can easily implement sGTM via this method through the GTM interface. Despite it’s ease of use, there is also the possibility that this may not be the ideal configuration for you due to implementation issues we will discuss in latter sections. Regardless, it is Louder’s recommendation that unless users have pre-existing server infrastructure within another environment, cloud hosted is the best of the three environment types.
Non Google Cloud-hosted environment (e.g. Amazon AWS and Microsoft Azure)
Alternatively users can implement sGTM with a huge swath of other cloud services. This is a relief for users who may have their website hosted in one of these alternate cloud services as it increases the durability of your measurement and helps shield you from the impact of Apple ITP and other recent privacy legislation (something we will expand upon in the next section).
On the downside, outside of the bigger cloud providers (e.g. Amazon AWS, Microsoft Azure, etc.) there is less extensive documentation on how to implement sGTM. As such, implementing sGTM outside of Google Cloud will require more knowledge, experience, and potentially a specialist proficient with these platforms.
Independently owned server
Finally if you have your owned privately owned server instance or require one due to security issues, there is also the option to implement sGTM within that server environment. As it would be expected, this is the most complex of the three to set up and as such, is most likely to encounter issues.
Which solution should I use?
As for which solution to use, the best solution depends primarily on your existing circumstances. If you are already hosting your website through a provider outside of Google Cloud, it is recommended to continue utilising them with sGTM. If however, you are in the situation where you have no pre-existing requirements for the hosting environment, Google Cloud is Louder’s preferred method. This is primarily due to it being the native setup and therefore much easier to setup without platform proficiency.
2. Website infrastructure (Safari ITP and first party cookies - depend on first 2 octets of IP range).
During the transition to Safari version 16.4 in June of 2023, Apple implemented updates to their privacy ITP technology in response to the use of CNAME cloaking tactics (a tactic which circumvented Safari’s privacy restrictions on third party tracking cookies by effectively disguising them as first party). Safari did this by restricting the cookie lifespan to 7 days for all cookies where the first two octets of the website address were different to the server container’s IP address. In doing so, they incidentally also caused many actual first party cookies to be labelled as third party and have their lifespan reduced. There are two ways to resolve this issue.
Server-side tag manager location
As mentioned previously, it is recommended to implement your tag manager instance within the server service as your website is contained. Thereby this will increase the likelihood (or ensuring depending on the service) that the IP address of the website and the subdomain where the tagging server is held, returns the same two octets on their IP address.
Load balancer
Alternatively you can utilise a load balancer to overcome this issue. A load balancer sits between the server and the user and is a resource used to mediate the distribution of tasks between a series of server instances in order to ensure that all servers in a network are utilised equally.
As a byproduct of this, a load balancer also leads to the information requested from any server on the network returning the same IP address regardless of its geographic location. Therefore it is important to ensure when data is sent from the website server to the tagging server, that both have the same IP address. It does have to be said however, that the implementation of a load balancer may lead to additional costs and increased complexity with your sGTM setup. How much it could end up costing is dependent on the amount of data that is being processed by the server. On the flip side, if you are already using a load balancer, it is just a case of tweaking the existing one to work seamlessly with the tagging server.
Solution
As with the previous section, which option you utilise in this instance is based upon your existing setup.
3. Server-side GTM sub-domain implementation and naming scheme
When you initially implement sGTM, the tagging server will be, by default, run in a domain created automatically by the service you are running it through. This will need to be changed in order to leverage the full benefits of sGTM, as in this state, all data that is received by sGTM is still considered as third party due to the domains being different. As such, you will need to expand on your tagging server configuration to utilise a sub-domain or ideally a same-origin configuration.
This can be done either by putting the tagging server in a subdomain of your website or by putting it in the same domain as your website but under a URL path that is reserved for sGTM usage. The latter of which requires the usage of either a load balancer or content delivery network (CDN).
Regardless of which option you choose, ensure that the name you give for your subdomain or URL path is one less likely to be flagged by ad blockers or future privacy legislation. As such, it is recommended to not use terms such as ‘track’ that may be targeted by ad blockers or privacy legislation in the future.
4. Resource allocation and redundancy plans
Unlike with traditional client side tag management, sGTM requires additional factors of server management to ensure that all the data being collected on your website is not lost. Improper service resource allocation, can and has in the past led to many people losing huge swaths of website information which could have been used. The primary factors with sGTM implementation are ensuring that you have a sufficient minimum number of server instances to deal with your expected daily demand, alongside the ability to scale your instances as necessary to deal with unexpected spikes.
As mentioned previously, the minimum number of server instances required is dependent on your average website traffic on a day to day basis. For most businesses utilising sGTM, the recommendation for the minimum number of instances is three. Depending on your website traffic’s specific circumstances and historical requirements, add or remove instances from this average as necessary.
When utilising Google Cloud as your cloud based server, there are options that allow for automatic scaleability for both app engine and cloud run implementations. In both instances, these features allow users to contend with unexpected spikes in demand by allowing for the system to automatically scale up the number of server instances as necessary, thereby reducing the chances of data being lost due to excess traffic. These scaleability features also ensure that your cost in the interim between spikes is reduced to only the number of instances necessary down to the minimum you specify as mentioned previously.
5. Which tags can be migrated to sGTM and current requirements?
As server-side tagging is still a developing product, which has only recently become popular, some of the vendor tags that you currently rely on are unable to be copied and pasted into the sGTM environment if at all. Therefore, you’ll need to evaluate if and how you will configure these to work in a server-side environment. As an example here are some of the more popular tags you can create in GTM and how they work in sGTM.
| Tag | Implementation | Implementation method |
|---|---|---|
| Google Analytics | Works seamlessly | |
| Works with caveats | Pinterest’s server-side tag will automatically fire within server-side GTM, when certain GA4 client side event types are sent from the client side GTM to sGTM. For example when a GA4 tag fires with the event type “purchase” the Pinterest tag with the event type “add_to_cart” will be fired off that tag. | |
| Works with caveats | Facebook recommends implementing the Facebook tags in both the client and server-side containers, wherein the conversion API (CAPI) will deduplicate based on match keys, i.e. user agent, event id, etc. | |
| Works with caveats | Similar to the Facebook conversion tag mentioned above, LinkedIn requests you send both their client side tag called an insight tag, alongside their server-side conversion tag, with the same event ID. When they receive duplicate event ID values, the conversion tag will be deduplicated. | |
| Floodlight & Google Ads | Works with caveats | Similar to a Pinterest tag, Floodlight and Google Ads tags require users to make changes to their client side GA4 tag in order to replicate them in the server-side instance. However, as both tags are still reliant on third party cookies they will then send a request back to the client side before sending data off to the desired destination. As such, in there current state, both tags can only be considered partially running server-side, as the browser is required to make a request to the end point, however the logic behind when and how that request is sent is determined by the server. |
| Small vendors | May not work | Some smaller vendors may not yet support server-to-server communication. Support will be determined at an individual vendor level. If you’re not sure if a specific tag is supported, it’s worth reaching out to the vendor to confirm. |
Louder’s recommendation
Server-side GTM is an ever evolving product despite some challenges associated with the current configuration. is an important tool in combating the data and tracking discrepancies that are due to arise with the deprecation of third party cookies in the third quarter of 2024. Louder recommends having an experienced analytics and tagging specialist team on your side to help you navigate through these updates and ongoing industry changes.
If you need help with server-side GTM, Get in touch to discuss how we can help you or sign up to our newsletter to receive the latest industry updates in your inbox.
About
Alex Byrne
Alex is a Digital Advertising Specialist at Louder. In his spare time, he enjoys reading classic novels, meditating and training at the gym.