Every tag loaded by the browser (aka client side) adds weight to your website, which leads to increased load times and negative user experience.
Enter the concept of server-side tagging, where tags are loaded from the server instead of from the client (browser). This isn’t a brand new concept as platforms like Tealium and Segment have offered this for a while, but Google recently got into the game with it’s release of Server-Side Tagging containers in Google Tag Manager (GTM). As with many Google products, this introduction means server-side tagging just became a lot more accessible due to being cheaper and delivered within a tool that many businesses are already using.
At a high level, the business value of server-side tagging is:
- Optimized performance
- Better security
- Higher quality data with more control
However, just because it has high-level benefits doesn’t mean it will provide value for you. Your business goals should be at the forefront of that decision. For instance, right off the bat it requires a technical implementation using Google Cloud Platform. Additionally, it’s generally free to test but a basic production environment will cost about $120/month to run the recommended three servers for redundancy and uptime.
I’m going to focus on laying out the general business case for server-side tagging. If you’re thinking about upgrading to server-side tagging consider your organization’s Digital Maturity, your competition/industry, your business challenges and the business goals you’d like to accomplish.
Page and website performance is one of the most obvious reasons to go server-side with your tagging. Improving page load speed is often a business goal or a recommendation made by a consultant or agency, but optimizing page load can be challenging. A large part of that challenge is due to third-party code execution time – or the time it takes for browsers to load tags. By moving tags server-side that load is processed on the server, instead of the browser, dramatically reducing the work a browser typically has to do to load a page.
While we all know having a faster page is a good thing, it can be difficult to know just how much this could help a business. Luckily for us, a Q4 2019 study conducted by Deloitte showed just how much speed can matter to your bottom line:
“With a 0.1s improvement in site speed, we observed that retail consumers spent almost 10% more”
With recent legislation (GDPR & CCPA) and browsers taking security into their own hands by severely limiting the power of third-party cookies with Intelligent Tracking Prevention (Apple/Safari) and Enhanced Tracking Prevention (Firefox), it should come as no surprise that security of data is a top priority for both businesses and consumers alike.
In fact, in a July 2020 Forrester study, titled The Future of Analytics, 750 decision makers responsible for analytics, media, or marketing business insights ranked “User privacy and data management controls” as the second highest investment area in the next 12 months, behind “Cloud or data warehouse solutions for more advanced data modeling and analysis.”
In a basic sense, server-side tagging adds an additional layer (the server) between a website and the data collection tool (Google Analytics, Facebook, etc.). This may seem counterintuitive – why would we want to add an additional layer? Third-party code can range from benign to outright malicious, and when this code is loaded in the browser it exposes user data that can be used for things like device fingerprinting and tracking users across websites. This is exactly why Safari and FireFox introduced their safety measures and Chrome plans to get rid of third party cookies by 2022.
In server-side tagging we send data to our server then to the data collection tool(s). This means we control exactly the data they are able to access and use. Put simply, direct visitor data is out of reach.
Before we delve into the last major selling point of server-side tagging I need to call out that with great power comes great responsibility.
User privacy should be at the forefront of collecting any and all data. This means that user privacy needs to be integrated at the basis of measurement, and cannot be an afterthought.
With that said, server-side tagging enables measurement that is higher quality and allows for more control. Many popular ad-blockers and privacy-focused browser extensions block outgoing requests based on domain lists. This is primarily to prevent requests to ad servers or other tracking sources but some block requests to the Google Analytics servers, too, which renders traffic on those browsers invisible to GA. With server-side tagging, since we’d be sending data to, say, analytics.seerinteractive.com instead of analytics-google.com, we would receive a more accurate count of that user traffic. It’s worth noting that this benefit can be abused to circumvent user privacy protections, and it’s important to take advantage of this ethically in a way that doesn’t violate user trust.
Additionally, there are significant implications in switching third-party cookies like those from Google and Facebook over to first-party cookies using server-side tagging. What this means in practical usage is that the seven-day (or often 24-hour) expiration of third-party cookies imposed by Apple/Safari and FireFox that are currently silently wreaking havoc on remarketing audiences aren’t a worry because our cookies are now set in the first-party context. All of this means that our remarketing audiences can go back to their previous often 90-day expiration and Google Analytics will continue to recognize the same user for two years instead of both platforms forgetting who this user was after a week.
Finally, server-side tagging is relatively future-proof. This is not only for all the reasons above about performance, security, and the ability to more accurately track users, but also because you can securely enrich and more effectively deliver data to various locations. You can add relevant information after it gets to the server and before it’s sent to an external party. This includes attributes like business context, lead quality score, product information or CRM data. Previously we wouldn’t want this sort of information to be exposed to the browser. Furthermore, you can send your data in different directions from a single request, like your own data warehouse.
This is a new and exciting option for deploying Google Tag Manager. As outlined above, it brings with it a host of benefits but, of course, there are some drawbacks.
The largest of which is that it comes with a monthly cost for maintaining the servers. As we mentioned earlier, this starts at about $120/month and scales up based on traffic. To add to this, the only current deployment method is through a specialized Google Cloud server configuration, which may or may not be your cloud platform of choice (hello AWS and Azure!). With these considerations in mind, some organizations might not derive enough benefit to justify the expense for server side tagging as it stands today.
Additionally, it is important to remember that this is a new product release for Google. They will likely bring many important improvements and updates to it in the coming years but for now. So while it is production ready, and Seer is working on multiple implementations for clients today, it’s still in beta. New features will continue to be added and refined. Lastly, community support is very small and there aren’t good case studies or GTM templates available to follow.
If you’d like to discuss server-side tagging options in more depth, we’d love to hear from you.
Or, you can subscribe to our newsletter where we will certainly be covering this in more detail in the months to come.