On tag placement and related mechanisms…


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.

When it comes to implementing a Javascript, tagging-based, Web Analytics solution, we are usually faced with one of three scenarii:

  • 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

the Javascript code for the tag is placed within the HEAD tag of the rendered HTML document.

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

the Javascript code for the tag is placed at the very bottom of the rendered HTML document, right before the end of the BODY tag.

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…)

Split tagging

base Javascript code in the HEAD section of the page implements some code logic and variables and code placed in the footer (before </BODY> tag) captures extended traffic information based on base code and user interaction.

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

  1. Copy/paste code into your HTML base code
  2. Adapt Javascript variables
  3. Save/upload the modified file
  4. Verify page source and data collection after changes
  5. 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

  1. Locate ideal spot (header/footer) in corresponding template
  2. Insert tag code or instructions to output said code in your template
  3. Call your script, generate the page or any other action to take change into account
  4. Visit page and verify page source & data collection
  5. Done.


  • 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

  1. Look at your server’s configuration files and check which files influence the pages’ final output before they’re served.
  2. Add a directive (instruction) to insert your tag at a location of your choice
  3. Restart your server
  4. 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.

3 Responses to “On tag placement and related mechanisms…”

  1. Dennis R. Mortensen Says:

    Hi Julien, 🙂

    Super post. This is something we, as you, work with on a daily basis. However; I do agree from a technical point of view that several options are available, but I find it un-realistic on an enterprise level to deploy Web Analytics “automatically”. Most Enterprise systems today have in the range of 50 to 100 variables and most of these is debated and “set” through standard business requirements consulting. Half the variables need again to be either inflated on-the-fly or even amended based on users actions.

    I think the future (as you indicate yourself) is more in the line of REAL integration in between CMS and Analytics packages. – way beyond fiddling with templates though.

    Again; really good post Julien!

    Dennis R. Mortensen, COO at IndexTools

    My Analytics blog

  2. Michael Notte Says:

    Hi Julien.

    Interesting post. On our side, we’ve “integrated” WebTrends tagging in our CMS platform for more than two years now. Javascript code is automatically added whenever a page is published from the CMS. We use the “footer” solution – mainly for performance and prevent potential display problems.

    We also integrated “logic” rules for the META tags in order to reduce manual definition as much as possible while offering flexibility. For example META tags are based on the templates used, META data fields from the CMS content (page title, section title,…), inheritance mechanisms… Still it offers possibility to override default rules for special cases.

    Of course, it has its limitations: we limited the number of tag used in our pages and we can’t no simply add any specific or new tags without extra development. But in our context, we opted for compromise. We also try to do constant improvements to our tagging mechanism – step by step.



  3. Julien Coquet Says:

    Thanks Dennis, Michael,

    I think both your comments point to the limitations of tagging automation in an enterprise context.

    However, it is refreshing to see some CMS editors take that paradigm into account and modify their tools, products and services to accomodate for their Web analytics needs.

    Again, this brings more water to my closing statements: go through the reflection process, structure your site and your content based on your business needs and mirror your Web Analytics tags.



Comments are closed.

%d bloggers like this: