ALGI    affiliate login
UAFL    update affiliate’s information
IAFL    insert affiliate
AFPW  email forgotten affiliate password
LOGN    customer login
EMPW  email forgotten customer account password
UCST    udpate customer information (on account page)
ICST    insert customer (on account page)
ADPR    add product to basket
AUPR    add upsale product to basket
AUPM    add multiple upsale products to basket
QNTY    update quantity of product in basket
RPRD    remove product from basket
ORDR  add/udpate customer information (during checkout)
CTAX  calculate tax
SHIP  calculate shipping/generate shipping list
AUTH    authorize payment

It’s hard to imagine a form that could be simpler: two fields, two buttons, and one link. Yet, it turns out this form was preventing customers from purchasing products from a major e-commerce site, to the tune of $300,000,000 a year. What was even worse: the designers of the site had no clue there was even a problem.

The form was simple. The fields were Email Address and Password. The buttons were Login and Register. The link was Forgot Password. It was the login form for the site. It’s a form users encounter all the time. How could they have problems with it?…

The $300 Million Button

…and I guess it just worked!

(via twitter)

(Article from my brother’s boss–his newsletter and blog are regularly packed with good info).

Click here for an interesting post on the power of using “click here”.

Inc.com has a good analysis of two sites that were modified to improve conversion rates. And here’s an account of a popular online store that has gone brick-and-mortar.

Arstechnica looks at what happened to Urchin after it was bought out by Google.

It’s a follow up to their earlier report on the same subject. There’s a link to that within the article. Definitely worth reading.

And speaking of passwords, we get to see a lot of, er, interesting ones. Although many banks and other sites have instituted frustrating login systems, forcing you to change your password frequently, use a mix of numbers, letters and mixed case, remember a bunch of security questions and the like, there is a good middle ground for your own site and store passwords. Don’t use any of the most obvious passwords, your sitename for both the login and password, and, if you’re generating a password for temporary use, don’t use “temp” “support” or, one of the best that I’ve seen–login: “help”, password: “me”. Personally, I don’t like the auto-generated OpenUI passwords either, as they have the same format, only changing a few digits. And, of course, regardless of the quality of your password, you shouldn’t be storing credit card numbers on the server. A defaced site can be fixed, losing your customers’ card numbers cannot.