Experimentation & Analytics Archives

Google tag manager’s job is to track things that happen in your application and send them to other applications, like Google Analytics, for analysis. You could use Google analytics on its own. Tag manager becomes useful when you also want to send the same information to other tools for analysis. Instead of tracking the same events with multiple tools, you track them once with tag manager and that send them to all your tools. Let’ say you have a software product set up with Google Analytics, then you also have some sort of email service provider and you want to track whether the people who read your email use certain features in the app, then you have a screen recorder like Hotjat and maybe product analytics suite like Mixpanel. Each of these tools need to know about important events, like when someone signups or becomes a paid user. Track these events once with Tag manager and you can send them to as many services as you want. I have tried to avoid using Google tag manager for as long as I can. In the past, I’ve used segment for this problem because it is relatively easy to start using. However, Segment costs $100 a month and that’s overkill when you’re working on a small project. Google Tag Manager is free, but there’s a bit of a learning curve. Until now we’ve just relied on the other free alternative, which is instrumenting every service on its own. We don’t have a lot of services so it has been manageable. The problem is we began running Google Ads. In order to track whether or not the ads are working events, you have to use Google tag manager. As far as I understand there is no other option. Hopefully, by the end of this article, you will have a mental model of how Google Tag Manager works if you ever need to start using it for your project. Tags# When you start using Tag manager you have to figure out your tags and your triggers. Tags are what connects you to your other services. You need to set up at least one tag for each service you connect so that Tag Manager has a way of sending it data. If you’re sending data to Google Analytics and Hotjar you will have a tag for Google Analytics and Hotjar. If you are used to using Segment, then your tags are much like your destinations. Confusingly, unlike Segment where you have a single destination for a service, in Tag Manager, a single destination can have multiple tags. For example, Google Analytics has one tag for pageviews and another tag for custom events. It’s unclear how the boundaries are being drawn here. For example, you don’t need a separate tag for logging in and logging out. Those are both events, so you can just have an event tag in Google Analytics and send in unique names for each event. You do need a separate tag for pageview though. Apparently, pageviews are a different kind of thing and you need a dedicated tag just to track them. So tags are kind of like destinations but they can be more granular, and the basis of this granularity is a bit unclear. Triggers# Next, you have triggers. A trigger listens for a specific type of activity in your app. You can pipe hundreds of events into Tag Manager but you probably only care about a handful of them. You set up triggers for the events you care about so that they get passed onto the necessary tags and you can safely ignore all the other activity in your app. Every time someone does something in your application that you care about, say log in or log out, a dedicated trigger will send the event to its connected tags. Separating tags from triggers makes sense because you might want to send the same event to multiple destinations. When someone logs in I usually want to know about that in Google Analytics, Mixpanel, and Customer.io. Instead of setting up listeners on every tag, I set up a single login trigger and then connect it to each of the tags that need to know about that event. Another reason why I think triggers make sense is that sometimes in an app you have a central juncture for events. Like, say a redux dispatcher. Rather than hooking up 30 separate triggers in different places around your app, you can hook into your redux middleware once and send all the events to Tag Manager. You don’t want to forwards hundreds of irrelevant events to Google Analytics and clog everything up with meaningless noise so you just set up triggers around the events you care about. Being able to separate the wheat from the chaff makes collecting events really easy on projects that have this kind of event hub architecture. Data# Let’s say we have a trigger setup on a signup event. This connects to some tags and now a handful of services know when someone signup in your app. The problem is that we also want to send these services some details about who signed up and what plan they were on. You’d think we can just pass this data into the little google tag event tracker on your app and we’d be done with it. But No. You have to the data pass into the tracker, but then it gets dumped into something called a data layer. This is confusing because the data layer is just a temporary clearinghouse. The data here doesn’t automatically get passed onto a tag. If you want to pass information from the data layer to an event you’re sending off then you have to reconfigure the tag to include references to the information you want to use in the data later. Frustratingly, you also have to do this for every tag you want to send the data to. You’d think that you could just update this in the trigger, and the change would propagate to all connected tags, but no, you have to recalibrate every one of your tags each time you want to send additional data down the pipe to the connected service. This took me a little while to figure out but once you understand this, everything makes much more sense. Preview mode# You also have preview mode so that you can debug this entire mess when you’re setting things up. Instead of having a browser extension like you’d expect, they have a dedicated page that acts much like a console debugger. I’m guessing do it this way to make it easier to debug tags on cross-platform applications. Not sure, but it’s still counter-intuitive if you’re just working on the web. Tags, triggers, data, and the ability to set everything up in preview mode is pretty much all you need to know to gets started with Google Tag Manager. Here’s a full walkthrough of what you need to do to track an event in your app and send it to a third-party service like Google Analytics or Mixpanel. I’m going to assume you have a Tag Manager account and it’s set up and you’ve added the snippet to your product. This is something you just do once so I won’t cover it here. Configuring pageviews in a single-page app is another trap you have to watch out for so I’ll leave a link on what t pay attention to in the footer. Assuming you have everything set up, here’s what to do every time you want to start tracking a new event. Instrument the event in the app with the gtag function on the window object. This comes from the snippet you added to your site when you set Tag Manager up.Once the event is instrumented in the source code then start your app up locally and check that the event, and any associated data, is showing up in the preview mode debugger.Now create a trigger to listen for the event and connect the trigger to each of the tags you want to send the event to.If you are sending any additional data with the event then make sure you reconfigure each of your tags to reference the associated data in the data layer. …and that’s pretty much it. Wait, there’s also server-side tag management. This one is a bit of a rabbit hole, so I’ll try and clear it up so you’re not confused when you bump into it online. So far everything we have talked about is in the context of an event being tracked on the client. This is not ideal because it means that anyone with an ad blocker can dismantle your entire analytics operation. I’m 💯 for privacy and I use brave myself, but there’s a difference between 3rd tracking cookies and being able to track your own user data. You’re signing up to our platform, we know you are a user, it’s the information we use to give you the service you signed up for. We use analytics to understand which features are popular and where things are broken. Not being able to reliably send this data directly from our back-end server to our analysis tool is a huge pain. Server-side tracking allows you to send events directly to Tag Manager via an HTTP request. However, it also means setting up up a whole new dedicated tracking server in Google Cloud, paying for it, and maintaining it. Costs saving was one of the reasons that tag manager was more appealing than Segment in the first place, so now we’re kind of going full circle. However, doing this means that we don’t have to load a bunch of snippets on our website and that will help speed things up, so it’s something I want to look into in the future. Related Links# I got accepted to CXL institutes’ growth marketing mini-degree scholarship. The program runs online and covers 112 hours of content over 12 weeks. As part of the scholarship, I have to write an essay about what I learn each week.This is post 9 in a series. The rest of the posts are listed here.Here’s how to configure pageviews in Tag manager in a single-page app. This post is specific to React but you can easily extrapolate to any framework.If you’d like to get more updates on my growth marketing learnings you can follow me on Twitter @joshpitzalis.