What ways are there to store information about an anonymous/guest user in a database?

Question

Our application has an online shop among other features, and users are normally requested to register before completing a sale, creating a unique customer_ID in the

Answer 1

Ofcourse you can track the sale session by using cookies. but Also register anonymous users to your site but don't let them realize that they are filling any registration form .Let them follow the sale process and at the end of the sale process generate a unique customer id and email them and also display that notification on the site after they complete their sale and make them login into the site by just entering their customer id.

Answer 2

Mmmm ... we generate a uniq ID for guest users -- a hash-value or uuid for the username and store this one in the basket table. You cold store this also in the customer table, if you don't mind cluttering your database with such data. The uuid is stored in a cookie in the customers browser, until he checks out the basket. The cookie thing is also nice for assigning the anonymous account (and the content of it's basket) to a valid account, if the user decided to register later on / before checking out the basket.

Answer 3

I would create a unique customer ID, and store it on the user's machine as a cookie. This should decrease the number of users with multiple customer IDs.

But in all seriousness, as long as your number of ids isn't getting into the hundreds of thousands (and congrats if it is!), it's not going to hurt your database as long as you have proper indexes on the customer id column.

If you had id=0 for each customer wouldn't you have just as many rows though? I think that's inescapable if you want to keep all the data, right? A zero id might cause your index extra problems too.

Answer 4

I doubt there are any perfect solutions to this problem. You simply have to make a choice: How important is it to guarantee recognizable customer history in contrast to the improvement in conversions you get from not forcing a customer to go through a full registration process.

If you go without forcing registration, you will not be able to recognize returning customers 100% of the time. One might argue that even with registration that will not be possible, as users sometimes choose to create new accounts for various reasons. But you might be able to do something that's "good enough" by understanding the data you already have.

For example, in some countries, postcodes are quite specific. Are they specific enough? Depends in which countries you operate and also how your customer base is built. If you tend to only have one user per household, maybe.

Or depending on which payment methods you support, you might consider building a one-way hash of the credit card number ("pseudo-unique ID"). Some payment solutions actually do return a unique "payer ID", which could be perfect -- assuming that you get something from all the payment services you support.

Answer 5

I usually use the user IP, I create an account with just an ID and his IP address. When he registers, I just update his record. Other things than IP could (and should) be used too, like creating a random token to put in a cookie to bypass any session system in use so you can make it last longer for example.

Now, in the application, you have to make your user class able to "identify" your users with either this IP/token, a real session or any other login system you may have in place.

Answer 6

Assuming you require an e-mail address for all online orders, you could create a temporary account for every customer at the completion of each order when they are not logged in.

This can be done by using the shipping address and other information provided during checkout to fill in the account, and e-mailing a random temporary password to them (optionally flagging it to require changing on the first log-in, if that functionality is built into the website). This requires minimal effort on their part to setup the account, and allows them to sign in to check their order status.

Since the primary key in your database is the customer_id, it should not cause conflicts if they continue making new accounts with the same e-mail/address/etc, unless you have code in place to prevent duplicates already. It's rare for someone to create more than one temporary account though, since it's easier to log in with the password e-mailed to them than entering their data again.

For the backend orders, we generally create an account in the same way as above for every customer. However, if they don't have an e-mail address (or they only want to purchase by phone), we generate an account with their shipping information and a blank e-mail address (have to code an exception to not send temporary passwords/order confirmations when it's blank). The customer_id is given to them, and their shipping information and company name are stored in the account to look up and expedite future orders.