It is definitely an interesting challenge to solve and we are continously tackling different parts of it. Today, we rolled out a number of updates; most of which are related to the backend and URL matching. Lest you miss our hard work, I thought of documenting them in this blog post. Following are some of the major updates:
Massive boost in response time
We upgraded our servers (doubled the capacity) and did some backend optimizations (added new database indexes, removed some query time sorts). Result: the response time for displaying a test on your website cut to half. Proof: here is one the users tweeting about the optimizations.
larsgundersen “http://visualwebsiteoptimizer.com just did some speed optimization & server upgrades! Now the response time rocks!”
Tests work with AdWords or other referral traffic out of the box
Earlier, tests defined for http://www.example.com/page.html did not work by default for traffic coming AdWords (or other campaigns) because Google sticks some tracking parameters to the URL (making the resulting URL as http://www.example.com/page.html?utm_campaign=XXX). Visual Website Optimizer treated these two URLs as separate and hence the test defined for former URL didn’t work if the visitor arrived on the latter URL. A hack to make it work for both the URLs was to use the wildcard * (that matches with any character) so that http://www.example.com/page.html* matched with both the URLs. But, it was a messy way to do something which should work by default.
So, the good news is that we modified our URL matching algorithm to make it work out-of-the-box. Now irrespective of presence of tracking (or query) parameters in the URL, test would work for all visitors. (This wasn’t as straightforward as it seems because the wildcards still work and you can still define tests containing query parameters that would only work if there are query parameters in the URL).
To “www” or not to “www”, that is the question
A common usability issue earlier was that people defined tests for http://www.example.com/ but their website actually was http://example.com/ – this confused our poor, little URL matching engine (not because we cannot treat both URLs as one, but we don’t want to; reason being technically both URLs are different and even search engines treat them as different URLs). So, what we do now is smart: when you create a test we access the URL entered, follow all redirects (as a browser would) and then see what is resulting URL. In lay man terms, Visual Website Optimizer will define the test on URL that actually exists on your website, not what you have entered in the wizard. In super lay man terms, you don’t have to worry a lot about how exactly you are entering the URL. (However, you still need to be careful about how you enter URLs for conversion goals – those are case sensitive and no URL magic happens for it)
Oh gawd, the curse of “index.php”
If a martian arrived on Earth and you asked him whether these strings are same: http://www.example.com/ and http://www.example.com/index.php – what will be his answer? Now, if the super-smart martian can get this answer wrong, how can our poor little URL matching engine can get it right?
The world of HTTP is complex and confusing – replete with numerous special cases like the above two URLs resolving to the same location. Earlier our URL matching engine thought those were two different locations but now they are treated as one – so your tests will work on both the URLs. (Other special cases include common homepage file names index.htm, index.html, home.html, default.aspx, etc.). Essentially, you don’t have to do any hacks or changes to your website, “index.php” or no “index.php” test would work for both the cases.
Detection of overlapping tests
As a policy, Visual Website Optimizer doesn’t allow overlapping tests – that is, while you can run multiple tests on a website at once, you cannot run multiple tests on the same webpage. But this wasn’t very obvious so users usually end up creating multiple tests on their homepage and then complaining that they only see one of them running. With this update, while creating a test, you will get an alert if you are trying to create a test on a page where an existing test is already running.
A much needed, remember me functionality was added so that you don’t have to login again and again for check test results. Session timeouts and the need for logging in again was a common hassle, now it isn’t 🙂
I will be happy to discuss if you have any specific questions on the URL matching engine, backend optimizations or other updates. Simply leave a comment here or email me at firstname.lastname@example.org