• DocumentationLogin
    Back to Blog

    💡GTM server-side explained

    Published by Michał on
    GTM server-side explained

    While GTM server-side cotainers are not a new concept their implementation on top of classic web-based setups can be a relatively complex subject. With the overall web trackig and privacy landscape being already overly convoluted we wanted to simplify the thigs and show you in details how you can benefit from latest technology achievements in the space. Each ways of applying GTM server-side comes with different amout of work needed and brings unique set of possible benefits.

    At the end of the day we want to help you make a decision if the investment in GTM server-side would have positive ROI for you or your customers.

    TL;DR

    GTM server-side can be implemented in few different ways having different impact on tracking performance. It can be used to serve GTM runtime, proxy all exteral communication or handle server-to-server traffic. When all capabilities are leveraged it can significantly impact results of business-critial operations such as analytics, advertising and content optimisation.

    You can get started with complete setup for WooCommerce shop using our dedicated:
    Advanced Server-Side addon.

    1. No server-side container

    First, to get a good understanding what server-side GTM container changes, let's start with traditional tracking setup using only web container:

    In this case all tags are loaded into user's browser from public GTM domain and then they interact with target tools such as Google Analytics. By interact I mean making external HTTP calls and setting 1st or even 3rd party cookies (cookies that are set from different domain that your website).

    In this scenario tagging can be easily blocked at different stages, making external HTTP calls, using specific JS SDKs or saving cookies.

    To illustrate that let's test it in Safari private mode which by default prevents well-known trackers:

    Boom, so our whole tracking setup was cut-off at the very first entry point, if gtm.js cannot be loaded no GTM tags will run.

    2. Serve gtm.js from the server container

    Probably the easiest thing that can be done when having GTM server container is the serve web GTM container from custom domain. This may help ensuring GTM web conatiner and related tags are loaded despite ad-blocks and privacy features of the browser but it won't by-pass all protections. Also, in this scenario all interactions with destination tools are still happening against public 3rd party APIs.

    Implementation

    The implementation is very simple and actually requires just two steps:

    1. Create Web Container Client in Server container to point to web container

    2. Changing URL in GTM snippet

    In original GTM snippet "www.googletagmanager.com" domain needs to be replaced with custom domain of the GTM server container

    Let's retry this again with our Safari test:

    Boom, it worked now, we can see gtm.js was loaded correctly from the custom subdomain. I would love to show you empty console without the "Blocked connection to known tracker" error, but I can't... because now the browser will blocked most of my tags from GTM:

    While implementation of this setup is very simple, the benefits and impact on tracking performance is limited.

    3. Server-side tagging

    Now we enter much more complex territory but at the same time possible benefits are more significant. "No pain no gain" sounds very applicable here ;)

    In this scenario we forward all events to server container and call the 3rd party APIs from the server container instead of the browser. It means that for both tags loading (loading gtm.js) and interactions with destination tools now the user's browser only talks to our server container (that's running on our domain). It also allows to have fine-grain control on what tracking cookies are set.

    Let's have a look at updated diagram:

     

    It have one more benefit - we need to send each event to server container once no matter how many tools we integrate with. When tracking in classic way just in the browser each connected service will mean spearate HTTP calls to send events data and load JS sdk:

    When having the setup with server container:

    If for instance we would deploy GA4, Google Ads, Facebook Pixel and TikTok it will mean making one HTTP request instead of at least 4 (this is rather simplified comparison, actually it will be even better since loading each service SDK will cause loading additional assets).

    It means less HTTP calls and JS happening in the browser. Also it allows to transform and modify data before it is sent to the 3rd party APIs. Loading external SDK in the browser does not give that level of control.

    Implementation

    The server-side tagging can be implemented using Google Tags in the web container - the tag needs to be pointed at the server container URL instead of public Google API and this would be relatively simple change requiring one extra configuration parameter on the tag:

    Alternatively a custom templates and tags can be used. Althought, I'm sure for a setup focused on Google products using the Google Tags will be recommended and preferred way I would personally opt-in for a more "agnostic" approach with generic tag responsible for sending all relevant events to server GTM container.

    Regardless of which solution would be used in web container, this traffic needs to be received and processed in the GTM server container.

    This is significantly more complex implementation and we will skip detail this time.

    As a result the web container should include:

    • "forwarding" tag
    • all triggers and variables that needs to be forwarded to server container
    • optionally consent tag
    • optionally any tags that cannot be handled in the server container (if 3rd party API does not support server-to-server communication)

    Then the server container will contain:

    • client to accept traffic from web container
    • triggers and variables to structure incoming data
    • all tags to talk to 3rd party services

     

    As you can see implementation of this step is significantly more complex and we couldn't cover all details here. That said, once the whole thing is correctly configured it should bring significant improvement to tracking performance and overall control of data that is being sent to the 3rd party.

    But these are still not all available options. Actually, there is one more step that brings tracking to another level and in my opinion it is not the most complex one.

    4. Server-side tracking

    In addition to server-side tagging which means creating tags in the server container we can also do server-side tracking which means tracking certain events not from the user's browser but from the website server.

    Here comes an updated diagram:

    As you can see we have one more "arrow" in the picture. From the Website Server to Server GTM, no browser involved at this stage. It may not be applicable for all possible events - "scroll" events or interactions on cached pages that are not hitting server are not suitable for that. On the other hand those events that are great candidates for server-side tracking such as "add_to_cart", "remove_from_cart", "purchase", "refund" can benefit a lot from this solution.

    First of all, some like "refund" actually are pretty hard to track without server-side tracking, since the actual refund operation is something that happends in the backoffice of the eCommerce shop.

    For "purchase" you can start be more precise of the exact moment the transaction is tracked, it not always may be the time when user visits order confirmation page - which is classic place of tracking purchase events. And what if the user never lands on that page? Or what if the actual transaction will be cancelled due to payments issue?

    This all can be easily solved by correct implementation of the sever-side tracking. Events can now be tracked in exactly correct moments to ensure it always hits the GTM server container.

    Implementation

    Most of the work is on the tracking side, you need a tool that can plug into your desired platform, gather required data-point and send them to server container in correct format.

    Similarily as in the server-side tagging you can use native Google Analytics format for server-side communication that is called Measurement Protocol or use custom, generic client template. Which option to choose will depend on what your tracking tool supports.

    Other things to take into consideration are:

    • events de-duplication - for most part your web- and server-tracking will overlap one way or the other. It is key part to ensure events are either sent just once or are sent with parameters that will allow destination tools to de-duplicate it. It means having reliable "event_id" for events that can be tracked from both browser and server or ensuring events are tracked just once
    • consent mangement - when deploying this setup you need to decide how and where user consent will be honoured - whether this will happen in web or server container - our recommendation is to do it server side
    • extra properties and their handling - server-side tracking APIs typically allows sending more detailed user information but it needs to be correctly formatted to ensure user privacy (one-way hashing is a common solution)
    • events retries - although your GTM server container may be a High Availability deployment you may want the tracking solution to be retry pending events if they cannot be delivered due to temporary networking issues or downtime of GTM server container
    • background queueing - in order to benefit from the server-to-server communication the most it is optimal to consider sending the tracking events in a background process no to interrupt the live transactions of your customers. Even if tracking operation would fail it should not cause errors for end users of the website

     

    Summary  

    Obviously we could dive deeper into each specific section and cover more of things related to cookies storage and privacy concerns. That said we covered major ways of how GTM server container can be implemented in a website in order to significantly improve tracking performance and as a consequence, results of operations in connected tools. Having reliable data is key for correct analysis of users' behavior, optimising paid campaigns or improving website conent using smart recommendations or personalisations.

    If you would like to short-cut the time to get live with the complete GTM server-side setup and you are already on one of supported platforms visit our dedicated solution page that extends our tracking plugin to give you all of the above out-of-the-box with complete GTM presets and point-and-click interfaces.

    Ultimate Tracking Setup for Woo

    Having questions or comments, we are happy to chat: [email protected]

     

     

     

    Back to Blog