In 2020 Google released the Server-Side Container (SSC) for Google Tag Manager. While it requires significantly more technical input to implement than the Web containers we are used to, it does have some large benefits. In this post, we will look at how the SSC works.
How The Server-Side Container works
The SSC acts as a midpoint between data sent from a website and the tool or service the data is being sent to. When you use the GTM Web container any tags triggered send (or receive) data directly to a service’s (Google Analytics, Facebook, Google Ads) API endpoint.
The server-side container (SSC) becomes an alternative endpoint. Data is sent from the website and is received by the Server-Side container which can then modify the data before sending it on to the service. The two illustrations below help to visualize this.
GTM Web Container
GTM Server-Side Container
Most of the functions of the SSC are fairly similar to the Web container in that you set tags, triggers, and variables to temporarily store and then send data to your various tools. Community and Google-built Templates for tags and variables are also available. These features, however, are much simplified because of an additional feature of the SSC. This feature is the Client and it does the heavy lifting in the container.
The Client
The Client is the aspect of the SSC that receives and manipulates the data coming from the website. It then makes the data available for the tag to send to the intended tool.
Currently, there are a handful of built-in clients. These are for:
- Universal Analytics
- Google Analytics 4
- GTM Web Container
- Measurement Protocol for UA (Used for offline systems like ticket kiosks)
- Measurement Protocol for GA4 (Used for offline systems like ticket kiosks)
New clients can be built but these need to be coded to interpret the data coming in via the requests from the website. While this does not need to be done for Universal Analytics as it is built-in we can use a UA request as an example:
https://www.google-analytics.com/collect?v=1&_v=j96&aip=1&a=1234567890&t=pageview&_s=1&dl=https%3A%2F%2Fwww.advance-metrics.com%2Fen%2F&ul=en-gb&de=UTF-8&dt=Home%20%7C%20Amazee%20Metrics&sd=30-bit&sr=1680×1050&vp=826×943&je=0&_u=SCCAgEAjQ~&jid=1234567890&gjid=1234567890&cid=1234567890. 1234567890&tid=UA-11111111-1&_gid=1234567890.1234567890>m=0wg0v00XGVWK&cd7=0&z=1605487952
Each of the URL’s parameters – v, _v, tid, aip, a, t, etc… – would need to be accounted for in the code and processed as desired to send on to Universal Analytics. This can make setting these up time-consuming. This coding can be made easier (particularly for Google tools) with several SSC predefined functions.
However, there are two handy ways around this. Firstly, there are a number of services that provide tags for SSC that make use of the built-in Clients and get their data from there. Second, there is a Client template gallery in the SSC. This, however, is still being worked on and community-built templates are not available yet.
Getting Data into The SSC
Data is sent to the SSC in the same way that data is normally sent using code on the site or with a tag manager. As we mostly deal with Google Tag Manager implementations on our blog this post will only focus on this method. For Google Analytics, your existing web container setup can be used with your server-side tagging. In your GA Settings variable (and in the overriding settings of GA tags) there is a setting called Transport URL. If you put the URL endpoint (this can be a subdomain of your own site) of the SSC into this text box then the tag will send its data to the SSC instead of Google Analytics.
For other tag types – like the Facebook Pixel – you could add them as a Custom HTML and just change the endpoint in the code snippet from the original to the SSC’s endpoint.
