Server-Side GTM - Early Adopter Tax
TL;DR - Update your SGTM docker-images reguarly. Or stand the chance of losing data! Cloud Run does not automatically do this for you!
Background
I've been fortunate enough to have installed a few production-grade server-side setups since the early days of SGTM. Well before Team Simmer pulled up a great course for it, and Mark Edmondson had a fancy article about how to Cloud Run it. And now the time has come for me to pay the early adopter tax!
Most of us in the analytics & marketing space don't nessecerily have the full background of cloud-infrastructure lifecycle managment. As long as it runs, data is collected, and the graphs are up and to the right, all seems fine!
And with SGTM you get all the new features rolled out automagically inside the admin-interface! So why bother touching something that is running?
Are there problems?
If you installed SGTM some time before June 2022 chances are that you are running an old SGTM container-image - an image that has a few flaws!
5kB collect limit
SGTM-installations before version 1.0.0 (13.june 2022) can't handle requests over 5kB. Unless you update it.
One of my clients had this strange data quality issue for GA4 over SGTM. A lot of random events seems to never be sent to GA4. And looking closer at the network-requests it seem like for some unknown reason promo_impression-event seems to often, but not always return a HTTP 400 error from the SGTM-server.
Reproducing the exectly same request, on my test-SGTM account, worked perfectly... Strange!
Turns out that my production SGTM-server, was not able to handle requests over 5kB. And for this client the combination of a lot of cookies on the request, and a large promo_impression hit with a lot of Items, pushed it over that limit.
As soon as I stripped away a few objects from the Items-array, or deleted a few of the cookies on the request, forcing the request under 5kB - SGTM was fine handling it!
But what about my test-sgtm, that could easily handle payloads over 5kB!?
My test-GTM was deployed way after my clients production-servers which where running an older 2020-version of the image. My test-account I redeployed fresh, pulling from the latest-tag. As is the default behaviour in all the offical and non-official guides to run SGTM with Docker.
Production-SGTM running 2020-image: Crash
Test-SGTM running v1.1.0 (2022-image): Works
The older image, based on a deprecated nodejs-server and with the package mix under the hood, will not handle >5kB requests. The newer (v1.0.0 and up) will!
Redeploying and pulling a new image in my production-SGTM so it runs 1.1.0 fixes the problem instantly!
Preformance - less is more!
As we see from the Container Registry the virutal image size has reduced quite from pre 1.0.0 and forwards. From around 240 MB and all the way down to 88.5MB in version 2.1.0.
Even though this mainly impacts the initial docker pull process - there are far less dependencies and npm-packages under the hood for the newer version. It also uses a much slimmer base-image, making it much more efficient.
In a large scale SGTM-cluster we saw CPU-usage drop 20% by upgrading to the newest version. On the same load.
Vulnerabilities
As we seen in the comparison between early versions of the image of and the newest, many of the packages included in the 720 package deep dependencie-three now has known vulnerabilities. So keeping the image up to date is also very good practise.
Cloud Run - How to check your version
Most installations outside of the AppEngine default are these days run via Google Cloud Run. As is most of my installations as well.
SGTM offer no version-endpoints to quickly check what version is deployed. (But that is something I've added as a feature-request).
So to check the version you have to go into the Google Cloud Console, and manually check your deployed version.
Navigate to your Cloud Run deployment.
Click on the Revision-tab.
Under Containers config in the right pane, hoover the Image URL.
For this Image URL you will see that is has a sha256-hash, representing the version from the Container Registry. Each hash pointing to a version uploaded by the Google SGTM team.
Cloud Run - Redeploy to newest version
So chances are that you are not running the newest version 2.1.0! Since that was released 17.March 2023. How do you upgrade?
In Cloud Run this is actually very simple - and can be done with zero downtime.
Still under the Revision Tab, click on "Edit & Deploy New Revision". Google will keep all your configs from the previous deployment, so you can scroll down to the bottom and click Deploy. Cloud Run will manage to transfer your traffic from the old version to the new for you!
As long as you have the Container image URL pointed to the stable-tag (:stable) you will pull the newest version that has this tag in the Container Registry.
How about a changelog?
As you have seen in the screenshots, the image jumped from version 1.0.0 and is now at version 2.1.0? So we had a major-version jump!
But what has changed? Are there some new hidden features, or some performance-boosts?
Well - I tried to ask the same question on the SGTM Partner Forum. And I got this link to an upcoming Server-side tagging release notes page. But at the time of posting this blog it empty. But the devs asured me that the v1 to v2 was just about bumping to NodeJS 16.
