So What? Google Tag Manager

Well, hey everyone, happy Thursday. Welcome to February of 2022. Uh, this is So What, the Marketing Analytics and Insights Live Show. I'm Katie, joined by Chris and John. This week, we are talking about Google Tag Manager.

Now, this is one of the topics that I personally enjoy revisiting over and over and over again because I feel like, at least for me, no matter how many times I am in the system or I've taken the you know Google training courses, Google Tag Manager is one of those systems that still eludes me in terms of me feeling like I'm an expert in it. And so, but it's so important to setting up your analytics correctly, especially moving from Google Analytics 3 to Google Google Analytics 4, which is easy for me to say. Today, since uh constantly operating in a state of the cobblers, kids have no shoes and walking around on bloody stumps. I figured I'd take a look at my tag manager account, and we can go through the things that if this was a paying customer, uh, we'd want to do want to see in place stuff that we would look for and things that we might make some changes. Now, obviously, uh, this is to my personal website, I'm also not terribly concerned if we just break a bunch of things, no one no one's gonna miss it.

Um, so we're specifically talking about governance today. Governance is all about making sure you know who's doing what, uh, making sure that you know who did what, and there are some really good features built into Tag Manager, but I think a lot of people probably don't use them. Um, so the first place I want to start is sort of at the account level, especially if you're at a company, if you're giving access to your tag manager account, uh, there's a bunch of things that you should do. So let's go into to admin here, and we see two different things. We have to see accounts and containers.

Account is the the whole of you know whatever's tied to my login. I can have one account with a bunch of containers for different websites. Um, I can't have um a bunch of accounts. I shouldn't have a bunch of accounts, it's it's not a good idea. Um, first thing we always suggest to people look at your account settings uh and your account activity.

So let's go ahead and go into account settings here. Uh make sure that uh you have turned on two-step uh verification. Uh if you don't have two-step verification on, you're doing it wrong. Um, there's there's no way around that because you don't want other people into the in inside your account. The second thing is to look at your account activity.

When you dig in here, you should be looking at well, who's in here and what have they been doing, right? Right. If you see uh activities that seem weird or spurious, that's a clear sign you may need to do a lot more digging, but at the very least, make sure the account activity looks good. And then the big one: account permissions. Who is permitted to see your tag manager account?

All right. So in this case, again, this is my personal website, so it should only be me if there's anybody else in here. I would be a little bit actually a lot concerned because uh just a bunch of things that I would maybe wouldn't want people to have access to to make changes. Remember that tag manager can make physical changes to your website. So you want to be really careful who gets access to stuff.

Generally speaking, if you're gonna give access to somebody to your account, do it at the container level rather than the account level. Because they can just so that they're sandboxed into how much damage they can do. Um, I have a question, Chris. With this, I know a lot of systems have notifications built in. So is this one of those systems where you, as the owner or an admin, can get notified as people are making changes?

Let's say you had trust insights or other agencies in here. Could you set that up? You're jumping ahead. Woohoo! Must be Thursday.

Um, after you've looked at the account level, then the next thing to do is to look at the container level. So the container is that piece of code that goes on your website. And the question here is what things should be on it. You can see I've got it my container set up for the web. You can have containers for iOS apps, for Android apps, things like that.

But for me, I've got this is on a website. And the big one is this one that people have not gone in and changed on their tag manager account. You need to make sure that your consent overview is turned on because that allows you to manage consent. Uh manage um uh what permissions are needed for a tag to fire. So always turn this on unless you have been told by your legal team not to.

If your legal team has told you not to, you probably want to like start updating your LinkedIn profile because they're doing something shady. So you know, before you move on from that, Chris, I guess one of my questions, I think that I never realized until I started going through these systems with you that a legal team should be involved with setting up some of these data collection systems. Like when we're talking about it now, it's like, oh duh, of course. But do you think that it's common knowledge amongst the marketing industry that as you're setting up these data collection systems, there are things that you might want to involve a legal team with? It's not common knowledge, and the worst thing about that is that an unsuspecting marketer may just go ahead and check yes on a bunch of stuff, and now you have signed a legal agreement with Google on behalf of your company.

Um that you have acknowledged the data processing agreement, that you've agreed to Google's data collection practices, that you have agreed to handle customer requests for you know the right to be forgotten and you know, GDPR compliance and stuff like that. So be real careful about what you click agreed on because these agreements are legally binding, uh, and they are binding not on just on you, but on behalf of your company. So if you like, oh, I'm just gonna let my you know 19-year old college student, you know, cousin uh administer my Google account, they may be signing you up for things that you are now legally liable for. I think he's talking to you, John. I've never stumbled through or read any of the agreements, so I'm sure I'm not in any trouble.

Um as with the account level, you want to look in the container level, see if uh what changes being made at the at the container level. Uh to and we generally tell people as a best practice, look look every quarter. Same thing with user management, make sure there's nobody in here that shouldn't be in here. Um the next thing is uh you may want to set up um or have uh like approvals and stuff like that, depending on how you uh want to what rights you give a people. So when you uh, for example, in users, I can set up a user and say, I can allow this user to uh edit, but then they have to.

So if I put in uh trust insights here, I would say trust insights. Yeah, you can edit, but if you make any changes, it's gonna go into my approval queue, and then I have to approve those changes so that you can't make changes to my live environment without uh without letting me know. Uh and then I, as the owner, get to say, yes, this goes in or no, this doesn't go in. Um and now, Katie, to your question. Generally speaking, um, we always suggest people have at the very least notify uh me by an email when a change is made to the live environment.

Now you can do you know notifications for other things and and get more notifications, but at the very least, you definitely want to be to know oh, somebody just pushed a new change to my con to my container. Again, if you work with any kind of agencies or you've got, you know, staff members that you're uh maybe have not trained up as well as you'd like, you you want this turned on. So these are sort of the major account level governance features that tell you who's responsible for what what's been happening and let you know that things have been happening. The other thing. Oh, go ahead, Katie.

Well, I was gonna say, you know, I want to go back to the approval queue piece. So there's two sides to this. One is you as the owner are setting it up so people have to go through you to approve it. But then the other side of that is you as the owner can't be the bottleneck to approve things. And so this was always a point of contention when I worked in software development.

And then um things like content management systems, where someone who's not on the development team who's making changes, and they need they're waiting on the development team to push the changes through, it becomes this, you know, tension point between different teams. And so I would say, yes, the approval queue is an important step, but make sure you have some kind of a process set up so that somebody owns it, number one, is responsible for approving them, and that there's a regular check-in so that vendors and team members and developers and whoever's making changes aren't then chasing you down to say, Hey, I did this, you know, six weeks ago, you still haven't approved it. I've been blocked since then. So just a little bit of a process word of caution of it's a good step, but make sure that you have the process in place to actually make those approvals. Exactly right.

Yeah, because isn't this normally I've seen this as no a cluster, I mean, because you this is good. You've got your one site and your one container, but uh we've seen clients that it's like there's 35 containers and they're you know, on each of seven sites, and it's just like you know, you'd need a whole dedicated person just to know what the hell's going on across the board. You actually raise a really good point. One of the things that people do that's something of a mistake, it's not a mission critical mistake by any means, but it is it's an inconvenience, is that they will set up separate tag manager accounts for each website as opposed to having one account and then multiple containers within that account. So, like if Trust Insights wanted to manage everything, I would have one account and then I have marketing over coffee and Katie Robert.com and Christopher S.

Penn.com, TrustInsights.ai, all those different containers in one account. And the reason for that is that you could then do delegated authority, like if I can have a user in the account and I can restrict their permissions just to a specific container. If I have five accounts, then it's a lot harder to keep track of like who's making changes, right? It's you know who has access and things like that. If I got five different tag manager accounts to check, and I have to check each quarter to see who's been doing what, after a while, things are going to fall through the cracks.

It's better to have it all centralized. It's almost like you're validating the need for business requirements up front to understand what the heck it is you're trying to do. And now, granted, things change, but if you start out with you know those scenarios up, like, okay, we have you know the CSP property, what happens if we decide to add one to it? And so talking through those business scenarios will help you make sure that you're setting things up correctly from the start. And so is it a hierarchy or are they all separate individual things?

Both are fine, but you just have to have a plan for each one. Exactly. And generally speaking, when it comes to analytics, if you have an option for a hierarchy, unless you have a compelling reason not to, the hierarchy is generally the better choice. Again, because it simplifies administration, simplifies, you know, who access control and things like that. So that's that that's a really critical point.

The other thing that again, a lot of folks don't remember, is the version manager. So the version manager in Tag Manager allows you to see what has been happening within this workspace. But here's the important part. I can take a look at previous uh versions of the site. And if I need to, I can roll back, right?

So if I if I break uh a website, if I push out some tags, I'm like, oh huh, the website just stopped working. Instead of futzing around trying to go, oh, I gotta delete this tag and I have to delete this trigger and I, you know, I messed with the valuable site, nope. Just go figure out which version was the previous version I didn't screw up and just set as latest version, push that back out, and boom, it's like uh your mistakes never happened. Um, this is a a critical feature that people forget exists. When you make a mistake, they think, oh, I just gotta go back and undo every single thing I did.

No, no, just go back in time, rewind, um, and and you will save yourself so much headache. All right, go ahead, Katie. I was gonna say, yes, but um, with that, so and I feel like you're gonna get into this, but with these changes that you're making, and this comes with the governance piece of it, especially as agencies and contractors and whoever making changes, there needs to be some kind of a document or some sort of a description of what the change was so that you know what you're rolling back to. And so that, you know, Chris, since it's your individual site, it's not as critical because it's literally just you messing around testing things. But as you get to be bigger and have more people with their hands in it, it needs to be a requirement that I can't push your changes through unless you tell me what was changed.

Exactly. So in your default workspace, one of the things that again, there's there's options in here to do little things like this. One of the things I think that people forget is that you can at least do a little bit of tuning up here. Some say something like contact if you need help, right? Just something that it's kind of like a little welcome message there.

That again, if you have somebody who's new in here, it doesn't hurt to let them know here's where to find things or who to call for help if you screw something up. Um, all those things would be be good things to have. So the next thing we would want to talk about is you have these sort of three layers in tag matchup, tags, triggers, and variables. All three from a governance perspective really should have some kind of intelligent convention. So let's go into to variables.

We're gonna ignore the built-in ones because you can't really make changes to those. I've got a bunch of uh user-defined variables here, and these are really problematic. Some of them are are worse than others. Um this one here, for example, is a custom UTM campaign, uh, which is a a URL custom variable. By looking at this, I don't know what this does.

I don't know why it's here. It was put in three years ago. So you know, if you think about it, like you if I was an agency, I was just coming in, the first thing I go is, hey, what do you use these for? And the person might say, Oh, I don't know, the person who worked on that's been gone for a couple of years, but it's it's a three-year-old thing. So it's like, so what do I what am I gonna do with this?

Now, tag manager does have the ability when you click on it to see what that variable is used for. And you can obviously you know click through that and see what that's used for, then click through that and see what's triggered for, and so on and so forth. But that's a lot of labor for what should have been something like this. Uh custom URL source variable for no script implementation. This now makes it a lot more clear what this thing is supposed to do, right?

Um there's it you don't have to guess anymore. Uh, what is that strange thing here? Uh let's do another one here. So this is this is medium variable. This is the medium.

And so it's really important to have a naming convention that when somebody looks at goes, oh, I know what that does, or at least I I maybe I have an idea who to ask. You could put your initials in there. You could put uh you know, remove this variable after this date or an expiration date, but put in the things that you need to have so that when you come back in three years, like, huh? What is that? Just to be square on that too.

So those are the ones where if the uh container is firing on a page that won't run scripts, you still get your um UTM codes. Is that the idea with those? Mm-hmm. Okay. Yep.

Um, which is uh kind of a nifty trick. Um other ones these like this one here is a little bit more intelligently named. This one is a GA4 variable. It's like, okay, at least I know generally what that is. Um this one here, count ad blocks.

I have no idea what that is. I don't even remember why what it is what exists. So this is a uh a script. Oh, okay. This this script uh is designed to detect ad blockers and then count in Google Analytics how many visitors are using an ad blocker on my site.

I don't remember putting this in. Which can be useful if you're gonna do something with that information. It would be super useful. I don't remember why I I have this. Uh but this is again one of those cases where there's no documentation uh and there's no project plan.

This was just something I probably read about somewhere. Turned it on my site and like eh, I'll get around to it eventually, and I've completely forgot about it. It happens. It happens to the best of us. It really does.

So that's what's in variables. Uh again, from a governance perspective, which is what we're talking about today, uh that documentation's really, really important. And you know, the fact that it's even in something here, like because this is JavaScript. Right? It's a it's just gonna show up.

So I can put in a little thing like in my script and say, okay, uh, in three years, when I look at this again, I'll remember, oh, I know who to ask about this. And you know, if the person in the company's moved on, you can find out who their successor was. But at least there any time that you're working in these tools, there's probably a chance to do some documentation. Okay. Next.

Same with triggers. Again, these triggers, some of these are okay. Some of these maybe not okay. Um and needs who's doing what, why it's there, you know, what it's what it's supposed to do. Like here's one that says fix Facebook source medium.

I don't remember what this is. It says uh trigger configuration on any page view where the page, the refer starts with m.facbook.com. Okay. So I'm guessing that means because we know from Google Analytics, a lot of social media traffic comes in as referral traffic versus actual social traffic. So is that meant to automatically change the data from referral to whatever the I think that was the idea.

However, if you look at the count of the tag count column here, you can see this is used in zero tags. So it actually does nothing whatsoever. I I mean it great idea F for execution. Exactly. And again this is one of those useful things.

If I could I can sort my tags based on um the number of times they're the triggers. I sort my number triggers by how often they're used. I got three triggers that connect to nothing. They literally do nothing. So these are immediate candidates to go straight in the trash can because why have them there if they if they serve absolutely no purpose so part of what we do with governance is a look at um how many times a trigger is used and how many tags it's used in and then also do a quick sort by last edited when was the last time this trigger was touched if it's you know uh in the previous presidential administrations, like uh maybe it's time, you know.

And if you're going back to presidential administrations, then it's really time to say, do we still need this? Now, some of these things, like this Node.js trigger, uh, which is really poorly named, uh, is actually still relevant. So this is a GA3 uh detect JavaScript disabled trigger, right? That's a lot easier to understand than Node.js. Um, and it's looking for uh the a particular custom variable.

The custom variable it's it's is looking at saying, is JavaScript enabled in the browser? If it is, um if it's disabled, then that trigger should fire. Uh and you can see here at some point I did start doing a little bit of cleaning. I could have a GA4 scroll depth trigger and stuff, which actually, by the way, is is redundant because scroll depth is done automatically. I don't know why I put this in.

Um, I did I put into customize the the the numbers of how far down it went. So again, from a trigger's perspective, go in and look and say, well, do we need all these things? What do these things do and are they named intelligently? And so a so one of the things that I recall, and this is where you know I need to review tag manager a little bit more frequently, is that tags, triggers, and variables as they're outlined in that menu, are in reverse order of the way in which they should be nested. So really you should be starting with the variable first and then the trigger after that, and then the tag after that.

So, how exactly how is it really nested? Well, so variables are are exactly what they sound like. They're they're the individual data points themselves. There's a whole bunch of obviously ones that are built in, and there's the ones we configure. So that answers the question: what data are we collecting?

Um is answering variables. Triggers then says, Tag manager, listen for this. So when this I these are the actions that I want you to listen for. So tag manager, for example, is listening for JavaScript not being there, or is listening for a click on an Amazon link on my site, or is listening for a click on an ebook, or is listening for a click on a on an MP3 link. So these are the things that it's constantly watching and listening and saying when it happens, it's going to raise its hand and say, hey, I I see this activity happening.

And so the that's part of the reason why we go in this order is know what data you want to collect, and then what are you listening for? And then the tag is what action do you want tag manager to take. If you go in the other order and say, I want tag manager to take these actions, well, yeah, but then you need to configure what is listening for that creates that action and then what data it's working with to for that. So it's I find it's easy to go in the from a logic perspective, start with the data you need, then develop the conditions for listening, and then when you get to the tag part, you can say all your other pieces are in place. You don't have to create anything on the fly.

And if you've done a good job with your your naming conventions and governance, it's really fast to set up. Didn't we create a worksheet? You don't have to try to find it now, but didn't we create a worksheet that helps people do that naming convention? So basically you can write everything out ahead of time and then literally just copy and paste things in, but then you have a living document of what exists in your tag manager account. Um okay, so I think, you know, if if you're interested in, you know, a simplified version of that, you can certainly um jump into our free Slack group, Analytics for Marketers, and you know, ping one of us to see how you can get access to that uh spreadsheet.

I think that that would be super helpful in terms of governance, because that then that's where you should be uh sorting out all of your naming conventions ahead of getting into a system, but then it's also something you can hand over to your agencies, your partners, your contractors, say this is how we do it. You have to follow these rules to play in our sandbox. Exactly. Okay. And so that brings us to tags, which is the last part.

Again, this is one of those things where you can look at the date and see you know when was the last time this tag was touched or edited, uh, and and do we need to do something about that. Um, you can look in the right-hand column to see uh tags that are paused. You can see there's a whole bunch of tags in here that on my site, they're just paused because I'm not using them uh currently. And then from that, you can of course look at the uh the tags themselves and see what what exactly this is a tag do. So you can see this one here went from you know that cryptic node.js to having a an intelligent name to trigger.

So now I can go into this one and go, what is this? Ah, so this is Google Analytics 3 JavaScript disabled image tracking tag. So what this tag does is when JavaScript is not running, it will still send those UTM source medium and variables into Google Analytics, um, letting me track uh UTM codes, even if the person's browser has turned off uh JavaScript. And the way it does this is by loading an image. Um the reason we want to know that is we don't if a person's got an ad blocker on or is JavaScript disabled, that's totally cool.

We want to respect that. Um but if you've come in ver based on a link that I've sent you, like on my Twitter account or in my email newsletter, I still want to know that link did its job and and got me that uh and so this is how you can handle attribution for uh for the case where JavaScript's not running. So that's an example of uh a tag that definitely needed a better naming convention. But tags are where all the action happens in here, and one of the things that um is is getting even more important is when somebody is switching to Google Analytics 4, a lot of the the useful data that goes into GA4 that used to be in like goals in GA3, you must do in here. So your naming conventions need to be really good and your governance needs to be really good.

Let's look at an example. Um I want to let's sort this by name. So I have my GA3 tags and my GA4 tags. Uh I'm going to I let's look at my this here. I want to configure this tag to indicate maybe uh someone visiting my speaking page, let's let's make it worth a dollar amount.

Um this is an event, it's called a public speaking goal, uh, but I have actually missed uh part of the thing. I need to specify for Google Alex4 what currency um the value is. So now I'm saying when somebody visits a speaking page on my website, um I want to say that visit is worth uh $25. Now, if I had like a uh if I was using HubSpot, for example, and I was a form fill or a newsletter subscription or something like that. I would want to say what that newsletter subscription is worth X dollars.

And we've talked about in a bunch of other shows, how to do those calculations. But this is where you set goal values now in Google Analytics for. You can you don't do it in Google Analytics. So is it safe to say that the tag, thinking about it in terms of like how you're setting up your marketing strategy, your business strategy, the tag is the why. Why are you doing the thing?

And so it's a newsletter subscription, it's a PDF click. That's why we need the information. The trigger is the how. And so it's what am I paying attention to? And the variable is the what what data are we collecting when the thing happens.

And so it's you know, if that's something that I can wrap my head around. I can think about it in terms of I'm setting up some sort of a marketing strategy. I need my basic why, what, how, when, where. And it sounds like tag manager answers a lot of those questions in terms of the data collection. But you first need to start with what the heck do you care about?

So you care about people coming to your public speaking page, you care about people subscribing to your newsletter, you care about um people taking your website survey. Yeah, I would say triggers are how, where, like, because you control um triggers based on that, and then even when, because you can do things like delay when a trigger how long a you know a trigger should wait before firing. So a lot of that is handled in the trigger side, and then of course, the yeah, the why or the the what next is handled in the tag side. Your Google Tag Manager then takes some kind of action once a trigger fires, assuming that you connected it to a trigger, unlike me, where it had a bunch of triggers that did nothing. It sounds like that's a pretty common issue.

I know we've seen that with uh clients of ours where a lot of these pieces get set up, but there's no story, there's no narrative that connects everything. And so when you're getting into auditing and your governance, then that's when you spend a lot of time asking questions like, well, what's this? Why is this set up? Because that governance and those requirements weren't done in the first place to answer those questions that will inevitably uh be asked. Exactly.

And it's an ongoing thing. So let's we've made nine changes to this workspace. Let's go ahead and publish those changes. This is the point where um tag manager's gonna have some options here for us to do stuff. So I'm gonna say, let's do um live stream updates.

Let's call that. We fixed a bunch of stuff, not rid of unused stuff. Now, obviously, if this was a production environment, you'd want changes to be a bit more descriptive than that. Uh you might also want to have changes made by who did the thing, right? Whatever you would normally put in essentially like patch notes, if you were thinking of software, um, this is what would go what gets logged to the instance so that uh somebody knows that something's happened.

You'll also note that in addition to the changes, it uh alert alerts you there's 34 tags in my site that have not been configured for consent, right? So if I have a if I'm required to be GDPR and CCPA compliant, I've got 34 problems to go fix. So I'm gonna go ahead and hit publish right now, and it's gonna go do its thing. And it said, okay, these updates have now been made. You can see what happened, right?

You can see the the diff the changes that were made in the environment, and we can have our description there. If we go back into our tags now, I'm gonna pick, let's do engagement Amazon click. I'm gonna click on this and go into advanced. There's a section called consent settings. And this is where you would specify like what kind of consent is needed for this tag to operate.

In this case, um, I don't need any additional consent because it's all just using Google Analytics. So if you've consented to the use of Google Analytics, this is fine. If I was using HubSpot, for example, I might need you know, the HubSpot permission banner that you see pop up on the screen. I might need to detect that, detect that the person has said yes, they consent to it before my this tag would be allowed to fire. So in a in a situation where you're dealing with regulatory stuff, you need to know how to configure every single tag individually to say, do I need extra consent or not?

Again, another plug for doing your business requirements up front before even getting into the system. You can answer a lot of these questions and save yourself a lot of headache by structuring your requirements to follow this interface of tags, triggers, variables, you get the naming convention, but also that extra layer of is this variable one that requires consent? Yes or no. If yes, what does that look like? If no, go about your day.

Exactly. So you can see here this little uh privacy shield here. If I click on this, this brings up a list of what tags um consent is and is not configured for. Uh so I would need to go through. You can see for a lot of the Google native ones, um, there's built-in consent for ad storage and analytics storage.

So if I don't need anything other than that, uh those would be ones where I could say, I don't need, let's let's do that. I don't need for these ones to have these things flagged, anything other than the default consent built in. And then where that's blank, those would be once say, Yeah, I might need to go and take a look at that. Let's see. That would be no additional consent is required for those 17 tags.

So now I've got all of these other ones. Nope, I missed a few. Um, like Bing Webmaster Tools. Do I need additional consent for that tag? Do I need an additional consent for my JSON LD script?

Because these are all custom HTML tags. Uh, I might like the Twitter tag, I probably do need extra consent on that because that's an advertising tracking tag. Now it's pause, so I don't need consent on something that's not running. Um, but Facebook Pixel, if that was running, for sure would need extra consent on that, and possibly possibly you know, like a blood sample from our visitors. Uh whatever the case is, we would definitely need to get those additional permissions from the user before those tags be allowed to be fired.

I can see where a lot of a lot of systems get half set up when people get stuck with these things, these questions, because then they have to go get an answer, and then they probably get pulled into something else, and then the setup never really gets finished. Um, because there's a lot of steps. It is a literal piece of software, and software development is not an easy thing. There's a lot of details, and that's why a QA process exists uh for most software development. This is no different.

You need to have your requirements up front. You need to have the implementation, you need to have the QA testing, the documentation, all of those things in order to ensure that you did it right and that your data is coming through correctly. This is it's there's always pain. The question is, do you want control of the pain? And do you want control when you have the pain, right?

Uh, when you do governance properly, you're opting to have the pain up front in a managed fashion, um, as opposed to the lawsuit you get, uh, which is you know, deferred pain that is maybe substantially you know more painful later on down the road. Uh so it's a question of when you want your pain. You're gonna have pain no matter what. Well, and you know, uh, you know, not to like pick on you, Chris. But as you were just showing that example, you submitted a second set of changes with no documentation.

And so six months from now, when we revisit tag manager and go through a lot of these same steps, you're gonna go, huh? Well, it looks like these happened on the same day, and the first one was for the live stream, but what the heck was the second one? And so, again, fortunately, because it's just your site, it's not that important to have that information, but it's not a best practice that we would encourage people, even with your own site. I can never remember what day it is, what time zone I'm in, it doesn't matter. God forbid I remember what changes I checked in to my website on any given day if I don't document something.

Mm-hmm. Exactly. And again, that that that also goes to risk management too. Um if you the risk of me screwing something up on my site is relatively low, all things considered. Right.

The risk of screwing up something on an e-commerce site where you know that's where customers buy stuff, substantially higher, right? If you break uh a tag firing uh on a shopping cart, you're probably going to get an angry phone call from your VP of finance relatively quickly. Uh if you are running a a government site or a military site, things, you know, obviously the all those environments, you don't get a choice. You have to do it. There's no chance for you to not do these things.

Uh you must do that. But it it is a risk calculation too. There is one thing I wanted to ask you about is you know, your tag manager is filled with a bunch of custom stuff you've got to get GA working right and to do your own tracking. But a lot of corporate sites, there's this huge gigantic junk bin of 150 tags for every SAS service that they've installed along the way. And is there anything people need to keep in mind with that kind of stuff?

Do you want to cord in those tags off into their own, you know, do you organize those in some way so you know because it those seem to be even more painful. Like if you install that tag and it breaks, you don't even know how those things run. So troubleshooting that stuff is you know can be incredibly painful. You can put them into folders. There's a a feature that allows for folders in in tag manager.

I find though that that's usually not sufficient. Uh having a name in convention, like especially if an agency installed a piece of software, having the agency's name in the tag trigger or variable is is best. You know, when we go in and we make changes to client uh stuff, we always name you know trust insights, G A3, whatever. Um, so that six months down the road, somebody looks at it and goes, Who's trust insights? And you know, and go, oh, that's the agency we were working with at the time.

Like, oh, okay, cool. You know, we know who's responsible for it. If it's just a bunch of you know, mangled letters, then nobody really knows what the thing does. And that's when you then you have a lot of cruft of like, do we does it? Does anyone know we're even still paying for the service?

Um we've seen that a lot, particularly for B2B customers where they've got you know uh a legacy of Salesforce tags and HubSpot tags and demand-based tags and all these things. Like, do you do you even still pay for these services? Um, because if if you want something that will make a either a compliance person and a lawyer either really itchy or is to start salivating, it's when you start when you're still sending data to unauthorized parties because you didn't uninstall their tags. Yeah, I think with the governance piece as well. Um, I think I've lost track of the number of times where a client has approached us and said, So the person who set this up is no longer with the company, and none of us have access to change ownership permissions or grant you access.

So we have to go chase him down, you know, three jobs from now. Um, you know, that's a pretty common thing uh amongst companies. Um so I would say, you know, as you're setting up these systems, build that into your maintenance plan. Um, you know, who's the backup to the backup to the backup of if Chris decides to leave is part of his transition plan that he needs to give me ownership of the stuff, and then I decide to leave, and I then have to give John ownership to the stuff. And like that needs to be built in.

Um, those are your business continuity plans, really, more so. Um, but they're important parts because it may feel like, oh, well, it's just a tag manager account. But if you've been using your tag manager account for six years and you're an enterprise-sized company, there's a lot of data in there that you may not have access to because the guy who set it up six years ago is off on his own private island somewhere, never to be seen from again. And uh unauthorized access to analytics is one thing. Unauthorized access to tag manager, again, you can make physical changes on somebody else's website.

You can control the user experience. Um, you can do a lot of things that you really shouldn't be, you know, unauthorized parties should not be allowed to do. Uh, I'm not going to show it on screen because uh for confidentiality reasons, but there's a long list of companies whose tag manager accounts I still have access to seven or eight years after the fact. Like, well, if I really wanted to hose this company, I could redirect all of their traffic. Now I would never do that because that's unethical and illegal.

Um if my account say I didn't use two-factor authentication, which I do, if I didn't use that, someone could hack into my account and then just compromise several Fortune 500 companies because they have not withdrawn access. So if you are on the company side, that's why we say quarterly clean out your access list. And then everybody who has access to these things should be using two-factor authentication because otherwise, you know, Vladimir the uh the Russian hacker is gonna come in and and you know charge cryptocurrency bots on uh across your site. And at that point, you're kind of hosed. So there's the there's this an element of security and risk management to this.

It seems like it can seem like it's very pedantic, like okay, you know, we have to do follow these procedures, I don't know why we have to follow these procedures. You know, we're not a fan of processes for processing, but tag manager is such a powerful tool that you can literally wipe out a company's digital presence if you if someone has unrestricted access to it. Process and documentation exists for a reason. And I will say ten times out of ten, it's the thing that people skip over because it's the boring part. People just want to get in, start clicking the buttons, doing the thing, seeing the data.

I get it. However, having come from working in a regulatory industry, I can I've seen literal life and death situations where not having that documentation does go very, very wrong. So I get it, it's boring, don't skip it. And if you don't want to do it, I'll do it. Hire me.

I'll do the documentation for you. You can go push the buttons and play with the things and make the bells ring. And on that note, uh, if you have comments or questions, feel free to follow up on our Slack group. We'll have a link in the end here. But thanks for tuning in this week, and we'll catch you next week.

Thanks for watching today. Be sure to subscribe to our show wherever you're watching it. For more resources and to learn more, check out the Trust Insights Podcast at TrustInsights.ai slash TI podcast. And a weekly email newsletter at TrustInsights.ai slash newsletter. Got questions about what you saw in today's episode?

Join our free Analytics for Marketers Slack group at trustinsights.ai/slash analytics for marketers. See you next time.