In the previous articles of our cookieless series, we already covered the critical points of what’s ahead of us and today’s article is a logical extension of the last one of them about the Facebook Conversion API. Like Facebook, Google is working more and more towards server-side articulation with their release of server-side GTM in Q3 2020 (still in Bêta when writing these lines).
In the meantime, a colleague of mine already highlighted the main advantages of server-side tracking in comparison with the current way of tracking: client-side.
In this article, we wanted to go deeper into highlighting how server-side GTM (or any other tag management system with server-side capabilities) will become even more relevant and important in regards to the evolving context in our industry: user-privacy and cookieless era.
Long story short, the purpose of server-side GTM (or sGTM) is to have an endpoint in a new server environment that is yours and where you have full ownership and control. This endpoint, which serves as a proxy, resides by default in Google Cloud, but you can now have it tied to another provider (AWS, Azure, etc.). The container itself operates as an HTTP API endpoint, to which any browser, device, or other sources that support the HTTP protocol can send requests. The client - which is the main new element compared to client-side GTM - is configured to listen to these incoming HTTP requests and parse the information captured in a unified format that you can then re-use in your various tags (should you decide to optimise it this way).
Here is a great visualisation from https://www.emerce.nl/ of a scenario where the differences between client-side and server-side are clear:
Client-side:
Server-side:
That is where the main benefit of sGTM lies. Indeed, theoretically, you could send only one hit from your client, capturing all the necessary information and making it available for the relevant tags. All the logic would happen in the server and you would drastically reduce the amount of third-party JavaScript that your browser will have to load. To give you a concrete example: for each ecommerce event you want to measure (add to cart, checkout, purchase, etc.) you could send all the information you need through your GA4 tag (from your client side GTM). Your GA4 client inside sGTM will then make the information available for all your other tags such as Facebook, Criteo, Pinterest, etc. Note that today, the pre-configured tags are limited to Google products, but we can expect a lot more to come in the future. Note that, as for the client side GTM, you have the possibility to create your own template or use one of the community.
I mentioned earlier that sGTM allows you to have much more ownership and control, I believe it is essential that I explain it a bit further as it’s a great USP of sGTM. If you decide to go through the Google Cloud Platform, you’ll get full ownership and control over your data. One important element to consider (in regards to GDPR) is that your data will not be processed for advertising purposes by Google. Another important element is that you are now acting as a buffer between the client side information and what is being sent to any third party. You can control exactly what is being sent or not in your Facebook tag, for example, which is a big step forward toward more control on user’s privacy. Here you can find the full details of the privacy measures.
Another important benefit resides in your ability to run your different tags in a first-party context, which will prevent you from losing data due to ad blockers or ITP prevention. If your server is set-up as a subdomain of the incoming request (collect.semetis.com for example), then the response will be considered as first-party. This will also allow you to bypass some of the restrictions set by ITP such as the cookie lifetime value. Instead of having it set to 7 or even 1 day, you will be able to redefine this value yourself and extend it, let say to 3 months.
Still, we believe that it should never be used as a way of dodging the different regulations in place of even the user consent choice. Even though sGTM will allow for more flexibility, it is crucial to respect the user’s choice when it comes to privacy.
In that regard, going server-side will also allow you to add some extra layers of security on top of your operations. There are multiple cases where you could improve your security. One is avoiding spamming via the Measurement Protocol. With a bit of technical skills, you could easily send hits to one or many random GA properties out there. This kind of spam is typically very hard to identify and block. Another security layer that you could have on top concerns PII. With your server-side container, you could make your client parse all the personal information potentially set as a parameter in your URL for example. From there, you can anonymise the data, hash it, or remove it from the source directly and make sure it’s not sent to any 3rd party vendor.
Finally, with the right APIs and services in place you could maximise the usage and privacy of your client-side information. You could reduce your current dataLayer to IDs only: product ID, user ID, event ID, etc. This should increase your data quality (no more human mistakes in the dataLayer), your development speed (sticking to IDs should reduce the development work), and your privacy (you’ll be the only one to have the key to decipher those IDs).
Server-side GTM is a very powerful tool for any marketer out there. We would like to insist on the fact that it should be used with respect towards the user's privacy and consent. Indeed, as any powerful tool, it could be used for the wrong reasons, such as simply bypassing ITP constraints.
Given the current context and the enormous changes that our industry will go through in the next months or years, we believe that sGTM will become a central piece of your digital marketing operations.