Slightly off the main topic:
The point about retaining the data from abandoned carts is a very good one.
The idea of per-user discount based on a previous 'almost purchase' makes me
feel a little uncomfortable though.
Perhaps if more than one particular item appeared in (let's say) 10 shoppers
abandoned carts within a 14 day period, you might think about reducing the
price.
If you _do_ like the idea of per-user discount, then please think about
involving more criteria. E.g.
Did the shopper read the full item description (for more than 10 seconds)?
Did the shopper also look at similar items in the same category (looked at
yellow, blue and green 'widgets' - at least you know they definitely want
that 'widget')?
Did the user navigate to your site from a click-through price comparison
site?
I could go on. I'm sure the likes of Amazon have an almost scary amount of
statistical analysis driving their pricing structure and marketing.
-- ___
| |
|--+--
| |.HushFriend (you'll see).
.Stefan Holmes.
> -----Original Message-----
> From: Joe Audette [mailto:[EMAIL PROTECTED]
> Sent: 30 August 2004 15:46
> To: [EMAIL PROTECTED]
> Subject: Re: Business Rule lacking technical process
>
> I think the database is a better place to store a cart for a number of
> reasons. For one thing you can do analysis of shopping behaviour on
> abandoned carts and if a user was logged in while adding items to a cart
> then abandons the cart you can send a discount offer taylored to the items
> he almost bought. If you store this in session data its lost forever. I
> also think in terms of scaling to large numbers of users it is better to
> avoid using session state.
>
> Just another opinion.
>
> Joe
>
> Fagyal Csongor <[EMAIL PROTECTED]> wrote:
> Hi,
>
> >Stuart,
> >
> >(I am trying to continue using the same analogy you started) A "cart" is
> >usually just a table where lots of users accumulate "purchases" until
> they
> >are ready to "buy". That implies 3 basic operations:
> >
> >1) The users can browse through a list of somethings and pick and choose
> >what they would like to have
> >2) As the users add and delete things from their "cart", database changes
> >occur. These changes should NOT affect the actual "inventory" numbers
> >until the "purchase" is complete.
> >All that changes is the "cart" table and it's contents **AS IT RELATES
> >SPECIFICALLY TO THAT USER**. Typically there is only 1 "cart" table per
> >design and a column is used to uniquely identify which user has "shopped"
> >for which items.
> >3) The actual "purchase" of the contents of the "cart" , at least for
> most
> >"merchandise" purchases, WILL involve external systems (generally EMAIL
> >for verification and FINANCIAL for the purchase transaction itself.) and
> >some sort of lock (reservation) on "inventory" so that you can ensure
> that
> >you will be able to deliver what the person is "purchasing". This is all
> >wrapped in a very critical transaction to make sure that if you get their
> >money, they get their "purchase"
> >
> >
> IMHO the cart is something you store in a session, and not in the
> database. You save a lot of programming this way.
> In Apache::ASP (perl) this would be something like (a little
> simplified, no verification, etc.):
>
> if ($form->{'addtocart'}) {
> $Session->{'cart'}->{$form->{'itemid'}} += $form->{'pieces'};
> }
>
> 3 lines and you have a shopping cart. At checkout, you do the DB
> transactions & all.
>
>
> I might have been a little off-topic here, though :-)
>
> - Csongor
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
>
>
>
> [EMAIL PROTECTED]
> http://www.joeaudette.com
> http://www.mojoportal.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
