The Chatterbox: Business on the Web Archives

December 30, 2008

Using Economic Troubles In Your Sales Pitch

The second interesting thing I mentioned in my last post has to do with how it can be advantageous to recognize and mention the current state of the economy as part of your sales pitch. Let me first be clear in saying I do not believe this should replace your Unique Sales Proposition/Unique Value Proposition. However simply stating the obvious, while breaking a couple of the normal Best Practice ideals, did manage to show some conversion improvements on the couple of sites I tested it.

What do I mean?

Well, first I think everybody is well aware by now that current state of the economy sucks. It sucks big time! And this is one where everybody is in the same boat. A boat that has apparently sprung a few leaks.

Tailoring part of your offer to give voice to this reality surprisingly seems to be something you may be able to use to improve conversions. It doesn't even have to be a grand statement. The two sites I tested the idea on recently made only small mentions, but people were having an emotional response to the site's recognizing the fact that people are hurting, while tying the tough times to the offer.

As far as the breaking the rules part, I didn't really break a rule. Just skimmed the edges a bit.

What I mean by this is that I always recommend that you stay away from superfluous, qualitative language in your headlines, copy and call to action. Instead you should use quantitative language. The former tends to get immediately discounted, or worse sets up a condition where visitors immediately question if they can trust you.

An example perhaps.

A qualitative headline might say something like:

We offer the best lederhosen on the web!

When you do something like this you're (unknowingly perhaps) challenging the visitor to review some of your competitors offers to see if they can find something better in some way or another. Even if the visitors don't take up the challenge to shop your competitors, such blanket statements tend to introduce a bit of distrust into the equation. This type of superfluous sales'y type of pitch simply doesn't work well in my experience. Ever.

A quantitative approach that gets across basically the same message might be something like:

Your source for high quality, 100% goat hide lederhosen!

There's still a qualitative idea in there ("High Quality") but there's also a strong quantitative statement to back up the thought. (100% Goat Hide) And the headline has shifted the focus from "We Offer" (the old wee-wee mistake) to a customer-centric idea.

Now, how did I skirt around the edges of these best practice ideals (quantitative vs. qualitative and no wee-wee hype) that worked with the concept of recognizing the tough economic times that ended up improving conversions? I added a simple sub-headline and a short paragraph to a part of the pitch. It's not the USP, but it does support the USP.

Sub-headline: Our best offer. Ever.

Followed by a short paragraph detailing how the site's offer has been tweaked to give even better value than normal because the owner(s) understands times are hard for everyone. This "Best Offer Ever" could be free shipping, a temporary price decrease, discounts for larger purchases, discounts for established customers, coupons, etc, etc.

There's a trick with using such a qualitative statement as part of your pitch though.

Notice how it doesn't set up a comparison to every other competitor out there. It doesn't cause the visitor to immediately distrust the hype. Instead it's comparing the current offer to what this particular business has done in the past. In a nutshell it's saying We feel your pain. If you help us, we'll help you..

This is an entirely different approach than I've used before. Though it seems to resonate with prospective customers, probably because of the current economic crunch. And it's something you may want to test with your own site if you've recently implemented some changes to help you survive the economic downturn.

I've tested the concept on two sites and seen very good success, with conversion rates doubling on one site and rising by roughly 60% on the other. In both cases this single, smallish addition has helped recoup all of the losses these two sites have seen over the last several months. Both are converting at a higher rate than they were a year ago, prior to the downturn, with improved gross revenues.

Obviously two sites is not nearly a large enough sample to say it'll work in every market for every site. However the general idea is something you may want to test on your own site. You may be pleasantly surprised at the emotional response it seems to evoke.

Posted by Randy at 06:46 AM | Comments (0) | TrackBack

December 29, 2008

Jus' Testin'

A couple of really interesting things that has come out of my recent kick of helping some friends with their sites. The first was a question someone raised, quite innocently. It was such a simple question too. The question was:

What are the first things you do when you look at a page you're going to start conversion testing?

Well, here's what I do first.

When I look at the page I first try to determine what the true objective of the page is supposed to be. Is the page supposed to get me to sign up for a free newsletter? Am I supposed to click on a Buy button to purchase something? Am I supposed to click on an affiliate link leading me to someone else's site? Am I supposed to click on an Adsense ad or other paid advertisment? Am I supposed to absorb some information and move on to another page in the sales funnel?

It may sound simplistic, but I've found time and time again that many if not most times either the webmaster doesn't know what the true objective of a landing page is, or isn't focusing users on the objective very well.

As an aside, I know everybody calls them landing pages and I do too, but for conversion testing purposes it's really a misnomer. You see, Landing Page creates a mental image that it's some kind of destination. Landing pages aren't a destination for our purposes. In fact they're just the opposite, they're a beginning.

So anyway, that's where you need to start. What is the objective of your landing page. Without knowing the objective you can never construct a good test.

Now, the follow-on question that my friend didn't ask by I answered anyway is what exactly should a good landing page do?

Well, that answer comes back to your visitors. Doesn't it always? ;)

What I mean by this is you need to understand that every visitor to every landing page subconsciously ask themselves three questions. It's always the same three questions and it's absolutely vital you answer all three within the first 5 seconds or so of their hitting the page. In my experience if you don't address them quickly, you've already lost a prospective customer.

These three questions, along with some explanation, are:

Where am I?

People need to understand where they are, including orientation within a site. This is especially true when you're talking about a landing page where the visitor is going to be deposited on a new-to-them site by clicking on a link in a search engine listing or a link from another site.

This isn't something you need to do with your text necessarily. It can be done with your branding efforts many times, by the header graphics you use to identify your site. If you're talking about an internal page being your landing page, this is where it's important to either have a prominent "Home" link and/or use breadcrumb navigation towards the top of your page to help users see where they are and where they can go.

What can I do here?

This leads us right back into why it's important to understand the true objective of your landing page. You can't possibly answer this question, one every visitor automatically asks, without knowing the answer yourself!

Conversely, since you know the answer all you need to make sure you do is make it apparent to your site visitors. This doesn't mean you have to slap a garish Buy button right in front of them. But you should at least start leading them down the path so that if they want what you sell they can easily figure out how purchase it.

Why should I do it?

Obviously you're not going to completely answer this question in the first 5 seconds. However you can start answering it enough to get visitors to read on. Heck, you can address these last two right in your headline many times!

This one comes down to how you structure your call to action and how you deal with building trust and handling objections and trust issues.

So those are the four things I look at when I first review a landing page prior to setting up some conversion testing.

The other interesting thing that came to light recently I'll write about another day. Hopefully tomorrow if I can manage to find a few moments to pop by.

Posted by Randy at 09:19 PM | Comments (0) | TrackBack

June 21, 2008

Conversion Confidence

Someone asked me the other day how one makes sure conversion tests they've run produce conclusive, actionable data. The short answer is to review the Confidence rating of the results to make sure they reach a minimum threshhold you're comfortable with. Which is easy to say, but sometimes hard to do if the spreadsheet or conversion analysis tool you use doesn't give you a Confidence rating.

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!

Posted by Randy at 12:14 PM | Comments (0) | TrackBack

February 02, 2008

Speeding up x-cart when using variants

I recently was called in to help on an x-cart (Version 4.1.7 in case it matters) site that was having some serious performance issues. The issues being a combination of the inefficient way x-cart handles database queries for variants and in stock items and the sheer number of visitors this particular site attracts.

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">

</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">

</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:

<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!

Posted by Randy at 07:41 AM | Comments (0) | TrackBack

December 16, 2007

Using Ajax To Create A Better User Experience

I'm going to be starting a series in the very near future showing how one can use the concepts and coding behind what is commonly known as Ajax in your site construct to enchance user experience. But before I do I feel the need to explain my approach to using the capabilities available.

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!

Posted by Randy at 09:29 AM | Comments (0)

March 26, 2007

Making Money on the Web

A discussion came up the other day at Jill's forum where we somehow got onto the subject of how much someone would have to pay me for a link on one of my main sites if I were to accept paid links. (I don't for the record, so don't ask.) During the course of the discussion everyone seemed surprised that I couldn't be bought, even for a million dollars.

When I explained why this was, which has to do with my business philosophy as much as anything else people got even more confused. My explanation basically hinged upon the concept that if I knew a site of mine as going to provide $200,000 in profit each year it would be foolish to risk its place in the grand scheme of things to allow a single link or series of paid links to jeopardize this. After all, in only 5 short years the site would make me that cool million all by itself.

I think it was the $200,000 figure that scared people, since most web sites do not make this kind of profit. It's not that they can't, it's just that they don't. Usually because the site owner has never conducted any conversion testing to make sure they're giving their target customers what they want.

To me, this is simple math. Nothing more, nothing less. Let's lay it out so that everyone can get a better grasp on what kind of potential their web site really has and hopefully point out how much business you may be giving away by not conducting some basic conversion testing. This is very basic stuff I'm talking about here. Not rocket science.

So let's say you have a site that has the following givens, which fits many of my sites pretty closely. Cept for the amount of traffic. I tend to get more traffic.

Let's say you have a site where your average Profit Per Sale (PPS) is $35. Note: This isn't the actual sales price unless you're selling services/downloadables. It's your average Profit you get with each sale. And is also a very low figure for many web sites.

Let's also say that you only get 400 New Unique Visitors (NUVs) per day. Here we're not talking about returning traffic or anything like that, but brand new people who are seeing your site for the first time. Again, it's not much. Most sites get at least this much traffic after having been around for awhile.

Hopefully you'd agree that both of the above are very reachable targets to shoot for. You may have to adjust your final numbers if your PPS is higher or lower, but simply plug in your own numbers.

Here's where Conversion Testing comes into the picture.

In my experience most sites that have never been analyzed for Conversions are running at well less than a 1% conversion ratio. Meaning for every 100 visitors they're ending up with a confirmed sale to less than one person.

The magic is that pretty much everybody --by employing some very basic conversion testing-- should be able to get a site up into the 4% Conversion range. Again, it's not much. It means that you're still only converting approximately 4 in every 100 NUVs who hit your site. I've seen lots of sites which run 4-5 times this conversion ratio because they'd conducted more indepth conversion testing. So at a miniscule 4% we're definitely not talking rocket science.

To end up with a 4% conversion ratio you're usually just talking about making some (usually minor) copy changes to make sure you're talking to your target audience --often nothing more than tweaking some headlines and product descriptions-- along with some streamlining of the order process once you figure out where things are breaking down. Seriously we're usually talking less than 10 changes. Changes that make complete sense when you truly understand who your target audience is and think about it a bit. So this is certainly a goal anyone can attain.

Now let's look at the numbers I put forward above again.

Average Profit Per Sale - $35
Average New Unique Visitors Per Day - 400
Average Convsion Ratio - 4% (or 4 in every 100)

Let's add it up.

Those 400 visitors per day at a 4% conversion ratio will produce an average of 16 sales per day. 16 sales per day times our $35 PPS means an average daily profit of $560.

$560 times 365 days per year equals $204,400 profit per year.

See, it's really not all that difficult to lay out a plan to bump pretty much any e-commerce site up into an income/profit range that most people would kill for! And it looks a lot easier to attain when you break down the numbers doesn't it?

This is what I'm saying... Getting pretty much any web site to produce an income most people would be very happy with doesn't mean you have to scale Mount Everest. All it takes is 400 visitors per day and a bit of very basic conversion analysis.

Posted by Randy at 04:31 AM | Comments (0)

January 16, 2007

Where to start testing?

A question I get asked quite often regarding Conversion Testing is which page exactly one should start testing once they've determined that some conversion testing is in order. It's a good question, and honestly one that doesn't have any stock answer.

Without knowing any of the details of a given site the best general advice I can give you is to start where the testing is likely to give you the biggest bang for your buck. This could be your most popular landing page(s) or your home page or whichever page the visitor needs to make a buying decision.

The best way to sort out where you should start is to already have some sort of stats program installed so that you can get at least some details on what's currently happening with your site's traffic. There are lots of free or low cost stats programs out there, as well as some that can get quite expensive.

But even if you have one of these installed already, many seem to get confused by the data. There is so much data it's hard to narrow your focus down on what's most important. So let's take an example of a site I was just looking at this morning. I'm going to be conducting some conversion testing/analysis on in the near future so it's a good case study. (I'm obfuscating some of the identifiable details so as to not put the exact site out there, but it's a pretty typical situation.)

This site has a Subscription business model and delivers a service via the web. It does offer some stuff for free, but the goal is to get people to sign up for the service. The stats program it currently uses is AWStats, which is one of the pretty good freebie stats tools out there.

After talking to the webmaster I logged in to look at the stats. I saw a couple of things immediately.

1. The site is averaging around 750 Unique Visits per day by AWS' definition of Uniques. That's not a bad number for the market this site inhabits. Could be better, but could also be a lot worse. One note here is that existing members are going to be included in the Unique Visits total, but still there is a lot of new traffic coming in each day.
2. According to the webmaster the site is really having trouble converting visitors into customers. It's dismal, but not anything all that much outside the norm from what I see with sites on which no Conversion testing has ever been conducted.

The bad news is the site is averaging right around 2.8 sales per day, which equates to a 0.037% Conversion Rate based upon the AWS Unique numbers. Like I said, it's dismal. But a lot of sites convert at a pace of well less than 1%, so it's not all that unusual.

So, we're back to the main question. Where do we begin?

Well, in the AWS stats I scroll down the page a bit and come to the Pages - URL (Top 10) area. For your reference I've made a screen capture of this section. It looks like this: Screen Capture

The first two lines there are not important in the case of this site. They're simply files that are being included via PHP to construct the site navigation.

The third listing is actually a series of Samples pages. There are literally a hundred of more of these that are dyncamically generated for samples in each category the site offers, but are all being reported as a single page. These pages do get a fair amount of long tail traffic since their content gets pretty specific.

The fourth page is where they keep the Free stuff they offer. We'll gloss over this one for the moment, but will probably come back to it down the road since it would be a good place to move people from being Free users to Subscribers.

The next is the Pricing page, which is towards the end of the sales process. This and the Subscribe page (number seven) basically provide the same function, though in a bit of a different way visually. This is the point where visitors need to choose either to:
A. Continue surfing the site
B. Buy
C. Leave

These are the pages where the rubber meets the road, so to speak. They're where whatever anxiety or friction is going to come out naturally. And based upon the data AWS is giving us it's pretty apparent that right now the anxiety and friction are winning!

Do you see those Entry and Exit numbers?

Relatively few people are Entering the site on either of these pages, with 130 and 108 Entries respectively. From this we know that most people are hitting other pages of the site first. We also know they must have been interested enough in the service to reach these end-of-sales-process pages. So they already like the service, or they wouldn't have made it to these pages. Forget those few per day that are going on to purchase, who also had to have come through these pages. Look at the number of people who are Exiting from the site from these pages. Especially as compared to the number of Entries.

1,721 have exited the site from the Pricing page in the first half of January. An additional 1,219 have left from the Subscribe page so far this month.

Doing a quick bit of math, that's 2,940 prospective customers who were interested enough to make it all the way to the point they wanted to know the costs. This is just through the first 15 days of January.

Compare this figure to the 42 sales the site has had through the same time period and it quickly becomes evident where we should start. Where we stand to get the biggest bang for our buck.

If we totally discount the overall traffic to the site and concentrate simply on those visitors who make it to these two Call To Action pages we should be able to make some pretty decent improvements. This traffic is already interested or they wouldn't be showing up at these two pages. Realistically, we should be able to really crank up the sales ratio for visitors hitting these pages.

We just have to get out of our own way!!!

Seriously, even at a moderate 5% conversion rate for these visitors, who have already been qualified to a large extent, would equate to 147 sales in the first half of the month. Or just shy of 10 per day. (FTR, I think it can do much better than 5% of this already-qualified traffic.)

Having talked to the webmaster, I can tell you he'd be estatic to have 10 sales per day. It's a small web site and basically a one-person show, but with their price point 10 sales per day would amount to around $8,500-$10,000 per month as opposed to the $2,500 or so per month the site is bringing in now. And since it's a web-deliverable service, there are no extemporaneous costs. It's almost all profit.

So there ya go. There's a (pretty common) example of how one figures out where to start when they've made the decision to start some conversion testing. Sure we could (and probably will) optimize the sales funnel, but by starting off with a realitively simple and easy series of tests on just these two pages we're likely to see a drastic positive change as compared against the current sales and profits. So that's where we want to start.

What will we test? A few different of things come to mind immediately.

We'll change the copy on the page in order to improve it. We'll clean up some things I think are probably either contributing to or at the very least not helping to reduce the anxiety and friction of prospective customers. These simple text edits will be something we'll want to test to see how the changes affect conversions.

We may also deconstruct the page and start over with a radical redesign so that it's 100% evident to visitors where to click to make a purchase. As well as making sure Why one should purchase gains a more prominent mention. We'll probably test several of these benefits to see which produces best.

We may even do some price point testing. The webmaster is afraid to raise his pricing because others that offer something similar are his pricing model. I personally think he's charging too little because his service is better than any of the others out there that I've seen. IMHO he's devaluing his service, which is a mistake.

So there you have it. That's where and what we'll be testing. I'll be tracking it all of course. At some point in the future I hope to bring you an update to let you know exactly what worked and what didn't. And how much a tiny bit of conversion testing on just a couple of pages have improved things.

Posted by Randy at 10:13 AM | Comments (0)

October 02, 2006

Conversion Testing 101 - Chapter 3

Continued from Chapter 2

In this entry we'll look at how we can make sure we have a large enough sampling of data to insure our results are something in which we can have confidence. This is where a lot of people seem to get lost, and it's easy to see why. When you're doing it by hand, this is the point where you have to start getting into some pretty heavy duty mathematical equations, formulas and functions. Things like computing Standard Deviation and the like.

This is where I'm going make a concerted effort to do everything I can to take out of the process for you. Starting with, I'm not even going to point you to any references for what the Standard Deviation formula looks like or how to incorporate it into your tests. Bottom line, unless you're a math geek or incredibly detail oriented you won't gain anything by either seeing or trying to understand the formula.

It'll just clutter up your mind and distract you from more important things.

So instead I'm going to be building all of these sorts of things into my tool so that you don't have to worry about them in the least.

There are a few numbers you will need to provide that will be plugged into the various formulas. But they're easy to come up with, so don't let it scare you in the least. Here's all you'll need to feed the tool to get the ball rolling:

The Minimum Conversion Difference You Wish To Detect
Let's say your site/page is converting at a 1% clip at the moment. You want to test to improve this, however you need some sort of minimum threshold that would be worth changing your site over. So you decide there needs to be a Minimum gain of .5% in conversions in order to make mass changes.

Note: The smaller the minimum difference is, the larger your required sample size in order to obtain valid and conclusive results. So a .25% difference is going to require more data in order to gain more specificity. Conversely, a .75% minimum difference would require a smaller sample size, but your end results will not be quite as specific. I find .5% to be a very good place to start in most cases. Though I will sometimes go lower when I get to the final stages of re-testing certain elements of a page.

The Average Success Rate of Your Control Page
This one is easy, but sometimes not so easy, depending upon your current stats program and how it reports things. It's your current conversion ratio. Basically, it's the number of sales per 100 unique visitors to your site/page as things stand before you begin testing. So if you're getting 1,000 new unique visitors per day and averaging 10 sales per day, your current conversion ratio is 1%. Or if you need to figure it out for your own site, it would be the number of sales per day (for example 10) divided by the amount of new, unique visitors (1,000) converted into a percentage.

The Degree of Confidence
This one is a personal choice you'll need to make. In a nutshell, how much Confidence do you want to be able to have in your test results? Generally speaking you'll want somewhere between a 90% and 95% Degree of Confidence. Anything less, and you won't be able to be sure the changes you're making are supported by valid and conclusive data. Anything more and your test will take longer and longer to complete.

Think of it like you might all of the political polls you see on TV. Most of them use a standard ~5% margin of error. This means the pollsters have 95% confidence in their results.

Note: The lower your Degree of Confidence, the smaller your sample size can be. Conversely, the higher your required Degree of confidence, the larger sampling of data required. I personally find 95% to be a pretty good choice, though when I'm testing radical design changes I'll sometimes take it down to as low as 90%. I never, ever go below 90% confidence. The tool will allow a Degree of Confidence from 80% all the way up to 99%, not that I would recommend either extreme.

New Arrivals Per Day
This is simply the number of new, unique visitors who typically hit your page/site each day. This one is only used to give you an estimate of how many days it will take to get a large enough sampling of data, so doesn't have to be 100% accurate. At the end of the day the tool will be looking at the Actual number of impressions, but by providing this number in a reasonably accurate form will give you a rough idea of how long your test will need to run in order to produce valid results.

Number of Treatments, Including Control
Simply the number of treatments you'll be testing. In our example this number would be 4. Or our Control page, plus our three new headlines.

Okay, let's roll it all together now to see just how easy it is.

Here's a link for the beginnings of the testing tool. (Will open in a new browser window.) For your reference, I'm also including a screen capture of what the tool will look like after we've entered our basic testing information.

1. We want to be able to detect a minimum conversion difference of half of one percent, or 0.5%. So we plug 0.5 into the first line.

2. Our current page is converting at 1%, or 1 out of every 100 new, unique visitors. This goes in line 2.

3. We want a 95% Confidence level in our results. So we plug 95 into line 3.

4. According to our stats program our current landing page is averaging 1,000 new, unique visitors per day. This number goes into the 4th line.

5. When we set up our example test (in the last chapter) we decided that we're going to test three new headlines against our control. So a total of 4 in the Number of Treatments section.

From there hit the Proceed button and the tool will start doing its magic. Not that it's really important for you to know, but it applies the Standard Deviation formula to the numbers we've entered, performs some addition, subtraction, multiplication and division, then spits out some preliminary information for us.

For our example test, it looks like we'll need a total of 3,043 impressions from 3,043 different people per headline treatment in order to have a sufficient sample size to make some determinations. This equates to 12,172 total impressions across all four of our headline versions, with the assumption that each will get an equal number.

If all of the numbers we entered are right, or at least close, the tool tells us that we'll need to let this particular conversion test running for 12 days in order to collect enough data to make an accurate assessment.

The tool also puts a variable I've called Current Control Successes Per Day into the page to give you an easy check of your current closure rate. Most people don't know exactly what their current conversion rate is running at, but most do know how many sales per day they average. So this quick check can let them know if the Average Success Rate needs to be tweaked.

Got it? See how it works?

Play with the tool a bit, changing different numbers a little bit at a time. For instance, see what happens when you reduce your Confidence Level to say 90%. Or increase it to 98%. Or change your Minimum Conversion Difference detection to 0.25%.

This will give you a sense of how all of the numbers work in conjunction with one another. They all depend upon each other to some degree.

Throw in the necessity of applying some fairly sophisticated mathematical formulas and it's easy to see why so many people get lost at this stage of the game if they have to do it by hand. It's simply too much, and everything depends upon everything else. My goal in designing a new tool is to keep this confusion and fall out from happening.

Next up: We'll skip over the nuts and bolts of the data collection side of things for the time being since it'll all be built into the final tool, and start looking at what happens after we've started collecting data. In short, how to determine the winners and losers, and making sure we have valid, conclusive results.

Posted by Randy at 09:51 AM | Comments (0)

Conversion Testing 101 - Chapter 2

Continued from Chapter 1

Okay, so now we have a basic understanding why it's important to test and how doing so can improve your Conversions. We've also got the ball rolling a bit by touching on what types of things you can test (we'll cover a lot more later, I'm keeping it to Headlines for now so that it's easier to grasp) and how to come up with our Final testing question.

It's time to start constructing our test, introducing a few new terms to help us keep it all straight.

Where we stand:

We have a site with a landing page that has a headline of:
World's Best Lederhosen Here!

This landing page is doing okay, but isn't converting at as high a rate as we think it can. For argument's sake, let's say our landing page is only convert 1% of all new unique visitors. So for every 100 people who hit the page for the first time, 1 of them ends up buying.

We've decided that maybe our Headline could be a bit better. It could better describe what we're selling; Or it could have a better call-to-action; Or it could stress the benefits of our product in a stonger manner. It could be anything really, but at least we've narrowed it down to deciding we want to test some different headlines.

So what's next?

Well, in the statistical world next is designing our test. Coming up with Variables, Values and Treatments. Let's take a moment to define what these three new terms mean.

A Variable is simply the General element we have chosen to test. In the case of our example, the Variable is our Headline. In other tests it could be a Price, the number of fields in a Form, the general coloring or layout of a page/site, etc. It's just the general thing we have chosen to test.

A Value is the specific option we intend to test. In our little example we have our current headline that will serve as the Control, plus I want to test three new headlines. Which ties back in with our Final Testing Question: We want to know which of the four headlines (1 control plus 3 new ones) will perform best.

The last definition is Treatments. In a nutshell, a Treatment is the more specific version of your Variable and Value. Meaning instead of saying we want to test the headline of our landing page (Variable), or we want to test to see which of four headlines performs the best (Value), we lay out exactly what we'll be testing.

So in the case of our example we already have one headline, which will be our control. So we need to come up with three other headlines that we think may have a chance to improve conversions. Our four treatments look like this:

Treatment 1 (Control): World's Best Lederhosen Here!
Treatment 2: Top Quality Goats' Hide Lederhosen
Treatment 3: Authentic Austrian Lederhosen
Treatment 4: Great Prices on Leather Lederhosen!

Do you see how we can test for different things all within a single test? We have the very generic control headline that may appeal to the masses. But then we're also testing against some different benefits shopping at our site can deliver, separating them to see which will have the most impact. Are people looking for lederhosen made from goat hide? Are they looking for authentic lederhosen, foregoing any knock-offs? Are they looking for the best price?

Even though we provide all of the above, which we stress as a benefit can have a large impact on how our site is viewed by our visitors, and how many of them convert from lookers into buyers.

So there we have it. We have our first test constructed and ready to go. We know what we're testing, both generally and specifically. And we've constructed our test in such a way that we can hopefully get a better idea of what Hot Buttons our potential customers may have that will naturally increase conversions.

See, it wasn't hard at all! With just a few tips and by following the above process, you'll be able to come up with tests for your own site(s), making sure you have a valid testing question.

For the record, the tool I'll be developing will help you to make sure you always have a valid final testing question, among other things. My goal in creating the tool is to take all of the guesswork out of the process, naturally and without anyone having to think about it too hard.

Next Up: How do we tell when we have a Sample Size that is sufficiently large enough to have confidence in our test results?

Posted by Randy at 09:12 AM | Comments (0)

September 11, 2006

Conversion Testing 101

Yes, it's finally time for me to start this series on Conversion Testing. Okay, okay... It's well past time to start it and I know it. It's just been very, very hectic! That said let's start digging into it, starting with the Basics.

First, let's start off with what I mean by Conversion Testing.

There are several kinds of tests you --as a webmaster-- can conduct, as well as several different methods you can use. Sometimes you'll see the methods referred to at Split Testing, A/B Testing or even Multivariate Testing. I consider it my job to de-mystify this stuff as much as possible, and frankly I do not think it's necessary for the average person to understand all of the various terms or mathematic formulas that go into conducting conversion testing.

In other words, you shouldn't have to hold a Phd in Mathematics and Statistical Analysis just to conduct a valid test.

We will have to use some common terms though, so that we're all talking about the same thing. I'll point out the terminology I use as I go along, and try to create a little Glossary down the road so that we all stay on the same page. So when you see me referring to Testing or Conversion Testing I'm kind of rolling it all into one big ball.

My goal somewhere down the road here I'll be constructing and releasing a tool that will allow you to conduct tests, as well as know at a glance when the tests are valid and conclusive.

Okay, now that that's out of the way...

What sort of things can you test help you increase your conversions?

A much harder answer here, because you can literally test anything and everything. For instance, you could test the Headline on your landing page to see if one version clicks better with your users. You can also test your order form to see if you're putting too much friction in the path of your visitors. You can test things as small as how a Submit button looks to total redesigns of page layout and content.

Or for that matter you can test your offer, your benefit statements, your price point, etc, etc, etc. Or your can test to see if people coming from one source (eg Google) are buying at a higher or lower clip than other (Yahoo) in order to make decisions on where your PPC emphasis or optimization efforts can give you the most bang for the buck.

Literally, you can test anything.

We're going to take a very simple example to get the ball rolling.

Let's say you have a landing page that has a headline of something along the lines of World's Best Lederhosen Here! and you're not sure that your headline is the best it can be.

So here you have what I'll hereafter call your Preliminary Testing Question. You can ask this Preliminary question several different ways, but they all mean basically the same thing. You could word it: Will another headline perform better and bring me more converions? Or: What will happen to my conversion ratios if I use a different headline? Or: How can I determine if a different headline would increase conversions?

Bottom line, you should always start with a Preliminary Testing Question so that you know where you're at now and what you're trying to determine. Make sure to jot this question down somewhere so that when you refer back to your test weeks or months down the road it'll be clear what you were hoping to test.

Next up, we want to take our Preliminary Question and break it down into something we can use in our test. This may sound goofy, but you need to do it. You need to get yourself a Final Testing Question. Some refer to these two questions as Preliminary and Primary, which has always been too confusing IMO. The words are too close in spelling, so nomral people end up getting them confused.

I use Preliminary and Final, because that's what they are! One is a Preliminary question and the other is a Final question.

There is a pretty easy way to tell when you have a Preliminary Question as opposed to a Final Question. It comes down to how the question is asked. The Preliminary question is more general, while the Final Question is considerably more specific. The easiest way to tell when you have a valid Final Question is if it starts with the word Which. (See, I told ya it was easy.)

99 times out of 100 a question that doesn't start with Which isn't specific enough to be a Final question. 99 times out of 100 a question that starts with Which will be specific enough.

For instance, looking at our above example let's say you've decided to test a few different headlines against your current one. You'll usually want to leave your original in the mix to be your Control, since you (hopefully) already know how well it performs. So your Final Question could be something along the lines of: Which of 4 different headlines will perform the best with regard to Conversions.

Quick rule of thumb... your Final Testing Question should always begin with the word Which. Make sense?

Let's knock off here before this single post turns into a friggin' novel. So a quick review...

You can (and eventually should) test pretty much anything and everything when trying to improve your Conversions.
Your first duty when getting ready to start testing is to come up with a Preliminary Question to get the ball rolling.
Once you have this Preliminary Question get more specific so that you can start constructing your test.

Next up ... Variables, Values and constructing your test.

Posted by Randy at 12:18 PM | Comments (0)

April 11, 2006

Analytics. Hunh? Wot's dat?

Sometimes we can get confused by unfamiliar or overly technical terms that are used in The Biz. So today let's look at one of the most important and misunderstood terms out there: Analytics.

What is it and why you need it.

In its simplest terms, Analytics is simply some software that allows you to be able to sift through a lot of information in order to tell what visitors to your web site are doing. It can be as simple as knowing how many visitors you get each day and some information as to how they arrived at your site. This is the sort of Analytics data you can get from something like the free Webalizer analytics software.

Very basic, very rudimentary but nonetheless better than nothing.

The next step up the ladder would be software that gives you the above information, plus can let you see click paths taken through your site by visitors. Sort of a 20 people started on this page, then went to that page sort of thing. Software that provides this type of data include Urchin (which I use), Google Analytics (which is what Urchin is now, though it's a bit different than the installed version I use), Clicktracks and the like.

These give you a lot more detailed information than you would otherwise be able to get access to. Many of these more powerful analytics solutions will even allow you to follow Sales from beginning to end. For instance, what keyword phrase and search engine someone used to find your site, each page they viewed and what they purchased.

This is the sort of detail you're looking for if you're going to run a web site. If you don't have this sort of detail you're simply wasting your time and the time of your visitors, because you're not doing everything you can to understand what they're looking for and putting your best foot forward. Having a web site but not really paying attention and managing it is the #1 sin far too many hopeful e-trepreneur's commit.

Ignoring feedback from your customers is a dumb way to run a business. Actively ignoring feedback they're giving you without even trying is the reason so many commercial web sites either fail completely or fail to reach a fraction of their potential.

You simply have to pay attention, and do everything you can to supply what they need. That's your Job!

Let me throw out what some might think is a funny way to look at it.

When people search they're looking for something. 9 times out of 10 they wouldn't mind paying for it if they find exactly what they're looking for and it's easy to get/use. People understand the concept of You Get What You Pay For, so as long as you make it easy for them to find you and buy from you, you're halfway there. The other half is simply supplying what they're looking for in the first place!

Soooooooooo... If you don't currently have any way to tell what people are doing you're missing the boat. If you don't have a way of measuring the effectiveness of your web site, you're probably missing out on a lot of business.

Look at it on your own site. Look at the amount of traffic you get in an average day. Then look at how many sales that traffic is producing for you.

Do less than 1% of your visitors buy from you? (That's average btw, so don't feel too bad when the answer is Yes.)

Still, doesn't this fact trouble you? It should!

So, what do we do about it?

We first make sure we can Measure what's happening. Without being able to have some way to measure both how people reach your site or what they do when they get there you have no chance of improving things.

Let me put this in other words by way of example that may help...

Let's say for instance that you have a site that get 1,000 new unique visitors each day (don't get hung up on the new unique visitors terminology for now! I'll explain it later in the series.)
Let's say the product or service or average sale works out to be $25 for each sale.
Let's also say that from these 1,000 people the site is making you $100 per day, or $3,000 per month. Which is not bad, but when you dig into the numbers a bit that's 4 sales per day. Or to put it another way, for every 1,000 new unique visitors you're getting confirmed sales to 4 of them. Which equates to a 0.4% conversion ratio.
Let's also say that you need it to be at least 3-5 times income each month from your site to make you comfortable in divesting yourself of other time consuming things in your life and becoming truly independent.

Given the above scenario, what are the paths that will get you to that $9,000 to $15,000 per month figure?

There are three answers.

1.) You leave your site as it is and figure out some way to increase your qualified traffic by 3 to 5 times what it is today. This is often very difficult to do, and each market does have an absolute traffic top end. If you're already ranking well for your key phrases and 2nd/3rd tier phrases you're probably close to your max traffic expectations.

2.) You make some changes to your site so that you convert more of your current traffic (window shoppers) into Buyers.

3.) You do a bit of number 1 and a lot of number 2.

Those are your choices.

Which is easiest? Which is the most effective?

Well, the sad part is that most webmasters only look at #1. They never even realize that they're only converting interested buyers at point 4 percent. They don't even think about the fact that getting this up to a lowly 2% would increase their income overnight by 300 plus percent of its current production.

Break time... Did you get that part? It's a very, very important point. So let me cover it again.

Your site is making you $1,000 per month. You get on average 1,000 new visitors each day. Of those 1,000 vistors, 4 of them become customers, for a 0.4% Conversion To Sale (CTS) ratio.

You make some changes to your site to make the buying process more appealing, easier and more sensible for your visitors. Because of these (usually small) changes your CTS jumps up to 2%, or 20 sales per day.

That's $15,000 gross revenue per month.

Got it?

Without doing a single thing to improve your SEO efforts or to get more traffic to your site you're now making $500 per day on average instead of $100. You're making $15,000 per month instead of $3,000.

Note here that I'm not saying that $3,000 per month is a bad thing. It's just not nearly as good as $15,000. Which can almost always be attained with a bit of testing and a bit of common sense.

The moral of the story here is that you really need to take control of your web site. You really need to know how people are finding you and what they do when they get there. Without this basic data you stand no chance of making your site the best it can be for your visitors and most certainly not for your potential customers.

That's Analytics in a nutshell. That's the tool you can use and should be using to make your site more successful.

(Note: This is the first part in a series. In later posts I'll be walking you through the entire process of how to test things, what to look for, easy changes you can make to improve CTS, etc.)

Posted by Randy at 06:47 AM | Comments (0)

January 15, 2006

Microsoft and PPC (Pay Per Click)

Well, the day some have been waiting for is almost here.

Many have been wondering when Mighty Microsoft would take on Google where it could hurt them most, as well as taking on Yahoo's Overture PPC system instead of feeding it $$$'s by using their system.

According to this Associated Press story Microsoft/MSN is shooting to fully release their own PPC component by June of 2006. Or I should say they're planning to release it in the US by June.

PPC, or Pay Per Click, is a huge deal. As I've written here previously, the vast majority (90% +) of Google's revenue can be directly tracked to their Adwords and Adsense sells. Yahoo! has already been competing Google's Adwords model via their Overture purchase from some time ago, and have introduced their own service to compete against Adsense as I wrote a bit about here and here.

Now it would appear that MSN is finally preparing to enter the PPC fray.

As I've said before, Microsoft is truly the Sleeping Giant. They have a huge network of sites they can use to feed a PPC component, and lots of money to throw at creating a better mouse. I've not seen the interface as yet since their pilot adCenter program is a By Invitation Only thing and I really don't have a personal need to sign up. However in reading through some of the documents and specifications it appears that this is exactly what they've been attempting to do in secret. To build a better PPC program.

(Click on the Learning Center link in the adCenter page to see most of those documents.)

It also appears that they're taking Click Fraud quite seriously and being very proactive in stopping it before it happens, rather than relying on reports from advertisers. Which is more than can be said for the others from everything I've been able to see.

Since their entry into the realm of Search MSN/MS has been pretty open to listening to Webmasters and SEO professionals IMHO. From initial indications it looks like they've been listening pretty closely to PPC advertisers as well.

Interestingly, it looks like they're going to give their PPC advertisers ways to target specific types of searchers. Their system attempts to support targeting via gender, age, geographic location, days of the week, time of day, etc. So if you truly understand who your target audience is you should be able to better limit your advertising spend yet still reach those you're trying to reach. This targeting aspect looks to be a really cool feature for advertisers.

It's sure going to be an interesting year in 2006! The sleeping giant is starting to awaken from its slumber, and we all know how grandiose some of the plans coming out of Redmond can be. Let's see if they can pull of some of these grandiose ideas. I'm hoping they do, because it will force others to follow suit and offer better tools and better control for all advertisers.

Posted by Randy at 10:03 AM | Comments (0)

January 09, 2006

Starting a business with little cash

Okay, now that I managed to survive Christmas it's time for me to dig in and get started on some catching up. This first one came across my desk almost a month ago, and is really neat.

Jennifer Laycock of Search Engine Guide fame started a little case study back in December to document the process of getting a web site up and running --and more importantly building a good foundation for a profitable e-business. She's been keeping a diary of sorts so that others can see how it's done and glean some ideas to use with their own endeavors.

It's a really good read. Jennifer has laid out, in plain English, each of the steps she's taken. While not all of the ideas will work for every type of site, her series of articles can definitely help anyone new to the e-commerce world.

The series has been dubbed Zero Cash, A Little Talent and 30 Days. I highly recommend taking the time to start at Day 1 and reading through each entry, taking notes on things that would fit in with your own site.

Though the series is due to end in a couple of days, I hope that Jenn releases updates six months, one year and eighteen months down the road. Sort of wrap ups of how things started, where she was at the end of one month and where she is at each of those markers. It's already a very instructive exercise, but I think it could become even more valuable when a little more time has managed to pass.

Posted by Randy at 08:24 AM | Comments (3)

October 09, 2005

Yahoo! Stores

A question has recently been pestering my (marketing) mind a bit. And that is, Are Yahoo! Stores a viable, or possibly even a better option for the average iEntrepreneur (Internet Entrepreneur in Randy-speak) who wants to open their own business on the Web?

Here's the way I've been looking at it when researching the question, with positives and negatives.

The Negatives first...

1. A Yahoo! Store, at $39.95 per month with a $50 setup fee for their basic account, is a bit more expensive on an ongoing basis then regular hosting would be for many. Note that this is looking at it from an ongoing, hosting/software only perspective. From a start-up perspective it is likely going to be less.

2. You have a bit less control over a Yahoo! Store than you would otherwise, if you were a code junkie and liked to tweak things. You also have less control over the type of Statistics you can gather since you're basically locked into what is offered, instead of being able to choose your own stats package.

Some things are just harder to do because of this lack of control.

That said, Yahoo! have recently taken some pretty healthy strides to overcome these types of deficiencies.

The Positives...

1. A Yahoo! Store does not require the type of technical knowledge that most other shopping cart software would. They've done a very good job of making it easy to get a store up and running.

2. They've even removed a lot of the hassle out of the process where getting a Merchant Account is concerned. Though you may pay a bit more for their integrated merchant processing solution than you could get on your own, it's easy. That said, pretty much any merchant account can be integrated. So it's not something that you're locked into.

3. With Yahoo's recent improvements, you can gain back some of the control over your site that simply wasn't there before. It used to be extremely difficult to SEO a Yahoo! Store. These days it's not. If you know HTML you can even totally customize your site.

4. As a Yahoo! Merchant you are privy to some pretty decent discounts on various advertising packages through Yahoo! This could certainly help a person to gain quick exposure with a reasonable advertising budget. Another money-saver is that you don't need to concern yourself with purchasing an SSL (Secure Socket Layers) Certificate for secure transactions.

5. Ease of Use. Simply put, getting a store up and running is a breeze, even without one having a technical background. This may actually end up being a money saver since an iEntrepreneur would not have to hire a Design Firm to design the site and a Tech to deal with your shopping cart software.

6. 24 Hour Support. You're simply not going to get this from the average design firm, tech or host. They even give you 30 days of Free Consulting to help you get off to a good start quickly. If nothing else, the folks at Yahoo! are absolute wizards at Marketing on the Internet. They have years and years of experience across multiple markets. It would certainly be nice to have such expertise on your side.

7. Access to the Yahoo! empire. That's right, if you don't mind spending a little money you can get access to all of those Yahoo! visitors, as well as visitors to Yahoo! partner sites. For those who may not know, Yahoo! is a behemoth in the Internet World. Their reach is everywhere.

8. Yahoo! has become much more open with data over the last year or so. This could be a key issue, since Information can not only make or break your business, but if used correctly could lead you to emerging, very lucrative markets before they become overwhelmed with compeitition.

9. They've made Yahoo! Stores options easily expandable. Meaning you could start out with a basic $40 per month package to test the waters, then expand your options easily and quickly when needed.

10. Possibly the most important, though intangible advantage is having the ability to immediately build Trust.

Building Trust between yourself or your site and prospective customers is one of the most difficult things to do, and is an absolute requirement if you're going to get the sale. This is just Human Nature. People are concerned about all sorts of privacy and security issues when purchasing something online to one degree or another. As they should be.

So let's say for example that you opened Joe Blow's Surf Shop on the web. Nobody is going to know anything about Joe Blow or his shop, so he's going to have to expend significant time and energy --which translates money-- to build Trust.

But what if Joe opened up his online shop as part of the Yahoo! Shopping Network? It still has Joe Blow's Surf Shop graphics and everything, but Joe's site is now also part of one of the more recognizable and most trusted Brands in the world! Is this worth a few more bucks per month?

After taking a new look at Yahoo! Stores, I'm pretty well convinced that the positives far outweigh the few negatives that still exist. Definitely for someone new to Internet Marketing because of the ease of use and limited cost of start-up. But even for old fogey's like yours truly who doesn't have a technical barrier and already has server space (so no cost hosting) available to him.

I've decided to start doing a little testing to see how well the perceptions I've based upon my research match up to reality. I'm going to do it a little bit differently. Rather than start a shop that I already have a product in mind for, I'm going to attempt to identify some products or services that are In Demand, then see if I can source someone or several someone's who will be willing to partner with me to function as a Drop Shipper.

I really don't want to have to --and frankly don't believe in having to-- stock a bunch of inventory. Sure I could probably get the products at a little better price, but I would then have an initial cash outlay to purchase the stock, have a place to store the inventory and have to deal with all of the shipping.

I want to stay away from that business model. Not only because I want to see how expensive or inexpensive it will be to get up and running (I'm guessing somewhere in the $500-$800 range) but because I want to come up with something that will be repeatable. Meaning coming up with a solid system, using Yahoo! Stores, to enable a person to diversify to both reduce market shift risks and also to expand their business.

I'm really convinced making use of a system like Yahoo! Stores is could ease the entry concerns of those who Have The Dream of owning their own home-based business or who want to become more independent finanacially. But somebody needs to work out the kinks and come up with a method that is as foolproof as possible.

I've got enough experiene and expertise in Internet Marketing to know if something is working or not pretty quickly. So when (not if) I make a mistake I should be able to identify and correct it before too much damage is done. You'll probably see me brainstorming with myself here in the near future.

Once I've nailed down the details I intend to release them so that they can serve as a guide for burgeoning iEntrepreneurs with little or no experience who want to Live The Dream.

Posted by Randy at 08:48 AM | Comments (1)

September 24, 2005

Google the ISP?

(Note: I'm going to try to keep this as non-technical as possible, but it's not going to be easy! I'll explain some of the terms as I go along so hopefully it makes sense to everyone. The term explanations will be in italic blocks of text.)

So what the heck is Google on about?

Back in January of this year there were job postings on Google where they were looking to hire people who were experienced in negotiating "dark fiber" contracts. An original story about this development still exists over on c|net news.

The term Dark Fiber refers to fiber optiic lines that have already been laid, but are not in use. In years past a lot of companies laid a lot of fiber. Much of it has never been used, some was used but is not now being utilized. Usually because whoever owns it has either gone out of business or ended up in bankruptcy.

Word has it that Google has been quietly and happily snapping up these dark fiber contracts at bargain basement prices. Because of the current climate in the Telecom industry, as well as because of the current glut of bandwidth that's available out there, these networks are able to be purchased for far less than it would cost one to lay it themselves.

It was originally thought that Google was buying up the dark fiber to beef up their own network and to help reduce costs so that they wouldn't have to write that big check they've been sending to the likes of AT&T each month. The dark fiber purchases made sense when viewed in this light, so nobody from the outside looked any farther for explanation.

Slightly later in the year Google began letting RFP notices to relevant tech firms regarding building a DWDM fiber optics network. The RFP process was reportedly completed earlier this month and Google are now reviewing the bids.

DWDM stands for Dense Wavelength Division Multiplexing and can drastically increase the bandwidth one can send across a fiber optics network. All very techie, and you don't really need to grasp the minute details. Just know that we're talking Bleeding Edge technology here. Only a handful of the largest telecom providers have anything like DWDM available on any part of their network; And even those had to pay a lot more to build it out than Google will, because the costs have fallen quite quickly.

One source, IP Media Monitor suggests that Google could build an entire US network for under $100 million --not counting what they've already spent on the Dark Fiber to this point-- based upon information received from those in-the-know. The full story is here, though it does require a free subscription to read.

The increased bandwidth ability and dynamic possibilities of a DWDM network would be very useful if Google were going to start delivering high-bandwidth applications. Such as Video, Audio or VoIP (Voice over IP) services. The VoIP component again makes a lot of sense considering their recently released GoogleTalk software.

However such a network could also be valuable for other things. Some who have seen the actual RFP requirements have stated publicly that the details point to idea that something more than Video/Audio/VoIP is in the works.

A nationwide DWDM networkd could be very valuable if say --for the purposes of discussion-- Google wanted to jump into the ISP market to compete directly with the Telecoms and Cable broadband providers. They would most definitely have the ability to roll out a nationwide broadband network with limited financial exposure on their part. The only problem with this concept being that Google would still be constricted from doing so because of the whole Last Mile problem that every other provider-wannabee has stricken with.

The deal has always been that the big telecoms and cable networks, who happen to own that Last Mile network to every home or business, really don't want the competition. And since they own the wire/cable they can charge pretty much whatever they want to anyone who wants access to their local network. Thus severly limiting competition and keeping broadband prices artifically inflated.

But now comes along Google WiFi, something that first came to my attention a few weeks ago.

Currently it's a Beta program that they're running in the San Francisco area. In fact, --from here in the Midwest anyway-- wifi.google.com redirects to the main Google page. So I can't even give you a good URL that explains the details. However I can still reach their WiFi FAQ page and Download page, which at least proves that I wasn't seeing things before.

Google WiFi, as I understand the concept, is basically a Secure Access Wireless Network. Sort of similar to what many people have in their homes and offices where they can set up a router that will send and receive encrypted data, rather than run CAT5 cabling to each machine. This Secure concept is different from most WiFi networks, simply because of the fact that it's Secure from your computer to the Radio Station and back.

Google WiFi would more than take care of the Last Mile problem I mentioned above. Plus they have this Dark Fiber Network that they've already purchased. And they're reviewing RFP's to fill in the gaps, as well as bring the network up to specs that are better than anyone else can currently offer.

So is GoogleNet far behind? Is that what they're going to do? Compete head-to-head with the big telecoms, cable modem providers, MSN and Yahoo/SBC via Secure WiFi connnected to a vast nationwide fiber optics network?

Again, I must point out that this is all total speculation on my part. However the parts and pieces they've already assembled certainly do lead me to this (rather shaky) conclusion!

The thing about using WiFi, with the way it's been expanding its reach recently, is this: It's quite possible that a single Radio Station tower --each of which only runs about $30,000-- could easily service homes and businesses for a 20 mile radius. Forget about the Last Mile, it's not a concern with today's WiFi capabilities. In pretty much any metropolitan areas the number of users utilizing a single tower would become a more serious issue than the reach of the signal.

Plus, even a few WiFi Radio Towers in any given area would allow broadband service to rural customers who at present have no broadband options. We're talking similar to Cellular Towers here. If you can get a cell phone signal you should be able to use WiFi from the same tower, in theory.

Are these the markets GoogleNet will be going after? The rural component makes definite sense, though we're not talking huge numbers here. Though when you're only talking $30,000 per Radio Station tower, you wouldn't have to have huge numbers to make it a profit center after a few years.

The experts are saying that Google could certainly roll out the beginnings of a nationwide network in under a year if they chose to do so, assuming their San Fran beta test of Google Wifi goes well. And the estimates of the total cost are very attractive for a behemoth like Google.

They're talking in the $3-4 billion range for a network that has complete nationwide coverage. Maybe less if Google can strike deals with some of the Cellular companies that already have existing towers that have space available. Or to put it another way, just about the same amount that eBay recently paid for Skype, if you add up the cash plus stock options eBay handed over. Skype is just software, not some sort of network with tangible assets.

No matter how you look at it, it's all that much to become the major provider of Internet services in the US market. And it's been said that Google is currently sitting on a stockpile of some $7 billion in IPO cash while deciding their next move.

In a few years a person in the US may be able to be completely wireless. Wireless PC's at home, Laptops that you can use at home or anywhere else, Handhelds that will work from anywhere. And you can take any of the above to a completely different city and log onto the same service provider with no hassles!

It would be a different world, wouldn't it?

And what other advantages would such a notion give Google that they now struggle with?

The Personalization and Localization of Search.

Today they don't have a good way to tell where you are located or what your personal preferences are. Throw in the above however, where you have to install Google software on your computer and they know exactly which tower you're coming through... Suddenly both personalization and localization become trivial issues.

While I'm on a roll with my speculation, let's throw another monkey wrench into the mix.

Google already has all of these advertisers lined up for their Search component, right? And their Gmail delivers ads as well. What would happen if Google made the initial investment to build out this new Secure WiFi Broadband Network and then made it 100% free to use, in exchange for the advertising revenue potential?

Free Broadband? Everywhere? I'm not sure I can even fathom the branding power of such a concept! But if not free, certainly at a reduced cost from today's broadband pricing, given that they'll be able to easily monetize other things.

As a final warning, this is all complete speculation on my part at this point in time. But all of the pieces of the puzzle fit.

I for one wouldn't mind seeing the boys and girls at Google, with their unusual approach to everything, take on the telecom/cable industries and their crushing hold on broadband.

Posted by Randy at 10:27 AM | Comments (0)

September 17, 2005

MSN Search API (part two)

Following up on the last entry...

MSN still has not put any documentation out there for the use of their new API, save for the Visual Studio SDK. I and a handful of others have taken it upon ourselves to work out the kinks and produce something for developer's to start working with.

What I've created is a very basic MSN Search tool, written in PHP that pulls its results through the MSN API. It's sort of a proof of concept thing that will provide you with the basics of how to construct your queries and retrieve the results.

Note that this first test run version also makes use of SOAP, or more specifically NuSOAP, to connect with the API. You'll need this installed as well, though you may already have it since Google's API also makes use of SOAP.

If you want to try it out for yourself, the working version is here. You'll also see it in the lefthand navigation block just below the Common Link tool.

To begin working with the code yourself, you'll want to grab the copy I've zipped up and placed here for download. It carries a GNU License as is normal for my tools.

There's info in the header of the script as to where you can get NuSOAP for free at SourceForge if you need it. Or, alternatively I've made the version I have installed here available in a zip file. You can grab that here if you would like.

As usual, I've commented the code so that hopefully you can tell what's going on everywhere. You shouldn't have any troubles with it, but if you do feel free to give a yell!

I'll be playing with it more as I can find the time, now that the hard lifting is done. Sorting out this first part, without any documentation at all, took me the better part of two days!

Posted by Randy at 11:44 PM | Comments (0)

September 14, 2005

MSN Search API is here!

I'm not sure how many caught the c|net news article late last week, or the short and sweet confirmation on the MSN Search Blog last week, but it's really true. MSN is coming through with their own API for people to use in colating the data they have available. It also looks like they're going to come out of the box swinging!

What I know so far:

Their Virtual Earth already has a way webmasters can utilize it. I expect this will get better with time, though it is already quite good. In my mind Virtual Earth is like the next step in evolution from Google Maps or even MSN Maps.

Hopefully they follow the same sort of idea they have with the Virtual Earth connectivity, as it can even be used for Commercial Applications. (Wooohooo! Though my intention is still to release most everything, if not everything, freely.)

The query limit is going to be more akin to what Yahoo's API license than to Google's. Same concept really. The developer applies for an Application ID to build into their API app, then the query limit counts against the IP number that is running queries. MSN's beginning query limit 10,000 per day per IP. So double Yahoo's current beginning limit and blowing Google's limit into the dust.

They have some infomation uploaded already. The main area is here. One thing you'll note there is that the only SDK currently available is for Virtual Studio .NET 2003 or above. Which is a bit of a pain for those web developers who really have no need to drop the kind of dollars that VS costs.

I've already asked the question on their very new forums, and you are not roped into using (or buying) Visual Studio to make use of the MSN API. You can also connect with it via SOAP, much like with Google's API I would imagine. I've not tinkered with it yet, and there is little, okay no documentation at this point. But I've raised the point on the developers forum and will start tinkering as soon as I can find a few spare moments.

If nothing else, I can attempt to document my experiences here for the benefit of others. Though it would be very nice if the MSDN or MSN folks were to release PHP, Java, etc toolkits as all the rest do. It wouldn't surprise me at all to see this happen in the very near future, as MSN has always been quite responsive. And it will only help them to reach already established API developers.

More as I know it!

Posted by Randy at 01:54 PM | Comments (0)

August 14, 2005

Sunday Funnies & Google Print

Okay, so it happened a few days ago. I'm just getting around to catching up on some of these news headlines ! LOL

Anyway, here's my (slightly more humorous) take on the Associated Press story about Google Print declaring a temporary halt to its Library Scanning Project. The AP story references an announcement from Google's Adam Smith, but doesn't provide a link to it. For your convenience, here is said announcement, found under the strikingly Orwellian title of Making Books Easier To Find.

The gist of the announcement is a change that is being made to the Scanning part of Google Print. They're giving the authors (how are they going to positively verify that someone is the actual author?) opportunity to opt out of the program if they would like, or they can opt out some of their titles but leave others included.

It's a gracious gesture on Google's part, and is in perfect agreement with Google's approach to everything else they do with indexing web pages. But it's still problematic. And has raised the ire of many authors and publishers.

My own view is that this new way of doing things smacks of the same disaster-in-the-making that I ranted about months ago regarding the Google Autolink feature they integrated into the Google Toolbar. In both cases everything was going to be automatically opted in, whether the author wanted to be a part of the program or not. At least Google Print is giving authors of published works the ability to Opt Out. Autolink doesn't afford that option.

Is this the way Google has always done things? Yes it is. It's part of their culture, me thinks. It's definitely part of their internal policy based upon everything I've ever heard them say or read in their official statements.

And see, that's where the problem lies.

Google is apparently unaware of how Copyright works. Or they think they're some special case, which is patently untrue.

Copyright affords an author immediate protection of their works. They law states that the author need do nothing else to gain this protection. It is immediate and automatic, and there is no mention of any Opting Out process.

Indeed, it is the exact opposite of Google's new procedure. In order for the author's work to be disseminated the author would have to grant a license for use, or in Web-speak the author would have to Opt In!

As noted in some comments by Patricia Schroeder, CEO of the Association of American Publisher, that were published yesterday, Google's Opt Out policy "shifts the responsibility for preventing infringement to the copyright owner rather than the user, turning the principle of copyright law on its ear."

I agree. So do the courts.

Jonathan Spira, chief analyst of an IT research firm called Basex, which focuses on knowledge sharing and creation adds, "Google does not enjoy a natural immunity from copyright law. The way Google approached the relationship with publishers and authors did nothing to assuage the feelings of the copyright holders."

Again, I agree whole-heartedly.

My personal view is thus...

If something is produced on the web in such a way that it is publicly available I have no issues with Google's normal policy of spidering and including snippets of the text in their search engine. Even though these snippets are placed right next to Ads that Google gets paid for. I simply do not consider this to be copyright infringement.

But on the other hand, and I say this even though I rather like the concept of Google Print's mission statement, whenever you're talking about taking the proactive action of scanning works which do not appear on the Web, you've stepped over the line. You've changed the nature of the work by changing methods of access to these copyright protected works.

In this type of case Google needs to take a serious look at their internal policies and change them. It should not be Opt Out if you're an author and do not want your works included. Instead nothing should be included until and unless Google has received verifiable communication from the copyright holder that grants them license to re-publish these works digitally.

The same holds true if Google is altering content, even if it is already publicly available on the Web. Ala Autolink.

The key being that any time Google, or anybody else for that matter, takes proactive actions that change the nature of copyrighted material, they first need to gain permission to do so. Whether this actually changes the content --Autolink-- or the simply changes the way in which it is accessed --Google Print.

This is simply a case where Google's internal policies is mistaken. They are not above the law. They need to realize this fact and alter their internal policies and procedures, as well as the way they do things immediately. Better to take those actions now rather than wait until they end up in court trying to defend how they've tried to change copyright law.

Posted by Randy at 06:02 AM | Comments (0)

July 22, 2005

Pay a host or run your own server?

The first topic we need to examine is whether one should pay someone else to host their site(s) or lease their own server from one of the many Colo firms out there today.

My view is that if you're only running one or two sites you're probably better off paying someone else monthly or yearly fees to provide your hosting. Just from the financial perspective it really doesn't make much sense to run your own server if you've only got a few domains.

Where is the cut off though?

Well, to put it plainly, I lease my servers through EV1Servers, which is a division of Everyone's Internet. With their Value Series I can usually pick up a server for around $100-120 per month. If I have some time to wait for it, I can usually pick up one of their deals where they have a $1 setup fee too.

These include up to 1,000 gigabytes of bandwidth transfer each month and are pretty stable machines. It's pretty easy to fit at least a few hundred domains on them if you need to, though I would caution you about getting a server for your own use and then going into the hosting business. It can be a huge pain in the arse, plus once you accept a few dozen clients you're pretty much locked into them for life. So don't get yourself into the hosting biz unless you really want to be a host. Forever.

That's kind of the breaking point for me. If you've got enough domains, or have a few domains that are pumping through enough traffic that your hosting is costing you $150 or more per month, then you might want to consider leasing your own server. Realize going into it though, that these figures are for an unmanaged server, meaning it's going to be up to you to set it up, secure it and keep it that way.

It's not all that difficult to do, but if you've never done it before it's all going to be a little bit alien to you. Not to worry if that freaks you out. My next post will be about the stuff I do with all new servers to get them set up and perking. As well as what I do each day to make sure everything is still running nice and smooth.

The only way I would advise anybody to jump to becoming their own host before the $150 barrier is if you're really a techie at heart. If you are, you won't have any issues at all with running your own server. In fact, you may be able to partner with someone else who is spending too much for their hosting needs, where they pay the cost of the server and you get to host your domains on it with theirs in exchange for setting up and maintaining the server.

Don't take the above to mean that you have to be some kind of geek to run a server. You don't. But you can't have an aversion to occasionally get in there and get your hands dirty with command line administration. Again, it's not hard. But it's "different" than what you may be used to.

Posted by Randy at 03:50 PM | Comments (0)

June 18, 2005

PCI Compliance

Disclaimer: None of the following should be construed to be legal advise. Views are based upon my own understanding of the issues from my own research.

This post is meant to be a Heads Up for all who accept credit card payment via their web site, though PCI Compliance actually encompasses more than just web transactions. Many online merchants have never heard of PCI Compliance. If you haven't, now is the time you need to get in gear and find a solution that works for you.

PCI (Payment Card Industry) Compliance is a good thing in my opinion. It may be a pain in the butt for some, but it's still a good thing !

With that personal opinion out the way, let's explore what PCI Compliance is, what it's supposed to do and what you need to do to get all of your ducks in a row.

PCI Compliance is basically an initiative that all of the major credit card vendors (Visa, MasterCard, AMEX, Discover) have put forward in an attempt to offer better protection to their cardholders. With all of the identity theft going on out there today, it's at least a step in the right direction.

Those who have already been taking their customer's privacy seriously, and who have already been guarding this type of ultra-sensitive data as they should, have nothing to worry about. However I imagine that many webmasters and merchants who though they had good security procedures in place are due for a real eye opener.

Which, again, is a good thing IMHO.

Basically, PCI is going to require anyone who accepts any of the major credit cards to do an assessment of how secure their internal systems are. At the very least, everyone is going to have to complete a questionaire that will make them take a good, hard look at their internal procedures. The vast majority of small businesses will fall into this category.

Merchants with larger volumes will have to do more. They will complete the questionaire also, but they will also be required to contract with one of the approved 3rd party companies who will scan their systems, looking for any security holes or other deficiencies. These basic requirements are placed on any merchant who conducts 20,000 or more transactions in a years time with any of the major credit card companies.

Anybody at or above this level has a deadline of June 30, 2005 to get everything in place, and to get your Proof of Compliance filed. Yes, you heard me right. Even though you may have never heard about PCI Compliance before, you have less than 2 weeks to get your ducks in order if you want to continue accepting either Visa or Mastercard for payment!

The issue is that many out there have been far to lax in their data security procedures. Now it's time to pay the piper, as they say.

Currently, there is no deadline requirement for merchants who have less than 20,000 transactions in a year's time. In fact, there are only recommendations from the credit card companies instead of requirements.

Don't expect this to remain the norm though, as there are a couple of caveats. First, your merchant bank can (and probably will) require you to complete and file the questionaire at the very least. They may also require you to contract for a scan to make sure everything is in order.

Why?

Because the credit card companies are going to place the merchant banks on the hook for all fines if you don't provide adequate security that results in theft. And you know the merchant banks aren't going to want to be liable for those fines, especially when it's easier for them to simply require that all of their merchants meet the minimum standards.

In other words, even if you're in the majority and have less than 20,000 transactions per year you should start familiarizing yourself with the PCI Compliance procedures and get everything in place now. You don't want to lose your ability to conduct business after all.

Additional information is available in a special section of MasterCard's site. You can also find a PDF version of the PCI Manual. Visa also offers information about the Cardholder Information Security Program (CISP) on their site.

Many, if not most, of the approved 3rd party providers, such as ScanAlert have a lot of good information on their site as well.

My suggestion to every webmaster who accepts credit card payment is to check with your merchant bank and/or merchant service provider as soon as possible to get the scoop. None of this has been publicized well enough in my opinion, and the standards put forth by the credit card companies leave a lot of wiggle room for the merchant banks.

As a for instance, I've not seen anything yet from any of the merchant service providers stating what their clients need to do. Probably because they do not know at this time, having yet to get the requirements their merchant banks are going to be placing on them. The question begs though whether places like 2Checkout.com are going to require every webmaster who uses their service to fill out a questionaire and/or have a scan of their site conducted. It's certainly within the realm of possibility!

And who's to say whether all of the popular shopping cart systems out there are going to have to make changes so that their customers can comply with the new standards. It's certainly possible, especially for those who store the cardholders data (mainly credit card number and CVV security code) in a database at the time of purchase.

In other words, don't wait. And don't be lulled into thinking that just because you have less than 20,000 transactions and/or use some merchant service provider that the new standards will not apply to you. They apply to everybody, even those merchants who do not offer any type of online payment option, but happen to occasionally send email. Or at least that's the way I read the standards.

Bottom line, you'll definitely want to be ahead of the curve on this one. The merchant banks, merchant service providers and 3rd party scanning companies are likely going to get overwhelmed quickly once it hits the fan on June 30th. Not having all of your i's dotted and t's crossed could make you liable for fines from the credit card companies. Or even worse they could simply refuse to process any transactions for you if you're not in compliance in their opinion. Forever.

I'll be blogging more about PCI Compliance as I go through the process myself (questionaire and quarterly scanning in my case). It really doesn't look too bad to me, but I've always had security procedures in place that are well above the average webmaster. And since I run our servers, it's not going to be a big deal if the scan says that something needs to be updated or tweaked. The same is definitely not going to be true for most, who will have to coordinate with their hosting company.

Get onboard the PCI Compliance train now. You don't want it to leave the station without you, since the consequences can be quite detrimental to your business' success.

Posted by Randy at 07:53 AM | Comments (0)

The Chatterbox