Analytics implementations make up a huge percentage of the work we do here at UpBuild. While we’re passionate proponents of Google Tag Manager, we also acknowledge that there are plenty of other ways to achieve the same result, i.e., actionable analytics. In fact, I’ll admit that Google Tag Manager isn’t always the best implementation method. ::gasp:: I know! Scary, right?
I’ve long wanted to write a post that broke down the different styles of analytics implementations so that folks could weigh the pros and cons of each and make an informed decision. In web analytics, there’s no “right way” to do anything so the important thing is to be thoughtful about it and make the right decision for you based on where you’re at.
Let’s get right into it.
Quick Links
- Hard-coded (Traditional)
- Google Tag Manager
- Autotrack.js
- Plugins + Duct Tape
- Comparison & Conclusion
Hard-Coded (Traditional) Analytics Implementations
I’m approaching my mid-thirties, so I’m excited that I’m able to start stories with “back in my day” a lot more. Back in my day, all of our analytics implementations were “hard-coded” (and we had to write code snippets in the snow with no gloves on). Hard-coded isn’t an official term by any means, but it refers to the fact that you need to make a semi-permanent change to your website’s code to facilitate data collection.
The most basic component of hard-coded implementation is putting the basic Google Analytics Tracking Code (GATC) in the source code of your website. In order to set up Google Analytics data collection on your website, you edit the source code and add in the GATC — hopefully, you can just edit a template file (e.g., head.php) and be on your way, but sometimes you literally need to open it up and make changes to every single page.
I know we, i.e., marketers, like to think that everyone is soon going to be on
- sites built with interesting new technologies like Node, Angular, Ruby, and the like, or
- tried and true standards like WordPress,
but that’s not the actual reality of the web.
There are still technological holdouts at the enterprise level who maintain their sites without a CMS, changing one page at a time. Yes, this is the kind of stuff I plan to tell my (future) kids on a dark winter’s night to scare them into always using standards-based open source platforms (I have yet to run this by my wife). But, I digress…
So the foundation of hard-coded implementation is the GATC. If all you ever want to do is collect basic data, you’ll actually be pretty well off.
Data that’s easy to get at with simple hard-coded implementation:
- Page views
- Referral data: traffic source and medium
- Time on site
- Pages per visit
- Bounce rate & exit rate
- Demographic & technological data: location, browser, device type, etc.
But what if you want to go above and beyond and really understand the value of your visitors and analyze how they use the site? Welcome to the world of actionable web analytics! In any of these scenarios, you’ll need to add more hard code. The code snippets may be smaller than the basic GATC, but two things may present challenges:
- Slogging through Google’s (admittedly much-improved) analytics implementation docs
- Putting code snippets in exactly the right place in the source code of your website
Let’s say you want to understand how many people click on our company’s logo to get back to the homepage. Consider the basic HTML below:
<a id='ourLogo' href='/' ></a>
In order to set up event tracking on that element, we’ll need to find where the logo lives in our site’s source code and then type out some additional code (bold) — further details here: Event tracking in Google Analytics.
<a id='ourLogo' href='/' onclick="ga('send', 'event',
'website header', 'logo click');" ></a>
That’s not so bad, but imagine doing that for every element you want to collect click data on! There could be hundreds of edits that you’ll need to make. And now imagine that you don’t have the keys to the website and you need to ask a developer to make those hundreds of changes for you and then have to ask them to redo the work if something gets placed incorrectly (spoiler: something’s always placed incorrectly).
This is just a basic example. What if you want to track social sharing activity, fire an event upon form submission, set up virtual page views for a single-page checkout, track scrolling on a site, collect data on video engagement, set up cross-domain tracking, adjust the site speed sampling rate, or anything else?
What if, heaven forbid, you go through all the trouble of getting this put onto the site and realize a few weeks later that something needs to be changed? Even a slight modification could require opening another ticket and waiting weeks!
Pros & Cons of Hard-Coded Implementations
Pros
- Easy and cost effective, if you just need the basic GATC
- Set it and forget it if your analytics needs are simple
Cons
- You can’t change any settings relating to the basic GATC without going back under the hood
- Layering on advanced tracking can range from “challenging” to “nightmare-inducing”
- Working in a multi-partner situation can result in a lot of back and forth (it’s not uncommon to see a 50-100% increase in project hours).
- If Google releases a new version of their analytics library (e.g., ga.js → analytics.js), you’ll have to go back in and update everything
Bottom Line
If all you care about is basic page view and engagement data, hard-coded is a fine way to go (see Plugins & Duct Tape as well).
Google Tag Manager
Before we start this section, note that I’ll be talking about Google’s tag management product but the principles apply to any platform that manages tags on your website.
The first step of implementing with Google Tag Manager echoes that of hard-coded implementation — copy a code snippet from your account and paste it into the source code of every page. The big difference is that once you do that, you’re done — no more touching the source code*. Everything else from event tagging to adding a Facebook Pixel can be managed through the GTM interface at tagmanager.google.com.
To illustrate the differences in how you’d layer on advanced analytics using GTM, let’s continue with our previous example:
<a id='ourLogo' href='/' ></a>
When GTM is on your site, you just tell it to listen for clicks on any element with the id of “ourLogo” and specify your event values (category=”website header”, action=”logo click”). Again, it’s all done within the Tag Manager interface. No changes need to be made to your site’s code!
The example above only scratches the surface of what’s possible and “tell it to listen for clicks” is a dramatic simplification, but I stand by my argument. Under the Google Tag Manager method, whenever you need to make a change or add on additional layers of advanced analytics you can do it all without bugging a dev team or having to get into the source code yourself. That, my friends, is incredibly powerful.
But, wait! There’s more. Google Tag Manager also supports multiple workspaces with conflict resolution (multiple people can work in GTM at the same time), approval queues, and versioning. Plus, you can use Preview Mode to test every tag before you air it on Primetime.
Google Tag Manager. It’s just the best thing ever.
* You may want a make some additions to your code base to support advanced data collection and analysis (i.e., a dataLayer array or custom pushes to the dataLayer) but this is still simpler and more maintainable than if you were to do the same under the hard-coded paradigm.
Pros & Cons of Google Tag Manager Implementations
Pros
- Extremely scalable and easy to maintain
- Triggers allow you to deploy tags conditionally based on any recipe you can come up with
- Unleashes the power of dynamic tag values
- Streamlines tagging for 3rd-party platforms as well
- If Google Analytics releases a new library, it should be relatively easy (if not automatic) to port all your UA (Universal Analytics) style tags into the new tag type
Cons
- Changes in the DOM can break everything (if you have tags and triggers that are based on those elements)
Bottom Line
Use Google Tag Manager. You’ll thank yourself later. It’s just as easy to install as the hard-coded GATC and everything from there on out in made vastly more efficient and powerful. Worst case scenario: You implement GTM to deploy a single Google Analytics pageview tag instead of the hard-coded GATC and never think about it again.
Want to learn more about the crazy things you can do in GTM? Check out 29 Tips for Google Tag Manager.
Autotrack.js + Hard-coded
Autotrack.js. The name seems to suggest “automatic tracking” and if that sounds pretty awesome, it’s because it is…in principle.
Google says that “Since most website owners care about a lot of the same types of user interactions, web developers end up writing the same code over and over again for every new site they build. Autotrack was created to solve this problem. It provides default tracking for the interactions most people care about, and it provides several convenience features (e.g. declarative event tracking) to make it easier than ever to understand how people are interacting with your site.”
Nice. That sounds like a sweet deal. Autotrack.js includes a handful of cool things that most organizations will want to see in their analytics implementations:
- Scroll depth tracking
- Consistent URL tracking to account for URL path inconsistency
- Declarative event tracking (requires code changes throughout your code)
- Social button tracking (official widgets from Facebook and Twitter only)
- Tracking for state (i.e., URL) changes on single-page web apps
- Automatic tracking for outbound link clicks
Overall, a lot of cool and innovative features.
However, it does require development chops and code savvy to work with. For instance, the installation instructions for autotrack.js begin with “Load the autotrack.js script file included in this repo (or a custom build) on your page.” That’s Latin to most people. The next step is to modify your hard-coded GATC; “modify”, in this case, being more of a complete rewrite.
C’mon. There aren’t more than two unmodified lines there! You’ve probably noticed by now that this is very similar to hard-coding and that’s just what AutoTrack.js is…only more complex.
From there, you’ll need to modify your source code to work with the Autotrack.js plugins you want to use. Let’s say we want to use the eventTracker plugin to track the same logo that we’ve been using as an example.
<a id='ourLogo' href='/' ></a>
Autotrack.js running eventTracker will not track this automatically; it still requires that you make changes to the code. eventTracker facilitates “declarative interaction tracking”, which means that you need to declare (i.e., hard code) a handful of things about the elements you want to track.
<a id='ourLogo' href='/' ga-on='click'
ga-event-category='website header'
ga-event-action='logo click' ></a>
So even with “automatic” tracking, you’re adding a fair bit of code to enable it. In fact, for this example, we’re adding more characters (77) than we had to with good old-fashioned hard code (62)! While event tracking is admittedly one of the more extreme examples, even a straightforward plugin like cleanUrlTracker requires that you set the correct parameters for your use case when you call the plugin. Just more code to familiarize yourself with.
A final note is that Autotrack.js is not an official Google Analytics product; it’s just developed and maintained by certain members of the GA platform team. I’m sure you can guess what that means for working with it — if you’re not a developer, you’re gonna have a bad time. That’s not necessarily a bad thing; it serves its purpose. The only thing I take a bit of issue with is that the name is a misnomer — tracking with Autotrack.js isn’t as automatic as most people are going to assume it is.
For the majority of marketers I know and work with, Google Tag Manager is going to be much, much easier to work with.
Pros and Cons of Autotrack.js Implementations
Pros
- Innovative plugins to solve common analytics challenges
- Saves a ton of time if you’re a developer who commonly architects your own analytics solutions for your clients
Cons
- Daunting to use for non-developers
- Doesn’t necessarily deliver on the “automatic tracking” promise
- Requires that you make extensive code changes to your site
Bottom Line
If you’re a developer building custom apps and you don’t want to (or can’t) use Google Tag Manager for whatever reason (performance could be a valid one), Autotrack.js is worth considering. If you’re a marketer looking to make the process of setting up custom analytics more streamlined and pain-free, forget you ever heard about Autotrack.js and stick with Google Tag Manager.
For what it’s worth, I love the idea of providing and maintaining pre-built solutions for common analytics challenges. What I’d love to see from the GA platform team is an equivalent GTM container (which are importable, BTW) so that analytics users can upload a container that has prebuilt tags, triggers, and variables that solve for the same common scenarios. That’s what we’re trying to do with Eru, but we honestly haven’t been able to prioritize working on it much this year.
Plugins & Duct Tape Analytics Implementations
It can be fun to give plugins a hard time because, after a while, you start to feel like your whole website is held together with duct tape and children’s wishes. But, ya know what? We use them all the time and some plugins can be quite good! When in doubt, you can always go the plugin or module route. There are a lot of great, reliable plugins for popular content management systems like WordPress, Drupal, Magento, etc. Plus, a lot of website SaaS products like Shopify, Squarespace, and others also provide a Google Analytics field that you can drop your Google Analytics tracking ID (UA-XXXXXX-Y) into.
While there are various levels of sophistication when it comes to plugins, the basic idea is that you supply the Google Analytics tracking ID and the plugin generates the requisite hard code on your site. In much the same way as Autotrack.js, plugins make assumptions about common scenarios that their users are going to want to track in Google Analytics. Some will only put the basic GATC on your site; others will automatically add event tracking to your navigation, enable scroll tracking, and more.
GTM Plugins
Along similar lines, there are also many plugins that will allow you to easily add the GTM container code to your website (UpBuild uses DuracellTomi’s GTM Plugin for WordPress. Solid.). The cool thing about using a plugin to add GTM is that it lets you be completely self-sufficient. You don’t need a developer for any step of the advanced analytics process.
Pros and Cons of Plugin-based Implementations
Pros
- Easy to find and install, sometimes with a single click (if you have a compatible CMS)
- Reduces or eliminates development time
- Many will provide support for common advanced use cases
Cons
- As with any plugin, can introduce security, compatibility, and/or performance issues
- Plugins can become inactive and unsupported over time
Bottom Line
If you’re on a CMS that has a well-rated GTM plugin, run with that, and then use Google Tag Manager for the rest. If you have a super simple site that only needs basic analytics, a GA plugin is a fair option, too. However, if you’re on a CMS (or a homegrown website) that doesn’t support plugins or extensions you might be out of luck.
Comparison & Conclusion
If you came here hoping to have an expert help you make a decision on how to implement analytics, I’ll give you our recommendation for most people: Google Tag Manager. If you can, use a plugin to implement because it’ll make your life that much easier.
If you’re still on the fence, refer to the helpful chart below.
I swear I didn’t set out to write a sales pitch for Google Tag Manager — it’s just that it’s that good.
Have questions? Want to share a different point of view on hard-coded implementations or Autotrack.js? Let’s keep the conversation going in the comments.
Until next time, happy optimizing!
