10 Google Tag Manager Questions That We Get Asked Most Often

Image source: themacx, iStock

We explored the business and the technical considerations and benefits of implementing a Tag Management System (TMS) in a webinar that you can watch on-demand as well as in the blog post that answered the great questions that the webinar attendees left for us. Not surprisingly, many of the questions were about Google Tag Manager, a free tool that is used by 60% of top online retailers according to our recent report on retailer tag management usage. So as a follow up, Dave Fimek, our Sr. Consultant, Implementation, collected the ten most common questions that we receive about GTM and addressed them here: Q. Is it only for Google products? A. No, you can deploy anything via Google Tag Manager. The tool is designed to be agnostic to whatever analytics or advertising platform you want to use. Everything from Adobe to Coremetrics will work in GTM. Q. Does it store any data? No, try to think of any tag management system as a junction that directs the flow of traffic. The data never stops in GTM and it just gets sent on through to wherever it’s going. This is typically something your IT security people want to know. Q. Do I have to be a developer to use it? A. Many will tell you no but if you really want to leverage GTM to its fullest then you’ll want some development chops. The development skill set needed to max out the features GTM offers is pretty basic so even a junior level developer can do well with this tool. If you’re comfortable with JavaScript, CSS, and basic HTML you’ll do just fine with GTM. Where this comes into play the most is building out triggers and variables for your tags. You’ll have to look under the hood of your website to make those configurations. Q. What kind of team should maintain it? A. GTM has various levels of user access that can control exactly who can do what in the configuration. It’s recommended that very few people have the ability to publish your container to the website and that those people are looped into the overall development of the website and are very skilled regarding the usage of GTM. The rest of the team can be more marketing and analytics-centric. This will allow them to configure GTM to their liking while your development-savvy gatekeeper reviews the updates and rolls them out to production. Such an approach will take a tremendous load off the development team and empower the marketing and analytics side of the house to get the exact data they need. Q. Do I have to remove the current implementation code? A. Yes and no. Your GTM container will not disrupt any existing tracking code on the page. If, for example, you have the Google Analytics Tracking Code (GATC) on the top of your page executing a pageview it will continue to operate normally. It’s important to avoid having code reporting to the same web property. If you have a tag in GTM firing a pageview to account X and a GATC directly on the page also firing a pageview to account X you will be double counting every session that hits your site. Q. Can I have code on the page as well as in GTM? A. Yes. On larger deployments that involve a lot of tracking you might want to ease yourself into transitioning fully to GTM. It’s perfectly fine to be iterative about deploying out GTM by migrating over functionality from direct code on the page to Google Tag Manager. Just be certain to avoid the double-counting issue listed above. Having both a GTM container code on the page as well as the legacy deployment is a great way to build a proof of concept, and a good method for getting some organizational “buy-in” for using GTM. Q. What are the alternatives to GTM? A. There are tons of other tag management systems (TMS) out there for you to use and I would recommend exploring your options. Most of the better ones out there are commercial and do have a price tag associated with using them. I won’t go into specifics regarding the pros and cons of each of the competitors but what I normally tell people is that GTM is one of the newer kids on the block which means that its competitors had a head-start on developing features and functionality. GTM is updating at a breakneck pace and it’s abundantly clear Google has dedicated itself to the product, but it did jump into the race later than some of the competitors. The main reason my clients have chosen another TMS over GTM is typically due to a “must-have” feature that GTM has not quite developed yet or another part of the organization is already paying the bill on some other TMS system. Q. Can I deploy out the container code using a CMS plugin? A. You can, but I don’t typically recommend it. When deploying out the container code you should embed it directly into the template or theme files of whatever CMS you’re using. All CMS’s from WordPress, Joomla, Drupal, to DotNetNuke have a small set of files that govern the look and feel of the website and it’s a perfect permanent home for your container code. If you download and use a plugin you run the risk of that plugin not abiding by best practices. Using a plugin is one of the most non-technical ways to deploy out, but you’re adding a lot more points of failure to your tracking. I would only use a CMS plugin as a stop-gap solution as the container code is being added to your template files. Q. What is the dataLayer? A. I’ve defined the dataLayer before in a previous blog post, but in a nutshell the dataLayer is a means to send values from the page into whatever tracking software you’d like as well as notify GTM that some important event or action has occurred on the page. The dataLayer is not a unique concept to GTM and most TMS systems have it in some form or another. The dataLayer does require a developer for your website to add code to the page itself. Q. How much development effort is it to use the dataLayer? A. Since this does require a web developer for your website to go in and add code there will be an unavoidable level of effort. Luckily it is pretty low impact and far less invasive than a traditional non-TMS implementation. There are two types of dataLayer code you’ll see on a page. One will push values to the dataLayer immediately upon the page loading. This is ideal for sending values such as, “what type of page is this?” or “who is the author of this page?” The second type will be more on-demand to push values and notifications of when some action happens on the page such as, “what button was just pressed and what was the text on that button?” or “what language did the user just change the page to?” The dataLayer code itself is very basic JavaScript. The bulk of the effort for your developer will be not understanding that basic dataLayer JavaScript but rather deciding where the JavaScript needs to execute, and how to pluck those values from the page and populate that JavaScript. The more familiar your developer is with the website the faster the turnaround on dataLayer requests. On most of our implementation project we allocate two weeks for the developers to implement the dataLayer changes, but the hours invested during those two weeks are generally pretty low. Whether you’re looking for a vendor-agnostic expert to help you select, implement, and configure a new TMS, or if you already have a system but are not seeing the ROI that you were hoping for, we can help. Contact us to speak with a TMS expert about your needs.

CP Marketing