[ic] Checkout and Userdb
paul at gishnetwork.com
Mon Jul 19 14:38:18 EDT 2004
> -----Original Message-----
> From: interchange-users-bounces at icdevgroup.org
> [mailto:interchange-users-bounces at icdevgroup.org]On Behalf Of Jamie Neil
> Sent: Monday, July 19, 2004 5:30 AM
> To: interchange-users at icdevgroup.org
> Subject: [ic] Checkout and Userdb
> We manage a website which despite many changes, still converts very
> badly (approx 0.3%) and we suspect it has to do with our checkout setup.
> We have a multistage checkout which starts with a welcome page that
> 1) Existing users login using their email address and password
> 2) New users enter just their email address (a password is autogenerated
> on completion of the checkout
> This is not an uncommon setup, but it's been suggested that it is
> probably putting off customers and that we should allow users to
> checkout without creating an account (even automatically). This is
> backed up by the large (>50%) abandonment rate we see after this stage
> of the checkout.
> So what we want to do is have 3 options at the welcome page:
> 1) Allow account holders to login using their email address and password
> 2) New users who want to set up an account click "New Account" and on
> the next page are prompted for their email address and to choose a
> password (along with other address details).
> 3) New users who do _not_ want to set up an account click "Continue
> checkout" and on the next page are just prompted for their email address
> (optional) and address details.
> The problem with this is that because we use email addresses for login,
> they have to be unique for each entry in the userdb table. So at the end
> of the checkout process, if a user has not entered an email address or
> if they have entered an address that is already in the userdb table
> (they might have created an account before but don't want to login for
> some reason), then the userdb record creation will fail.
> The only solution I can think of to this problem is to skip the userdb
> record creation if the email address is missing or duplicate. However
> I'm not sure whether there might be problems with this approach that I
> haven't spotted.
> Has anyone else done something like this or solved the same problem in a
> different way?
Jamie, you can always do a quick query to check if the address is already in
your db, then if so, run alternate code.
If it is duplicate, maybe it is not the same person? most email addresses are
not "owned". It could very well be someone else at a later date, or someone
placing in a fake email, may link it to a real customer... you know?
If it is blank, you can do something like <order number>@storedomain.com or
I've always been against using email addresses are logins. It can cause
problems especially when to change your username, you must still have access to
that email account, which I have seen happen many times. People change email
addresses but forget about their many accounts at ecommerce stores, Some of
which send a "click to confirm" email to the original email to guard against
Big, frequently used sites can generally get away with it, like amazon. This is
one reason why I always tell friends to buy a domain, and NOT use their ISP
More information about the interchange-users