Is it possible to host Google Tag Manager's script locally?

13
votes

Is it possible to host the scripts generated by Google Analytics and especially Tag Manager on the executing server, rather than fetching them client side, through Google's script block?

The goal is to avoid any dependencies on external scripts.

I understand it is not Google's recommendation to host neither analytics, nor tag manager locally, but is it possible to do so?

As I understand, tag manager works, by embedding a local script like so:

<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','YOUR-GTM-CODE');</script>
<!-- End Google Tag Manager -->

When this executes client side, it fetches a newly generated script (https://www.googletagmanager.com/gtm.js?id=YOUR-CODE), containing any new tags or triggers your editors have added to the container since last publish.

enter image description here

Apart from losing new tag manager features, and newly generated tags, will this work?

1
javascriptgoogle-analyticsgoogle-tag-manager
Yes, this solution will work. But It will limit your ability to use all GTM features if you won't renew the script. – mrbubu
I would probably recommend against trying to use your own locally hosted version of this. By staying on a specific static version, you're leaving yourself vulnerable to any possible security vulnerabilities associated with that version of gtm.js. If you don't trust Google to serve safe JavaScript, you might want to consider using a different analytics provider. – mootrichard

1 Answers

4
votes

Nobody except the developers of these tags can answer this question with 100% guarantee. I’ll just outline the pitfalls you might face besides missing versions updates.

  1. The script versions returned may depend on your browser. Even on your browser version. Or whatever else. This is a very efficient trick to minimize code served for a particular environment - i.e. you don’t need to return any polyfills for modern browsers. Or serve lighter mobile-optimized tags for slow mobile devices. Given the volume of traffic Google needs to serve it’s likely such technics might be used. To fully eliminate this you’ll need to test everything in all the browsers your webapp is going to support.
  2. Your script may stop working any time without prior notice. Or stop working in some environments. From my experience when a new version is rolled out backward compatibility is provided for a while. After the script owners ensure the amount of traffic using outdated versions is negligible it’s dropped. Yes it may take a long time, but still - you’re likely be there sooner or later, unlikely will anybody in your team track Google's announcements & releases on such things.

The goal is to avoid any dependencies on external scripts

A few more notes to consider:

  • These scripts are to be loaded in async mode => no page rendering blocking
  • These scripts are likely to be already in your browser’s cache as they’re almost on any site on the Internet
  • Google's CDN has dozens of edge servers and even if the script isn’t in your cache it’s likely to be loaded very quickly

Finally, if this is really necessary do your best to make sure it would work in all possible environments