Google Tag Manager Server Side Tagging

Introduction

This article describes Google Tag Manager's evolution phases, where it started, and why we need it.

Agenda

1. Why do we need it 
2. Before GTM
3. GTM Client Side
4. GTM Server Side
5. GTM Server Side pros and cons

Why do we need it

We are living in the digital world, where data is playing a vital role, Based on the data, we can understand the end-user expectation and plan around some level of percentage. Recently I saw an article, where the internet recommended to the end user to buy some item, actually s/he ignored it, literally after some time, the end user recognised, that the recommended products are mandatory for her. So what I meant to say here its everything is data. Also, I heard somewhere nowadays talks are going on where "data is considered as more than gold".

Before GTM

In late earlier days, we can collect user-probing data, however, the Analytics Tag suppose to be available on HTML pages. If we are working on the dynamic page, this supposes to be available on a common or layout page. Usually, we generate Google Analytics Id and tag it into our local website, which eventually sends all data so we can understand what is going on and who is looking on our portal. 

This tech stack is nice, however, we are investing a lot in the engineering team and the marketing team needs to prioritize which tags are required as of now. so always we have a lot of backlogs to do repeat work.

With the help of this method, we can collect data in analytics, but we don't have much control, such as PII complaints and if the end-user added an extension block then we won't get any data in the analytics tool, however, the advantages over here is over early days, we can see more data's what user actually does, that's one of the major good points on earlier technology.

GTM Client Side

The GTM client side gave good options to marketing professionals, where they can come out of developer dependency. The marketing team can able to add their own tags and publish them into the GTM portal(regular container). Basically, GTM CS will create a website container which resides on the browser side, so you have a good amount of centralised control to trigger tags. However again we are directly connecting Google Analytics, FB ads, Google Ads from the browser and which takes a lot of workloads.

It gives flexibility in some amount of areas, however still lags on page load, reducing SEO ranking if you are doing a lot of tag manipulation.

Please refer to the architecture flow about GTM Client Side. In this snippet, we are connecting only one client (GA), we can connect additional clients however the drawback here is we are connecting or probing from the browser side.

GTM Server Side

The GTM SS is an advanced version of GTM CS. In simple words, we can say it is an extension of the Client Side version. In the server-side version, we suppose to create a couple of containers, one is called a regular or browser container which resides in the browser section and connects with Analytics ( which reads browser, pixel, size and etc). another container is called a service side container, this is an additional stack introduced in the GTM SS option. 

We are creating here a single point of contact, so the browser is unable to connect directly to a third party, instead, it will route it to our own GTM SS. We can connect GTM SS via three options GTM, Custom code and gtag.js. This works with Measurement protocol, which means GTM act as API and accepts http/s request. The server-side containers are hosted in a google cloud environment, so obviously we have to pay a few quid on monthly basis(~£120).

In GTM SS, we can have a client (listener) which accepts all requests from the browser, based on tags configuration we can trigger to the appropriate client. So it means we have good control over here, what we need to send and what not.

If you see the below snippet, if you look a bit, the analytics URL differs when compared to the previous version, instead of google-analytics.com/collect it is customdomain/collect. By this stack, even though the end user blocked google ads, we can get the data, because we are using a custom URL instead of a google analytics URL. 

In GTM SS, we have advantages and a few disadvantages, eventually which overcome in the upcoming days :)

The task to follow while working on GTM Server Side,

• On top of the client-side GTM regular container ( website container)
• Create Server Side GTM container + cloud project ( where you host your container). The Minimum supposes to have 3 servers in the container and max suppose to be 6 servers.
• Create tags, variables, triggers and client ( This is a listener/ interface which accepts requests from the browser to divert or manipulate the request data.
• Map the transport URL as your custom subdomain (recommended), For testing purposes, we can use generated URL for our initial testing.
• Finally Testing :) 

GTM Server Side pros and cons

We can see more advantages here which overcome disadvantages area, however, we need to eye on it what is required for our environment.

Pros

• Page Speed, moving all browser load to the server-side container.
• A good amount of control, where you can mask sensitive data using a tag before sending it to clients.
• Reduce the impact of extension blockers
• Extension of cookie expiration

Cons

• Paid Solution because we are hosting a server container in the cloud
• A bit complex, In a few areas engineering effort, is required.
• Still in the evolution phase.