Why Container Tags and JavaScript Frameworks are an Analyst’s Friends

It's not an uncommon scenario: you want to add in some additional tracking functionality or correct an issue with the analytics script on a client site, but the development and maintenance of that site is handled either in-house by the client or by a third party development agency. In such circumstances you can quickly find yourself subject to long delays waiting on development schedules, UAT, differences of opinion regarding priority and so on. It can be very frustrating, especially if all you want to add in is a couple of extra lines of tracking code! In some cases, it is simply not practical to get even minor tracking changes implemented due to scheduling, budgets or other factors.

This tangled web of woe and delayed reporting doesn't have to ruin your day, however. The approach that we at Fresh Egg are starting to use to address this problem is to advise our clients to set up a container tag solution. Plenty of these are on offer, including TagMan, DC Storm or even free offerings such as QuBit OpenTag, and I would advise researching in order to find out the best one to suit your needs on a case-by-case basis.

What is a container tag?

For those of you unfamiliar with the concept of a container tag, they are essentially as the name suggests: containers. They take the form of a small piece of code that you place into your website, typically in a part of the markup common to all pages such as a header template or include file. Once this small change has been made to your pages and deployed to the live (or test) site, you're ready to start filling the container up with custom scripts.

Custom scripts (also referred to simply as ‘tags') are composed and added to their parent container individually. For example, you may create a tag that contains your basic Google Analytics tracking snippet and then a tag to handle client-side validation of a checkout form and so on. Any typical application for using JavaScript on a website can be implemented via a container tag.

So why would you want to take this approach? Why not simply take the tried-and-true approach of having scripts loaded in from .js files or inline in your document's markup? Well, there are several compelling reasons:

• If you have a lot of custom functionality in a .js file, the chances are only one or two parts of it are required by any specific page. For example, you may have a single file that handles validation rules for your contact, checkout and feedback forms. If each of these forms appears on its own page then there's no need for one of the three to have the code for the other two loaded in: you're just bloating your load times with irrelevant code

• If, as mentioned earlier, code changes and updates are handled by a client or third party agency, you can end up waiting around for changes to be made when you're quite capable of making them yourself. Using a container tag gives you the option to jump in as you need to and add in snippets that are deployable when you need them to be

• Container tags keep your scripts in a centralised environment. There's no need to root around a dozen different templates looking for a single piece of inline or referenced code to duplicate to another part of your site

However, that's not to say there aren't cases where you might want to keep part of your site's JavaScript outside of a container tag. For example, if you are using a framework such as jQuery or MooTools, which is provided in a compressed library and generally also deployed site-wide, then you may elect to simply load that in with a <script src=""> tag as normal. Placing these scripts into a container tag should not present any specific issues, but it's important to remember that that's where you need to go to update their code as new versions of the frameworks are released.

The full benefits and features of using container tag solutions are well-documented by their providers, and so I will let you make up your own mind on which aspects of your scripting are best suited to implementing such a solution.

How does this approach combine with web analytics?

We regularly undertake audits of the analytics implementations on our client sites, and without exception (to date, at least) there is always something more than can be tracked or that needs correcting. This can be anything from disastrous oversights, such as pages missing their tracking code completely, to simply adding in additional event tracking.

Following completion of an examination of a setup, there is inevitably a list of necessary code changes that need to be made to implement any fixes and improvements. Documenting these updates can often be a long process when there are a lot of changes to make. Sometimes clients or development agencies will not have as great a familiarity as you do with the analytics code, and so extra care is needed to clarify both the how-to and the benefits of implementing your proposed updates.

Even if the body responsible for the development work is up to speed on the tracking in use, large lists of code changes can sometimes lead to certain elements being missed, code level conflicts going unnoticed in testing and so forth. If an initial change does not work as intended (especially if there's an unforeseen conflict with another piece of code), you can lose a lot of time emailing or discussing with those making the changes, asking them to try possible fixes in turn or make amendments to how a new behaviour should work.

Container tags avoid these two issues by allowing you to get stuck in to making the updates straight away (although please do still tell your client what you are doing and why!), typically allowing you to test and fix any errors that might pop up unexpectedly.

Putting aside any issues that may arise while ensuring you've explained the changes correctly and any issues that occur in testing, the other key benefit is once again keeping things centralised.

Let's say you have a number of outbound links to promotional offers on a page, and that list changes every week (or even every day). If you want to track those outbound clicks, the last thing you need to be doing is manually updating onclick events for each new or changed hyperlink. The chances are that in time you will end up not only begrudging the task but also forgetting it, copy and pasting a value without updating it and all the other errors that creep in to monotonous minor changes.

By using a script kept in your container tag to automatically apply the outbound click tracking via onclick events, you can handle multiple code changes from a single resource and avoid needing to keep jumping back in to make regular and irritating little updates. This principle is just as much of a boon when you want to apply lots of little tracking changes (event tracking is again a prime example) across multiple pages but don't want to have to update each page's links individually.

Now of course, when you want to apply bulk updates to your page markup you do need to have a means of traversing and manipulating the DOM effectively. Simply using a container tag doesn't innately provide the means to magically control your code – you still need to handle the details yourself. An ideal solution to this is to implement a toolkit or framework such as jQuery or MooTools on to your site.

Dynamic tagging in practice

Taking a jQuery example in hand, let's go back to our example of tagging all outbound links on a page relating to promotional offers. Suppose our markup is as follows:

<div id="promo-offers">

<a href="http://www.promotion.com?id=1">50% discount</a>

<a href="http://www.affiliate.com?offer=bogof">Buy one get one free</a>

</div>

Normally, we'd need to go through the hassle of applying onclick events individually to trigger our event handling. We've already discussed the problems there, so let's see how we could automatically look after any updates to this content with a mix of a container tag and jQuery for a Google Analytics implementation.

Our tag would simply be:

$(document).ready(function() {

$('#promo-offers').children('a').click(function() {

var offerName = $(this).text();

_gaq.push(['_trackEvent', 'Promotions', 'Outbound Clickthrough', offerName]);

var t = new Date().getTime();

while ((new Date().getTime() - t) < 250) { var x = 0 >> 1; }

});

});

We're doing a few things with this little snippet. Using jQuery, we're waiting until the document is fully loaded before applying onclick events to any <a> tags within the element with an ID of ‘promo-offers' (the div, in this case). Next, we're capturing the inner text of each of those hyperlinks, so that we have a unique label for each of our tagged links, in order to identify individual link clicks in Google Analytics later. Then we actually send the event to Google Analytics with our _gaq.push() call.

The final step is to introduce a short delay. The reason for this being that clicking an outbound link (or link to another onsite page) can sometimes load the destination page before the event has fired to Google Analytics. We're calling an arbitrary function (that simply bitshifts an integer zero one place right) until 250ms have elapsed. This is typically enough time, but feel free to test that for yourself and adapt it as necessary.

Selective rendering

The next benefit in this approach comes from being able to pick and choose which tags within your container you display on each page of your site. Most solutions allow you to define ‘rules' which dictate what URLs or circumstances render your tags. This means that in the case of our link tagging script above, we can define a rule so that the code is only served on our ‘promotions' page. Similarly, for other situations such as the earlier example of having contact form validation on your checkout pages, the irrelevant code no longer needs to be rendered as you can define a rule to say ”only write out the contact validation script on the contact page”. These rules provide simple but invaluable way to start shaving valuable seconds off your loading times on otherwise script-heavy sites.

This is a very basic example, but it should give you an inkling of the kind of quick, potent and centralised control you have at your fingertips when utilising container tags and a JavaScript toolkit.

Things to remember

One important aspect to keep in mind, and perhaps my only real caveat to using a container tag, is that server-side data isn't inherently available to you (remember these are JavaScript containers!). This can mean that for pages where you rely on server-side results, such as on a checkout receipt page when you want to fire your ecommerce tracking, you need to be careful with your solutions. Some platforms, such as DC Storm, allow you to allot ecommerce data to metric fields available for use with your tags, but the mechanics of these aspects varies between providers, so research your options before you rush into using a provider. You don't want to get to the last stage of your implementation and then find out something's not available for you to use, after all!

Overall, container tags provide a quick, powerful and centralised means for you to implement, manage and update your analytics configuration. If you aren't already using them then now is a great time to check out what's on offer and see for yourself how they can help you.