[ic] Discounts and coupon tracking?

Jonathan Clark jonc at webmaint.com
Fri Jun 4 05:30:29 EDT 2004


> >>>   Thoughts on associating and tracking a code with a particular
> >>> item?
> >>>
> >>>   [discount] and [item-discount] will show me the change in values.
> >>> However, I'd like to track a code/value with this and log with
> >>> transactions.  In some basic testing it doesn't appear that session
> >>> will track using an associative array / hash.
> >>>
> >>> Something like ...
> >>>
> >>>   1) user enters coupon number
> >>>   2) lookup number in a coupon table
> >>>   3) if active, apply discount
> >>>   4) store discount code/valuey persistant means
> >>>   5) at checkout verify discounts and log transaction
> >>>
> >
> >> I am attempting do a similar process.  I need to give out coupons
> >> based on previous orders and discounts offered to individual
> >> customers. How can I effectively track the coupon and personalized
> >> amount of the coupon for orders?
> >>
> >> Any recommendations would be appreciated.
> >>
> >
> > I am working on a coupon system at the moment. Here is what it can do
> > so far:
> >
> > Discounts (amount or % off):
> >  All items
> >  Entire order
> >  Single item
> >  Single item, auto add a qty to cart
> >  Shipping (if I can work out levies)
> >
> > Constraints:
> >  Apply only if order/item over $x
> >  Date range
> >  Max uses (allow to be used x times only, then disable)  Apply only
> >  to zzz affiliate. Apply only to specific user.
> >  Disable coupon entirely
>
>
> Hi Jon
>
> I have a system similar to this. I had it built a while back, but
> since have
> become pretty decent with perl, so will be rewriting it myself. I
> rewrote some
> of it a few months ago out of necessity.
>
> One thing I currently rely on is querying 'transactions' for
> checking usage. I
> think I will be making a additional dicount_log table which would
> provide for
> applying/limiting/marketing purposes.

I plan to do all this with the coupon record, and transactions record. There
is already a campaign field in transactions, I will add coupon, salesman. I
don't see why a separate table is needed.

> Another thing I can say is it kinda "feels" like IC is headed for
> default SQL
> db, so don't be afraid at utilizing it's power.

Have been doing for 5 years :-)

> You mentioned ..."Apply to one specific user". I recently needed to apply
> similar discount for 10 customers. This was kinda clumsy, as they were all
> single use. I ended up making 10 coupons for them. When I rewrite
> mine, I think
> I allow a field to insert multiple usernames into. So a TEXT
> field that you can
> insert 50 names into, then check against the discount_log table
> as each user
> uses theirs.
>
> OK, So if Kevin Walsh reads this, I must revise my plan. He
> wouldn't talk to me
> anymore if I placed many id's into a TEXT field. I think I should
> just extend
> discount_log:
>
> discount_id		username		order_number	date_used
> 00230			halleberry		028422		20040316
>
> This would extend you schema to allow one coupon (and its
> definitions) to be
> applied to many people. You could mulipart-key the above (discount_id,
> username) to disallow accidental duplicates.

I have constraint_type and constraint_cond fields. I suppose a constraint
type of username would work here.. but you would not be able to limit to
one-user-one-use. I think separate coupons would still be a better solution,
unless it was 10 people get issued the coupon and told the first 10 orders
any of them placed use up the coupons. (can already do the qty usage)

...

>
> On thing to beware of is this coupon will be applied most probably near
> checkout. You will have to devise a "intuitive and apparent" plan
> to deal with
> those that find a way to continue to shop after they have been to
> your discount
> code app. They could back out and remove items and circumvent
> your "qualifying
> amount". You can just recheck it at checkout once again, but if it is not
> apparent, a user might think you bait & switched them... "Hey the coupon
> disappeared when I actually checked out"...
>
> Maybe when coupon is applied, set a scratch. then in your top
> master template
> have a

I am using the discount features of IC for the limits. I have discount code
snippets which do things like:

'ALL_ITEMS' => 'return $s * 0.9 if $s >= 60; return $s'

The idea is to rely as much as possible on IC's built in features to do this
work, that way there are very few mods required to apply a coupon - once
when you have set up the discount it just lives in the session. You only
need to interact again when you want to alter the coupon record, say to
decrement the qty_remaning or the value.

Same applies to using the Levies system in IC. You can set a levy to work
with a sub or usertag. That means I can have the usertag code look to see if
a coupon is in effect and do its stuff when required - apply a 'Shipping
discount: $x.xx' levy for my shipping coupon. I could also have a coupon
which was a customer credit which would be applied in the same way.

What I can't do at the moment is apply conditions to a specific line in the
cart. Lets say I have an item which is available with multiple options - the
basic item (no options) I make virtually no money on and can't afford to
discount, but some options I can afford the discount. There is no way of me
doing an item discount through the discounts system to cover this. If my
item is 12345 and I set up an item discount, I have access only to quantity
and subtotal. It would be too complex to make a whole lot of other variables
available to the discount sub, but I think the way forward might be to have
a new type of discount:

'CART_ITEM_1' => 'return $s'
'CART_ITEM_2' => 'return $s * 0.9'
etc.

Obviously I would have to recreate this each time the cart changed though.
Maybe a better way would be to allow the discount sub to use or have access
to a modifier in the cart.

'ALL_ITEMS' => 'return $s unless $MODIFIER_my_modifier eq 'foo'; return $s *
0.9'

Once you have access to a modifier all sorts of things are possible.

Of course I could scan the cart and use a levy, but that way I don't get the
nice discounted messages appearing in the cart.

Jonathan.


--
Jonathan Clark
Webmaint.com - Building Clever Websites        http://www.webmaint.com/
Webmaint.net - Business Web Hosting            http://www.webmaint.net/
WireTel      - Internet Connectivity Solutions http://www.wiretel.net/




More information about the interchange-users mailing list