Fixing Server-Side GTM Loader deployed on Cloud Run

Jan Javurek
Etnetera Activate
Published in
3 min readJan 15, 2023

As was the case for the Google Tag Manager, the server-side Google Tag Manager (SGTM) gives the same possibility to use custom templates created by the community. One of these is the GTM Loader created by Simo Ahava that allows you to tweak the way the client-side Google Tag Manager library is fetched by the browser. However, some users might experience issues with this template if their SGTM is deployed on Cloud Run.

By implementing server-side Google Tag Manager you can tackle many of the issues caused by ad-blockers and other default browser tracking prevention mechanisms that break your tracking setup. Nonetheless, the user’s consent to tracking must be respected and you should not try to bypass it in any way. The most crucial way to protect your tracking setup is creating your own end-point running on a first-party domain where the data are routed from the browser. However, this end-point can be also used for fetching the client-side GTM library among other tools such as Google Analytics. SGTM allows you to replace the default domain used by GTM library — googletagmanager.com/gtm.js?id=GTM-XXXXXXX with your own custom domain so it can look something like this sgtm.activate.cz/gtm.js?id=GTM-XXXXXXX.

This adjustment already brings increased protection against ad-blockers. However the gtm.js?id=GTM-XXXXXXX part of the url can still give you some trouble as it is a generally recognized format used by GTM. This means it still can be flagged by an ad-blocker. Luckily we can take this even further and change the library url completely — the path and the query parameters included. For this we can use the GTM Loader custom template and follow his step-by-step guide here. The setup is not complicated and the steps in the guide are easy to follow.

GTM Loader template configuration

If you have server-side GTM deployed on App Engin everything should work smoothly. However, if your setup is deployed on Cloud Run you are very likely to run into the issue where the 502 status code is returned back to the browser instead of the actual GTM library. After closer examination the response error message looks like this:

Response error message

This problem is caused by the Cloud Run service not returning the content-encoding header in the response which App Engine does by default. This can be easily fixed by going to the custom template detail in Templates — GTM Loader — Code and adding the following line of code to the sendResponse function right above the returnResponse() part:

setResponseHeader(‘content-encoding’, ‘gzip’);

The whole function code should then look like this:

const sendResponse = (response, headers, statusCode) =>{
setResponseStatus(statusCode);
setResponseBody(response);
for(const key in headers){
// Do not set the "expires" and "date" headers
if (['expires', 'date'].indexOf(key)===-1) setResponseHeader(key, headers[key]);
}
setResponseHeader('content-encoding','gzip');
returnResponse();
};

This way the browser is given information about the required decoding that needs to take place in order to acquire the original response message. In our case the Google Tag Manager library code.

--

--

Jan Javurek
Etnetera Activate
0 Followers
Editor for

Digital analyst working with Snowplow, Adobe and Google stacks.