Forum Moderators: buckworks
this time i want to write the cart to a db as the customer goes along instead of just at checkout time.
my reasoning is that this way i can get an insight into those carts that never made it to checkout ... i'd use a cookie to hold the unique cart id for the customer
the volume won't be high, possibly 20/30 checkouts a day max, and an unknown number of non checkouts,
any thoughts on this? ... seems a god way to pick up some stats, with the bonus that i have several sites that can all use the same db but only one ssl certificate, so all transactions have to be made on the 'master' checkout area, which being able to connect to the db makes it easy.
previously i was using session variables for the cart.
I read somewhere that 9 out of 10 shopping carts are abandoned. I put some code in our site to check it and it seems to be about right - so you'd probably have 200 database entries per day. This wouldn't be a problem at all with a good database, but if you're using Access you might want to think about upgrading.
At current i use the session id as a reference in the db, but without a method to check if the session is still alive i do not know whether its safe to delete the item or not....
am just about to upgrade to sql server so that shouldn't be a problem,
any other problems that may come up?
was wondering if there was going to be an appreciable loss of speed,
reading from and writing to a db instead of just reading cookies or session varibles
as for deleting entries, i was hoping (space permitting) to keep the entries for 14 days (the date being updated if the user revisits) and then deleting or actually importing to local machine for later analysis but deetig from the server for space reasons.
Also you'll be able to keep the files for longer than 14 days as long as you're not silly with data types etc.
Thinking of doing this myself actually, and we already store tracking data for every user (3,000 a day) whenever they hit certain pages in a SQL Server database - so really, you won't have to worry about whether the system can handle it.
Only problem would be that your one secure site won't be able to read the cookies from the other domains. Perhaps you've thought of that though.
(in case you haven't, the solution is to have an intermediary page which writes the cookie data to a form and autosubmits that to the checkout)
yes had realised the transfering cookies issue, but hadn't yet pondered the workaround - and that looks like a sensible solution.
Speedwise, for the amount you're speaking of don't worry. A MySQL or SQL server on a modest box will handle that load quite fine.
We create reports that detail how popular products are:
Total Qty sold
Number of Orders product spans (how many orders does the product appear in)
Total Dollar Value
We also break down Product Popularity and Ordering Popularity between products and regions (country/state/province) as well as comparison breakdowns.
Very useful for clients, especially in their marketing efforts. Example:
Client does offline radio ads to 5 cities.
In reviewing the reporting he notices that city 1's sales were only $3000, city 2 was $15,000, city 3 was $500, city 4 was $12,500 and city 5 was $0.
Using this reporting, he'll be able to more efficiently target his advertising for next week/month/year.
Also, he has the ability to cross-refernce products to cities.
Its all about the reporting. Sure it's expensive to develop but when they can now look at the DATA and determine areas in which are a waste of money? The money they save more than pays for the cost of the Reporting.
Another reason why I save everything I can do Databses.
Aaron
