How to configure permissions and security in Google Tag Manager - Google Tag Manager Tutorial

- [Illustrator] Now, before we dive in, and start creating and deploying containers to our site. It's worth taking a moment to talk about permissions and securities. This is an extremely important topic. In the early days of tag management, some of the things that had marketers most excited about it, being able to bypass their IT team, was exactly what had the IT team, and the security team in full freak out mode, and probably with good reason. As we discussed in the previous chapter, the GTM container is a way to automatically inject scripts into your page without having to actually embed those scripts into your HTML. That's great for convenience, but it also means that anyone who has access permissions, can inject whatever scripts they want to into your site. That's why it's so critical to be mindful of who we give that power to. Fortunately, GTM has some features built in, that will help make sure only authorized folks are able to publish code to your site. We're here in the overview. And if I click into a container here, and then I go up into the admin panel, we have two options here for user management. One of those is going to be in the account level, and one of those is going to be over here on the container level. Things that we do at the account level can cascade down to the containers that live in that account. So, let's start here at the account level. And here we see the users who have access to this GTM account. Now reminder, these have to be Google accounts, but they don't have to be Gmail accounts per se. In fact, we suggest using corporate verified emails whenever possible, over personal Gmail accounts for security reasons. We could invite a new user by clicking here on this plus sign. But for now let's look at an existing user that's already in the account by clicking on the name. We see the account permissions here on the top, and then the individual permissions for each container on the bottom. As a rule of thumb, it's always a safe idea to give a user the lowest permissions needed to conduct their work. This protects your website from any accidental deployments. And so, as we said, here, we have two of these available for the account. And we have the administrator, and the user. We also have an indication of whether this is something that was directly assigned or inherited. We're going to give most people the user level here. Next, we can select container permissions for each of these different containers. So we'll go here into the hansel and petal, and we see there's four different levels of check boxes here. If we uncheck all of these boxes, then this is no access. Nothing is checked and this user will not see this container at all in the interface. If you add a user to the account, but you don't give them access to any of these containers, it might be a little bit confusing. They won't be able to see this container. So make sure you use this permission level, only when they're multiple containers within the account. And you only intend to show some of those, but not all to the user. Otherwise read is probably the basic level that we're going to give most people. This is going to give the user visibility to the container, but doesn't allow for any changes to be made. The next level up here edit, allows a user to collaborate within the container and make updates to the tags, triggers and variables. This type of user can not create new versions, or publish the container out to production. We'll talk more about what that means later. This level is helpful for individuals you want to be able to make tweaks to the configuration, but not be ultimately responsible for the finalization of that deployment. Approve is the next step above edit. Now this user not only has the ability to update the tags, triggers and variables, but also create versions and workspaces for users to modify. And again, we'll see a bit about this later. This role is generally for someone who has expertise in GTM, but again not the final approval for those to be launched into production. That is the last one up here. The most important here is publish. This is going to allow for user to push any container out into production to go live essentially. This is a critically important role, because it assumes that if a container is being published into production, that it's gone through the due process in terms of quality assurance, all your security checks, all the things that you internally need to do. And this is how we control people who need to be able to edit and be creating, versus those who actually have the ability to hit the go live button. This access should be limited to a few key individuals. Now there's one more security setting that's a bit hidden, but I want to make sure you're aware of it, since I think it's critically important. If we back out here, I'm not going to save those changes, and we go all the way back to the account settings. And going to here this last one is required to step log and verification. This will force users to identify themselves with an additional step. Maybe a text message to their phone, for example. Before they can utilize the features that could be abused, such as custom HTML, or JavaScript injections. Now you can also do this, the Google account level too, but this is an extra step here for publishing in GTM. User permissions are important piece to consider. We embark on a GTM implementation. So it's important to make sure we get these set up correctly.