How to manage customer data w/ creating password accounts

So I’m working on an ecommerce website and I’m struggling with how to handle customer data. I know that I don’t want to require the customer to register. But that leads to a conundrum. I want to store data on them and get reports about repeat customers, but I can’t force them to use the same information without creating an account. For example, the obvious key for a customer is an e-mail address. But how do I handle a customer that comes back? I see a few possibilities:

(1) Show them what I have stored and ask them to verify. This is obviously a huge security issue as anyone can access anyone’s information by entering an e-mail.

(2) Update the information stored with the associated e-mail address based on the new order. This presents problems because it changes the information associated with past orders, and since I am not verifying their e-mail address anyone can overwrite their information.

(3) Create a customer profile per order and then aggregate them for reporting purposes. This seems like the best option, but it’s unappealingly messy.

(4) Get rid of the customer concept and simply have orders with stored customer information. Not a bad solution, but it’s cleaner to have a separate customer object within my code.

(5) Store many profiles associated with a single e-mail address, and then store a record indicator in the order. Something like customer_record = 3, meaning that it’s the 3rd profile associated with that e-mail.

Any ideas?

We have a site like this and the whole thing is messy. We’re doing basically #3…customer data does go right in the order’s details and doesn’t change if the overall customer data changes.

Everything is keyed off the customer’s email address so when they come back for another order, they put in their email address and we pre-fill a form with all of their existing info (there is a customers database - we do not get customer info from previous orders). They can update the data when they check out, and the new data goes to the customer database and to the order.

Since we do it this way, in the back end we can have customer lists with associated orders.

Although it’s super messy, I still can’t think of a better way to do it. I’m no database expert so the thought of email as a key just blows my mind. I try not to think about it and just make it work how they want.

Our site is just for requesting quotes, nothing to do with actual money changing hands. I wouldn’t trust a system like this for actual monetary transactions.

I (heart) web sites that give me the option to register or continue as a guest. You’ll pull reliable customer-related information from those that choose to register (and therefore are expressing an interest in repeat visits), and reliable product-related information based on sales, pageviews and conversions.

You could also jump through the hoops of combining browser/computer configurations (ex. here) with email address and cookies to get mostly, but not completely, reliable stats on visitors.

In all this, are you sure have a cohort of *customers * that are likely to use disposable email addresses such that anyone can place an order overriding the other customer’s information? Is tracking them and acting on their ostensibly expressed preferences worth the investment in figuring out how to quietly track them?

I agree with this x10.
And for the love of Og if you’re using SQL check for injection. Hell, check for it anyway.

What’s wrong with it?

One option is to allow people to sign in with a Facebook, Twitter or WordPress.com account. That doesn’t require them to manage yet another user account and password, assuming they already have one on one of those sites.

The disadvantage is that you probably have to integrate multiple authentication types, and still need a way to deal with customers who don’t have or won’t use one of those accounts.

(Disclosure: I work for the company that runs WordPress.com)