Note that this all pertains to the newer Google Analytics methods. The older version used the same cookies and saved mostly the same information, however there are some minor differences. The way to tell if your site (or someone else's for that matter) is using the new Google Analytics code or the older legacy code is to review the HTML source of a page containing GoAn code and look at the file being called. A reference to "urchin.js" means the site is using the older legacy code. A reference to "ga.js" means it's using the newer code.

First the cookies. As a general rule GoAn sets four cookies on the users machine. Their names are: __utma, __utmb, __utmc and __utmz. There's a possibility of more cookies, depending upon how the webmaster has things set up --such as the __utmv cookie-- but 99% of the time you'll see just the four main ones.

Here are the dirty details of what each does and the information it saves to the users computer, best I can tell.

__utma - utma is the main cookie that saves all kinds of interesting information. The interesting thing about this cookie is the massive amount of really pertinent data it saves in such a small package. This info will look like a bunch of goobly-gook numbers until you understand what they mean.

The cookie contents typically looks like:

XXXX.RRRR.FFFF.PPPP.CCCC.N

Where...

XXXX = A domain hash. A domain hash is simply a group of numbers that relates directly back to the domain name of a site. Think of it as a sort of numerical representation of your domain name.

RRRR = A random number the GoAn script generates to be used as a Unique ID for each visitor.

FFFF = A timestamp of the first visit/session for the user. Or in English, the time someone first hit the site. As a note, all of these timestamps are in the same format you'd give if you ran a php date('U'); call. They're not in the date format we humans are used to seeing, but they're just as effective.

PPPP = A timestamp of the Previous visit by the user. Or the date and time the user last visited your site.

CCCC = The current time, in the same timestamp format as the previous two.

N = The number of visitor Sessions the user has had since their first visit. This number gets incremented by 1 each time the returning visitor starts a new Session.

As you can see, there is a lot of potentially very useful information in this one cookie.

Essentially the utma cookie is what is known as a Persistent cookie. Its expiration date is set out to two years in the future on the first visit, and the expiration date is moved out to two years in the future on each subsequent visit. So if a visitor doesn't let two years pass between visits, you'd still be able to tell the first time they visited your site, the last time they visited your site, the time of their current visit and the number of times they've visited. This would be some good information to know for all kinds of reasons, especially if you're doing any sort of conversion testing. Or tracking visitor loyalty.

Some of the above stay pretty much constant throughout, from the first time the cookie is set to the last visit. Others get updated with each visit. Those that stay the same are the Domain Hash (XXXX), Random ID (RRRR) and Time of First Visit (FFFF). Those that get updated and changed are the Time of the Previous Visit/Session (PPPP), Current Time (CCCC) and the Number of Visits/Sessions (N).

__utmb - utmb is one of two cookies that work together to record information about what happened during the current visit or session. Including the ability to tell when a session ends. This is a cookie that has been changed pretty significantly between the older legacy version of GoAn and the newer version. (The old version simply saved the Domain Hash and nothing else.) The info it saves now looks like:

XXXX.P.10.C

Where...

XXXX = The Domain Hash.

P = Pages of the site viewed this session.

C = A timestamp of the Current Time.

I'm not 100% sure what the "10" in there does, but every one of the dozen or so sites I looked at that had the new GoAn installed all had the number 10 in the third octet. In looking at what's in the ga.js file it looks like this part is going to be utilized at some point in the future to perform automated off-site click tracking, but at this time it's not something that's reported in GoAn.

Again, we've got some useful information. Especially that part where it records the number of pages you have viewed this Session.

This cookie sets itself to expire in 30 minutes, but it's 30 minutes from the time you loaded the last page you viewed. Meaning if you hit a GoAn enabled site, view a page for a couple of minutes, then move to another page of the same site you're going to see two things happen to the cookie. First the Pages This Session (P) value is going to be incremented by one (FTR it gets incremented if you reload the same page, so it technically isn't a Pages Viewed count) and the Created and Expires details are going to get updated to start the 30 minute clock ticking again.

Why 30 minutes? Well, some browsers (some versions of IE notably) don't correctly erase a Session cookie like they should. So the 30 minute timer works pretty well. It gives a user plenty of time to move on to a new page, but ends the session in 30 minutes if nothing happens.

utmb in conjunction with utmc is what GoAn used to determine things like time on page, pages visited per session, how long a session lasts on average, etc.

__utmc - utmc is a true Session cookie, meaning it is one that expires at the end of the current session/visit. If you navigate away from the site or close your browser it should be automatically deleted, if the browser does what it's supposed to do.

As mentioned above, it's utlized with the "b" cookie, with its main function being to tell how long a session or visit lasted. It is not overwritten once a session starts, so by looking at the Created timestamp and the current time one can in theory tell how long a visitor has been on a given site.

The only info in utmc's content is the Domain Hash.

__utmz - utmz is another of those powerhouse cookies, one that saves a lot of information that can be quite useful. The treasure trove of info it saves relates to how a user arrived at a site. The channel though which they came, date/time info and even what keywords they used if they arrived via a search engine.

Its content normally looks something like:

XXXX.TTTT.V.S.utmcsr{source}|utmccn{campaign}|utmcmd{medium}|utmctr{keyword}

Where...

XXXX = The Domain Hash.

TTTT = The timestamp of when the cookie was last set.

V = How many visitor sessions there have been in total. (should be the same as the final number in the "a" cookie in theory.)

C = Via how many different sources or channels this user has arrived at the site. In other words, if a user searched at Google and found your site one time, then searched at Live or Yahoo another time and clicked through, this number should increment. In theory this number should also increment if one time a user clicked on your Organic search ranking in Google and a second time clicked on an Adwords ad you had running on Google.

utmcsr = The source of the last time the cookie was updated. So if someone searched and found your site on Google here it would say utmcsr=google

utmccn = Campaign information. This is really there for Adwords types of situations. If you tag your campaign with an identifier it'll show up here in the cookie. If it's just a normal search hit it should say utmccn=(organic)

utmcmd = Medium. But not as in Large, Medium and Small. Their Medium is more really more channel information. So if a hit comes from a normal, non-paid search it'll show utmcmd=organic

utmctr = The keyword phrase someone typed into the search engine. Really useful this one, however remember it shows the last search data, not how someone originally found you.

The utmz cookie gets set with a lifetime of six months into the future, and gets its expiration date updated with each time the cookie is updated. This can be a bit misleading though. The important thing to remember about this particular cookie is it doesn't necessarily get updated with each and every visit. For normal visitors it pretty much does, but if you're checking your own site and its cookies you may see some sightly odd information updates.

So those are the four main cookies that get set by Google Analyzer, what they do and what information they contain. A fifth one, and one I don't see often, is the __utmv cookie. This one is known as a Custom Segmentation cookie and is one that requires the webmaster to have configured their GoAn via --utmSetVar() to track some special data. I see it rarely. In fact I think I've seen it exactly twice.

Thanks for the heads up Ed !

While I had the tool down to bring it up to date, I decided to do a total rewrite of the back end code, adding a couple of features that had been requested. No time like the present, as the say.

So the tool still does the same basic thing. It allows you to enter a keyword phrase that it then uses to grab the Top 10 ranked sites for said phrase on whichever of the three major search engines you choose to query. It then uses Yahoo's API to grab backlink data for each of these top ranking sites, sorting and ordering it so that you can see which other sites link to two or more of the top ranking sites.

The idea being to give you a heads up regarding some sites you may want to approach to obtain links to your site. Hopefully links from sites that are already considered to be trusted and authoritative by the search engines.

The concept is pretty simple actually. Gathering, ordering and sorting all of the data is a bit more complicated. Almost impossible to do by hand in fact. Hence the reason I built the Common Links tool in the first place.

New additionals to this updated version of Common Links include:

1. The ability to manually insert your own site into the results table, even if it doesn't currently rank in the Top 10 on a certain engine. This feature was requested and I decided to add it into the mix since it can give you a quick visual reference to how your site stacks up against the top ranking sites.

The format you use when entering an Additional Site isn't all that important since I've added some checking into the back end code. You can use the http:// address, the www.domain.com address or even the hostname like domain.com. The tool will handle all of the above.

The tool also automatically checks for duplicate entries, which for the purposes of the tool means the same domain name. So if there are two listings for two pages of the same domain, the tool will automatically strip out the dupe and show the domain only one time. This applies for Additional Sites too. If you manually enter your site and it's already in the Top 10, it'll still only show up once.

Also, it's important to remember Additional Sites will always show up in position #1 in the tool. For our purposes the numbers aren't really the ranking of the sites, though it is if you do not enter an Additional Site. For the tool the numbers are used simply as a reference, not the ranking.

2. I've also added the ability to select whether you want the tool to report on backlinks to the specific page that ranks well, or show every link to the domain regardless of which page it links to. Personally I find the Domain choice gives me a lot better information, but a couple of people have asked for the ability to check backlinks to a specific page. So it's there now.

A couple of notable things to remember...

Sometimes you'll have a phrase that says only 8 or 9 sites were returned as being Top 10 sites. This happens because of the automatic pruning of dupes I mentioned above. Meaning if a certain keyword phrase in a certain search engine has two pages from one site showing in one of those indented listings, it's only going to show up once in the tool. This is done to eliminate needless queries for backlink data for the same domain multiple times.

Also, remember that this tool uses API licenses with each of the three major engines to gather its information. I've always been of the mind that it's a good thing to be a responsible Netizen, so I won't do any scraping, search engine or otherwise. A potential downside to this stance is that occasionally one or the other API licenses will max out its daily usage limits as set by the search engines. For Google that's 1,000 per day, for Yahoo and MSN/Live it's considerably more. And of course they Yahoo API gets a lot more use in this tool because that's the API that does most of the heavy lifting.

So if you get an Error, especially a 403 error, it typically means my license for a particular engine has hit its limit for the day. If you simply wait a day these issues should correct themselves.

I don't regularly monitor the use of this or other API tools I've developed, so I don't see when this happens 9 times out of 10. If you run into a problem where day after day you can't get the tool to work for you, let me know and I'll look into it. If I find someone abusing the free tool with automatic queries or overuse I'll simply cut off their access so they don't adversely affect anybody else.

That's it! Enjoy the new tool.

One particularly maddening thing with my switch to XP x64 was that while Acrobat (version 7 in my case) installed and worked for the most part, it did so as a WoW enabled 32 bit application. This means it doesn't work as a browser plug in for the 64 bit version of IE7, which isn't a huge deal. It just opens PDF's in an Acrobat window instead, which is fine by me. Better in most cases actually.

The thing that was maddening is that the ability to pen something in Word or any other application then save it as a PDF failed to work on an x64 system. The issue is the print drivers (and a PDF Port) being unable to be installed by Acrobat on an x64 system. This situation still continues today, though there is a rumor that Adobe might finally be fixing the problem by making Acrobat 9 x64 capable. I have no clue on that one since I'm not about to pay that much to upgrade just for something this silly. I'd sooner dump Acrobat and use CutePDF, PDF Creator or a host of other options out there that are either completely free or very low cost. Which is why it makes no sense to me that Adobe allowed this to go on so long.

There is something of a workaround I've set up for now on my system, though I personally think it's silly to have to make it a two-step process. This works okay for me since I really don't need to convert that many documents myself. In case you're in the same boat I am, here's how I did it and got it to work.

First, you'll need to install a Postscript printer driver. Note that this doesn't have to actually be a printer you have attached to your computer since it's going to be a virtual printer for our purposes. To do this go into your Control Panel (Start > Settings > Control Panel if you're using the Classic Windows start menu like me, or Start > Control Panel if you're using the newer start menu) and select the Printers and Faxes icon.

There select the Add Printer icon.

In the Add Printer Wizard select Local printer attached to this computer and make sure the Automatically detect option is NOT selected.

In the next window choose FILE: (Print to File) form the Use the following port dropdown list. We're doing this here so that we don't have to remember to choose Print To File each time we go to save a document.

In the Printer Software window select HP from the Manufacturer box and HP Color LaserJet 8500 PS from the Printers box. The PS is important, since we want it to use Postscript.

It would be wise for you to select No to the Default Printer question. This is just a virtual printer after all.

That's it, you're done with the driver set up. Well I did go back into the Printers and Faxes window, right clicked on the new 8500 PS printer listed there and renamed it to be Adobe PDF so that I'd know what it was.

Now when you're in Word or whatever and want to convert the document to PDF format instead of clicking on the Acrobat stuff up to, select File > Print and select your Adobe PDF printer. If you didn't set the Port to FILE: you'll need to make sure to select Print to file before clicking OK. If you set it up as above you shouldn't have to remember to do this each time.

This will open a Print To File window. Change the .prn to All Files if it's automatically selected and name your file with whatever file name you want along with a .ps extension.

Lastly back in Acrobat choose Create PDF, then From File and select your .ps file. Now it should be converted to pdf format, ready to be saved.

Like I said above, the two-step process would be a pain if you had to do this often. If that is the case you should probably check out some of the x64 enabled options for PDF creation I mentioned earlier. But for those like me who do this rarely, it works at least.

The new Google All In Title tool uses their old SOAP API of course. I'm not about to release a tool into the wild that scrapes their results like some others seem to do all too often. If you have one of the old SOAP API license keys please plug it into the tool so that the queries will count against it. If you don't have one you can't get one anymore, so the tool will attempt to my Google SOAP API key.

Remember though, Google API licenses are limited to 1,000 queries per day and mine gets used by a few tools when someone else doesn't have one. So if the tool errors out it's probably simply that the license queries are used up for the day. Be nice if you have a license key. Use your own so that others who can't get a license anymore can get the data they want by using mine.

The tool is pretty self explanatory. Simply put a semi-colon after each keyword phrase so that the tool knows where one ends and the next begins. And after you've run you're query download the CSV file of your query to refer back to later, rather than having to run your phrases through the tool again later.

Enjoy!

So, rather than have people guess (which is never a good idea!) I've php'ized a little tool I derived from my own internal conversion testing system and put it up on the site. It's here: Conversion Confidence Tool

This is basically the flip side of the Conversion Pre-Test Tool that tries to estimate how much traffic you'll need and how long it'll take to successfully complete a given test. The Pre-Test Tool is used before you start a test, and provides Best Guess information.

The Conversion Confidence Tool on the other hand is used after your test is done, where you enter in the real conversions and impressions data from your test, then it takes this data and runs it through several mathematical equations to tell you which treatment won the test, what the conversion rate on each was and how much Confidence you should have in the results being conclusive and repeatable.

I've also added a link to each of the tools to the main navigation to the left. Dunno why I hadn't done that with the Pre-Test Tool before...

Enjoy!

Technically speaking, Windows XP Pro will tell you that it supports up to 4 gigs of RAM. However even if you stick in only 4 gigs if RAM, which is not all that out of line in these days of high end graphic applications, Windows will keep you from using that last gig. They set that aside for PCI, without ever looking to see if your PCI cards have their own onboard memory.

It's silly. But I think I understand way. My guess is that with the networking capabilities of XP Pro they're afraid people will buy it and use it to run servers instead of running a true Server version of Microsoft software. Whatever the reason, I think it's silly. Bordering on stupid.

So I decided to take on trying to install XP Pro x64, which has a maximum supported RAM figure of a whopping 128 gigs. (I'm not even going to try to explain that one. Makes no sense at all!)

I did have a choice of trying to move to Vista x64, which might be wise since XP is bound to be coming up on its EOL or End of Life cycle. But I've heard enough bad things about Vista that I don't want to make that leap. At least not with my main computer.

So... To make sure I was reasonably ready I had a new motherboard installed in my computer (the old one would only handle up to 4 gigs and I wanted more) and purchased another couple of 2 gig ram sticks that matched up with my other ram sticks.

The issue with changing things to x64 is the general lack of driver support for hardware. It's not that widely used yet so finding the right drivers can be troublesome according to everything I'd read and heard.

I got lucky in this because I was putting in a new Intel (model DG965SS) motherboard, and Intel does have x64 driver support. Other than this one rather major item, the only other things I had to sort out were drivers for my ATI x1300 Dual Monitor graphics card and my Linksys Wireless-G ethernet card.

The ATI card was a piece of cake. They also had an x64 driver set available. The only issue I ran into when installing it was that the default .NET version on my XP Pro x64 disk wasn't up to snuff with what ATI wanted. Quick fix on that one, assuming one could get internet connectivity.

The Linksys Wireless-G ethernet driver was a bit more challenging. I couldn't find where Linksys has 64 bit drivers at all. But lo and behold I figured out that Linksys uses either Broadcom or Ralink drivers for my version of the wireless ethernet card, depending upon when it was manufactured. Mine was a Ralink chipset, but it wouldn't have mattered since both Ralink and Broadcom provide 64 bit drivers for these cards.

I had done most of my research before I started, so didn't have too many unexpected problems. In all it took me about 24 hours between other work to get the x64 sorted and running. The way I did it was to install XP Pro x64, then installed all of the Intel updates that I'd previously downloaded (with crappy graphics since I didn't have the ATI stuff installed yet), the moved on to the ATI card drivers I'd already downloaded and lastly the NIC card drivers from Ralink.

After all of that was done I let the computer do its upgrades from Microsoft, rebooting and re-updating after each one until there were no more critical or necessary updates waiting for me. Seriously, in my case it was all pretty painless, though others have told horror stories. I would imagine preparation was 99% of the reason I had an easier time of it.

The other thing that probably made it easier for me was in how I was doing the upgrade, or really testing things. You see I have SATA hard drives in the computer now, which was one of the side advantages of replacing my motherboard. Unlike IDE hard drives where you have to set the switches to tell the computer which is the master and which is the slave, with SATA you simply hook 'em up and go. Then you can go into your BIOS and set the boot order.

So while I may call it a dual boot system, it's not in the traditional sense. Instead I have two totally different systems, with XP Pro (32 bit) installed on one 250 gig Western Digital drive and XP Pro x64 installed on a separate 250 gig Western Digital drive. I can toggle back and forth between which boots by making a quick change in my BIOS boot order.

If you can do it this way I'd definitely suggest doing it this way. Not only does this approach save you some heartache when you need to go back to x32 to grab another driver like I had to, since they're completely separate you don't have to worry nearly as much about messing something up.

At the end of the day the only things I couldn't get working properly were an older version of Acronis' True Image backup software (I had version 8 from a year or so back) that simply doesn't support x64 at all. However for a $30 upgrade I moved up a couple of versions and it's now supported. According to their docs Acronis started supporting 64 bit apps during their version 9. I just upgraded to 10 to be sure.

The only thing I never got working at all was Computer Associates Anti-Virus suite. They tell me they don't have a solution currently, period end of discussion. I saw some posts in various places about disabling Floppy scanning in CA/AV, but that didn't work for me. I still couldn't get realtime scanning to work. Support told me they had no solution to the problem.

No biggie. I've got multiple computers and a multi-computer license with CA, so the license can always be used somewhere. And Avast! has a 64 bit version of their anti-virus software that works just fine for me.

All of my other software worked just fine in x64. This includes Office, Powerpoint, Excel, PhotoImpact, PhotoShop, Acrobat Pro, Putty my SSH software to talk to the servers, WSFTP, etc, etc. They all work flawlessly, I suspect because of x64's WOW module that runs 32 bit apps.

I did have to also make a couple of small registry tweaks to get x64 working as well as I thought it should with 6 gigs of RAM, however I'm not sure if those were because of my specific system configuration or if it's a general thing everyone should do. The only time I noticed a problem was after XP came back from being in screensaver mode, so my performance improvement may have come from me simply changing some configs so that nothing goes into standby or hibernation when the screen saver is activated.

In any event if you try this and need the registry tweaks you can find the same documents I used by searching Google for something like "speed up xp x64"

Next up, I'm going to be playing with installing a Desktop Linux OS on a third drive. Hey, I have 4 SATA ports on the motherboard and want to test one against the other in my everyday working environment. And hard drives are cheap these days. So I'm going to keep them all separate.

I think I'm going to try Ubuntu Linux, but my first (quick) attempts have run into problems. Ubuntu doesn't even want to fully install on my system, so something is throwing it for a loop. I'm not sure if that's my graphics card (the ATI is supposedly a problem child with Ubuntu), my Wireless ethernet card or something else. I mention the wireless card because Ubuntu looks for network stuff during it's initial setup. But because my wireless network is WEP password protected it'll never be able to connect to the network until I can give it a keyphrase, which it never does during the install. I'm not even positive that it's detecting the wireles card though. It may be looking for a network via the wired cat5 port on my motherboard.

Anyway, that'll be next up. I haven't had much time to dig into it yet. Just tried a couple of quick installs and they failed.

If I get it working though it'll be a good thing. I'll be able to compare the performance of one OS against another easily since they'll each be fully enclosed on their own hard drive, and I'll be able to swtich back and forth pretty easily via BIOS. Though I must admit I can't recall of anybody ever having a Tri-boot system before. LOL

Until next time...

I made it mainly for those who need to figure out which encoded characters mean what when needing to account for them in rewrites. I don't know about others, but I get tired of having to look at ASCII conversion tables to figure out what an encoded character string means, so this tool will come in handy for yours truly. Regardless of why I made it, the tool will work just fine for lots of different things having to do with encoding or decoding urls.

There's a link to the new tool in the "links" nav menu to the left under URL Encoder/Decoder, or you can simply click here to go to the new tool.

Enjoy!

One way to accomplish the task on an IIS server is to install ISAPI Filters. The ISAPI Dyanmic Link Library functions much the same .htaccess does in an Apache environment, to the point that many .htaccess rewrite syntax can be used without alteration in ISAPI.

The main issue with ISAPI being that unlike .htaccess many ISAPI extensions are going to cost you real money. Since ISAPI runs as an application on IIS there is often a cost involved for the webmaster in order to utilize them. The other issue being that if you're on a shared IIS server you often won't have enough control to install ISAPI filters yourself. And many hosts balk at installing them for reasons of their own.

A classic catch-22 situation.

Just because you're on an IIS server doesn't necessarily mean you cannot employ rewrites and redirects though. Though I don't dabble in IIS rewrites personally, Chris Hirst --who I hang out with over at the HR Forums-- is an IIS guru and has come up with several differnt ways one can accomplish what I do with .htaccess on IIS servers. For completeness, here are some links to his ideas.

Tweaking the Application Mappings in IIS - This will allow you to have pages with one extension treated as if they were files carrying another extension. So if you need .htm pages to be parsed as if they were .asp, this is the one you'll want.

Handling www/non-www issues in ASP - This snippet of code is something Chris developed to deal with www and non-www requests when you have a .asp site. It is code that is run at the Script or File level, but is dynamic. One note: The original code Chris posted in reply #4 does not account for variables in the URL string. If you have a dynamic ASP site that needs help with www/non-www issues, look a bit farther along in the thread. In post 22 on page 2 Chris provides a code snippet that will take care of query strings.

Using a Smart 404 Page - A Smart 404 is basically a method you can use when you have pages that are changing location and you want to make sure the link pop the old page had accrued gets passed along to the new page. What happens is everyone (spiders included) initially gets sent to the custom 404 page when they request a file that no longer exists. Then the custom (smart) 404 runs through a small bit of code to decide if it should really deliver a 404 Not Found response or if it should instead deliver a 301 Moved Permanently response, sending the visitor on to the correct page. This can be very, very effective regardless of the extension your site files use, because you can always set your IIS server to display an asp file as your custom, smart 404 page. All it requires is that you enter your page uri's (relative path from root) at the top of the code. The script then does all of the heavy lifting for you.

If the above references do not address your specific situation or if you have an IIS redirect problem that you can't sort out, by all means feel free to post your question in the Technology & Coding > Redirects portion of High Rankings Forum and someone will be by to help you sort it out.

This project was a dress site that had recently been migrated to the x-cart platform. There were some 6,000+ dress styles by different designers, with each dress having somewhere in the neighborhood of 20 variants when you looked at the different sizees and colors that might be available. This site was somewhat unusual in that all items are available to be ordered, whether they are in stock or not. In stock being in stock and everything else being special order.

The way x-cart is coded this meant that every time one of the thousands of product pages was hit by a surfer or bot the backend code would have to roll through over 600,000 lines in the database in order to see which variants were In Stock and which were Special Order. As you might imagine, having this happen on every single product page ended up eating server resources pretty quickly. Especially when you're talking about a site that gets over 10,000 unique visits per day and pretty much every visitor is going to be hitting mulitple product pages.

We'd already done all of the normal things to help speed up x-cart, like disabling statistics, enabling zlib compression, using the html catalog feature, enabling template caching, etc. They helped a some, but it wasn't nearly enough. We went even farther by off-loading the database to a separate dedicated MySQL server, and while it helped a good bit this still didn't solve the load issue entirely. There were still spikes during extremely high traffic times that slowed things to a crawl.

After reviewing the situation I decided there were probably two things still giving us problems. One being that the queries to show what was in stock and what wasn't for a particular product was simply inefficient. The second being that because the query was inefficient and taking too long to complete, people were quite likely clicking numerous times when trying to get to the product pages. When loads were high nothing appeared immediately, so I made the leap that users were clicking and clicking and clicking trying to move forward, which of course only exaccerbates the problems and creates more load for everyone.

I'm going to document what we did to fix these load issues in hopes it gives others in the same boat some ideas. I could find no documentation of anything like this anywhere, but the approached worked for our situation.

First, I wanted to off-load the In Stock bit from the product pages. The theory being that the girls looking for a dress would click on the smaller thumbnail image in the Category area to see the full-sized view to see if they really liked the dress or not, but at this point of the buying process they really didn't need to know what was in stock and what was a special order dress.

To start the process the store staff cloned every product they had in stock to become part of a special category. The new category was simply called In Stock Dresses, and the products carried the same Product Name as the original, except that the text string "IS-" was appened to the beginning of the product name. So if they had an Alfred Angelo dress style 3207 that was available in sizes 0-8 and with colors of midnight blue and red it would stay there in the normal Alfred Angelo category as product name Alfred Angelo 3207 with lots of variants and 0 availability of each. However if they had a size 2 dress in blue and a size 4 dress in red actually in stock there would also be another entry as IS-Alfred Angelo 3207, showing just the two dress variations that were actually in stock.

Note: Make sure to back up any templates you alter just in case!

Then in the x-cart product template (/skin_name/customer/main/product.tpl) we removed the section that normally would show which items were In Stock variants on the product page. It was a fairly sizable chunk of code with a couple of {if} statements, staring with {if $in_stock_variants} in case you need help finding it.

After removing this we added a bit of smarty code and language to the normal product variants section to give people a way to check the available stock. This was just after the code block for the <form name="orderform" and table cell that creates the section in the product.tpl file. Here's what was added.

{if $product.product|truncate:3:"":true !="IS-"}

<tr>

<td colspan="2" class="instock"'>

<a href="javascript:to_instock_window('http://www.somedomain.com/store/get_instock.php?pn={$product.product|escape:"quotes"}')">Click here</a> to see if there are any sizes and colors of this style

<br />

in stock and available for immediate shipment.

</td>

</tr>

{/if}

What does the above code do?

It analyzes the first three characters of the product name field to see if the product starts with the string "IS-" or not. If it's not there people see the text and a link. If someone is already on an IS- product page they see nothing.

Notice that the link is firing a javascript event. We need to add this to the product.tpl template as well. You'll probably already have some JS in this template enclosed in {literal} smarty tags. If not, make sure the following javascript is inside a {literal} {/litersal} section towards the top of the product.tpl template.

<script language="JavaScript" type="text/javascript">

<!--

var newwindow = '';

function to_instock_window(url) {
if (!newwindow.closed && newwindow.location) {
newwindow.location.href = url;
}
else {
newwindow=window.open(url,'get_instock','height=400,width=400,scrollbars=yes');
if (!newwindow.opener) newwindow.opener = self;
}
if (window.focus) {newwindow.focus()}
}
//-->
</script>

Okay, so we have our template ready. With a bit of css styling thrown in for good measure the relevant portion of our product pages for items that are not in stock should now look similar to this.

So let's get on with making this thing work. We need to next create our get_instock.php page. The code for this page looks like:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>
<head>
<title>In Stock Availibility</title>

<link rel="stylesheet" href="/store/skin_name/skin_name.css" />

<script language="JavaScript" type="text/javascript">
<!--
function to_parent_window(url)
{
opener.location.href = url;
self.close();
}
//-->
</script>
<style type="text/css">
body {
background-color: #F9E2EC;
margin: 0px;
}
p {
margin-left: 10px;
margin-right: 10px;
}
</style>

</head>
<body leftmargin="0" topmargin="0" marginwidth="0" marginheight="0">
<img src="/store/skin_name/images/dialog-headers.gif" width="100%" alt="">
<?php
$dbhost=""; // Enter localhost or ip number of remote MySQL server
$dbname=""; // Enter database name
$dbuser=""; // Enter database user
$dbpass=""; // Enter database password

// Connect to the database
mysql_connect($dbhost, $dbuser, $dbpass);
// Select the databse
mysql_select_db($dbname) or die(mysql_error());
$pn = stripslashes(htmlspecialchars($_GET['pn']));

### If not an IS- product name, see if one is available
$IS_product = "IS-" . stripslashes(htmlspecialchars($pn));

$func_IS_product_query = "SELECT productid FROM xcart_products WHERE product = \"$IS_product\"";

$IS_result = @mysql_query($func_IS_product_query);
$IS_rows = mysql_num_rows($IS_result);
if($IS_rows == 0) {
$IS_exists = 0;
?>
<p>
<div align="center">
<?php
echo "<h2>" . $pn . "</h2>";
?>
</div>
</p><p>
There is currently no stock of this item in our store, however we will be happy to order it for you. Please return to the shopping cart and place your order. We will contact you with a shipping date for your special order.
</p><p>
If you need a dress immediately, please check the <a href="javascript:to_parent_window('http://www.somedomain.com/store/catalog/In-Stock-title0-p-1-c-###.html')" style="font-weight:600;">in stock category</a> or call us at ###-###-#### and we will be happy to help you find the perfect selection.
</p>
<p>
<a href="javascript:self.close()" style="float:right;font-weight:600;">Close Window</a>
<?php
}else{
$IS_exists = mysql_result($IS_result,"productid");

$IS_product_tmp = ereg_replace(" ", "-", $IS_product);
$IS_url = "http://www.somedomain.com/store/catalog/".$IS_product_tmp."-p-".$IS_exists.".html";
$get_availables = "SELECT classid FROM xcart_classes WHERE productid = '$IS_exists'";
$classes_result = @mysql_query($get_availables);
$classes_rows = mysql_num_rows($classes_result);
$classid = mysql_result($classes_result,"classid");

$get_options = "SELECT option_name from xcart_class_options WHERE classid = '$classid' AND avail = 'Y'";
$options_result = @mysql_query($get_options);
$options_rows = mysql_num_rows($options_result);

?>
<p>
The following are selections available for immediate shipment:
</p><p>
<div align="center">
<?php
echo "<h2>" . $pn . "</h2>";
for ($k=0; $k<$options_rows; $k++)
{
$new_options = mysql_result($options_result,$k,"option_name");
echo "<strong>" . $new_options . "</strong><br />";
}
?>
</div>
</p><p>
Please <a href="javascript:to_parent_window('<?php echo $IS_url; ?>')" style="font-weight:600;">Click Here</a> if the above In Stock selections meet your needs. Your main browser window will be refreshed to the order page for the above items.
</p><p>
Or you may simply <a href="javascript:self.close()" style="font-weight:600;">close this window</a> to continue shopping normally.
<?php
}

?>
</p>
</body>
</html>

There are several things going on in this popup window code. First and foremost being some database queries to ascertain if a given product has an IS- sister. If it does it writes the info to the popup window. (Note: To make things easier we had the store folks combine the size and color variants into a single class. I would highly recommend you do so also if at all possible, otherwise you'll need to alter the code considerably.)

It also has a little javascript function built into it to feed data back to the parent window. So if the user sees something that fits their need they'll get taken to the correct IS- product page in the store when they click on the link.

Lastly, when there is no In Stock availability for a given dress the user gets the option of either closing the popup and going back to the same page they were on in the main window, or they can click on the link we're providing them to take them directly to the jumping off point of our In Stock category. This is hard-coded, so you'll want to check to make sure the ### in the url gets changed to your In Stock catalog page.

That's all there is to this part of the equation. We've effectively off-loaded the In Stock variants to a separate popup window, which should decrease the server load considerably.

Next up, we wanted to give users some sort of visual queue that the server was trying to satisfy their request for a product page so that the girls wouldn't keep clicking and clicking and clicking and simply adding more load with their impatience.

I took a two-pronged approach to this. First, I simply added a standard "Loading..." graphic via a javascript onClick event when someone clicked on a product page link from a category page. I coded the JS function so that the loading image would be centered in the users browser window no matter where they were in the page. At the same time I added a Opacity routine so that the colors on the category page would fade out if there was going to be much of a wait. And lastly, I disabled their ability to click on other links on the page. Or I should say they can still click on them, but nothing happens if they do because the script heads off the click before it can add any server load.

Since there are several things going on I simply added these javascript functions to the end of the common.js file that x-cart already uses. This file can be found at /skin_name/common.js. The additonal javascript for all of the magic looks like:

// Added for fade out and loading graphic on category pages

function f_clientWidth() {

return f_filterResults (

window.innerWidth ? window.innerWidth : 0,

document.documentElement ? document.documentElement.clientWidth : 0,

document.body ? document.body.clientWidth : 0

);

}

function f_scrollTop() {

return f_filterResults (

window.pageYOffset ? window.pageYOffset : 0,
document.documentElement ? document.documentElement.scrollTop : 0,

document.body ? document.body.scrollTop : 0

);

}

function f_filterResults(n_win, n_docel, n_body) {

var n_result = n_win ? n_win : 0;

if (n_docel && (!n_result || (n_result > n_docel)))

n_result = n_docel;

return n_body && (!n_result || (n_result > n_body)) ? n_body : n_result;

}

function toggle_visibility(id) {
var e = document.getElementById(id);
if(e.style.visibility == 'visible')
e.style.visibility = 'hidden';
else
e.style.visibility = 'visible';
e.style.top = f_scrollTop() +120 + "px";
e.style.left = f_clientWidth()/2 - 30 + "px";
}

function opacity(id, opacStart, opacEnd, millisec) {
//speed for each frame
var speed = Math.round(millisec / 100);
var timer = 0;

//determine the direction for the blending, if start and end are the same nothing happens
if(opacStart > opacEnd) {
for(i = opacStart; i >= opacEnd; i--) {
setTimeout("changeOpac(" + i + ",'" + id + "')",(timer * speed));
timer++;
}
} else if(opacStart < opacEnd) {
for(i = opacStart; i <= opacEnd; i++)
{
setTimeout("changeOpac(" + i + ",'" + id + "')",(timer * speed));
timer++;
}
}
}

//change the opacity for different browsers
function changeOpac(opacity, id) {
var object = document.getElementById(id).style;
object.opacity = (opacity / 100);
object.MozOpacity = (opacity / 100);
object.KhtmlOpacity = (opacity / 100);
object.filter = "alpha(opacity=" + opacity + ")";
}

function DisableLinks(xHow){
objLinks = document.links;
opacity('thefade', 100, 60,500);
// Pause 2 seconds before loading the loading graphic
setTimeout("toggle_visibility('loading')", 2000);

for(i=0;i<objLinks.length;i++){
objLinks[i].disabled = xHow;

//link with onclick
if(objLinks[i].onclick && xHow){
objLinks[i].onclick = new Function("return false;" + objLinks[i].onclick.toString().getFuncBody());
}
//link without onclick
else if(xHow){
objLinks[i].onclick = function(){return false;}
}
//remove return false with link without onclick
else if(!xHow && objLinks[i].onclick.toString().indexOf("function(){return false;}") != -1){
objLinks[i].onclick = null;
}
//remove return false link with onclick
else if(!xHow && objLinks[i].onclick.toString().indexOf("return false;") != -1){
strClick = objLinks[i].onclick.toString().getFuncBody().replace("return false;","")
objLinks[i].onclick = new Function(strClick);
}
}
}

String.prototype.getFuncBody = function(){
var str=this.toString();
str=str.replace(/[^{]+{/,"");
str=str.substring(0,str.length-1);
str = str.replace(/\n/gi,"");
if(!str.match(/\(.*\)/gi))str += ")";
return str;
}

Lastly, we need to tie it all together by making a couple of tweaks to our category pages. IMO this template has a wacky name in x-cart, but it's the one called products_t.tpl located at /skin_name/customer/main/products_t.tpl

First we need to add a couple of new div layers that are initially going to be hidden by our css rules. Add this to the top of the products_t.tpl file, right after the $Id comment section:

<!-- Added for fadeout loading layer -->

<div id='thefade'>

<div id="loading" style="position: absolute; width: 160px; height: 160;">

<img id="loadingImg" src="/images/loadingb.gif" alt="Loading..." width="160" height="160" border="0" />

</div>

Then a bit farther down in this same template look for the section that kicks off the loop through the products. You should see an A HREF reference just below a section that says:

{section name=product loop=$products}

There may be a few of these, depending upon what you have enabled in x-cart. Have a look at each one as the View Source of your original cart page and you'll know which you need to edit. All we're going to do is add an onClick event to trigger the fadeout, so there's not much danger in playing with it a bit. Most installations I've seen are going to have three places you'll need to add the onClick event. Once for the product title, once for the thumbnail image and once for the Details language.

Our addition to these A HREF tags is simply:

onClick="DisableLinks(true);

That's it, you should be done now!

By utilizing the above we were able to take a site where the combination of x-cart's inefficiencies and sheer numbers were killing a pair of servers and get everything running smoothly again.

I hope this helps someone out there who finds themselves in a similar situation!

The need arose for me to have the ability to make a backup of a database that lives on a separate MySQL Database Server. So rather than back it up on the db server itself via a shell script I chose to use the php database dumper script to create the backups on the main server that runs Apache, mail and everything by the MySQL server.

The additions allow one to specific either localhost (for local dbs), and IP number of a remote server or a hostname. It also allows one to set the port to use in case you're using something other than the standard MySQL port 3306.

While I was tweaking the script I added a --lock-tables option to the mix, which will cause the script to lock a table before starting its dump. This was done to fend off the rare cases of potential data corruption if the db was changing at the exact moment a table was being updated.

If you need to make any other changes to how mysqldump works in the script you can simply edit the three appropriate lines to add them. For instance, if you wanted to add a --add-drop-table so that the dumps would automagically drop existing tables when performing a restore it's a trivial edit. Just remember there are 3 places in the script to make such edits (they're easy to find) and also be careful about leading spaces with the concactenation. In other words, to insert --add-drop-table it should look like " --add-drop-table" as opposed to "--add-drop-table".

Cheers!

I have (at least temporarily) reactivated Comments and Trackbacks in the blog. You can thank or blame Craig for this, depending upon your view on the matter. ;-)

As I explain previously these were disabled because of the amount of spam the blog seemed to attract, coupled with the fact that I don't have 2 or 3 hours per day to moderate this domain. Which is what it was requiring.

I'm not going to lay out everything I'm doing in this little test, but here are a couple of things real people posting comments will want to do or not do as the case may be.

1. You'll see a new field on the comments form that asks you what my first name is. Think of this as a dumb CAPTCHA, since I really don't want to have to enabled a full CAPTCHA because I know there are are some sight-impaired users out there who read my blog. Simply input my first name (randy or Randy, it's case insensitive) and you'll go on through.

2. Since most spammers are trying to get their URLs into other people's blogs, I've set up the system I'm testing to automatically block any comment or trackback that mentions more than 2 URLs. As a link or non-linked text. I may up this later, but for testing purposes I want to start out strict. So when you're posting make sure you do not include more than 2 url addresses anywhere in the post. This goes for both the URL and Comments fields combined. Got it? No more than 2 urls anywhere.

Also know that during testing I'll still be manually moderating comments and trackbacks. This has to be done to make sure the spammers can't get through the various filters I have set up. So don't expect your comments to show up immediately. Though I certain appreciate comments and feedback, I'll get to 'em when I get to 'em. This site simply isn't my main focus. My sites that make me a living are.

Also, don't expect to see any error message if your comment gets caught up in the filters. To give a detailed error message would give the spammers a leg up in reverse engineering the several layers of checks I'm performing. So it's going to look like everything went through, even though it may have gotten headed off by the spam checking system.

If I can get it working so that it catches a majority of the spam (by majority I want 99% with as few false positives as possible) I'll open it up more so that comments are immediately visible. In fact, I may tell you exactly what Movable Type plug-ins and other methods I'm using to help keep me sane so that you can use them on your own MT blog.

First, let's start off with a quick discussion/definition of what Ajax actually is.

At it's heart Ajax is nothing more than JavaScript. Really it's more than JavaScript -- it's a collection of inter-related web development techniques that can be used to create interactive web applications. But even this rather broad and often confusing definition doesn't explain why Ajax can be such an improvement over using html or any of the server side scripting languages such as php, asp, etc. So where does Ajax fit into the puzzle?

Well when you think of the Web, or more specifically Web Applications, it's important to remember there are two sides to the coin.

First you've got things that happen on the Server side of the equation. This includes how Apache processes and delivers pages, server side scripting languages, databases, etc, etc.

On the other side of the equation you have the Client side applications, which generally means Browsers and everything that happens in a browser that is independent of a (new) connection to a web server. In an Old World sense JavaScript would be considered to be a Client side application because JS does all of its work in the browser, which lives on the clients (users) side of things.

This is where Ajax is different from the JavaScript most people have been used to using over the years. Unlike things like Image Rollovers and the like, which take place squarely in the Client, Ajax also has the ability to communicate with the server to send and/or receive additional information. Ajax thus opens up a new world to web developers.

It's an important distinction. Whereas almost everything that didn't require a 3rd party application be installed (eg Flash, Java, ActiveX controls) could be broken down to one of the two groupings --Client side or Server side-- Ajax sits in the middle somewhere. It can and does effect changes on the Client side of the equation, but at the same time it can communicate with the server like a Server side application. And every browser supports Ajax natively, meaning no 3rd party application needs to be installed by the user to take advantage of the additional functionality.

This is where the power of Ajax comes from. It is neither Client nor Server side. It's a middleman. It's something else, something different. Yet doesn't require anything special of the user.

Now, how powerful is Ajax? In a word, very.

It can do everything JavaScript can do on the Client side. Plus it can do much of what Server side scripting languages can do.

But here's the deal ...

As far as I'm concerned just because Ajax can do a lot of the heavy lifting that Server side scripting typically does, it doesn't necessarily follow that web deveopers should use it to perform every single function that would normally be done by a server side script. Not only don't you need it to, but it's folly to depend upon Ajax to do all of the heavy lifting. Beyond that it's just bad coding and bad for business if you're running an e-commerce site.

Why? Well, because you can never fully depend upon what a user has available to them in their browser (Client side) application. So if you rely totally on Ajax to do the heavy lifting it is an absolute certainty your site will not work as expected for all users.

It's simply wiser from the development perspective to leave the heavy lifting to the Server side utilities, then use Ajax and its Client side abilities to update the browser. The beauty being that instead of having to update the entire page --as happens with solely Server side scripting languages-- Ajax can simply update the part of the page that needs to be updated when used in an Ajax compatible browser.

Read that again to make sure it sticks.

Server side applications (.php, asp, etc) requires a full page update when something happens. Ajax allows the user to stay on the same page, only updating the part of the page that requires an update.

At the same time, if you build your applications correctly, those users whose browsers do not support Ajax will still be able to use the site, because the back end Server side application is still doing all of the heavy lifting.

In the coder geek circles this phenomenon is known as Progessive Enhancement. Some also refer to it as being a situation where the code enables the application to degrade gracefully. Or in the Ajax circles some refer to the concept as Hijax.

How does it work?

It's simple really.

You have a back end Server side application that still does all of the heavy lifting, and on top of this you lay an Ajax application to provide a better user experience. The general concept comes from how CSS development has progressed over the years.

With CSS you have HTML (or XHTML or whatever) that provides Structure to the page. Then you use CSS to style all of the content that goes into the structure. Good use of CSS allows you to separate Structure from Style. To create a modular design that not only looks better, but works better and is much easier to maintain.

Correct use of Ajax utilizes this same idea of modularity, except that it keys on how the Client side and Server side applications mesh together to create a superior user experience. And also makes use of the CSS modularity mentioned above to style the content. Done correctly Ajax, or some would say Hijax since we're talking about something a bit more, allows we web developers to increase a site's interactivity, speed, functionality and usability.

Wow! That's a lot isn't it?

Yes, it's a tall order. But it's not really all that difficult to do. Here's all you need to remember to develop a site that is going to make use of Ajax:

1. Plan for Ajax from the very beginning.
2. Implement your Ajax at the very end.

Sounds simple doesn't it? It really is that easy if you can remember these two rules.

Planning for Ajax simple means that you need to create your basic page templates to be modular --as should already be the case if you're using CSS to style content-- but still have the Server side applications do all of the heavy lifting. Meaning even if someone comes to your site without an Ajax capable browser --say a Search Engine Spider or someone who uses a screen reader for instance-- they'll still be able to use your site. The only downside for these users is that they'll get a version that isn't quite as pretty, nor will they be able to stay on the same page as they communicate with the server. But everything will still work for them.

That's the key... Keep the initial page design as simple as possible, but very functional as you're developing your web application in the beginning. There's no need to pretty things up, because during Step 2 you'll be using Ajax and CSS to make everything pretty and provide additional functionality. It's already in your plan after all !

That's the basic concept you need to understand as we move forward. The moral of the story being that just because Ajax can do a lot of heavy lifting doesn't mean it should. In fact, I would contend that it shouldn't, because if you allow it to do all of the work you're going to be locking some very important visitors out of the best your site has to offer. Most notably the search engine spiders.

So remember the two rules and you'll be fine as we move forward to build some Ajax-enabled applications.

1. Plan for Ajax from the very beginning.
2. Implement your Ajax at the very end.

Got it?

Moving forward we'll start to develop some Ajax-enabled web applications. Starting off with some pretty simple stuff to get your feet wet. Eventually moving up to an Ajax-enabled, spider friendly shopping cart application.

Fasten your seat belts! This is going to be a fun (and hopefully educational) ride!

First, let me make it clear that with one exception I do not consider any particular stat to be The Most Important. The reason being that these most important statistics are going to be different for each site.

As a for instance, let's compare some of the more important stats for an e-commerce site versus a non-commerce information-only site. So say something like Walmart.com vs. CNN.com.

For Walmart.com, where the main goal is to urge someone to purchase products, the more important statistics are going to be the Entry Page, Path Taken and Conversion To Sale.

For CNN.com it is probably going to be more important to pay particular attention to the Length of Visit and Customer Loyalty, or return visits by the same person.

The difference being Walmart.com wants people to buy things. While it may be of some use to track Customer Loyalty, the main goal is to help customer get from the entry page to the checkout as quickly and easily as possible. Whereas for CNN.com, they'd be better served by encouraging users to stay longer and come back more often.

Make sense?

Now, let's move back to the real question and take the second part first. What is the least important or useful statistic.

In this case it's not so much that the stat isn't important, but that the type of stat can introduce some major confusion into the data analysis process. And thus can lead you to making some wrong decisions.

My personal vote for the least important/most useless stat is anything that is shown in Percentages. The reason being that if you stop at the Percentage (as too many do) without drilling down any further, you stand a high likelihood of making some really bad decision that are being based upon dubious data.

Let's take an example from my previous post about how you You Have No Home Page. If you viewed your general Entry Page stats you might see that 40-50% of your traffic first lands on your home page. So you think this has to be the most important page on your site, hands down.

However if you bothered to dig more deeply in your stats you might also find that 80% of your sales came from people who were first landing on a page that was not your home page. Either because those users were conducting a search with a better focus that matched up well with what you offer, or because your home page simply wasn't constructed well to convert visitors, or even because your home page wasn't focused well enough so was pulling a lot of unqualified traffic that stood no chance of converting and quickly bounced.

Hopefully the above quick example illustrates why it is incredibly dangerous to use percentages and only percentages when making decisions about your web site. You simply cannot do it and still make the most of your traffic. It's business suicide to do so.

Don't rely on percentages. Glance at them, make note of them, but make sure you drill down to the real data.

The Most Important Stat is an easy one actually. It's the Bounce Rate for your site overall, and especially the Bounce Rate for individual pages.

For the uninitiated I'll give you a quick definition of what Bounce Rate means. It's simply a measurement of how many people come to a page of your site via one means or another, then immediately leave. As some aptly describe it, "I came. I puked. I left."

The reason this is the most important stat is very simple.

If visitors come and then immediately leave they never have a chance of converting. Period, end of story.

Now the reasons for high bounce rates can by myriad. It could be the layout of your site. It could be that you're popping up boxes at them, or showing them ads instead of real content. It could be that your copy simply doesn't hook readers right off the bat. It could be that the visual layout of the page doesn't match the personality type of the audience arriving at the page. It could be that you're simply getting statistically large amounts UNtargeted, UNqualified traffic because your site is ranking in the search engines for some phrase(s) that don't really relate to what you do.

The whole trick is to limit your bounce rate. So you need to drill down past the percentages, look at all of the possible factors, make appropriate changes and give those bouncers a chance to convert. In the real world the more you can decrease your bounce rate, the greater the chance that more people will convert into customers.

Which brings up another question or two. What is the average bounce rate, or what is an acceptable bounce rate.

It's tough to give a general answer because again each site and each market is so different. However as a very general rule the overall site bounce rate for a typically web site will range somewhere between 40% and 60%. (Damn Percentages!) If your bounce rate is 60% or above you really need to make some changes. If you're below 40% you're doing a really good job.

An Aside : It always astonishes me when I talk to a webmaster who doesn't know what their bounce rate is. It's that important to know, because it's THE starting point to increasing conversion rates. But I have to admit most webmasters don't know, so don't feel bad if you don't. I'd hazard to guess 80% or more of the webmasters I talk to didn't know what their Bounce Rate was until I pointed out why it's an important metric to know.

The real trick (see my percentages rant) is to drill down below the overall percentages so that you can figure out what's going on, why and how to fix it. For instance, if you drill down and find out that a page with an 80% bounce rate is getting a lot of traffic for keyword terms that don't directly relate to what you do, you'll want to tweak your copy so that it doesn't. After all traffic that immediately bounces is useless.

The real truth is you're never going to have a 0% bounce rate, just like you're never going to have a 100% conversion rate. However these are both worthy goals, and ones you want to strive to get close to.

The simple answer is that it doesn't really matter as long as the tool provides data you can use to take action. There are literally dozens of really good (and sometimes really expensive) Web Analytics/Data Analysis tools out there that will help you gather the information you need and drill down to get to the information you actually need in order to make smart decisions.

Personally, I've used Urchin for years. Urchin is software that gets installed on the server and builds all of its information from there. Other notables would include Google Analytics --which was built off of the Urchin platform when Google bought Urchin a couple of years ago-- WebTrends, CoreMetrics, Omniture, ClickTracks, etc.

All of those, save Google Analytics, cost money to use. Some are installed on the server, some are not. And you'll notice that I've left general Web Statistics programs (eg Webalizer, AWStat, etc) off of my short list. From years of experience the general statistics programs simply don't provide enough information to enable one to come up with an actionable marketing plan.

For the purposes of this series I'm going to be referring mostly to Google Analytics. It's free, and is a good choice for many smaller webmasters. However the same concepts can be easily transferred to any suitable Web Analytics program.

You'll need find something that fits for You, and most of them offer some sort of free trial period so you can test them. If you've got a budget that allows purchasing an installed analytics solution, go for it. Doing so will ensure that all of your proprietary visitor data stays exactly that, proprietary.

If not, something like Google Analytics will likely be the best choice, at least for now.

So, let's kick it off with a concept that some may find controversial, as well as one in which others may find some enlightenment. The concept is a very simple one:

You Do Not Have A Home Page.

"Wait," you say. "Of course I have a home page. It's the index.html page that I've uploaded to my site!"

Technically speaking, you would be correct. But we're talking about the Real World here, not technical stuff.

The fact of the matter is that 80% of the Real People out there start off their web journey by using a Search Engine. Be it Google, Yahoo!, MSN/Live, Ask or any of the other public or private search engines, the vast majority of new traffic you receive is probably going to originate from a search engine. Even if they arrive at your site from a link on someone else's site, they probably started out searching for something.

Of the remaining 20%, a significant portion of this traffic is going to come to you via a link on someone elses site.

Here's my point. In both of the above cases --which is probably going to make up over 90% of your overall online traffic-- you are not in control of what each visitor considers your home page! The search engines may list an interior page as the best fit for a search phrase someone typed in. Another webmaster may link to something other than your home page if they found it particularly useful.

Those are both good things, however it means you really need to understand and accept that you have no single Home Page. Since Real People are going to consider the first page of your site they see to be your "Home" page, in many, many cases are what you consider to be your home page simply does not match up with the user experience of the real people you're trying to attract.

This is why you're going to hear me say over and over again that you need to have a way to measure the data (Web Analytics) and a sound methodology to determine what's happening, why it's happening, and develop an action plan to take advantage of this newfound knowledge and approach.

How you do this is different for every site, every market and every situation. However if you can simply embed in your memory that there is no single Home Page of your site in the Real World, you'll be miles and miles ahead of the competition. Because once you do you'll find it much easier to discover that one user or type of user who searches for "phrase abc" may land on pageabc.html of your site, which another another user typing in a search for "phrase xyz" gets shown your pagexyz.html. They're both home pages in the Real World.

Once you grasp and accept this concept you'll also be able to understand what they want, what will be their hot button, which leads to how you may want to construct your page or the words you want to do in order to encourage them to take the action you want them to take.

So there you have it. You have no home page. You have several, or in many cases several dozen. Work on them from this new perspective and you're guaranteed to see your profits grow.