Rob,
I think Store is an essential field that needs to be kept in the data
model, between postcode, and product, even though
it adds complexity. Here's why.
> Currently I think it makes it a lot simpler if we just simplify it down
> to 1 brand price per postcode and assume that the data will balance this
> out.
When I use (and others pls add how you would image using the system)
Price check, I want to know
which store in my local area:
a. gives the best prices
b. has some specials that I am interested in
so i can decide where i want to shop this week.
I am less interested in whether Sydney prices are different from
Melbourne, or that Apples are cheap in Brisbane, when I live in
Melbourne.
I want to know in Prahran, where I shop at Safeway, with a Coles next
door, that if I shopped at Coles, the
basket price for my shopping list would be $Z more expensive (X% more
expensive),
but if particular items are cheaper at Coles - say 2L fruit juice
$1.50 off, if there are enough specials,
I will shop for some things at the Coles store, and other things at
the Safeway store.
> Can you find any specific examples that suggest this won't work?
1.For instance, I buy UHT 200ml milk. Coles Prahran sell them in a six
pack at $2.50 (Saving over 20%), but
Safeway only sell the 150ml singly at $0.66. Over time this could add
up. If there is a product where
there is some funny business going on with pricing (game playing - eg
low price one week, most weeks high price)
then price_check should highlight this.
Eg look at the items on your shopping list, or normal purchases, and
show a specials report
which shows items with unusual percentage variation, from the normal
(average) price.
2.Last week for instance, 5L Olive Oil Moro?? was at $30, instead of
the usual $42 (saving 29%).
But if to justify this special, they put other prices up, to offset
then we want to sense this and flag this in Price_check.
3. Sirena Tuna 150g, usually 2.25. Last week four for $7 - saving $2
(22%).
Seeing the data by store identifies particularly good specials that
are temporary (loss leaders), which are used
to keep good customer relations.(This might be tricky to fit into the
data model??)
At the end of the day, data storage is cheap, and an extra field might
be difficult to add later.
However, you could roll the store data up easily to postcode, to still
provide the postcode functionality.
I think we need to be very careful with averages, and record as much
detail as possible - store, product, brand, size, minimum purchase.
Well maybe not the last. We can roll up to postcode level, but I want
to see at store level.
However, what does everyone else think? How would you all envisage
using the system.
Cheers
Richard in Melbourne