Also worth noting--depending on your setup, GTM essentially allows arbitrary execution of JS for anyone with access to edit and publish containers.

I'm a more technically inclined marketer, but I make damn sure to check with an engineer before trying anything fancy with JS, and I make sure to test with QA.

But having stuff in GTM more or less means you have separate workflows for code outside of your existing repo. Yes you can dump a JSON export of the container and commit that, but it definitely can cause some headaches when engineers not super familiar with GTM or how it is setup have to touch things that impact it (or vice versa).

This is a really important point. It can be really helpful to decouple analytics / tracking from the application -- especially in large companies. However you need to fully understand the security implications (don't trust vendor code!), have someone that is technically inclined using it, make it easy for the product teams to debug around it, take ownership of QA, etc.

Can you elaborate on this? I recently had my marketing team ask me to replace GA with Google Tag Manager, and I'm not all that familiar with either, as running the web site is just a minor thing I do on the side of my product work... but this sounds like something I should know more about.

In the simplest terms, Google Tag Manager (GTM) is a script you load on your site that then loads additional (arbitrary) code based on conditions (which are executed client side). In the case of something like GA, let's say you want to track a new website activity or maybe want to pass data to a new custom dimension. Without GTM, you would update your GA javascript file. With GTM, you would make the update within their interface and that new code would get injected into your site. This enables (for right or wrong) the analytics team to manage what / how data gets collected in GA.

Within GTM you have the ability to inject html, javascript, css OR in many cases they have a wizard where someone less technical can put in some info and the code is generated. You can also use conditions to determine which code should load. For example, if page URL matches "orderConfirm" then execute this. Moreover, it gives you the option of when the code should run (immediate, DOM ready, onLoad).

Aside from GA, most companies have a shit load of 3rd party scripts that run on their pages, so GTM provides a central place to manage everything.

One problem is that anyone with editor access to GTM can inject just about anything (unless you block custom scripts within GTM which has other implications) and those deployments are real-time and done directly within the GTM web interface. I'm a developer on the marketing team, so I'm a fan, but it's risky in the wrong hands.

Thanks, that makes sense, and while I do like to trust my team, that sounds like something I want to keep an eye on. Appreciate the info...

On top of what peter_mcrae said, CSP[1] is a way to sandbox the page in modern browsers. But because GTM basically requires "root" access on the page it makes that sandboxing model useless.

[1]: https://en.wikipedia.org/wiki/Content_Security_Policy