by Patrick Altoft on June 7, 2007
Since Google Analytics was launched in 2005 it has become one of the top analytics packages for small to medium sized websites. Growth was initially slow due to the frustrating waiting list system initiated by Google to avoid over stretching their servers. Now that the waiting list has been removed anybody can sign up to use this great service.
The user interface had a major redesign in May 2007 and a lot of the features we love have become hard to find. This guide should help you find your way around the new system.
I see a lot of comments on the forums asking whether Analytics can do X, Y and Z. In most cases it can do it but people just don’t realise it. As webmaster of several large sites I have been using GA for around a year now to track a huge number of variables. In this post I will go through a few of the more obscure interactions that GA can tack on your site.
Tracking exit clicks, banner clicks and RSS feed subscribers
Have you ever wanted to know how many people clicked on a particular link or banner on your site? You may wish to find out how many people click on an affiliate link, how many people from a certain country click on your banner advert or even the number of visitors from Digg that clicked to sign up to your RSS feed.
GA can track this for you quite easily by simply adding an onClick event to your hyperlink code.
<a href="http://www.example.co.uk" onClick="javascript:urchinTracker ('/outgoing/rssfeed'); ">
Every time somebody clicks on the link above GA will register a page view on the page www.yoursite.com/outgoing/rssfeed. To view the stats for the link you will need to follow the directions below:
In your GA account visit Content > Top Content and you will see the most popular pages on your site. Enter the term “outgoing” into the filter box as shown below and you will see a list of all the pages on your site with “outgoing” in the url. Normally this will just show exit clicks unless you happen to have real pages with “outgoing” as part of the url.
To drill down into the data simply click on the url you are interested in and you will see a snapshot of data like the image below.
(screenshot courtesy of Gas Fires Galore) If you want to drill down further by clicking on the “Segment:” drop down menu you can see details such as the source of the visitors, the keywords they were searching for and the landing page they arrived on.
This data is extremely valuable to webmasters who are not selling products. Sites selling products can measure ROI accurately by looking at the profits made on a particular sale compared to the cost of obtaining the visitor whether by SEO or Pay Per Click marketing. If you don’t sell products you need to place a value on other aspects of your site. How much are you willing to pay to acquire another blog subscriber? Was the $5000 you spent on link bait worthwhile?
All these actions can be tracked using the onClick event in Google Analytics.
More information at the Google Help Section.
How do I track downloads?
Downloads can be tracked again using the onClick event as above:
<a href="http://www.example.co.uk/files/map.pdf" onClick="javascript:urchinTracker ('/downloads/map'); ">
Tracking ecommerce revenue
Tracking where your visitors come from is very important. Tracking where your actual customers came from is even more important. If you knew that people searching for your keywords on MSN Live were twice as likely to buy your product as people searching on Google you can happily bid far more for your Adcenter clicks as your Adwords clicks.
Sales reports by traffic sources can be found under the “Traffic Sources > All Traffic Sources” section of the menu.
Before explaining how to track your transactions lets look at the data that GA can provide on this subject. These figures are for April 2007. Some details are blocked out for privacy reasons.
Lets drill down into the stats for Google (keywords removed):
From the chart above we can see that some keywords earn £31.52 per visit whereas some only earn £5.72 per visit. This data is hugely valuable as you can adjust your PPC bids on high and low paying keywords to maximise your profits.
GA also lets you drill down to see stats such as the number of people who bought product A after searching Google for Product B.
Now we know why we need to see these stats it makes the task of enabling the tracking slightly more appealing.
How to track Sales
To track your sales you will need to use some server side script on your confirmation page (the page people see after they complete a transaction on your site) to populate a form in the following format:
<body onLoad="javascript:__utmSetTrans()">
<form style="display:none;" name="utmform">
<textarea id="utmtrans">UTM:T|[order-id]|[affiliation]|
[total]|[tax]| [shipping]|[city]|[state]|[country] UTM:I|[order-id]|[sku/code]|[productname]|[category]|[price]|
[quantity] </textarea>
</form>
Example
UTM:T|34535|Main Store|111108.06|8467.06|10.00|San Diego|CA|USA
UTM:I|34535|XF-1024|Urchin T-Shirt|Shirts|11399.00|9
UTM:I|34535|CU-3424|Urchin Drink Holder|Accessories|20.00|2
Once you have populated the form GA will start tracking your sales right away.
The Google Help Section has a good reference guide for this topic.
Tracking 404 errors
Google Analytics makes the process of tracking your 404 errors fairly straightforward. Simply add the code below to your error page and GA will tell you the source of the traffic that is generating the error.
Make sure you replace the xxxxx-x with your GA account number!
<script type="text/javascript"
src="http://www.google-analytics.com/urchin.js">
</script>
<script type="text/javascript">
_uacct = "xxxxx-x";
urchinTracker("/404.html?page=" + _udl.pathname + _udl.search);
</script>
Compression is a simple, effective way to save bandwidth and speed up your site. I hesitated when recommending gzip compression when speeding up your javascript because of problems in older browsers.
But it’s 2007. Most of my traffic comes from modern browsers, and quite frankly, most of my users are fairly tech-savvy. I don’t want to slow everyone else down because somebody is chugging along on IE 4.0 on Windows 95. Google and Yahoo use gzip compression. A modern browser is needed to enjoy modern web content and modern web speed — so gzip encoding it is. Here’s how to set it up.
Wait, wait, wait: Why are we doing this?
Before we start I should explain what content encoding is. When you request a file like http://www.yahoo.com/index.html, your browser talks to a web server. The conversation goes a little like this:
1. Browser: Hey, GET me /index.html
2. Server: Ok, let me see if index.html is lying around…
3. Server: Found it! Here’s your response code (200 OK) and I’m sending the file.
4. Browser: 100KB? Ouch… waiting, waiting… ok, it’s loaded.
Of course, the actual headers and protocols are much more formal (monitor them with Live HTTP Headers if you’re so inclined).
But it worked, and you got your file.
So what’s the problem?
Well, the system works, but it’s not that efficient. 100KB is a lot of text, and frankly, HTML is redundant. Every <html>, <table> and <div> tag has a closing tag that’s almost the same. Words are repeated throughout the document. Any way you slice it, HTML (and its beefy cousin, XML) is not lean.
And what’s the plan when a file’s too big? Zip it!
If we could send a .zip file to the browser (index.html.zip) instead of plain old index.html, we’d save on bandwidth and download time. The browser could download the zipped file, extract it, and then show it to user, who’s in a good mood because the page loaded quickly. The browser-server conversation might look like this:
1. Browser: Hey, can I GET index.html? I’ll take a compressed version if you’ve got it.
2. Server: Let me find the file… yep, it’s here. And you’ll take a compressed version? Awesome.
3. Server: Ok, I’ve found index.html (200 OK), am zipping it and sending it over.
4. Browser: Great! It’s only 10KB. I’ll unzip it and show the user.
The formula is simple: Smaller file = faster download = happy user.
Don’t believe me? The HTML portion of the yahoo home page goes from 101kb to 15kb after compression:
The (not so) hairy details
The tricky part of this exchange is the browser and server knowing it’s ok to send a zipped file over. The agreement has two parts
- The browser sends a header telling the server it accepts compressed content (gzip and deflate are two compression schemes):
Accept-Encoding: gzip, deflate
- The server sends a response if the content is actually compressed:
Content-Encoding: gzip
If the server doesn’t send the content-encoding response header, it means the file is not compressed (the default on many servers). The “Accept-encoding” header is just a request by the browser, not a demand. If the server doesn’t want to send back compressed content, the browser has to make do with the heavy regular version.
Setting up the server
The “good news” is that we can’t control the browser. It either sends the Accept-encoding: gzip, deflate header or it doesn’t.
Our job is to configure the server so it returns zipped content if the browser can handle it, saving bandwidth for everyone (and giving us a happy user).
In Apache, enabling output compression is fairly straightforward. Add the following to your .htaccess file:
# compress all text & html:
AddOutputFilterByType DEFLATE text/html text/plain text/xml
# Or, compress certain file types by extension:
<Files *.html>
SetOutputFilter DEFLATE
</Files>
Apache actually has two compression options:
- mod_deflate is easier to set up and is standard.
- mod_gzip seems more powerful: you can pre-compress content.
Deflate is quick and works, so I use it; use mod_gzip if that floats your boat. In either case, Apache checks if the browser sent the “Accept-encoding” header and returns the compressed or regular version of the file. However, some older browsers may have trouble (more below) and there are special directives you can add to correct this.
If you can’t change your .htaccess file, you can use PHP to return compressed content. Give your HTML file a .php extension and add this code to the top:
In PHP:
<?php if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ob_start("ob_gzhandler"); else ob_start(); ?>
We check the “Accept-encoding” header and return a gzipped version of the file (otherwise the regular version). This is almost like building your own webserver (what fun!). But really, try to use Apache to compress your output if you can help it. You don’t want to monkey with your files.
Verify Your Compression
Once you’ve configured your server, check to make sure you’re actually serving up compressed content.
- Online: Use the online gzip test to check whether your page is compressed.
- In your browser: Use Web Developer Toolbar > Information > View Document Size (like I did for Yahoo, above) to see whether the page is compressed.
- View the headers: Use Live HTTP Headers to examine the response. Look for a line that says “Content-encoding: gzip”.
Be prepared to marvel at the results. The instacalc homepage shrunk from 36k to 10k, a 75% reduction in size.
Try Some Examples
I’ve set up some pages and a downloadable example:
- index.html – No explicit compression (on this server, I am using compression by default
). - index.htm – Explicitly compressed with Apache .htaccess using *.htm as a rule
- index.php – Explicitly compressed using the PHP header
Feel free to download the files, put them on your server and tweak the settings.
Caveats
As exciting as it may appear, HTTP Compression isn’t all fun and games. Here’s what to watch out for:
- Older browsers: Yes, some browsers still may have trouble with compressed content (they say they can accept it, but really they can’t). If your site absolutely must work with Netscape 1.0 on Windows 95, you may not want to use HTTP Compression. Apache mod_deflate has some rules to avoid compression for older browsers.
- Already-compressed content: Most images, music and videos are already compressed. Don’t waste time compressing them again. In fact, you probably only need to compress the “big 3″ (HTML, CSS and Javascript).
- CPU-load: Compressing content on-the-fly uses CPU time and saves bandwidth. Usually this is a great tradeoff given the speed of compression. There are ways to pre-compress static content and send over the compressed versions. This requires more configuration; even if it’s not possible, compressing output may still be a net win. Using CPU cycles for a faster user experience is well worth it, given the short attention spans on the web.
Enabling compression is one of the fastest ways to improve your site’s performance. Go forth, set it up, and let your users enjoy the benefits.
This article was taken with thanks from” BetterExplained Learn Right, Not Rote.”
http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/
For a web page to function properly, six essential tags must be present. The six tags must also be placed in specifice order as well and they form the basic ‘shell’ or ‘skeleton’ for any web page that you build. The six tags and their order is as follows (you have to memorize the tags and the order that they are placed in
In every HTML page, the words starting with < and ending with > are called HTML tags. These tags allow the web browser to display the web page properly.
Most HTML tags have two parts: an opening tag, to indicate where a piece of text begins, and a closing tag, to show where the piece of text ends. Closing tags start with a / (forward slash) just after the < symbol.
For example, the <body> tag tells the web browser where the actual body of text begins and the </body> indicates where it ends. Everything between the <body> and </body> tags will appear in the main display area of hte web browser window.
Until 1990, accessing information through the Internet was very technical. It was so hard that even 
physicists were often frustrated when trying to exchange information. One such physicist, the now famous Tim Berners Lee, created a way to cross-reference text on the Internet through ‘hypertext‘ links. His new Hypertext Markup Language (HTML) become a pillar of the Internet. The term hypertext refers to text stored in electronic form with cross-reference links between pages. HTML is the language for describing how pages of text, graphics and other information are organized, formatted and linked together.
By 1993, almost 100 computers throughout the world were equipped to serve up HTML pages. 
Those interlinked pages were called the World Wide Web (WWW) and several web browser programs had been written to allow people to view Web pages. One of the programmers to develop a browser was Marc Andreesen who later became rich and famous for his creation of Netscape Navigator (which is now the world’s most popular web browser.)
In short, HTML is everywhere. There are four versions of HTML that have been developed over the years and I will use the 4.0 version to reference in this blog.
