I was having a stimulating conversation with Maxime, our Technical Web analytics Specialist (in-training).
It’s a technical debate but it fits clearly in our role as Web Analytics education provider.
- Manual insertion of the tag
- Automatic insertion of the tag via a scripting stack, CMS or other Web application package
- Automatic insertion of the tag by means of a server-based mechanism
Before we go any further, let’s go over the basic tagging implementation types:
Regular – header
PROs: Easy to implement; ensures traffic collection before page content is finished loading
- Can (and will) stop page loading until tagging code is finished loading/executing, a major frustration generator
- Collects traffic info right away and misses out on user interaction
- Has a tendency to mess up your layout if placed inadvertently in the general ‘header’ section of the page but right after the BODY tag opens (“the unsightly pixel that broke my design”)
Regular – footer
PROs: Easy to implement; captures traffic after page is fully loaded
CONs: you can miss out on user interaction, with base code that’s supposed to be in the header and feeds on usability information generated by user interaction (AJAX, Flash, custom clicks…)
PROs: Extensive data collection, a reliable tracking method
CONs: More difficult to implement
On to the tagging implementation scenarii!
Manual tag insertion, a.k.a ‘touching the pages’
In this scenario, it’s just you, the tag provided by your vendor and your favorite Web page editor. That’s where you get to manually modify your web pages very much like any ‘webmaster’ does.
How it’s done
- Copy/paste code into your HTML base code
- Save/upload the modified file
- Verify page source and data collection after changes
- And you’re set!
- Fairly straight-forward procedure.
- Can be semi-automated with a script or a text editor that supports find/replace operations across multiple files
- Can be very time and resource consuming, especially in the case of deep variable tagging
- You usually end up missing pages. Build a detailed site map before you go on with manual tagging!
Automatic insertion of tag via script, CMS, web application
This is usually done using your favorite package. Scripting stacks include a scripting language plus a development framework but we’re not going to list them all here 😀
CMS packages usually allow for HTML template modifications in which to store your tag but you usually require additional coding for advanced variable tagging, especially in the case of split tagging. See my previous post on the subject (in French).
On that note, our own OniSystem CMS has WebAnalytics built-in 😉
How it’s done
- Locate ideal spot (header/footer) in corresponding template
- Insert tag code or instructions to output said code in your template
- Call your script, generate the page or any other action to take change into account
- Visit page and verify page source & data collection
- Once it’s set up, you don’t have to worry about it, as the dynamic scripting engine of your choice will always insert your tag.
- Ideal for split tagging by defining tagging zones for both header and footer.
- Difficult to manage for daily operations and quick changes
- Usually lacks proper interface although very few open source CMS now offer modules for integrated Google Analytics or WebTrends tagging
Automatic insertion of the tag by the server
Server-side inclusion/injection is when the Web server software itself (not the applications hosted on it) tampers with the web page’s content before it is served, very much in the same way your corporate e-mail server inserts a legal/disclaimer notice at the end of every email you send.
This is where Maxime brought valuable input when he confessed to modifying his Apache server library files to automatically insert Google Analytics tags to every single page served by Apache. For those of you not in the know, Apache is an open source Web (HTTP) server that powers overs 65% of all Web servers worldwide.
How it’s done
- Look at your server’s configuration files and check which files influence the pages’ final output before they’re served.
- Add a directive (instruction) to insert your tag at a location of your choice
- Restart your server
- And you’re set!
- One shot-operation, ideal for sites with very basic tagging needs
- Performance: your Web server is designed to serve Web pages that are either static files or dynamic content.
With static files, there is no performance impact other than file size.
With dynamic content the server relies on other applications and assets to build the page.
Server-side inclusion adds a performance burden where a scripting language could do the job much more efficiently and, most of all, in a scalable fashion if need be.
- Accuracy: exact tag placement in the page depends heavily on the page’s content compliance with X/HTML coding standards.
- Redundancy: that method adds the tag to every single page served, additional filters notwithstanding. This can lead to an over estimation of traffic, especially in the case of sites built around framesets (sic), in which case every single page in the frameset is counted.
There you have it, folks. This pretty much covers tag-based Web analytics implementations.
As you can judge from the different evaluations, you can have regular or split tagging but you’re better off with dynamic pages instead of manual work or server side includes. Don’t get me wrong, manual or server-side inclusions can work for you but should be reserved for sites with limited content and traffic.
At any rate, this post should further illustrate the need for a deep reflection on your Web Analytics strategy prior to choosing a Web Analytics tool, a Web application platform or CMS or even choosing a hosting solution.