It is the Product page testing I am struggleing with as I send the majority of traffic direct to the site with no google involvement hence the question.

With regard to the coding are you thinking along the lines of an interception script of some descrip? I was thinking of maybe utilising something at the server level to redirect a page, not looked into it yet so don't know how difficult it would be, maybe find a load balancer that can handle traffic at page level and hack (just thinking outloud!)

My idea is to set up a new table with 4 fields - the id, the test reference, the variable used in the test and then the result (conversion or no conversion). Then I'm going to set up a system where it checks if a cookie for the test is in place, if it isn't then it is created and a decision is made as to which variable is used. Every page where there is a potential for this variable would check this cookie first. Then code would change the element if needed.

For example if you want to test the buy button then you would place a call to the script around the function for the production of the add to cart button. The script would determine the variable to be used (from the cookie) and replace the normal button with another one.

To ensure the user keeps the same variable on a retrun visit you can put a decent expiry on the cookie and to ensure you have a fair spread amongst the users you can say all odd numbers in the table ID produce variable A and all evens variable B. For more complex sharing (like 75/25) you could use the mod calculation so if the ID is completely divisable by 4 then show variable B if it leaves a remainder use the standard variable A.

It sounds complex and to be honest I think it will be, so I'm still going to test a few more reasonably priced offerings. But I have a feeling I'm not going to find anything that does more than the basics in our budget range.

I trialled a few more and none of them do what I need, so today I started drawing up my flowcharts to get this thing moving.

Hit one problem and that was spiders and crawlers. A cookie covering a big portion of the site may block spiders (which obviously isn't good). There are ways to get round this with redirects but I don't really want to do that. So I've found a package that you install on the server and can do those sorts of checks easily. It's called BrowserHawk, expensive but I'm sure I'll get my money back on it with the testing.

Think I've cracked this. I purchased a piece of software called BrowserHawk which gives details on the visitor before any rendering is done on their machine, so the cookie problem blocking spiders is fixed.

I've got a test going on now with one of our sites where the template for the product is changed both in product listing views and product expanded views, dependent on the variation given to the user.

I can also stop a variation immediately by changing a variable in the database.