Do you like it on the top or on the bottom?

Web Analytics Tag Top Bottom

Top or Bottom?

This is a question I get asked a lot?  Do you like it on the top or the bottom?

We’re talking web analytics tag code placement obviously.  And just like the sexual innuendo, it depend on who I’m working with.

Bounce Rate

Until recently the argument for the bottom was easy.  The web analytics tag belonged on the bottom of the page because I didn’t want to count the visitor unless the entire page loaded.  If they bailed before then, then I didn’t consider them a bounce.  I classified them as mistake, a typo a fat finger misclick.  Placing the web analytics tag on the top would muddy that metric.

Page Load Speed

My other reason is related to page load speed.  Even though most web analytics tags are fairly light, I wanted to delay their load until the very end.  Placing it on the bottom makes for a better visitor experience and follows SEO best practices for page load speed.

But with Google Analytics recent release of their asynchronous code snippet that second reason no longer applies.  You can now place your web analytics tag at the top of the page and not worry about its impact on page load speed because it will load in parallel the main content of your page.

I still like it on the bottom.

My first reason still holds.  I track bounce rates and have a personal definition of what a bounce is and isn’t.  To me, therefore, the page has to fully load before I’ll consider it a true pageview.

So tell me, do you like it on top or on the bottom?

Do you have a compelling reason for me to move the web analytics tag to the top of the page?

Let me know in the comments.

How to Implement _trackPageview() with Google Analytics new Asynchronous Tab

Tracking pageviews in Google Analytics
If you are planning your migration to the new asynchronous Google Analytics tag then you probably need to migrate your override of the _trackPageview() code you set up using the old non-asynchronous code.

Or perhaps you migrated your web analytics already and just realized that you didn’t code your new Google Analytics tag correctly.  Either way, here’s your answer.

Old code sample: Synchronous

var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);
document.write(unescape(“%3Cscript src='” + gaJsHost + “’ type=’text/javascript’%3E%3C/script%3E”));

var pageTracker = _gat._getTracker(“UA-1111111-11”);


New code sample: Asynchronous

var _gaq = _gaq || [];
_gaq.push([‘_setAccount’, ‘UA-1136567-11’]);
_gaq.push([‘_trackPageview’, ‘/landingpages/goal1.html’]);   (function() {
var ga = document.createElement(‘script’); ga.type = ‘text/javascript’; ga.async = true;
ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl&#8217; : ‘http://www&#8217;) + ‘’;
var s = document.getElementsByTagName(‘script’)[0]; s.parentNode.insertBefore(ga, s);

Why override your trackPageview?

If you don’t change the default _trackPageview()command then the page recorded into your Google Analytics reports will be the fully-qualified URL of the page with the tag.  This is usually fine for most implementations.  But there are times when you need to control the page name being logged.

Why do people override page name

  • Dynamic pages

Depending on your website’s technology, some pages (or the code that implements them) may show the same URL even though the pages are logically different and distinct to the website visitor.  In those cases you need to have your webserver also assign a unique page name to each of the logical instances.

  • Goal/thank you page

When you use goals you sometimes come across the need to define the goal in Google Analytics in advance of knowing the fully-qualified URL.  Thus you need to pre-define the URL and have the web page assign it regardless of the where the page eventually resides.

I’d be interested in your experience with _trackPageview().

  • Why do you use it over the default URL method?
  • Are there any other gotchas migrating to the new Google Analytics asynchronous tag?